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: Re: CC Mode and electric-pair "problem". Date: Wed, 27 Jun 2018 18:27:17 +0000 Message-ID: <20180627182717.GA4625@ACM> References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@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 1530124451 4016 195.159.176.226 (27 Jun 2018 18:34:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2018 18:34:11 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Stephen Leake , =?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 Wed Jun 27 20:34:06 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 1fYFGY-0000wU-Gn for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 20:34:06 +0200 Original-Received: from localhost ([::1]:60883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYFIf-0003UQ-Oi for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 14:36:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYFIS-0003S0-LE for emacs-devel@gnu.org; Wed, 27 Jun 2018 14:36:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYFIQ-0004u3-1x for emacs-devel@gnu.org; Wed, 27 Jun 2018 14:36:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:48519 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fYFIP-0004nm-Ql for emacs-devel@gnu.org; Wed, 27 Jun 2018 14:36:01 -0400 Original-Received: (qmail 53535 invoked by uid 3782); 27 Jun 2018 18:35:59 -0000 Original-Received: from acm.muc.de (p5B1462B5.dip0.t-ipconnect.de [91.20.98.181]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Jun 2018 20:35:57 +0200 Original-Received: (qmail 4723 invoked by uid 1000); 27 Jun 2018 18:27:17 -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:226791 Archived-At: Hello, yet again, Stefan. On Wed, Jun 20, 2018 at 10:16:05 -0400, Stefan Monnier wrote: > > How about this idea: we add a new syntax flag to Emacs, ", which > > terminates any open string, the same way the syntax > terminates any > > open comment. We could then set this syntax flag on newline. I've been making negative comments about this suggestion of mine over the last day or two. I now believe, again, that the proposal is sound; it would allow the desired fontification (an unterminated string being fontified only up to the next unescaped NL) easily, without interfering with the 'chomp facility in electric-pair-mode. > To me this looks like adding a hack to patch over another. > I don't think the new behavior of unclosed strings in CC-mode is worse > than the old one, but I don't think it's really better either: it's just > different (in some cases it's better in others it's worse). This new fontification in CC Mode is much better. When the terminating " is missing, it no longer fontifies spuriously an unbounded piece of the buffer as a string. Clėment and Stephen Leake have responded positively to this possibility. I think we should enhance Emacs such that it is easy to fontify in this new way. > So the problem I see with it is that it brings complexity in the code > with no real improvement in terms of behavior. The bad-interaction with > electric-pair shows that this complexity has a real immediate cost. > The suggestion above suggests that this complexity may bring in yet > more complexity. The desired facility _is_ complicated. I am not fond of the code in CC Mode which implements it. The question is, where do we put this complexity? With my suggestion, it would be confined mainly to the scanning routines in syntax.c rather than being spread (and duplicated) amongst several major modes. Adapting the forward scanning functionality would be straightforward. Things like (scan-sexps POS -1) would indeed become more difficult. For example, starting at BONL, (scan-sexps BONL -1) in "foo bar would need to find the ", but the same in "foo"bar would need to find the start of bar. In other words, we would have to pair off quotes from the beginning of the line we were scanning backwards over. There may well be difficulties in a NL potentially acting as the terminator of both a string and a comment. I think these are the sorts of complexity you're wary of. font-lock-fontify-syntactically-region could then be amended straightforwardly to apply warning-face to the opening unbalanced " (controlled, of course, by a customisation option). > Me not happy. My suggestion has the strong advantage that it will benefit Emacs as a whole, and there won't need to be separate implementations in CC Mode, Python Mode, Ada Mode, ..... The need for a multilinne string to have escaped NLs between its lines is actually a common pattern in the languages Emacs handles. Why can we not handle it in syntax.c? [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).