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: Mon, 02 Jul 2018 22:10:26 -0400 Message-ID: References: <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <20180701105820.GB4697@ACM> <20180701181832.GD4697@ACM> <20180702191859.GA4739@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530583716 25682 195.159.176.226 (3 Jul 2018 02:08:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2018 02:08:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 03 04:08:32 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 1faAk3-0006Yp-Rk for ged-emacs-devel@m.gmane.org; Tue, 03 Jul 2018 04:08:31 +0200 Original-Received: from localhost ([::1]:37355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faAm9-0001lb-G0 for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2018 22:10:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faAm2-0001lM-JX for emacs-devel@gnu.org; Mon, 02 Jul 2018 22:10:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faAly-0001Il-HU for emacs-devel@gnu.org; Mon, 02 Jul 2018 22:10:34 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faAly-0001GY-A2 for emacs-devel@gnu.org; Mon, 02 Jul 2018 22:10:30 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w632AQOW021619; Mon, 2 Jul 2018 22:10:27 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8E47D66223; Mon, 2 Jul 2018 22:10:26 -0400 (EDT) In-Reply-To: <20180702191859.GA4739@ACM> (Alan Mackenzie's message of "Mon, 2 Jul 2018 19:18:59 +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, RV6320=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6320> : inlines <6732> : streams <1791429> : uri <2667712> 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:226892 Archived-At: >> >> 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? Of course it does. > Can you identify any other sensible strategy a compiler could follow? It could look for the next (closing) " and if it's not on the same line signal an error about "invalid multiline string" (or "unterminated string" if it bumps into EOF). GCC used to do just that (without even signaling an error) IIRC. > 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. I'm not sure you can define "optimal" without defining "intended valid state" in this case. > 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. >From what I remember of back_comment (not very fresh, to be honest), I think there's a good chance it would be pretty easy, actually (at least easy in terms of the resulting patch being short: it may take some time to come up with the patch, OTOH). > With the `s' flag in place: 1.9489 seconds. > Without the `s' flag: 1.3003 seconds. Wow, I must say I expected a significantly lower overhead. Stefan