From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/fontify-open-string. [Was: CC Mode and electric-pair "problem".] Date: Sun, 15 Jul 2018 16:56:58 +0000 Message-ID: <20180715165658.GB4897@ACM> References: <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <83tvpkkr93.fsf@gnu.org> <20180630201447.GE6816@ACM> <83o9frkmk7.fsf@gnu.org> <20180701163825.GC4697@ACM> <86bmbiceq7.fsf@stephe-leake.org> <86lgacswk8.fsf@stephe-leake.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531674511 2969 195.159.176.226 (15 Jul 2018 17:08:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 17:08:31 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: emacs-devel To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 15 19:08:27 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fekVW-0000gI-U6 for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 19:08:27 +0200 Original-Received: from localhost ([::1]:46482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fekXd-0005Oj-Sy for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 13:10:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fekW8-0005GE-Uo for emacs-devel@gnu.org; Sun, 15 Jul 2018 13:09:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fekW4-0001Ve-Bz for emacs-devel@gnu.org; Sun, 15 Jul 2018 13:09:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46069 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fekW2-0001TD-UX for emacs-devel@gnu.org; Sun, 15 Jul 2018 13:08:59 -0400 Original-Received: (qmail 13646 invoked by uid 3782); 15 Jul 2018 17:08:55 -0000 Original-Received: from acm.muc.de (p5B14752F.dip0.t-ipconnect.de [91.20.117.47]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 15 Jul 2018 19:08:54 +0200 Original-Received: (qmail 6376 invoked by uid 1000); 15 Jul 2018 16:56:58 -0000 Content-Disposition: inline In-Reply-To: <86lgacswk8.fsf@stephe-leake.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227435 Archived-At: Hello, Stephen. Many thanks for trying out and testing this branch. I'm afraid I've found a rather large snag - there are backward moving commands and functions in Emacs which bypass proper syntax checking. For example, in the following in (the modified) shell-script-mode: 1. foo="Foo" 2. bar="Bar 3. , with point at BOL3, a C-M-b moves to the F, rather than "Bar. This is because (forward-comment -1) crashes into the "whitespace" at the end of L2 (the newline) rather than taking account of its syntax (the string closing flag). At the very least, the function back_comment (in src/syntax.c) will need to be modified to take account of such things, and in doing so, might as well become a function that also goes back over EOL-terminated strings, as Stefan suggested. This will be a lot of work. I fear there may be several, or even many, lisp functions in Emacs which may likewise need modifying. The root cause of this problem, in the abstract, is that Emacs attempts to scan backwards over strings and comments, which is only heuristically possible, rather than scanning forwards over the same constructs and remembering the endpoints. Right at the moment, I don't know how to proceed. Sorry. -- Alan Mackenzie (Nuremberg, Germany). On Sun, Jul 15, 2018 at 04:00:23 -0500, Stephen Leake wrote: > An update on this; I just had several missing quotes in a buffer, due to > a copy/multiple paste that had a quote error. I did lots of editing with > the quote errors present. > I didn't even notice them until the compiler complained, just like any > other syntax error. > In my opinion, that is far preferable to the previous behavior of > fontifying large parts of the buffer as string, which forced me to pay > attention to a trivial syntax error instead of what I was actually doing. > This is in Ada, that does not have the option of escaping a newline to > create a multiline string, so treating a newline as string terminator is > always correct. > Anything I can do to help merge this to main? > Stephen Leake writes: > > Alan Mackenzie writes: > > > >> It's no longer a matter of assumption. Earlier on this afternoon, I > >> committed a preliminary working version of this change to the branch > >> scratch/fontify-open-string. > > > > I've just tried this in ada-mode, and it works nicely. I like the red > > face on an unbalanced string quote. > > > > No noticeable slowdown in anything I've tried so far. > > > > Let me know if there's some experiment you'd like me to run. > -- > -- Stephe