From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Fontifying unterminated strings [was: CC Mode and electric-pair "problem".] Date: Tue, 26 Jun 2018 16:08:50 +0000 Message-ID: <20180626160850.GA4464@ACM> References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180618180846.GC3973@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530029791 1312 195.159.176.226 (26 Jun 2018 16:16:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2018 16:16:31 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 26 18:16:26 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 1fXqdi-0000AN-Gv for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2018 18:16:22 +0200 Original-Received: from localhost ([::1]:53740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXqfp-0008Ag-GO for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2018 12:18:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXqem-00089O-Dm for emacs-devel@gnu.org; Tue, 26 Jun 2018 12:17:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXqej-0005A9-8V for emacs-devel@gnu.org; Tue, 26 Jun 2018 12:17:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:50184 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fXqei-00059i-Sy for emacs-devel@gnu.org; Tue, 26 Jun 2018 12:17:25 -0400 Original-Received: (qmail 15683 invoked by uid 3782); 26 Jun 2018 16:17:22 -0000 Original-Received: from acm.muc.de (p5B1471C9.dip0.t-ipconnect.de [91.20.113.201]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Jun 2018 18:17:20 +0200 Original-Received: (qmail 28107 invoked by uid 1000); 26 Jun 2018 16:08:50 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:226745 Archived-At: Hello, Stefan. On Mon, Jun 18, 2018 at 21:48:41 -0400, Stefan Monnier wrote: > > char *foo = "foo; > > int bar = 5; > > char *baz = "baz"; > > The entire second line, and the third line, up to the first ", get string > > face. We've been used to this for so long that we've lost sight of just > > how bad and amateurish it really is. > But what about when you write > char *thedoc = "Here it is: > - First do this > - Then do that > And that's it!"; > ? > Both cases are valid transient states. Which one will occur more often > depends a lot on the particular kind of code you write and your > coding habits. I suggest the most common case by far will be writing char *foo = "foo.... in the middle of an existing buffer. > Emacs can't reliably distinguish the two cases, so whichever behavior it > chooses it will look "amateurish" in some cases. No, you've misunderstood my point. It is not the aesthetic "niceness", the lack of which is amateurish; it is fontifying as a string something which isn't a string (as defined by the compiler's error messages). > I think the better option here is to focus on the following: > 1- Make sure the programmer is aware there's a problem in its code. > I.e. highlight the opening quote or the non-escaped end-of-line or > something in bright red or something like that. > 2- Don't try to guess what the user intended to do. > Instead keep our code as simple as possible: the C code we're handed > is broken, so there's no real clear "right behavior" anyway. How about the following suggestion - instead of having permanent string-fence syntax-table text properties to define the ends of unterminated strings: (i) We leave the syntax of the string opener and EOL alone; (ii) we amend font-{lock,core}.el to apply the desired fontification, to be like the new fontification in CC Mode? This could be done straightforwardly in font-lock by temporarily putting the string-fence properties on these strings, applying all the face properties, then removing these properties again. It would need a few new customisation variables to specify what counts as an open string, and so on. > -- Stefan -- Alan Mackenzie (Nuremberg, Germany).