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 17:32:01 +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="0000000000006257a3058d421ac6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="48074"; 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 18:34:27 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 1hkt4V-000CJs-2C for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 18:34:27 +0200 Original-Received: from localhost ([::1]:51892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkt3r-0001KA-LC for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 12:33:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36673) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkt2P-0001H6-3M for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:32:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkt2N-0003J9-BB for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:32:17 -0400 Original-Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]:33152) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkt2N-0003IL-4j for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:32:15 -0400 Original-Received: by mail-io1-xd41.google.com with SMTP id z3so29536574iog.0 for ; Tue, 09 Jul 2019 09:32:14 -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=VFcWyalHylvd0y7Sxh+vHlviFfds00nNDAlrbR05B1A=; b=U0Fs22YUDIRGVYzpRxHus4s8nCmgPNVVgygV+6JdWN7/oLpIvxk/5LLe7rXNDsr3GJ 3HretA8pZt5JKGToYjzQQWqSLD1OH9bhQ5RczS7azHqgiuVJXEmM790FnBTb/4GdTP1t 4T0wV6Ef2rKKKnLiUtwBE108lple+7BMNbhkA98uYwj+1qqgLIcrtA0khhfZGGeQ5VJH D3dK5fk1tk0p6aiMBHRWHPCgq/ucUSXGcJFuvh8Kk25M50S7dgTVxSQqMIxL6J9u3Fvw K8PawjD4aZaS0MdV3jOgzzhf4NpMAYTdsdBIarYScoIJRZd4aZLoamzYKBSE1WWKjA3x Xpnw== 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=VFcWyalHylvd0y7Sxh+vHlviFfds00nNDAlrbR05B1A=; b=iSZeCNvo793U0ftkOw2T5XDtLtxw/tJNbtdK7kFpkLe3f5nICD2Wp9/FGlhug4jsqd tpuM4eKiw1nUM4iownnPw5hA345ho9phzxMc+17R+sjwqmSGZteO28TE7wn0Hw5IokG0 T4sD/JCW7NoEKEzBkcu37snMwhPr1tXIloPcmbopLk+YUJXWXDVN37XseyuocxY1vLVN yScDmlDz6B57H4hhdQHXAZ7a682PPXilfe5snELS8ddnVjlfByS/J3P+Kq/GKtZZ6D+N cqFx/L8Ke86zbRSLz7oQSBaZxgVwxIRsEmaGsOzlXf+1WjNpxM0aVYo+MLKdafOTS77i Zemg== X-Gm-Message-State: APjAAAVY4qP8W+5emqCYoGQxy3RDQuU2EycrLuPlxtbF0Zb7pRHz9obS 96wDCx4mQ7CsSzmBACjTDT1wdoL1yoIUq6Z6CEQ= X-Google-Smtp-Source: APXvYqwsh0yugV+eFW3Fm7lnWuLYhed1X7c7v/bdz0D6AuavEn36JIbFepOyCdMmgn+oVURpL8uuSgNueAqkmDtcemg= X-Received: by 2002:a6b:b214:: with SMTP id b20mr25978689iof.149.1562689933562; Tue, 09 Jul 2019 09:32:13 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d41 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:238464 Archived-At: --0000000000006257a3058d421ac6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2019 at 5:05 PM Cl=C3=A9ment Pit-Claudel wrote: > > On 2019-07-09 10:28, Jo=C3=A3o T=C3=A1vora wrote: > > > > On Tue, Jul 9, 2019 at 1:33 PM Cl=C3=A9ment Pit-Claudel < cpitclaudel@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. > > You wrote "No, it doesn't". I wrote that we you said it would "minimize refontification and blinking". I still believe that, that it _doesn't_ minimize blinking, at least how I use Emacs (more on that below). In your follow up you dropped the "blinking" part, and kept the "minimize refontification" thing. And so that part is not "controversial" (it's also not very interesting, as I tried to explain afterwards). > > > I don't know what that amounts to" care about: > > > > - consistency: this is not consistent with how the rest of Emacs works. > > Which rest of Emacs? I'm saying I'd happily use an option all major modes to work the way Alan did it in cc-mode. But below you agree with me that it does't make much sense in elisp or ruby. > > - distraction: this is just as "distracting", and I actually like the current "global > > switch" more as it helps me spot the error easily; > > For me there's no error to spot: in the course of typing a string, I type its opening ", > then its contents, and then its closing ". The rest of the buffer being painted in > string color is distracting, and it doesn't help me spot any error. Of course. For me it never happens, _becauue I use electric-pair-mode_. But it also probably would happen quite infrequently, if instead of electric-pair-mode, I used another popular paren-matching package such as smartparens, or paredit, or whatever. So, again, it has to do with how you write code. > >> > 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= , > > But I told you, didn't I? I said I'd like it better because I don't like my buffers blinking :) But _I_ don't see which, because I don't use Emacs the way you do. In the next message I can start to sell the benefits of electric-pair-mode. Oh what the heck, I can't help myself: it is designed to have you type _exactly_ the same keys as you do now, while never unbalancing the buffer. No blinking, really. Heck even smartparens will give you that, in principle. > > or at least I don't see any advantage that outweighs the fact that this > > breaks consistency to virtually all other emacs major modes. > > It would break consistency with those major modes that allow > multi-line unescaped strings, indeed. I'm not too bothered by that. OK. But let's not make it the default. Let consistency breakage be a user-customized exception, not the norm. > >> > 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. > > No, I meant what I say: to the end of the line. > > While that may be less text, I would > > expect perfomance of (re)fontification to vary according to the thing being > > fontified. > > In the model I'm describing, you don't have to refontify anything > except the current line. Am I missing something? You and I are, I was talking about your "model" but assuming a different usage pattern situation where you strip off a closing backslash at the end of a multi-line string. Also I'm assuming you are editing code, not writing code from scratch. The latter never brings such problems, because I use a paren-matching solution. Jo=C3=A3o --0000000000006257a3058d421ac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >
> > I don't know what that amounts to&q= uot; care about:
> >
> > - consistency: this is not consi= stent with how the rest of Emacs works.
>
> Which rest of = Emacs? I'm saying I'd happily use an option all major modes to work= the way Alan did it in cc-mode.

But below you agr= ee with me that it does't make much sense in
elisp or ru= by.

> > - distraction: this is just as "= distracting", and I actually like the current "global
> >= ; switch" more as it helps me spot the error easily;
>
&= gt; For me there's no error to spot: in the course of typing a string, = I type its opening ",
> then its contents, and then = its closing ".=C2=A0 The rest of the buffer being painted in
> string color is distracting, and it doesn't help me spot any= error.

Of course. For me it never happ= ens, _becauue I use electric-pair-mode_.
But it also probabl= y would happen quite infrequently, if instead of
electric-pa= ir-mode, I used another popular paren-matching package
such = as smartparens, or paredit, or whatever.

So, again= , it has to do with how you write code.

> >&g= t; > Both situations are wrong, and neither is "more wrong" th= an the other.
> >> I'm glad we agree. That's why I wrot= e 'That's not more "correct", of course'
> >=
> > You seemed to imply there was some kind of advantage. I don&#= 39;t see which,
>
> But I told you, didn't I?=C2=A0 I = said I'd like it better because I don't like my buffers blinking :)=

But _I_ don't see which, because I don't = use Emacs the way you do.

In the next message= I can start to sell the benefits of electric-pair-mode.
Oh what = the heck, I can't help myself: it is designed to have you type
_exactly_ the same keys as you do now, while never unbalancing the
buffer. No blinking, really. Heck even smartparens will give you t= hat,
in principle.

> > or at least I don't= see any advantage that outweighs the fact that this
> > breaks co= nsistency to virtually all other emacs major modes.
>
> It= would break consistency with those major modes that allow
&= gt; multi-line unescaped strings, indeed.=C2=A0 I'm not too bothered by= that.

OK. But let's not make it the default. = Let consistency breakage be
a user-customized exception, not the = norm.

> >> > But the version you propos= e is much harder to implement, likely less
> >> > efficient,=
> >> Strong words :) Are you saying refontifying the whole scr= een after the
> >> point is faster than just refontifying to th= e end of the line?
> >
> > In your model, you are not ref= ontifying "to the end of the line".
> > You may have mea= nt to say "to the next closing double quote", which may
> &= gt; happen after the end of the screen.
>
> No, I meant what I = say: to the end of the line.
> > While that may be less text= , I would
> > expect perfomance of (re)fontification to vary accor= ding to the thing being
> > fontified.
>
> In the mode= l I'm describing, you don't have to refontify anything
> except the current line.=C2=A0 Am I missing something?
You and I are, I was talking about your "model" but = assuming a
different usage pattern situation where you strip= off a closing
backslash at the end of a multi-line string. = Also I'm assuming you
are editing code, not writing code= from scratch. The latter never
brings such problems, becaus= e I use a paren-matching solution.

Jo=C3=A3o
--0000000000006257a3058d421ac6--