GNU bug report logs - #44465
28.0.50; tcl-mode mismatched parenthesis for nested [strings]

Previous Next

Package: emacs;

Reported by: mvar <mvar.40k <at> gmail.com>

Date: Thu, 5 Nov 2020 12:36:02 UTC

Severity: minor

Found in version 28.0.50

Full log


Message #11 received at 44465 <at> debbugs.gnu.org (full text, mbox):

From: mvar <mvar.40k <at> gmail.com>
To: 44465 <at> debbugs.gnu.org
Cc: mvar <mvar.40k <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: Re: bug#44465: 28.0.50; tcl-mode mismatched parenthesis for nested
 [strings]
Date: Sun, 15 Aug 2021 01:22:50 +0300
mvar <mvar.40k <at> gmail.com> writes:

> After the applied fix in #39277, font locking fails in the following case:
>
> set a "Testing: [split "192.168.1.1/24" "/"] address"
>
> the last bracket ] reports "no matching parenthesis found"
>
> this part:
>
> 192.168.1.1/24"
>
> is not locked as a string, but "/" is.
>
> Note that the whole argument is evaluated properly by tclsh as a
> single contiguous string:
>
> % set a "Testing: [split "192.168.1.1/24" "/"] address"
> Testing: 192.168.1.1 24 address
>
> i can't find a way around this behavior even with escaping the double
> quotes or using single quotes, because doing that will change how the
> argument is evaluated by tcl (array instead of string):
>
> % set b "Testing: [split '192.168.1.1/24' '/'] address"
> Testing: {} 192.168.1.1 24 {} address
> % set a "Testing: [split \"192.168.1.1/24\" \"/\"] address"
> Testing: {} 192.168.1.1 24 {} address
> %
>


i've been trying every once in a while to figure out a solution to this
bug but keep failing.

@Stefan i've added you to cc: in case you can help a bit and provide
some tips.
In the fix for #39277 you've added tcl--syntax-of-quote and also this comment:

(defconst tcl-syntax-propertize-function
  ;; FIXME: Handle the [...] commands nested inside "..." strings.

so my question, is the problem described in this bug report supposed to be fixed as
a regexp in the tcl-syntax-propertize-function rules list or should i try
to extend tcl--syntax-of-quote to cover this case too? I've failed in
both accounts so far, especially the regexp i can't find the proper
pattern to fix this and not break something else (which kind of proves the
saying "you fix 1 problem with regexp - you now have 2 problems" :)

thank you in advance,
Michalis




This bug report was last modified 4 years and 1 day ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.