From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Fri, 29 Jun 2018 00:11:24 -0400 Message-ID: References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530245412 15074 195.159.176.226 (29 Jun 2018 04:10:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Jun 2018 04:10:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: =?windows-1252?Q?Cl=E9ment?= Pit-Claudel , Stephen Leake , =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 29 06:10:07 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 1fYkjW-0003nS-2i for ged-emacs-devel@m.gmane.org; Fri, 29 Jun 2018 06:10:06 +0200 Original-Received: from localhost ([::1]:39783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYklb-0002iX-HQ for ged-emacs-devel@m.gmane.org; Fri, 29 Jun 2018 00:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYkkx-0002iP-BW for emacs-devel@gnu.org; Fri, 29 Jun 2018 00:11:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYkkq-0005y7-SX for emacs-devel@gnu.org; Fri, 29 Jun 2018 00:11:35 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYkkq-0005wi-Md for emacs-devel@gnu.org; Fri, 29 Jun 2018 00:11:28 -0400 Original-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 w5T4BPbS012107; Fri, 29 Jun 2018 00:11:25 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 11C426611F; Fri, 29 Jun 2018 00:11:25 -0400 (EDT) In-Reply-To: <20180627182717.GA4625@ACM> (Alan Mackenzie's message of "Wed, 27 Jun 2018 18:27:17 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6318=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6318> : inlines <6728> : streams <1791056> : uri <2665714> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:226830 Archived-At: >> > How about this idea: we add a new syntax flag to Emacs, ", which >> > terminates any open string, the same way the syntax > terminates any >> > open comment. We could then set this syntax flag on newline. > I've been making negative comments about this suggestion of mine over > the last day or two. I now believe, again, that the proposal is sound; It's definitely sound. And I very much agree that it could be cleaner than the current code on `master`. I dislike this solution mainly because it requires changes to Emacs's core API, so it bumps against my feeling that the need is not clearly documented: you think the new behavior is more often beneficial than the old behavior but we have no actual data to verify it. FWIW, I do not know that the old behavior is more often beneficial either, but I'm definitely not convinced that the new behavior is often enough more beneficial to justify such changes to syntax-tables. 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 ] - This implies we'll need a new C-level function `back_string` to jump backward over such a ]-terminated string, corresponding to back_comment. `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 than jumping forward, so this innocuous ] will be more costly than might meet the eye. - 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? If so, what's the benefit over using string-fences? - 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. > would need to find the start of bar. In other words, we would have to > pair off quotes from the beginning of the line we were scanning > backwards over. There may well be difficulties in a NL potentially > acting as the terminator of both a string and a comment. I think these > are the sorts of complexity you're wary of. Yes. > My suggestion has the strong advantage that it will benefit Emacs as a > whole, and there won't need to be separate implementations in CC Mode, > Python Mode, Ada Mode, ..... The need for a multilinne string to have > escaped NLs between its lines is actually a common pattern in the > languages Emacs handles. Why can we not handle it in syntax.c? Emacs has handled it for the last 30 years or so. You just want to handle it in a different way. I agree that Emacs's core should ideally make it easy for a major mode to choose this "different way". But the way I see it, your suggestion is just adding one more wart to syntax-tables whereas we should instead work on "syntax-tables NG". IOW, I think that we should introduce a brand new replacement for syntax-tables (tho I don't really know what it should look like, otherwise I'd have coded it up already); something much more powerful and generic (probably based on a mix of a DFA at one level and some kind of push-down automata on top of it), and such a thing could/should easily accommodate such a feature without even needing any ad-hoc support. Stefan