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: Sat, 30 Jun 2018 18:09:26 +0000 Message-ID: <20180630180926.GB6816@ACM> References: <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180626182348.GB4464@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530382604 7905 195.159.176.226 (30 Jun 2018 18:16:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2018 18:16:44 +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 Sat Jun 30 20:16:39 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 1fZKQH-0001yi-RI for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 20:16:37 +0200 Original-Received: from localhost ([::1]:47611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZKSO-00066z-Sn for ged-emacs-devel@m.gmane.org; Sat, 30 Jun 2018 14:18:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZKSI-00066u-S9 for emacs-devel@gnu.org; Sat, 30 Jun 2018 14:18:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZKSD-0000xR-Tk for emacs-devel@gnu.org; Sat, 30 Jun 2018 14:18:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:21610 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fZKSD-0000w1-Je for emacs-devel@gnu.org; Sat, 30 Jun 2018 14:18:37 -0400 Original-Received: (qmail 80397 invoked by uid 3782); 30 Jun 2018 18:18:35 -0000 Original-Received: from acm.muc.de (p5B147D93.dip0.t-ipconnect.de [91.20.125.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Jun 2018 20:18:35 +0200 Original-Received: (qmail 9753 invoked by uid 1000); 30 Jun 2018 18:09:26 -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:226847 Archived-At: Hello, Stefan. On Thu, Jun 28, 2018 at 23:42:34 -0400, Stefan Monnier wrote: > > This is effectively electric-pair-mode, which if enabled, already > > inserts two "s when you type ". > It's very different: it inserts/removes the second " at the end of the > line, so it ends up behaving very much like your current code, except: > - it only affects self-insert-command. > - it uses an explicit " character rather than a syntax-table text-property. Some people, including me, find the insertion of characters they haven't typed (aside from tabs/spaces for indentation) annoying. It's good that there are minor modes that can do this, but it's not the way to solve the current difficulty. > So OT1H it provides a behavior closer to current `master` than to > electric-pair-mode, but like electric-pair-mode it has a fairly focus'd > effect, so is less likely to have unexpected interactions. > > Not everybody likes electric-pair-mode. I don't think your suggestion > > is any better than mine (snipped) to which you replied. > Its main benefit is that it's very superficial with a narrow focus. > No need to change any core API like syntax-tables with a feature which > will need to be supported for the next very many years. But it doesn't really address the problem. That problem is how to fontify unterminated strings (in both senses of the word "how"). Up till now, Emacs hasn't bothered - it just allows these strings, and the subsequent buffer portion, to be fontified randomly. 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). I can't see any other way anybody would want such a construct to be fontified. > Stefan -- Alan Mackenzie (Nuremberg, Germany).