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

[Clément Pit-Claudel]

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

> - 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.

>> > 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 :)

> 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.

>> > 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.  
If I have this text:

  s = "xyz
  def main():

I prefer def main() to be highlighted as if it wasn't inside a string.  

> 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?

>> > 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?

That's a good point.  I misunderstood your original statement.

>> 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.

I'm not sure.