From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 9 Jul 2019 15:28:35 +0100 Message-ID: References: <20190703105804.GA11238@ACM> <20190704165846.GF5564@ACM> <20190704190100.GG5564@ACM> <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <9d579361-cc1e-d2c0-e4f2-a0e62dba32f2@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000faf00f058d4060df" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="49826"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 09 16:29:39 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 1hkr7g-000Ckf-Sl for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 16:29:37 +0200 Original-Received: from localhost ([::1]:50508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkr7e-0001yc-Ti for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 10:29:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59283) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkr6x-0001yR-3P for emacs-devel@gnu.org; Tue, 09 Jul 2019 10:28:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkr6v-0004fX-H6 for emacs-devel@gnu.org; Tue, 09 Jul 2019 10:28:51 -0400 Original-Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]:44570) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkr6v-0004et-AY for emacs-devel@gnu.org; Tue, 09 Jul 2019 10:28:49 -0400 Original-Received: by mail-io1-xd44.google.com with SMTP id s7so43535493iob.11 for ; Tue, 09 Jul 2019 07:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bStRIkDdS93PGmL7RUp+ES06WNAwVtdzg7GnPoXmHIw=; b=GnJF4L8JaZ3jAVKHmqhtsbhvavtEvAqVWMAMYuGNUzQSoYHp0hMplKBOkbKzzDYHVl 6mzQxS3gH32yteNNu6CIObiNbDWAx0rgoFCUyn4g2H5Xkjip2mRAmWn+PDo157fu4p95 EAC3IVItqSkWssonegElyfVbL4V11GnKQtO9gcjztiNkV2gun2wrvB7o1L5ALURBIKh2 vL4PJWQ3NTqUfNmwtZju3a5GRYAoQI6aUuUaiEM12xDL8nqeFFuAun5eZpQ+EBaMGWV4 hzILhJIrhzMATrkj2Qab5j0NkmSVXyYL3lkkPhC93rWILSpzcULiKsP4iUZJNdWtFdXx E9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bStRIkDdS93PGmL7RUp+ES06WNAwVtdzg7GnPoXmHIw=; b=EUuo2oVLCWPOqEY/C3LqKtv2RZWXZxh5yinpTecYasna0fZf/pEy5nNN4taQRWF9mI 1+S/A7Our0kfxhiSHcEHOVKuckH7xO0tMK+kn0d4aiRKQHi0qraAOLJS9YtrlO014ocu JXoZRGZ86dkC6/M/L43fjk5u8sUkg/dA53v257r9yMYDtLVyw1I7zKp42C1p8vkwtDsz 0LER1vxlqbAD6bdrJW2Qn16OGThKZvYJT3zypxMrVpQ5LkjCg9UWpoasfZJzpBGw9Y8k ixdnll0xQztgbId+pLChRTBKOhn448dL6+r0dHG2D+u49A6lffK/u/NXWJsoA/jBGDGS dvrA== X-Gm-Message-State: APjAAAWUZXmVr16aAMhj1FBwJ5CHoUR6jhYi3b80HKH+dfNScOGYy5cL 4gl72IR01MDSEh+tR5dCauvnrh+fHHC3RERUOmw= X-Google-Smtp-Source: APXvYqw8Ex5yJtpyR8Idb29nhhdxKQE2t48ds8fnKYHw9+E+vHY4k55NSLw8/dPd5qyiRwBoHFr7OhdvkwzKaWsm6N4= X-Received: by 2002:a5d:8049:: with SMTP id b9mr2896981ior.199.1562682528032; Tue, 09 Jul 2019 07:28:48 -0700 (PDT) In-Reply-To: <9d579361-cc1e-d2c0-e4f2-a0e62dba32f2@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d44 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:238444 Archived-At: --000000000000faf00f058d4060df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2019 at 1:33 PM Cl=C3=A9ment Pit-Claudel wrote: > * Fontifying to the end of the line and not past it minimizes refontification in that case > > Is that controversial? I didn't say it was. I don't care about "(re)fontification minimization" because I don't know what that amounts to" care about: - consistency: this is not consistent with how the rest of Emacs works. - distraction: this is just as "distracting", and I actually like the current "global switch" more as it helps me spot the error easily; - efficiency: this might well be less efficient (see below). > > Both situations are wrong, and neither is "more wrong" than the other. > I'm glad we agree. That's why I wrote 'That's not more "correct", of course' You seemed to imply there was some kind of advantage. I don't see which, or at least I don't see any advantage that outweighs the fact that this breaks consistency to virtually all other emacs major modes. In breaking that consistency other minor modes and commands are broken, such as C-M-stuff and electric-pair-mode. > > But the version you propose is much harder to implement, likely less > > efficient, > Strong words :) Are you saying refontifying the whole screen after the > point is faster than just refontifying to the end of the line? In your model, you are not refontifying "to the end of the line". You may have meant to say "to the next closing double quote", which may happen after the end of the screen. While that may be less text, I would expect perfomance of (re)fontification to vary according to the thing being fontified. A large string is probably easier to handle than parsing lots of other types of tokens, which is what you would be doing to the text that was formerly a string. And there's the added complexity to implement this to start with. > > Depending on how it is implemented (certainly how Alan > > implemented it) it breaks things in Emacs core and third-party code. > > But surely the quality of Alan's implementation has little impact on the > worthiness of the feature in general (I'm not arguing about how things > should be in cc-mode today =E2=80=94 just saying that I like the general = idea) Like I said, depends on how you value consistency to other parts of emacs. For example, I particularly value the ease in which the unequivocally wrong situation can be fixed. But even if you develop a very complex implementation (presumably such as the one Alan is developing now) which allows that, it is probably a net loss (in Emacs) because navigation and fontification won't go hand-in-hand like before. > > It is also > > useless in languages which do allow unescaped multi-line strings > And more strong words :) I'm saying it's an option I'd like to have while conceding > it's not universally better, so it surely wouldn't be useless to me ^^ Perhaps I'm not following. What use would it be in a language that does allow unescaped multi-line strings? Say, what use would it be in elisp or ruby? > Do we know what behavior is standard in other IDEs, and whether it is configurable? > On my machine I have vim, geany, gedit, and vscode, and all of the behave like Emacs > currently does (but they refontify immediately, without a jit-lock idle delay). What are you doing with those other editors installed, you heretic? Joke aside, do any of those editors have a paren-matching solution that also does paren-balancing? I remember searching a bit and not finding anything interesting. Curiously, in cc-mode, the behavior is easily configurable (earlier I though it didn't work but it does, it's just not officially "blessed" by the maintainer, and unfortunately not the default). (add-hook 'c++-mode-hook (lambda () (setq c-multiline-string-start-char t))= ) Jo=C3=A3o --000000000000faf00f058d4060df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 9, 2019 at 1:33 PM Cl=C3=A9ment Pit-Claude= l <cpitclaude= l@gmail.com> wrote:

