From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Mon, 8 Jul 2019 17:24:36 +0000 Message-ID: <20190708172436.GC5244@ACM> References: <20190703105804.GA11238@ACM> <20190704165846.GF5564@ACM> <20190704190100.GG5564@ACM> <20190708100539.GD4529@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35938"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 08 19:24:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkXNe-0009Be-Te for ged-emacs-devel@m.gmane.org; Mon, 08 Jul 2019 19:24:47 +0200 Original-Received: from localhost ([::1]:43502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkXNd-0006sb-Vz for ged-emacs-devel@m.gmane.org; Mon, 08 Jul 2019 13:24:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33550) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkXNZ-0006sV-N1 for emacs-devel@gnu.org; Mon, 08 Jul 2019 13:24:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkXNY-0006sx-N8 for emacs-devel@gnu.org; Mon, 08 Jul 2019 13:24:41 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:22028 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hkXNY-0006sO-Gd for emacs-devel@gnu.org; Mon, 08 Jul 2019 13:24:40 -0400 Original-Received: (qmail 95795 invoked by uid 3782); 8 Jul 2019 17:24:37 -0000 Original-Received: from acm.muc.de (p4FE15FEC.dip0.t-ipconnect.de [79.225.95.236]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 08 Jul 2019 19:24:36 +0200 Original-Received: (qmail 8352 invoked by uid 1000); 8 Jul 2019 17:24:36 -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.23 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:238409 Archived-At: Hello, Stefan. On Mon, Jul 08, 2019 at 12:33:56 -0400, Stefan Monnier wrote: > > While I'm not completely sure what this will look like, my gut reaction > > to this description is "Yuck!! Ugly hack to workaround breakage > > introduced by other ugly hack!" > > Usually this leads to yet more ugly hacks. > BTW, re-reading this, I see it could be taken as a personal attack, so > I want to clarify that I consider Emacs to be full of ugly hacks and > that a significant proportion of them come directly from me: > sometimes it's still the best we can come up with :-( > But I obviously still think in this case that the choice of leaving the > text on subsequent lines (after a string with no \ nor closing ") > highlighted as if they were part of the string is a much better option. No it is not. I explained this in detail last Thursday, to which your reply was to snip my explanation, apparently without reading it. You then posed another point to which what you had snipped containe the answer. If you really believe that the old way is better, then I suggest you take up that post of mine from last Thursday and actually debate the issues with me. The fact that it is difficult to get CC Mode's fontification in most other modes which are constrained by the restrictive syntax-propertize-function mechanism is not a good argument against CC Mode; rather it should act as a spur to remove those restrictions from those other modes. > Stefan -- Alan Mackenzie (Nuremberg, Germany).