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: jit-lock-antiblink-grace Date: Sat, 12 Oct 2019 16:14:00 +0000 Message-ID: <20191012161400.GB9818@ACM> References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="107955"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 12 18:14:16 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 1iJK24-000Rz5-1S for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 18:14:16 +0200 Original-Received: from localhost ([::1]:34728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJK22-0002Nh-UY for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 12:14:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57349) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJK1v-0002NN-Gf for emacs-devel@gnu.org; Sat, 12 Oct 2019 12:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJK1u-0003D0-4u for emacs-devel@gnu.org; Sat, 12 Oct 2019 12:14:07 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:50851 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iJK1t-0003C7-RR for emacs-devel@gnu.org; Sat, 12 Oct 2019 12:14:06 -0400 Original-Received: (qmail 47447 invoked by uid 3782); 12 Oct 2019 16:14:03 -0000 Original-Received: from acm.muc.de (p2E5D584B.dip0.t-ipconnect.de [46.93.88.75]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Oct 2019 18:14:01 +0200 Original-Received: (qmail 9963 invoked by uid 1000); 12 Oct 2019 16:14:00 -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:240927 Archived-At: Hello, Joćo. On Sat, Oct 12, 2019 at 15:23:08 +0100, Joćo Tįvora wrote: > On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii wrote: [ .... ] > > It's a backward-incompatible behavior, and is not being developed due > > to bug reports, so why make it the default right from the start? It > > also slows down cursor motion (which should probably be in the doc > > string as well). > Regarding slowdown, we have to check by how much. Regarding the > pertinence of the modificaiton, there are mode-specific modifications > with (IMO much worse) backward-incompatible behaviour being made to > modes like to c-mode to circumvent precisely this problem. No. The feature in CC Mode I think you're referring to, namely the correct fontification of unterminated strings is a static feature, clearly indicating that the string hasn't (yet) been terminated, and where its current end (as would be interpreted by a compiler) is. The feature you've implemented is, if I understand correctly (I haven't tried it, yet) a dynamic one, where fontification gets delayed a bit to give the user a certain chance to terminate an unterminated string before fontification kicks in. I would guess that your new feature is less needed in a CC Mode mode than in modes where the fontification of a string extends to the next string quote, no matter how far away. > Perhaps you could weigh in on the pertinence of those on-by-default > (and moreover impossible-to-turn-off) alternatives, too. Although > those other modifications target a reduced subset of modes, indeed > precisely because of that fact, I think it's better that Emacs provides > an effective and more generic solution to this problem. I agree with that. My view is that such a feature should be provided in syntax.c and the font locking system, such that a major mode can specify that unterminated strings are to be regarded as terminated by an unescaped new line. I think I said this before, off hand, but it didn't go anywhere. [ .... ] > Joćo -- Alan Mackenzie (Nuremberg, Germany).