bug#39277: 26.3; Tcl font lock does not understand quoting

[mvar]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The original case is solved
>> (although the enclosed {"string} is not font-locked as string but I
>> wouldn't consider it an error)
>
> Yes, this is a separate problem and I can't see how to fix it: since
> "everything's a string" in Tcl, it's really not clear what
> `font-lock-string-face` should apply to and what it shouldn't apply to.
>
> The current design is to use it only where "..." is used.  When the code
> is fully under your control it lets you choose (to some extent at least)
> what is highlighted and what is not (by choosing "..." vs {...}), but
> clearly it won't be "right" in all cases.
>
>> plus it fixes the following:
>>
>>     proc foo4 () {
>>        puts "hello}"
>>     }
>>
>> this was marked as valid before your changes but tclsh won't accept it
>> as such - the bracket } inside the string needs to be escaped when
>> inside a proc context (but as a plain statement there's no such
>> requirement).
>
> Indeed.
>

hi again,

i stumbled upon a not-so-rare case where this fix breaks a previously
valid syntax locking. Example:

set a "Testing: [split "192.168.1.1/24" "/"] address"

the closing ] is marked as unmatched (no matching parenthesis found)

notice how the above statement is evaluated by tclsh/wish:

% set a "Testing: [split "192.168.1.1/24" "/"] address"
Testing: 192.168.1.1 24 address
% 

the problem with the unmatched ] can only(?) be solved by escaping both
inner "strings"

set a "Testing: [split \"192.168.1.1/24\" \"/\"] address"

but then this is evaluated into an array

% set a "Testing: [split \"192.168.1.1/24\" \"/\"] address"
Testing: {} 192.168.1.1 24 {} address

i still consider the previously applied fix as an overall improvement,
so perhaps i should open a new bug report for this problem? btw i tried
to come up with some fix but i'm still a looong way from grasping those
syntax & parsing mechanisms (syntax-ppss and friends)


thanks,
Michalis