Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]

On Tue, Jul 9, 2019 at 5:05 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:
>
> On 2019-07-09 10:28, João Távora wrote:
> >
> > On Tue, Jul 9, 2019 at 1:33 PM Clément Pit-Claudel <
cpitclaudel@gmail.com <mailto: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ão

[-- Attachment #2: Type: text/html, Size: 5511 bytes --]