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: Mon, 2 Jul 2018 19:18:59 +0000 Message-ID: <20180702191859.GA4739@ACM> References: <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <20180701105820.GB4697@ACM> <20180701181832.GD4697@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530559599 6750 195.159.176.226 (2 Jul 2018 19:26:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2018 19:26:39 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 02 21:26:35 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 1fa4T2-0001cV-JN for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2018 21:26:32 +0200 Original-Received: from localhost ([::1]:35043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa4V9-0007gz-SB for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2018 15:28:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa4V2-0007gc-Da for emacs-devel@gnu.org; Mon, 02 Jul 2018 15:28:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fa4Ux-00083g-Ev for emacs-devel@gnu.org; Mon, 02 Jul 2018 15:28:36 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:44898 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fa4Ux-000810-3t for emacs-devel@gnu.org; Mon, 02 Jul 2018 15:28:31 -0400 Original-Received: (qmail 90937 invoked by uid 3782); 2 Jul 2018 19:28:28 -0000 Original-Received: from acm.muc.de (p5B1465FA.dip0.t-ipconnect.de [91.20.101.250]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Jul 2018 21:28:26 +0200 Original-Received: (qmail 5755 invoked by uid 1000); 2 Jul 2018 19:18:59 -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:226891 Archived-At: On Sun, Jul 01, 2018 at 19:16:06 -0400, Stefan Monnier wrote: > >> >> Why? How 'bout: > >> >> char foo[] = "some unterminated // string > >> > Bug compatibility with the current scan-sexps. > >> I don't see why: currently, scan-sexps skips over the comment, but > >> that's not a bug: it's exactly what it is documented to do. > > There is no comment there, but scan-sexps skips to it nevertheless. > The starting point is within the string (not according to the C language > rules, of course, but according to the syntax-tables settings), and > operations like scan-sexps are documented to work under the assumption > that the starting point is outside of strings/comments, so it is very > much correct for it to consider this "// string\n" to be a comment. Yes. Apologies for my misunderstanding. [ .... ] > ..... I see we agree. Yes. > >> It needs to work reliably for those languages where strings > >> are indeed terminated by newline (e.g. jgraph-mode in GNU ELPA). > > You mean, jgraph-mode is another use-case for `s'? (I'm not familiar > > with it.) > I looked for existing use-cases and I indeed found one. It's very much > not high-profile, tho. Also this use-case is slightly different in that > the \n is really the normal/only way to terminate the string in jgraph. > In case you're interested: > http://web.eecs.utk.edu/~plank/plank/jgraph/jgraph.html > >> But that brings us back to "why not use string-fence?". > > Yes. String-fence interferes with syntactical stuff "inside" the > > invalid string, whereas the `s' flag won't. > Not sure how serious this "interferes with syntactical stuff" is > in practice. Maybe not very. > >> But we usually don't make any effort to guess what the intended > >> closest valid state might be, except where the user is actively > >> editing the text (e.g. by proposing completion candidates for > >> identifiers). > > There's no need to guess. The compiler defines the state, namely that > > the (invalid) string ends at the EOL, and what follows is non-string. > The compiler just makes an arbitrary choice, .... No. The compiler has no choice here. Or does it? Can you identify any other sensible strategy a compiler could follow? > .... just like we do and that has no bearing on what the intended > valid state is (which is not something the compiler can discover > either: it's only available in the head of the coder). There may or may not be a unique "intended valid state". I don't think it's a helpful concept - it suggests that the states a buffer is in most of the time are in some way unimportant. I reaffirm my view that Emacs should present optimal information about these normal (invalid) states, and that they are very important indeed. > > There's no need to guess. back_maybe_comment is in the new > > scratch/fontify-open-string branch. It is NOT that complicated. > Unsurprisingly it introduces a complexity which I find unjustified by > the presented benefits. > But it now occurs to me that maybe we can do better: have you tried to > merge back_maybe_string into back_comment? After all, back_comment > already pays attention to strings (in order to try and correctly > handle comment openers appearing within strings), so there's > a possibility that back_comment might be able to handle your use case > with much fewer changes (and in that case, the performance cost would > be pretty close to 0, I think). That's a good idea. I think it's clear that such a merge could be done. But it would need a lot of detailed painstaking work. It's optimisation (as in "don't do it yet!"). Once we decide to adopt the idea is the time to do this merge, I think. That's assuming some measurements show it's worthwhile (which I think it would be). In fact, in my modified shell-script-mode I timed (scan-sexps BONL -1) a million times on the following text: "string" at the start of a line. With the `s' flag in place: 1.9489 seconds. Without the `s' flag: 1.3003 seconds. This is an overhead of almost exactly 50%. > Stefan -- Alan Mackenzie (Nuremberg, Germany).