From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: era+emacsbugs@iki.fi Newsgroups: gmane.emacs.bugs Subject: bug#4030: forward-sexp parses character literal ?; as comment Date: Thu, 06 Aug 2009 11:55:47 +0300 Message-ID: <1249548947.6570.1328564497@webmail.messagingengine.com> References: <1249387642.18128.1328220453@webmail.messagingengine.com> <4A782D00.4040808@gmx.at> <1249460270.18460.1328376993@webmail.messagingengine.com> <4A799766.9050304@gmx.at> Reply-To: era+emacsbugs@iki.fi, 4030@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249549642 14621 80.91.229.12 (6 Aug 2009 09:07:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2009 09:07:22 +0000 (UTC) To: "martin rudalics" , 4030@emacsbugs.donarmstrong.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 06 11:07:15 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 1MYywI-00067D-IS for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Aug 2009 11:07:10 +0200 Original-Received: from localhost ([127.0.0.1]:44716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYywH-0004Ed-QE for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Aug 2009 05:07:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MYyw4-00049p-UY for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2009 05:06:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MYyvz-000443-6g for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2009 05:06:55 -0400 Original-Received: from [199.232.76.173] (port=51520 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYyvy-00043i-VP for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2009 05:06:51 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:43178) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MYyvy-0002Zq-8j for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2009 05:06:50 -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 n7696lkD027362; Thu, 6 Aug 2009 02:06:48 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n76955VL026722; Thu, 6 Aug 2009 02:05:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: era+emacsbugs@iki.fi Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 06 Aug 2009 09:05:04 +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.124954894925746 (code B ref 4030); Thu, 06 Aug 2009 09:05:04 +0000 Original-Received: (at 4030) by emacsbugs.donarmstrong.com; 6 Aug 2009 08:55:49 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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) Original-Received: from web7.messagingengine.com ([10.202.2.216]) by compute1.internal (MEProxy); Thu, 06 Aug 2009 04:55:47 -0400 Original-Received: by web7.messagingengine.com (Postfix, from userid 99) id 0FD6C17039; Thu, 6 Aug 2009 04:55:47 -0400 (EDT) X-Sasl-Enc: MSK3H6AymqMAiMy5pQiGSd60me0BWlbVsj+MyAhOiKIR 1249548947 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <4A799766.9050304@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Thu, 06 Aug 2009 05:06:55 -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:29928 Archived-At: 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.