From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Sat, 30 Jun 2018 22:29:12 +0300 Message-ID: <83tvpkkr93.fsf@gnu.org> 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; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530386834 23775 195.159.176.226 (30 Jun 2018 19:27:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2018 19:27:14 +0000 (UTC) Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, stephen_leake@stephe-leake.org, monnier@IRO.UMontreal.CA, joaotavora@gmail.com To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 30 21:27:09 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 1fZLWW-00063M-SE for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 21:27:08 +0200 Original-Received: from localhost ([::1]:47770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZLYc-0006t1-E0 for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 15:29:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZLYQ-0006sv-TL for emacs-devel@gnu.org; Sat, 30 Jun 2018 15:29:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZLYM-0007Bf-TU for emacs-devel@gnu.org; Sat, 30 Jun 2018 15:29:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZLYM-0007BD-On; Sat, 30 Jun 2018 15:29:02 -0400 Original-Received: from [176.228.60.248] (port=2362 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fZLYM-0000a6-5L; Sat, 30 Jun 2018 15:29:02 -0400 In-reply-to: <20180630190327.GC6816@ACM> (message from Alan Mackenzie on Sat, 30 Jun 2018 19:03:27 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:226852 Archived-At: > 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.) Thanks.