bug#4030: forward-sexp parses character literal ?; as comment

[era+emacsbugs@iki.fi]

On Wed, 05 Aug 2009 16:29 +0200, "martin rudalics" <rudalics@gmx.at>
wrote:
>  > While the workaround is good (and documented in the Ubuntu bug as well),
>  > the ability of Customize depends on this code working correctly, and it
>  > should handle any nominally well-formed .emacs file.  Perhaps there are
>  > other pieces of code which rely on forward-sexp et alii for Emacs Lisp
>  > parsing as well.
> 
> Using a backslash _is_ the canonical way for handling this problem.  If
> some part of Emacs puts such a semicolon into an Elisp buffer without
> escaping it, then that part of Emacs is wrong and has to be fixed.  If
> you manually insert such a construct, then you are on your own (just as
> when within a string you put a left paren in column zero). 

Is this an authoritative statement from the Emacs maintainers (in which
case this bug should be closed as Invalid or Wontfix or whatever)?

>  > It appears that src/syntax.c could perhaps be adapted to take into
>  > account character literals as well as quoted strings, but I am not
>  > familiar enough with Emacs internals to tell whether this is really a
>  > feasible approach.
> 
> Let's say we give `?' character quote syntax in Elisp.  I suppose this
> could be done.  But someone would have to rewrite the corresponding
> parts of the parsing code.  I'm afraid there's hardly anyone around to
> volunteer.  (And think of an `?' escaping a subsequent backslash.)

Like I wrote, I'm not a good C programmer and not at all familiar with
the C internals of Emacs.  If you (the collective you) think this is not
feasible -- as opposed to there's nobody around to actually do it --
then that's another reason to close this bug.  I'm thinking it should
not be all that much harder than coping with quoted strings, which are
already (mostly) properly handled, but the actual code is idiosyncratic
and somewhat complex, so this is just a hunch of mine.