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: Sun, 01 Jul 2018 00:02:56 -0400 Message-ID: References: <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530417719 20149 195.159.176.226 (1 Jul 2018 04:01:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 04:01:59 +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 Sun Jul 01 06:01:54 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 1fZTYg-00057a-20 for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 06:01:54 +0200 Original-Received: from localhost ([::1]:48746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTan-0005Ri-7U for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 00:04:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTZm-0005Of-GE for emacs-devel@gnu.org; Sun, 01 Jul 2018 00:03:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZTZj-0003LF-B7 for emacs-devel@gnu.org; Sun, 01 Jul 2018 00:03:02 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:43796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTZj-0003Kf-58 for emacs-devel@gnu.org; Sun, 01 Jul 2018 00:02:59 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w6143WsJ015667; Sun, 1 Jul 2018 00:03:32 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6E71465491; Sun, 1 Jul 2018 00:02:56 -0400 (EDT) In-Reply-To: <20180630190327.GC6816@ACM> (Alan Mackenzie's message of "Sat, 30 Jun 2018 19:03:27 +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, RV6319=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6319> : inlines <6730> : streams <1791246> : uri <2666734> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:226863 Archived-At: >> 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'. Better, yes. > 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. Why? How 'bout: char foo[] = "some unterminated // string >> 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"). I suspect that it'll be easier to fix electric-pair-mode. So the right answer was that you won't need syntax-table text-properties. But the downside is that every time we scan backwards over a newline we'll have to pay the extra cost of checking whether it's maybe closing an unterminated string. I think such a "string terminator" thingy would be valuable if it were used/needed for *valid* code. But introducing such complexity just to tweak the handling of invalid code doesn't seem like a good tradeoff at all. > 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. I can't imagine how seeing the code could change my opinion on whether it's worth it. > "S-T-NG" may be fine for Emacs 28 or 29, but the syntax table is what we > have, and what we must work with in the short term. We'll never get to "S-T-NG" if we keep it for the future. Stefan