From era+emacsbugs@iki.fi Tue Aug 4 05:07:27 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 4 Aug 2009 12:07:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.0 required=4.0 tests=HAS_PACKAGE autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74C7NDA000571 for ; Tue, 4 Aug 2009 05:07:24 -0700 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 84CB03BDFFB for ; Tue, 4 Aug 2009 08:07:22 -0400 (EDT) Received: from web7.messagingengine.com ([10.202.2.216]) by compute1.internal (MEProxy); Tue, 04 Aug 2009 08:07:23 -0400 Received: by web7.messagingengine.com (Postfix, from userid 99) id 3BAE7DCE9; Tue, 4 Aug 2009 08:07:22 -0400 (EDT) Message-Id: <1249387642.18128.1328220453@webmail.messagingengine.com> X-Sasl-Enc: As1WZBomo/VHmoilSfMxSNKZpCs+RSjelWWwKpNx/gbI 1249387642 From: era+emacsbugs@iki.fi To: submit@debbugs.gnu.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Subject: forward-sexp parses character literal ?; as comment Date: Tue, 04 Aug 2009 15:07:22 +0300 Package: emacs Version: 23.1.50.1 Severity: normal X-Debbugs-Cc: era+emacsbugs@iki.fi This is a pared-down version of Ubuntu bug report #405498 https://bugs.launchpad.net/bugs/405498 -- please see the URL for the full bug report. It seems that forward-sexp (and its underlying C implementation) does not cope correctly with a character literal semicolon, seeing instead (effectively) end of line. In the *scratch* buffer if you write (insert ?;) you can evaluate this Lisp code and it behaves as intended (inserts a semicolon in the current buffer) but doing M-x forward-sexp just before the expression results in an "Unbalanced parentheses" error. This causes problems e.g. when Customize wants to edit an .emacs file which contains the character constant ?; anywhere in it, because Customize uses forward-sexp to parse the user's .emacs file. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. From rudalics@gmx.at Tue Aug 4 05:43:59 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 4 Aug 2009 12:43:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n74ChqfV003609 for ; Tue, 4 Aug 2009 05:43:54 -0700 Received: (qmail invoked by alias); 04 Aug 2009 12:43:46 -0000 Received: from 62-47-34-20.adsl.highway.telekom.at (EHLO [62.47.34.20]) [62.47.34.20] by mail.gmx.net (mp010) with SMTP; 04 Aug 2009 14:43:46 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18D9dVGSXIDiRKAwAs0Q7dcVR/kod+rp55LmG7EGh orh+OJxZM/CAZd Message-ID: <4A782D00.4040808@gmx.at> Date: Tue, 04 Aug 2009 14:43:44 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: era+emacsbugs@iki.fi, 4030@debbugs.gnu.org CC: submit@debbugs.gnu.org Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> In-Reply-To: <1249387642.18128.1328220453@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-CrossAssassin-Score: 2 > It seems that forward-sexp (and its underlying C implementation) does > not cope correctly with a character literal semicolon, seeing instead > (effectively) end of line. > > In the *scratch* buffer if you write (insert ?;) you can evaluate this > Lisp code and it behaves as intended (inserts a semicolon in the current > buffer) but doing M-x forward-sexp just before the expression results in > an "Unbalanced parentheses" error. A similar thing happens with (insert ?") so why don't you escape such a character by writing (insert ?\;) instead? From the Elisp manual: You can use the same syntax for punctuation characters, but it is often a good idea to add a `\' so that the Emacs commands for editing Lisp code don't get confused. For example, `?\(' is the way to write the open-paren character. If the character is `\', you _must_ use a second `\' to quote it: `?\\'. martin From era+emacsbugs@iki.fi Wed Aug 5 01:17:55 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 5 Aug 2009 08:17:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n758Hogx014748 for <4030@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 01:17:52 -0700 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5D8D13BC399; Wed, 5 Aug 2009 04:17:50 -0400 (EDT) Received: from web7.messagingengine.com ([10.202.2.216]) by compute1.internal (MEProxy); Wed, 05 Aug 2009 04:17:50 -0400 Received: by web7.messagingengine.com (Postfix, from userid 99) id 3F8A754E88; Wed, 5 Aug 2009 04:17:50 -0400 (EDT) Message-Id: <1249460270.18460.1328376993@webmail.messagingengine.com> X-Sasl-Enc: TJwJQU7/5uZH/8CYpVv2igA7N3K2WG9ULY77CI7QmxGZ 1249460270 From: era+emacsbugs@iki.fi To: "martin rudalics" , 4030@debbugs.gnu.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment In-Reply-To: <4A782D00.4040808@gmx.at> Date: Wed, 05 Aug 2009 11:17:50 +0300 On Tue, 04 Aug 2009 14:43 +0200, "martin rudalics" wrote: > > It seems that forward-sexp (and its underlying C implementation) does > > not cope correctly with a character literal semicolon, seeing instead > > (effectively) end of line. > > > > In the *scratch* buffer if you write (insert ?;) you can evaluate this > > Lisp code and it behaves as intended (inserts a semicolon in the current > > buffer) but doing M-x forward-sexp just before the expression results in > > an "Unbalanced parentheses" error. > > A similar thing happens with (insert ?") so why don't you escape such a > character by writing (insert ?\;) instead? 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. I'll also point out that an "Unbalanced parentheses" error from deep inside Customize is not a very helpful error message (especially as it does not indicate in which buffer the unbalanced parentheses were found); but perhaps Customize should be adapted to cope if forward-sexp cannot easily be fixed. 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. From rudalics@gmx.at Wed Aug 5 07:30:46 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 5 Aug 2009 14:30:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n75EUeQi017255 for <4030@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 07:30:42 -0700 Received: (qmail invoked by alias); 05 Aug 2009 14:30:35 -0000 Received: from 62-47-55-223.adsl.highway.telekom.at (EHLO [62.47.55.223]) [62.47.55.223] by mail.gmx.net (mp070) with SMTP; 05 Aug 2009 16:30:35 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18laUMnJmElGRXcElD8saxx+tzYfRyk0YqdQ9xzLF E7uRe4LEyvj8FU Message-ID: <4A799766.9050304@gmx.at> Date: Wed, 05 Aug 2009 16:29:58 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: era+emacsbugs@iki.fi CC: 4030@debbugs.gnu.org Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> In-Reply-To: <1249460270.18460.1328376993@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 > 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). We could try to mark any `?;' or `?"' sequences appropriately when fontifying though. > I'll also point out that an "Unbalanced parentheses" error from deep > inside Customize is not a very helpful error message (especially as it > does not indicate in which buffer the unbalanced parentheses were > found); but perhaps Customize should be adapted to cope if forward-sexp > cannot easily be fixed. Getting good diagnostics after a parsing error is hard. > 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.) martin From era+emacsbugs@iki.fi Thu Aug 6 01:55:49 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 6 Aug 2009 08:55:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n768tl7F025743 for <4030@emacsbugs.donarmstrong.com>; Thu, 6 Aug 2009 01:55:49 -0700 Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 34B254EA; Thu, 6 Aug 2009 04:55:47 -0400 (EDT) Received: from web7.messagingengine.com ([10.202.2.216]) by compute1.internal (MEProxy); Thu, 06 Aug 2009 04:55:47 -0400 Received: by web7.messagingengine.com (Postfix, from userid 99) id 0FD6C17039; Thu, 6 Aug 2009 04:55:47 -0400 (EDT) Message-Id: <1249548947.6570.1328564497@webmail.messagingengine.com> X-Sasl-Enc: MSK3H6AymqMAiMy5pQiGSd60me0BWlbVsj+MyAhOiKIR 1249548947 From: era+emacsbugs@iki.fi To: "martin rudalics" , 4030@debbugs.gnu.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <4A799766.9050304@gmx.at> References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment Date: Thu, 06 Aug 2009 11:55:47 +0300 On Wed, 05 Aug 2009 16:29 +0200, "martin rudalics" 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. From monnier@iro.umontreal.ca Thu Aug 6 11:51:27 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 6 Aug 2009 18:51:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n76IpQdX017541 for <4030@emacsbugs.donarmstrong.com>; Thu, 6 Aug 2009 11:51:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAGvDekpFxL8W/2dsb2JhbACBUL9bCI9wgkQIgUwFhzQ X-IronPort-AV: E=Sophos;i="4.43,335,1246852800"; d="scan'208";a="43113688" Received: from 69-196-191-22.dsl.teksavvy.com (HELO ceviche.home) ([69.196.191.22]) by ironport2-out.teksavvy.com with ESMTP; 06 Aug 2009 14:51:20 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 87CAEB40CD; Thu, 6 Aug 2009 14:51:20 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 4030@debbugs.gnu.org, era+emacsbugs@iki.fi Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment Message-ID: References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> Date: Thu, 06 Aug 2009 14:51:20 -0400 In-Reply-To: <4A799766.9050304@gmx.at> (martin rudalics's message of "Wed, 05 Aug 2009 16:29:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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. Indeed. > 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). Pretty much, yes. > We could try to mark any `?;' or `?"' sequences appropriately when > fontifying though. We could/should/will improve the syntax parsing to handle those things properly. But it's a non-trivial amount of work, especially since every major mode has similar issues but needs different extra functionality. >> I'll also point out that an "Unbalanced parentheses" error from deep >> inside Customize is not a very helpful error message (especially as it >> does not indicate in which buffer the unbalanced parentheses were >> found); but perhaps Customize should be adapted to cope if forward-sexp >> cannot easily be fixed. > Getting good diagnostics after a parsing error is hard. Agreed, but that doesn't mean we shouldn't intend to do better: the current behavior (signalling an internal error to the user) is a bug that needs to be fixed. >> 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. Yes, clearly it deserves improvement, but that's nontrivial. Stefan From rudalics@gmx.at Fri Aug 7 06:01:42 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 7 Aug 2009 13:01:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n77D1ekQ019380 for <4030@emacsbugs.donarmstrong.com>; Fri, 7 Aug 2009 06:01:41 -0700 Received: (qmail invoked by alias); 07 Aug 2009 13:01:30 -0000 Received: from 62-47-54-134.adsl.highway.telekom.at (EHLO [62.47.54.134]) [62.47.54.134] by mail.gmx.net (mp071) with SMTP; 07 Aug 2009 15:01:30 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX191DCRdEaF14PiPEtFkylVyy0yG2tH1AGn4ip38+L 6z0rc/urXeB7m8 Message-ID: <4A7C25A7.6000900@gmx.at> Date: Fri, 07 Aug 2009 15:01:27 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: 4030@debbugs.gnu.org, era+emacsbugs@iki.fi Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 >> We could try to mark any `?;' or `?"' sequences appropriately when >> fontifying though. > > We could/should/will improve the syntax parsing to handle those > things properly. But it's a non-trivial amount of work, especially > since every major mode has similar issues but needs different > extra functionality. But fontification is mode-specific. So it would be sufficient to look for ?s that are not within strings or comments and followed by a semicolon, paren or double-quote and mark that appropriately (obviously the parser is derailed at that time but it still might help people spot the bug). >>> I'll also point out that an "Unbalanced parentheses" error from deep >>> inside Customize is not a very helpful error message (especially as it >>> does not indicate in which buffer the unbalanced parentheses were >>> found); but perhaps Customize should be adapted to cope if forward-sexp >>> cannot easily be fixed. >> Getting good diagnostics after a parsing error is hard. > > Agreed, but that doesn't mean we shouldn't intend to do better: the > current behavior (signalling an internal error to the user) is a bug > that needs to be fixed. If the problem comes from the unprotected (save-excursion (forward-sexp (buffer-size)))) ; Test for scan errors. call in `custom-save-delete' we could simply wrap it as in the patch below. But do we really have to scan the buffer in the first place? martin *** cus-edit.el.~1.364.~ 2009-07-27 08:09:05.997162900 +0200 --- cus-edit.el 2009-08-07 14:49:22.890625000 +0200 *************** *** 4341,4347 **** ;; Skip all whitespace and comments. (while (forward-comment 1)) (or (eobp) ! (save-excursion (forward-sexp (buffer-size)))) ; Test for scan errors. (let (first) (catch 'found (while t ;; We exit this loop only via throw. --- 4341,4349 ---- ;; Skip all whitespace and comments. (while (forward-comment 1)) (or (eobp) ! (condition-case nil ! (save-excursion (forward-sexp (buffer-size))) ; Test for scan errors. ! (scan-error (error "Scan error, watch out for ... ")))) (let (first) (catch 'found (while t ;; We exit this loop only via throw. From monnier@iro.umontreal.ca Mon Aug 10 12:59:53 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 10 Aug 2009 19:59:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7AJxpPh024897 for <4030@emacsbugs.donarmstrong.com>; Mon, 10 Aug 2009 12:59:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAB8ZgEpFxL8W/2dsb2JhbACBUtA+hBgFhzg X-IronPort-AV: E=Sophos;i="4.43,355,1246852800"; d="scan'208";a="43260002" Received: from 69-196-191-22.dsl.teksavvy.com (HELO pastel.home) ([69.196.191.22]) by ironport2-out.teksavvy.com with ESMTP; 10 Aug 2009 15:59:30 -0400 Received: by pastel.home (Postfix, from userid 20848) id 7DA138370; Mon, 10 Aug 2009 15:59:39 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 4030@debbugs.gnu.org, era+emacsbugs@iki.fi Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment Message-ID: References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> <4A7C25A7.6000900@gmx.at> Date: Mon, 10 Aug 2009 15:59:39 -0400 In-Reply-To: <4A7C25A7.6000900@gmx.at> (martin rudalics's message of "Fri, 07 Aug 2009 15:01:27 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> We could try to mark any `?;' or `?"' sequences appropriately when >>> fontifying though. >> We could/should/will improve the syntax parsing to handle those >> things properly. But it's a non-trivial amount of work, especially >> since every major mode has similar issues but needs different >> extra functionality. > But fontification is mode-specific. So it would be sufficient to look > for ?s that are not within strings or comments and followed by a > semicolon, paren or double-quote and mark that appropriately (obviously > the parser is derailed at that time but it still might help people spot > the bug). Yes, but we need to do that even on chunks of code that have not yet been (and may never be) displayed and in buffers where font-lock is disabled. IOW I'm not talking about fontification but about parsing. >>>> I'll also point out that an "Unbalanced parentheses" error from deep >>>> inside Customize is not a very helpful error message (especially as it >>>> does not indicate in which buffer the unbalanced parentheses were >>>> found); but perhaps Customize should be adapted to cope if forward-sexp >>>> cannot easily be fixed. >>> Getting good diagnostics after a parsing error is hard. >> >> Agreed, but that doesn't mean we shouldn't intend to do better: the >> current behavior (signalling an internal error to the user) is a bug >> that needs to be fixed. > If the problem comes from the unprotected > (save-excursion (forward-sexp (buffer-size)))) ; Test for scan errors. > call in `custom-save-delete' we could simply wrap it as in the patch > below. Pretty much, yes, tho the error message should give more info (the OP complained about lack of info in the error message). > But do we really have to scan the buffer in the first place? Don't know. Maybe not, indeed. Maybe it's just to detect the "too many closing parens" case as well (i.e. rather than silently ignore trailing code). Stefan From rudalics@gmx.at Tue Aug 11 02:19:55 2009 Received: (at 4030) by emacsbugs.donarmstrong.com; 11 Aug 2009 09:19:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MIXEDBDN,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n7B9JrAP010897 for <4030@emacsbugs.donarmstrong.com>; Tue, 11 Aug 2009 02:19:55 -0700 Received: (qmail invoked by alias); 11 Aug 2009 09:19:47 -0000 Received: from 62-47-35-215.adsl.highway.telekom.at (EHLO [62.47.35.215]) [62.47.35.215] by mail.gmx.net (mp032) with SMTP; 11 Aug 2009 11:19:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+uj/52bv2u6/zxIb2VSCuh7id0mCKgQN02K6BkbX nSuYmA3MRWoOPW Message-ID: <4A813736.8030403@gmx.at> Date: Tue, 11 Aug 2009 11:17:42 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: 4030@debbugs.gnu.org, era+emacsbugs@iki.fi Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> <4A7C25A7.6000900@gmx.at> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020208070503030001080608" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67,0.5600000000000001 This is a multi-part message in MIME format. --------------020208070503030001080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Yes, but we need to do that even on chunks of code that have not yet > been (and may never be) displayed and in buffers where font-lock > is disabled. IOW I'm not talking about fontification but about parsing. Sure. But I was only talking about the possibility to highlight such instances just like we do with column 0 parens in strings already. > Pretty much, yes, tho the error message should give more info (the OP > complained about lack of info in the error message). That's what the ellipsis stands for. But what info? Guessing a good buffer position seems next to impossible. Where else can `forward-sexp' go astray when called from a top-level position? >> But do we really have to scan the buffer in the first place? > > Don't know. Maybe not, indeed. Maybe it's just to detect the "too many > closing parens" case as well (i.e. rather than silently ignore trailing > code). We could simply search for (concat "^(" (symbol-name symbol))) and do a `forward-sexp' over the form starting there as in the attached patch. I see no reason why we should try to handle an .emacs broken before or after that form. martin --------------020208070503030001080608 Content-Type: text/plain; name="cus-edit.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cus-edit.el.diff" *** cus-edit.el.~1.364.~ 2009-07-27 08:09:05.997162900 +0200 --- cus-edit.el 2009-08-11 10:51:21.812500000 +0200 *************** *** 4338,4374 **** This function does not save the buffer." (goto-char (point-min)) ! ;; Skip all whitespace and comments. ! (while (forward-comment 1)) ! (or (eobp) ! (save-excursion (forward-sexp (buffer-size)))) ; Test for scan errors. ! (let (first) ! (catch 'found ! (while t ;; We exit this loop only via throw. ! ;; Skip all whitespace and comments. ! (while (forward-comment 1)) ! (let ((start (point)) ! (sexp (condition-case nil ! (read (current-buffer)) ! (end-of-file (throw 'found nil))))) ! (when (and (listp sexp) ! (eq (car sexp) symbol)) ! (delete-region start (point)) ! (unless first ! (setq first (point))))))) ! (if first ! (goto-char first) ! ;; Move in front of local variables, otherwise long Custom ! ;; entries would make them ineffective. ! (let ((pos (point-max)) ! (case-fold-search t)) ! (save-excursion ! (goto-char (point-max)) ! (search-backward "\n\^L" (max (- (point-max) 3000) (point-min)) ! 'move) ! (when (search-forward "Local Variables:" nil t) ! (setq pos (line-beginning-position)))) ! (goto-char pos))))) (defun custom-save-variables () "Save all customized variables in `custom-file'." --- 4338,4364 ---- This function does not save the buffer." (goto-char (point-min)) ! (if (re-search-forward (concat "^(" (symbol-name symbol))) ! (let ((from (goto-char (match-beginning 0))) ! (to (condition-case nil ! (progn ! (forward-sexp) ! (point)) ! (error nil)))) ! (if to ! (delete-region from to) ! (error "Malformed %s expression" symbol))) ! ;; Move in front of local variables, otherwise long Custom ! ;; entries would make them ineffective. ! (let ((pos (point-max)) ! (case-fold-search t)) ! (save-excursion ! (goto-char (point-max)) ! (search-backward "\n\^L" (max (- (point-max) 3000) (point-min)) ! 'move) ! (when (search-forward "Local Variables:" nil t) ! (setq pos (line-beginning-position)))) ! (goto-char pos)))) (defun custom-save-variables () "Save all customized variables in `custom-file'." --------------020208070503030001080608-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 17 23:47:18 2016 Received: (at 4030) by debbugs.gnu.org; 18 Jun 2016 03:47:18 +0000 Received: from localhost ([127.0.0.1]:44660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bE7E6-00024E-66 for submit@debbugs.gnu.org; Fri, 17 Jun 2016 23:47:18 -0400 Received: from mail-qk0-f174.google.com ([209.85.220.174]:34542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bE7E4-000242-My for 4030@debbugs.gnu.org; Fri, 17 Jun 2016 23:47:17 -0400 Received: by mail-qk0-f174.google.com with SMTP id s186so105491635qkc.1 for <4030@debbugs.gnu.org>; Fri, 17 Jun 2016 20:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=V5y0fs8CZQXRNcVXNGajFAWk4VHzW6WXs9vPwnwB5ts=; b=kI75pwry9/KdS5fdfk9FuAyXf7oEI5sLZSEp0HMX65zkXmRnPX6Kfi5YEsDNM6Szvv uU1M2iZQVKXkXqXMvDNFhqh7FoR95hSm+V2RH1QlGaQAdF1XKDKOirivoMqKWxMK+F/z Ad4ScDNrNLSQSiHpa/pLLqgWBKedhLOZ3+5Y7U8YOaAftgdTXabhFfMsLP0zQJLOA7UK OBHs+5fOigfO7tp6JjtucJnBwB2/gHX10C/EmW5aftRK6YmgoVSBt7EAjq/0wteFqY3c I9sa2fsfnvwDx6F3ObA0ir7uamJwogG1/JkyQljleo0EWk3p0nmig1C453+7tsOWuwtX EeGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=V5y0fs8CZQXRNcVXNGajFAWk4VHzW6WXs9vPwnwB5ts=; b=LijM0xo50lKM3ung7I24PF1GWMjTF2FOajD/ISc8nrOFCEw0pdIzicYHOOTC+t8AzJ mZpl0GUkOopLght0ZBFsbiv6hbquRaC3NpDUMBuQfFRXXfHu2lV/j5Iy9BEDpiL0GUi/ eYtUULqcfmZHUY/Qu8Ty4a96FvDxsCsIg9TymkIxDDayJJYCvLbER3bCxOC7j7QG8wsU IXllp8/IKi4n6vu/Shr32washAUZuTmn6TDqnYzsqQBGt0MgUSPBUsmbAWPW1HY3FOZW AVUZ8jPrHu7nawSkzfpZWSVKR9NZ1NhFP3jgf8n7gcvEKFzb7i2662VmZn0rxw79cuZ0 p8Uw== X-Gm-Message-State: ALyK8tKxD+oUjnH+XlS2fEG14+8h7TQ+rEeU4ccwjM3S4kIRJETMNdSyddqoYWjDLNy7WQ== X-Received: by 10.55.119.66 with SMTP id s63mr4851699qkc.63.1466221630215; Fri, 17 Jun 2016 20:47:10 -0700 (PDT) Received: from Andrews-MacBook-Pro.local (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id p39sm11748918qtp.14.2016.06.17.20.47.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jun 2016 20:47:08 -0700 (PDT) From: Andrew Hyatt To: martin rudalics Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> <4A7C25A7.6000900@gmx.at> <4A813736.8030403@gmx.at> Date: Fri, 17 Jun 2016 23:47:07 -0400 In-Reply-To: <4A813736.8030403@gmx.at> (martin rudalics's message of "Tue, 11 Aug 2009 11:17:42 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 4030 Cc: 4030@debbugs.gnu.org, Stefan Monnier , era+emacsbugs@iki.fi X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This problem still exists in Emacs 25, and this was the last message in the thread. When I try this, though, I do at least see the issue pretty clearly due to font-locking. Does anyone have any further thoughts? It wasn't clear to me from this discussion whether there was any consensus that this was actually a bug or not. martin rudalics writes: >> Yes, but we need to do that even on chunks of code that have not yet >> been (and may never be) displayed and in buffers where font-lock >> is disabled. IOW I'm not talking about fontification but about parsing. > > Sure. But I was only talking about the possibility to highlight such > instances just like we do with column 0 parens in strings already. > >> Pretty much, yes, tho the error message should give more info (the OP >> complained about lack of info in the error message). > > That's what the ellipsis stands for. But what info? Guessing a good > buffer position seems next to impossible. Where else can `forward-sexp' > go astray when called from a top-level position? > >>> But do we really have to scan the buffer in the first place? >> >> Don't know. Maybe not, indeed. Maybe it's just to detect the "too many >> closing parens" case as well (i.e. rather than silently ignore trailing >> code). > > We could simply search for (concat "^(" (symbol-name symbol))) and do a > `forward-sexp' over the form starting there as in the attached patch. I > see no reason why we should try to handle an .emacs broken before or > after that form. > > martin > > *** cus-edit.el.~1.364.~ 2009-07-27 08:09:05.997162900 +0200 > --- cus-edit.el 2009-08-11 10:51:21.812500000 +0200 > *************** > *** 4338,4374 **** > > This function does not save the buffer." > (goto-char (point-min)) > ! ;; Skip all whitespace and comments. > ! (while (forward-comment 1)) > ! (or (eobp) > ! (save-excursion (forward-sexp (buffer-size)))) ; Test for scan errors. > ! (let (first) > ! (catch 'found > ! (while t ;; We exit this loop only via throw. > ! ;; Skip all whitespace and comments. > ! (while (forward-comment 1)) > ! (let ((start (point)) > ! (sexp (condition-case nil > ! (read (current-buffer)) > ! (end-of-file (throw 'found nil))))) > ! (when (and (listp sexp) > ! (eq (car sexp) symbol)) > ! (delete-region start (point)) > ! (unless first > ! (setq first (point))))))) > ! (if first > ! (goto-char first) > ! ;; Move in front of local variables, otherwise long Custom > ! ;; entries would make them ineffective. > ! (let ((pos (point-max)) > ! (case-fold-search t)) > ! (save-excursion > ! (goto-char (point-max)) > ! (search-backward "\n\^L" (max (- (point-max) 3000) (point-min)) > ! 'move) > ! (when (search-forward "Local Variables:" nil t) > ! (setq pos (line-beginning-position)))) > ! (goto-char pos))))) > > (defun custom-save-variables () > "Save all customized variables in `custom-file'." > --- 4338,4364 ---- > > This function does not save the buffer." > (goto-char (point-min)) > ! (if (re-search-forward (concat "^(" (symbol-name symbol))) > ! (let ((from (goto-char (match-beginning 0))) > ! (to (condition-case nil > ! (progn > ! (forward-sexp) > ! (point)) > ! (error nil)))) > ! (if to > ! (delete-region from to) > ! (error "Malformed %s expression" symbol))) > ! ;; Move in front of local variables, otherwise long Custom > ! ;; entries would make them ineffective. > ! (let ((pos (point-max)) > ! (case-fold-search t)) > ! (save-excursion > ! (goto-char (point-max)) > ! (search-backward "\n\^L" (max (- (point-max) 3000) (point-min)) > ! 'move) > ! (when (search-forward "Local Variables:" nil t) > ! (setq pos (line-beginning-position)))) > ! (goto-char pos)))) > > (defun custom-save-variables () > "Save all customized variables in `custom-file'." From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 18 00:30:08 2016 Received: (at 4030) by debbugs.gnu.org; 18 Jun 2016 04:30:08 +0000 Received: from localhost ([127.0.0.1]:44669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bE7tX-00032V-W0 for submit@debbugs.gnu.org; Sat, 18 Jun 2016 00:30:08 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bE7tV-00031Y-KT for 4030@debbugs.gnu.org; Sat, 18 Jun 2016 00:30:06 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u5I4U32M021829; Sat, 18 Jun 2016 00:30:03 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 33532661DE; Sat, 18 Jun 2016 00:31:39 -0400 (EDT) From: Stefan Monnier To: Andrew Hyatt Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment Message-ID: References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> <4A7C25A7.6000900@gmx.at> <4A813736.8030403@gmx.at> Date: Sat, 18 Jun 2016 00:31:39 -0400 In-Reply-To: (Andrew Hyatt's message of "Fri, 17 Jun 2016 23:47:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5709=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5709> : inlines <4940> : streams <1653775> : uri <2233211> X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 4030 Cc: martin rudalics , 4030@debbugs.gnu.org, era+emacsbugs@iki.fi X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) > Does anyone have any further thoughts? It wasn't clear to me from this > discussion whether there was any consensus that this was actually a bug > or not. With the support for syntax-fontification "on-the-fly" within forward-sexp, we could actually make forward-sexp handle those cases correctly nowadays. So we can either: - make it work with a syntax-propertize-function. Not sure it's worth the cost. - deprecate ?; and friends, probably adding font-lock highlights to help spot the problematic cases, and maybe changing the Lisp reader code to warn about those things as well (with intention to remove support for them). - keep on living with this occasional problem. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri May 12 22:54:06 2017 Received: (at 4030) by debbugs.gnu.org; 13 May 2017 02:54:06 +0000 Received: from localhost ([127.0.0.1]:41571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9NC2-00038P-IF for submit@debbugs.gnu.org; Fri, 12 May 2017 22:54:06 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:32788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9NBz-00037o-Gy; Fri, 12 May 2017 22:54:04 -0400 Received: by mail-io0-f177.google.com with SMTP id p24so49979290ioi.0; Fri, 12 May 2017 19:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=7qo1EfzjFa98RiEbSCqVyXzAjSE2Ro58+acFQJcrYHI=; b=VzolYEj9VtnuYndNET+zvzDzhZlF9iH1pP0wJMWYRio/P9ofjaVJTSgGGetzKosV95 6zgAFvCBbi79qht8jsrSPvz3Q4gO1NjdU5boxOSdU8a7+p5ov3o5NRV/aKUP1NSUZGRf elvQ+S3hxJExtUkbm9WfHzZ7FQRDig9xviI10Ic6HnMyfKuoAKqHlVVErD9ADrkR8a/O eEwJ5LwW4ihRyW8DHi8N0vQyg1gvrgF2Ftdcg6z7yy+teU6NOjCvDlTusdUTbsY7BLgg PjjqQ6Rgs5yyrXtjhtpkUeF4VkSp6YhwhKclQRAxOzQRlkMV41t3W4xTl2e0KlQi5aAF f2GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=7qo1EfzjFa98RiEbSCqVyXzAjSE2Ro58+acFQJcrYHI=; b=DdbYH/ce8xcccpMv+WF59WUbJUT3xeopC+tppvhFGrWBWGi7YceJtsNe2+RmTbxUpU b1m4GjGUzTS3CPicix2AfDuDm3r1/aglxQ9YlRX5qLPWqIPV4hfye0Nhi5YCgCU/t2dc A54uh8rLIKRkSEYXK3d8+NQcrS3oDx6LFA9XP9Vqwy3lZyymFM0fjpuHFlx9coOrjgIE On7dbntJpW6i7hBEdtsa9zeREyp/bdxebyKpCt0bh1Frk+q9QQuYLP/6kUPNSPkPAByK Jy/2aadnG43Vay5gaZIrMUvxnGn48UpJVODhzEIeje3zs2SUowiPZrWWvnMLzD0miuvM 7TNQ== X-Gm-Message-State: AODbwcAwtw1rlFIOibUiLYDJrV56UgB5Me1EoNSNY49K20kXZ63Ghid2 mtwCW7u4jKqFCw== X-Received: by 10.107.25.3 with SMTP id 3mr6798319ioz.62.1494644037746; Fri, 12 May 2017 19:53:57 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id b10sm2240753iod.33.2017.05.12.19.53.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 May 2017 19:53:56 -0700 (PDT) From: npostavs@users.sourceforge.net To: Stefan Monnier Subject: Re: bug#4030: forward-sexp parses character literal ?; as comment References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> <4A7C25A7.6000900@gmx.at> <4A813736.8030403@gmx.at> Date: Fri, 12 May 2017 22:55:29 -0400 In-Reply-To: (Stefan Monnier's message of "Sat, 18 Jun 2016 00:31:39 -0400") Message-ID: <871srtjwim.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 4030 Cc: martin rudalics , Andrew Hyatt , 4030@debbugs.gnu.org, era+emacsbugs@iki.fi X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) tags 4030 wontfix close 4030 quit Stefan Monnier writes: >> Does anyone have any further thoughts? It wasn't clear to me from this >> discussion whether there was any consensus that this was actually a bug >> or not. > > > So we can either: [...] > - deprecate ?; and friends, probably adding font-lock highlights to help > spot the problematic cases, and maybe changing the Lisp reader code to > warn about those things as well (with intention to remove support for > them). Since we now emit such warnings, I'm closing this bug as wontfix. See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20852 [1: c2bbdc3316]: 2017-05-01 20:39:10 +0200 Warn about missing backslashes during load http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c2bbdc3316487e34eba1470dd059c0c290431e00 [2: 3c4c8ca06e]: 2017-05-07 13:22:34 +0200 Fix all unescaped character literals http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3c4c8ca06e3306ccbcd07e354eb51abe53b52d22 From unknown Tue Aug 19 02:52:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 10 Jun 2017 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator