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: Sun, 01 Jul 2018 18:22:48 +0300 Message-ID: <83o9frkmk7.fsf@gnu.org> References: <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <83tvpkkr93.fsf@gnu.org> <20180630201447.GE6816@ACM> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530458476 30019 195.159.176.226 (1 Jul 2018 15:21:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 15:21:16 +0000 (UTC) Cc: joaotavora@gmail.com, cpitclaudel@gmail.com, stephen_leake@stephe-leake.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 17:21:11 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 1fZeA1-0007hF-LF for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 17:21:09 +0200 Original-Received: from localhost ([::1]:54700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZeC8-0004qr-Vu for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 11:23:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZeC2-0004qf-D7 for emacs-devel@gnu.org; Sun, 01 Jul 2018 11:23:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZeBz-00088R-4u for emacs-devel@gnu.org; Sun, 01 Jul 2018 11:23:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZeBn-0007xT-Rc; Sun, 01 Jul 2018 11:22:59 -0400 Original-Received: from [176.228.60.248] (port=3768 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fZeBn-0000BB-6U; Sun, 01 Jul 2018 11:22:59 -0400 In-reply-to: <20180630201447.GE6816@ACM> (message from Alan Mackenzie on Sat, 30 Jun 2018 20:14:47 +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:226869 Archived-At: > Date: Sat, 30 Jun 2018 20:14:47 +0000 > Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, > stephen_leake@stephe-leake.org, monnier@IRO.UMontreal.CA, > joaotavora@gmail.com > From: Alan Mackenzie > > > 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. Not your fault. Thanks for taking the time to recap. > 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. But not really a catastrophe, IMO. > 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. So am I. I'm also concerned that introducing this will slow down various syntax-related features, only to cater to what I consider a minor improvement at best. Of course, if the extra functionality turns out to be not as complex as Stefan fears and won't cause any significant slowdown that concerns me, then perhaps we should have it. But is that a reasonable assumption? Thanks.