From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Fri, 06 Jul 2018 16:58:26 -0500 Message-ID: <86in5sc9h9.fsf@stephe-leake.org> 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 1530914199 21972 195.159.176.226 (6 Jul 2018 21:56:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 21:56:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 23:56: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 1fbYiQ-0005Yb-Pr for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 23:56:34 +0200 Original-Received: from localhost ([::1]:59783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbYkW-0000IZ-5Q for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 17:58:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbYkP-0000IS-Ne for emacs-devel@gnu.org; Fri, 06 Jul 2018 17:58:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbYkK-0007Vo-SV for emacs-devel@gnu.org; Fri, 06 Jul 2018 17:58:37 -0400 Original-Received: from smtp113.iad3b.emailsrvr.com ([146.20.161.113]:37226) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fbYkK-0007Uh-Nn for emacs-devel@gnu.org; Fri, 06 Jul 2018 17:58:32 -0400 Original-Received: from smtp15.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp15.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 2E4BEC009C for ; Fri, 6 Jul 2018 17:58:30 -0400 (EDT) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp15.relay.iad3b.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id ED2BEC009A for ; Fri, 6 Jul 2018 17:58:29 -0400 (EDT) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 06 Jul 2018 17:58:30 -0400 In-Reply-To: (Stefan Monnier's message of "Sat, 30 Jun 2018 23:37:33 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 146.20.161.113 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:227025 Archived-At: Stefan Monnier writes: > 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. True, but I still agree with Alan; treat the newline as a string terminator for fontification. > 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 disagree. When we are editing code, it has incorrect syntax most of the time, yet we still as Emacs to fontify and indent it. So it is a strong requirement that Emacs work "acceptably well" in this context. I'm working on adding robust error correction to my Ada parser, precisely for this purpose. > 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. Right. It would be nice to have the "terminate string on newline" behavior as an option. >> 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. Right. > 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. Ok. I'm hoping for a coding solution that is not as complex. -- -- Stephe