> * Fontifying to the end of the line = and not past it minimizes refontification in that case
>
>= Is that controversial?

I didn't say it was. I= don't care about "(re)fontification minimization" because
I don't know what that amounts to" care about:

- consistency: this is not con= sistent with how the rest of Emacs works.
- distraction: this is just as "distracting", and I actually like= the current "global
switch" more as it helps me sp= ot the error easily;
- efficiency: this might well be less efficient (see below).

=
> > Both situations are wrong, and neither is "more wrong&= quot; than the other.
> I'm glad we agree. That's why I = wrote 'That's not more "correct", of course'

You seemed to imply there was some kind of advantage. I do= n't see which,
or at least I don't see any advantage that= outweighs the fact that this
breaks consistency to virtuall= y all other emacs major modes. In breaking
that consistency = other minor modes and commands are broken, such
as C-M-stuff and = electric-pair-mode.

> >= But the version you propose is much harder to implement, likely less
&g= t; > efficient,
> Strong words :) Are you saying refontifying= the whole screen after the
> point is faster than just r= efontifying to the end of the line?

In your model,= you are not refontifying "to the end of the line".
You may have meant to say "to the next closing double quote", w= hich may
happen after the end of the screen. While that may = be less text, I would
expect perfomance of (re)fontification= to vary according to the thing being
fontified. A large str= ing is probably easier to handle than parsing
lots of other t= ypes of tokens, which is what you would be doing to
the text= that was formerly a string. And there's the added complexity
to implement this to start with.

> > Dependi= ng on how it is implemented (certainly how Alan
> > implemented it= ) it breaks things in Emacs core and third-party code.
>
>= But surely the quality of Alan's implementation has little impact on t= he
>=C2=A0 worthiness of the feature in general (I'm = not arguing about how things
> should be in cc-mode today= =E2=80=94 just saying that I like the general idea)

Like I said, depends on how you value consistency to other parts of
emacs. For example, I particularly value the ease in which the
<= div>unequivocally wrong situation can be fixed. But even if you develop a <= br>
very complex implementation (presumably such as the one Alan = is
developing now) which allows that, it is probably a net l= oss (in Emacs)
because navigation and fontification won'= t go hand-in-hand like before.

> > It is also=
> > useless in languages which do allow unescaped multi-line stri= ngs
> And more strong words :) I'm saying it's an option= I'd like to have while conceding
> it's not universa= lly better, so it surely wouldn't be useless to me ^^
Perhaps I'm not following. What use would it be in a langu= age that
does allow unescaped multi-line strings? Say, what = use would it
be in elisp or ruby?

> Do we know what behavior is standard in other IDEs, and whether it = is configurable?=C2=A0
> On my machine I have vim, geany,= gedit, and vscode, and all of the behave like Emacs
> cu= rrently does (but they refontify immediately, without a jit-lock idle delay= ).

What are you doing with those other editors installed, you = heretic?=C2=A0
Joke aside, do any of those editors have a pa= ren-matching solution that also
does paren-balancing? I reme= mber searching a bit and not finding anything
interesting.

Curiously, in cc-mode, the behavior is easily config= urable (earlier I though
it didn't work but it does, it&= #39;s just not officially "blessed" by the maintainer,
= and unfortunately not the default).

(add-hook '= ;c++-mode-hook (lambda () (setq c-multiline-string-start-char t)))

Jo=C3=A3o
--000000000000faf00f058d4060df--