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:37:33 -0400 Message-ID: References: <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180626182348.GB4464@ACM> <20180630180926.GB6816@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530416177 15166 195.159.176.226 (1 Jul 2018 03:36:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 03:36:17 +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 Sun Jul 01 05:36:13 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 1fZT9n-0003qs-Uz for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 05:36:12 +0200 Original-Received: from localhost ([::1]:48704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTBt-0007zr-AI for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 23:38:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTBD-0007zb-3A for emacs-devel@gnu.org; Sat, 30 Jun 2018 23:37:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZTB9-0003SK-VH for emacs-devel@gnu.org; Sat, 30 Jun 2018 23:37:39 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZTB9-0003Q0-Pp for emacs-devel@gnu.org; Sat, 30 Jun 2018 23:37:35 -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 w613bXLC006400; Sat, 30 Jun 2018 23:37:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id BCC4D65491; Sat, 30 Jun 2018 23:37:33 -0400 (EDT) In-Reply-To: <20180630180926.GB6816@ACM> (Alan Mackenzie's message of "Sat, 30 Jun 2018 18:09:26 +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 <1791244> : uri <2666726> 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:226861 Archived-At: > some people, including me, find the insertion of characters they haven't > typed (aside from tabs/spaces for indentation) annoying. Don't think of it as a character, think of it as "a special syntax-table string-closer that's not really in the buffer": it will be automatically removed when you fix the unterminated string anyway. For that reason it's very different from electric-pair-mode: the " char it adds is not meant to save you from typing typing the closing string delimiter, it's just a technical device to bound temporarily the extent of the string until the time you close it. > It's good that there are minor modes that can do this, but it's not > the way to solve the current difficulty. Maybe the sample implementation I provided is not quite right, but I think the approach of temporarily inserting a " instead of messing with syntax-table properties is actually much closer to the current CC-mode behavior than to electric-pair-mode. > But it doesn't really address the problem. That problem is how to > fontify unterminated strings (in both senses of the word "how"). An unterminated string can only occur in an invalid piece of code. To the extent that invalid code has no clear meaning, there's no way to know what is really the "right" behavior. My point of view is that Emacs should focus on behaving as correctly as possible for valid code. The only effort worth doing w.r.t invalid code is to avoid doing something clearly harmful and to help the user make the code valid again. Anything further than that is time that would be better spent improving the handling of valid code. I don't see any concrete benefit (for the user) of the new behavior over the old (or the reverse for that matter). Either behavior is equally good and which behavior is better will depend on things which Emacs cannot know unless the user explicitly tells us. > Up till now, Emacs hasn't bothered - it just allows these strings, and the > subsequent buffer portion, to be fontified randomly. It's not random: it's arbitrary. The new behavior is also arbitrary. AFAIK you have no statistical data to claim that your new behavior is more often better than worse (and even less data to claim that the difference is significant). So it's mostly different. > I think such a string should have string face up till the first > unescaped newline (in modes where escaped NLs are required for > multiline strings). Yes, we saw that. Some other users agree. Yet others disagree. Personally, as a user, I don't really care which behavior I get: it's a rare transient situation which I'll fix soon anyway, whether Emacs tells me about it or not. OTOH, there is very concrete evidence that the new behavior is worse in the sense that it adds complexity to the code and (as expected) introduces bugs. To me, this is a bad tradeoff. > I can't see any other way anybody would want such a construct > to be fontified. That's just a lack of imagination on your part. Tho it also means you haven't made the effort to appreciate some of the scenarios people have presented here where the old behavior is preferable. Stefan