forward-sexp parses character literal ?; as comment

I'm afraid I don't see how to reproduce this with emacs22. What do you see and what did you do when you started Emacs in order to see this?

More to the point, if you can reproduce this every time you run Emacs, do you think you could do the following, please? Run Emacs with the following:

bash$ emacs --eval '(setq debug-on-error t)'

... and then do whatever you do in order to get the error message. The contents of the resulting *Backtrace* buffer show which function was invoked and how; save that to a temporary file, and attach that file here. Thanks in advance.

I'm marking this bug as "Incomplete" to mark that we are waiting for clarifications from the person who reported the bug, but of course, anybody else who is able to supply the missing information is free to do so, and revert the Status back to "New".

The problem does not occur when emacs is opened without a file, nor
when it is called from the command line, in these cases, it just comes
up with a single buffer shown (*Scratch* or the file).

It does occur whenever I click on a file whose type is bound to emacs,
or select "open with > emacs22 (X11)" in konqueror, or if I drag the
file onto the emacs icon on the KDE panel. In these cases, emacs
starts with a split screen, the file in the upper half, and a welcome
page in the buffer *GNU emacs* in the lower half.

By eval'ing '(setq debug-on-error t)' in the scratch buffer, I did get
the backtrace:

Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 6391 9919)
  scan-sexps(103 9918)
  forward-sexp(9918)
  custom-save-delete(custom-set-variables)
  custom-save-variables()
  custom-save-all()
  (progn (customize-set-variable (quote inhibit-startup-screen) t)
(customize-mark-to-save (quote inhibit-startup-screen))
(custom-save-all))
  (if startup-screen-inhibit-startup-screen (progn
(customize-set-variable ... t) (customize-mark-to-save ...)
(custom-save-all)))
  (when startup-screen-inhibit-startup-screen (customize-set-variable
(quote inhibit-startup-screen) t) (customize-mark-to-save (quote
inhibit-startup-screen)) (custom-save-all))
  (lambda (button) (when startup-screen-inhibit-startup-screen
(customize-set-variable ... t) (customize-mark-to-save ...)
(custom-save-all)) (let (...) (and w ... ...)) (kill-buffer "*GNU
Emacs*"))(#<overlay from 737 to 764 in *GNU Emacs*>)
  push-button(752 t)
  push-button((mouse-2 (#<window 7 on *Backtrace*> 752 (108 . 287)
563149 nil 752 (15 . 16) nil (4 . 7) (9 . 18))))
  call-interactively(push-button)

Thanks for the repro steps. I still do not get the error message, but I do see the "Dismiss this startup screen [ ] Never show it again." text at the end of the *GNU Emacs* buffer. (For testing, I picked the application/zip attachment from http://sprott.physics.wisc.edu/viewtest.htm and selected "Open with > /usr/bin/emacs" in the Download dialog in Firefox.)

Is this somehow specific to KDE? Does it matter whether you use the keyboard or the mouse to select the "Dismiss this startup screen" link? Do you have anything in your .emacs file which could be causing this? (Can you create a shell script which runs emacs -q, and select that as the application to open the file with? That would cause it to not read your .emacs file.)

#!/bin/sh
exec /usr/bin/emacs -q "$@"

In fact, the error message sort of suggests that you might have an error in your .emacs file. If it doesn't contain anything sensitive, do you think you could attach it here?

Note that the initialization file could have a different location, depending on your setup etc. In emacs22 the file can also be ~/.emacs.d/init.el; see http://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html for the full scoop.

Leaving this bug report as "Status: Incomplete" still.

On 02/08/2009, era <email address hidden> wrote:

> Is this somehow specific to KDE? Does it matter whether you use the
> keyboard or the mouse to select the "Dismiss this startup screen" link?
> Do you have anything in your .emacs file which could be causing this?
> (Can you create a shell script which runs emacs -q, and select that as
> the application to open the file with? That would cause it to not read
> your .emacs file.)
>
> #!/bin/sh
> exec /usr/bin/emacs -q "$@"

I've only tried the mouse, and I've not used anything other than KDE.
When I use the script, then there is only the "dismiss this startup
screen" but no "never show it again" button.

> In fact, the error message sort of suggests that you might have an error
> in your .emacs file. If it doesn't contain anything sensitive, do you
> think you could attach it here?

Done.
From the date stamp on it (July 04) I think it may well be the default
.emacs from Debian Sarge (which had emacs 21.4.1).

With this .emacs file I am able to reproduce the error. The error message implicates the tex-mode-hook stanza which begins on line 195 of the .emacs file. Apparently forward-sexp cannot cope with the character literal for a literal semicolon character, which I think is a bug if Emacs doesn't otherwise choke on it. Changing the line

                        (modify-syntax-entry ?; "w")

to

                        (modify-syntax-entry ?\; "w")

allows forward-sexp to parse the sexp correctly.

I don't think Debian ever shipped with a default .emacs file but I could be wrong.

I can confirm that inserting the backslash before the semicolon as
suggested works for me.

Successfully reproduced the forward-sexp error with a recent emacs-snapshot (20090730-1~intrepid1 corresponding to GNU Emacs 23.1.50.1; to my best understanding more or less an official Emacs 23)

I have now reported this bug upstream. http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4030

Upstream seems to be leaning towards "character literals really should have a backslash if they contain tricky characters" but has not (yet?) closed the bug as invalid / wontfix.

FWIW the Bug Watch Updater has incorrectly marked the upstream bug as Fix Released. This seems to be a recurring problem with Emacs bugs; see LP bug #343469

Upstream is now (finally!) closed as Wontfix, but the rationale is that other code paths have been updated to provide a useful warning (if I am reading this correctly). Updating Package: from emacs22 (sic) to emacs25 and setting status to Fix committed.