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: Sat, 30 Jun 2018 23:50:29 -0400 Message-ID: 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 Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530416916 31069 195.159.176.226 (1 Jul 2018 03:48:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 03:48:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: joaotavora@gmail.com, Eli Zaretskii , stephen_leake@stephe-leake.org, cpitclaudel@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 05:48:31 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 1fZTLj-0007zg-EV for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 05:48:31 +0200 Original-Received: from localhost ([::1]:48726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTNq-0002Xv-Fk for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 23:50:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTNj-0002Xo-At for emacs-devel@gnu.org; Sat, 30 Jun 2018 23:50:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZTNg-0005NH-8T for emacs-devel@gnu.org; Sat, 30 Jun 2018 23:50:35 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTNf-0005LP-Ly; Sat, 30 Jun 2018 23:50:31 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w613oTg5007426; Sat, 30 Jun 2018 23:50:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1590765491; Sat, 30 Jun 2018 23:50:29 -0400 (EDT) In-Reply-To: <20180630201447.GE6816@ACM> (Alan Mackenzie's message of "Sat, 30 Jun 2018 20:14:47 +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 <1791245> : uri <2666731> 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:226862 Archived-At: > 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. Of course, as mentioned elsewhere, the new functionality is not good either when you have char foo[] = "first line second line\ third line"; Unless we find a magic way to distinguish those cases, both behaviors will be sometimes right and sometimes wrong (and of course, neither really matters since the code is invalid and will be inevitably fixed soon by the user). > 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: Complexity brings bugs, indeed. > 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. "foo gets warning-face on the " is completely unrelated to the discussion at hand: you can have it both with the new code and the old code, and indeed CC-mode had it with the old code as well. > What I'm now proposing, and implementing as a trial, is to enhance the > syntax table facilities to support unterminated strings. Oh indeed, complexity calls for yet more complexity. > Stefan is concerned that the extra functionality may not justify the > increase in complexity in syntax.c. Yes. Stefan