bug#54131: 29.0.50; Flyspell incorrectly reports first word in Python f-string

[Eli Zaretskii]

> Resent-From: Philipp Stephani <p.stephani2@gmail.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 23 Feb 2022 21:27:04 +0100
> Cc: 54131@debbugs.gnu.org
> 
> Am Mi., 23. Feb. 2022 um 21:13 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> >
> > Philipp Stephani <p.stephani2@gmail.com> writes:
> >
> > > Given this Python file:
> > >
> > > $ cat /tmp/a.py
> > > print(f'hello world')
> > >
> > > Visit it and enable Flyspell:
> > >
> > > $ emacs -Q /tmp/a.py -f flyspell-prog-mode
> > >
> > > Flyspell then marks the string "f'hello" as incorrect, thinking it's a
> > > misspelling of "hello".  But it shouldn't cross the string boundary.
> >
> > Hm, yes.  In this case, the mode knows that f isn't part of the
> > expression, but I guess we have no way of communicating that to ispell?
> >
> > Skimming ispell-get-word, it looks like it uses a regexp to determine
> > what the word at point is, so we'd need to make some sort of framework
> > to allow modes to say where a string begins and ends?
> 
> Like the syntax table? (nth 8 (syntax-ppss)) gives you the beginning
> of the string, and that seems to give correct results even for
> f-strings.

That's not how flyspell-prog-mode works, see my other message.  I
guess it doesn't want to run syntax analysis functions on the fly, as
that could be too slow (flyspell being on post-command-hook), but
instead relies on font lock that is run by the display engine anyway.