From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#4030: forward-sexp parses character literal ?; as comment Date: Mon, 10 Aug 2009 15:59:39 -0400 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> Reply-To: Stefan Monnier , 4030@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249934874 17064 80.91.229.12 (10 Aug 2009 20:07:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2009 20:07:54 +0000 (UTC) Cc: era+emacsbugs@iki.fi, 4030@emacsbugs.donarmstrong.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 10 22:07:46 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mab9m-0002Dh-1C for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Aug 2009 22:07:46 +0200 Original-Received: from localhost ([127.0.0.1]:47634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mab9k-0005Mx-VU for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Aug 2009 16:07:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mab92-00052v-O4 for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 16:07:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mab8x-00050s-Sa for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 16:06:59 -0400 Original-Received: from [199.232.76.173] (port=45185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mab8x-00050o-Mq for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 16:06:55 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:33274) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mab8x-0002q2-1Y for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 16:06:55 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7AK6mH9026564; Mon, 10 Aug 2009 13:06:53 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n7AK5595025780; Mon, 10 Aug 2009 13:05:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 10 Aug 2009 20:05:05 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4030 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4030-submit@emacsbugs.donarmstrong.com id=B4030.124993439324900 (code B ref 4030); Mon, 10 Aug 2009 20:05:05 +0000 Original-Received: (at 4030) by emacsbugs.donarmstrong.com; 10 Aug 2009 19:59:53 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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" Original-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 Original-Received: by pastel.home (Postfix, from userid 20848) id 7DA138370; Mon, 10 Aug 2009 15:59:39 -0400 (EDT) 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) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Mon, 10 Aug 2009 16:06:59 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30071 Archived-At: >>> 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