On Tue, Jul 9, 2019 at 4:19 PM Dmitry Gutov 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