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: CC Mode and electric-pair "problem". Date: Sat, 30 Jun 2018 20:14:47 +0000 Message-ID: <20180630201447.GE6816@ACM> References: <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <83tvpkkr93.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530390159 8282 195.159.176.226 (30 Jun 2018 20:22:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2018 20:22:39 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: joaotavora@gmail.com, cpitclaudel@gmail.com, stephen_leake@stephe-leake.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 30 22:22:34 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 1fZMO8-00021t-QD for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 22:22:33 +0200 Original-Received: from localhost ([::1]:47902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZMQG-0005mM-07 for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 16:24:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZMPc-0005mH-A4 for emacs-devel@gnu.org; Sat, 30 Jun 2018 16:24:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZMPZ-0002dO-1r for emacs-devel@gnu.org; Sat, 30 Jun 2018 16:24:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:10477 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fZMPY-0002ZU-M8 for emacs-devel@gnu.org; Sat, 30 Jun 2018 16:24:00 -0400 Original-Received: (qmail 29795 invoked by uid 3782); 30 Jun 2018 20:23:58 -0000 Original-Received: from acm.muc.de (p5B147D93.dip0.t-ipconnect.de [91.20.125.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Jun 2018 22:23:56 +0200 Original-Received: (qmail 10212 invoked by uid 1000); 30 Jun 2018 20:14:47 -0000 Content-Disposition: inline In-Reply-To: <83tvpkkr93.fsf@gnu.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:226855 Archived-At: Hello, Eli. On Sat, Jun 30, 2018 at 22:29:12 +0300, Eli Zaretskii wrote: > > Date: Sat, 30 Jun 2018 19:03:27 +0000 > > From: Alan Mackenzie > > Cc: Clément Pit-Claudel , > > Stephen Leake , > > João Távora , > > emacs-devel@gnu.org > > I am in the middle of writing a trial implementation (code speaks louder > > than words). Thus far, it has already worked in shell-script-mode > > (which required a one-line change, this: > > - ?\n ">#" > > + ?\n ">#s" > > the new `s' flag is how I've constructed it, so far). > > > But that's for Eli to judge. > > > So let's look at the technical issues: > > > You suggest introducing a new syntax-table thingy similar to > but for > > > strings. Let's call it ] > > As I noted above, I have implemented it as another flag, `s'. > > > - This implies we'll need a new C-level function `back_string` to jump > > > backward over such a ]-terminated string, corresponding to > > > back_comment. > > Yes. > > > `back_comment` has proved to be rather nasty, so while > > > we can learn from it, part of what we learn is that jumping backward > > > over such things is much easier .... > > much less easy. :-) > > > .... than jumping forward, so this > > > innocuous ] will be more costly than might meet the eye. > > It requires the new function, which at the moment seems somewhat less > > complicated than back_comment, and this requires to be called from > > scan_lists. > > > - In CC-mode, \n already has syntax > so it can't also have syntax ] > > > How do you intend to deal with that: will you mark those few \n that > > > terminate strings with syntax-table text-properties? > > This is simple with the flag `s'. NL would thus have end-comment syntax > > _and_ the `s' flag. In scan_lists, back_comment will be tried before > > what I'm calling `back_maybe_string', since being a comment ender must have > > precedence over being a string terminator. > > > If so, what's the benefit over using string-fences? > > String-fence stopped the 'chomp facility of electric-pair-mode working > > properly (for the currently accepted value of "properly"). > > > - Another approach would be to make it possible to mark \n as both ] and > > > > at the same time, which would make the CC-mode feature much cleaner > > > (no need to muck with syntax-table text-properties) but the cost of > > > yet more complexity in the syntax.c code. > > That's what I'm doing with `s'. The extra complexity in syntax.c > > doesn't seem all that bad at the moment. back_maybe_string is currently > > 137 lines long (including a macro analogous to INC_FROM, and a lossage: > > clause modelled on the one in back_comment)), compared with > > back_comment's 289 lines. I'm planning on committing this new code to a > > branch in the next few days, then you can judge better whether the new > > facility is worth it. > Could you please recap what problem(s) you are trying to fix with > these changes? (I'm sorry for not following, but this thread spans > two months and many long messages with several days in-between. It's > hard to keep focused on the main issues.) Sorry. That's just the way things go, sometimes. The initial problem I tried to solve was for CC Mode source files with things like: char foo[] = "foo char bar[] = "bar"; Historically, the missing " on "foo has caused subsequent lines to have their string quoting reversed. This is not good. A recent series of CC Mode commits "solved" this by putting string-fence syntax-table text properties on the " and the NL around foo. This caused a "make check" test to fail. With electric-pair-mode enabled and electric-pair-skip-whitespace set to 'chomp, in the following: " ( ) " , typing ) on line 1 should replace the ) on line 2, "chomping" the space between ) and ). However the string-fence property on L1's NL prevented electric-pair-mode from functioning correctly. João and I have discussed at length ways of fixing this. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Also, the CC Mode solution has the disadvantage that other languages cannot get the same fontification advantages, namely that the "foo gets warning-face on the ", and string face extends ONLY to EOL. What I'm now proposing, and implementing as a trial, is to enhance the syntax table facilities to support unterminated strings. There will be an extra syntax flag `s' on newlines meaning "terminate any open string". This is straightforward for forward scanning, but somewhat complicated for backward scanning. However, it does enable unterminated strings to be easily fontified to EOL in any language, with minimal effort. It should allow the desired fontification without causing problems for electric-pair-mode. Stefan is concerned that the extra functionality may not justify the increase in complexity in syntax.c. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).