emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuita


From: João Távora
Subject: Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode
Date: Tue, 9 Jul 2019 16:43:42 +0100

On Tue, Jul 9, 2019 at 4:19 PM Dmitry Gutov <address@hidden> wrote:

> Since the "correct" behavior is a matter of interpretation here, who
> broke what is a matter of interpretation. And I'm sure you can agree
> that "you broke XXX" can be interpreted emotionally.

Anything can (and everything is). That's the nature of being an animal
and not a machine.

So what word/phrasing would you suggest when you need to
unequivocally state that "the actions (of individual A) led to the loss of
a previously verified behaviour X, desired by individual B, such that both
A and B now agree that X is desirable and A is working to
make X work again"?

I don't repeat this gratuitously: I am using it to make an argument
against a feature, listing it in the "cons" part. Other people are
stating facts that they add to the "pros".

> To get back to Clement's question (and maybe I'm just restating your
> opinion here), I think:
>
> * Fontifying "broken" strings only until EOL might be beneficial, at
> least in certain languages, where it's consistent with the syntax. The
> result will be less "blinking".

Depends on how you edit. If the most common case is that
you, for example, C-k kill-line a closing " at EOL away, then yes, you're
right. If the most common case is that you RET newline at the middle
of a string then no, you're wrong. Both can be accidents/mistakes
or deliberate actions. But let's say they are accidents. Which
one is more common? For me it's the RET thing, after which I
usually C-M-u C-M-SPC to fix the situation. So I would experience
_more_ blinking (along with all the other disadvantages).

Consistency with how the compiler views invalid code is not very
important for me, because every view allows me to spot the error
unequivocally (also the compiler probably doesn't care about
this because the compiler doesn't edit code or fontify it).

> * It doesn't seem trivial to implement without breaking a lot of
> pair-matching and quote-matching functionality, because both font-lock
> and the latter features depend on parse status, and buffer can be
> fontified in chunks, etc.

I would agree fully here.

João

reply via email to

[Prev in Thread] Current Thread [Next in Thread]