[vim/vim] make syntax regression - string ending with $$ (Issue #19986)
elenril
elenril created an issue (vim/vim#19986)In a makefile, if I write a recipe containing a string in single or double quotes, ending with '$$' (i.e. an escaped literal dollar), syntax highlighting does not end the string:
foo:
echo "bar$$" baz
In the above, 'baz' is highlighted as being a part of the preceding string.
This regression seems to have been introduced at some point between 9.1.1230 and 9.2.0218.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19986)This seems to be caused by #18403
I think the following patch fixes it:
diff --git a/runtime/syntax/make.vim b/runtime/syntax/make.vim index 0e973237a..9bafa45f3 100644 --- a/runtime/syntax/make.vim +++ b/runtime/syntax/make.vim @@ -38,8 +38,8 @@ if get(b:, 'make_flavor', s:make_flavor) == 'microsoft' endif " identifiers; treat $$X like $X inside makeDefine -syn match makeIdent "\$\$\w*" -syn match makeIdent "\$\$\$\$\w*" containedin=makeDefine +syn match makeIdent "\$\$\w\+" +syn match makeIdent "\$\$\$\$\w\+" containedin=makeDefine syn match makeIdent "\$[^({]" syn match makeIdent "\$\$[^({]" containedin=makeDefine if get(b:, 'make_flavor', s:make_flavor) == 'microsoft'
ping @littlewu2508 can you have a look please?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
littlewu2508
littlewu2508 left a comment (vim/vim#19986)Sorry I admit 35c172e introduce this, but not as @elenril described. Here's what I see:
image.png (view on web)Using vim shipped by Debian 13 with the make.vim from master (1c299f2)
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled May 23 2025 00:48:59)
Included patches: 1-948, 950-1230, 1242, 1244
And the patch provided by @chrisbra does solve the case I see.
I think the real issue is whether $$.... should be highlighted or not. In define...endef block and $$* that uses secondary expansion, it should because $$(something) $$* is a joint variable seen by make since it is escaped to $(something) $*; but if it is in normal rule like "bar$$" it is just an escape to provide a single $ for shell command. It really depends on context, some people may just want to provide $* so $$* is written and * should not be highlighted, and no one can tell if it is a secondary expansion where * should be highlighted without understanding the context.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
elenril
elenril left a comment (vim/vim#19986)> chrisbra left a comment (vim/vim#19986)
>
> This seems to be caused by #18403
>
> I think the following patch fixes it:
> ```diff
> diff --git a/runtime/syntax/make.vim b/runtime/syntax/make.vim
> index 0e973237a..9bafa45f3 100644
> --- a/runtime/syntax/make.vim
> +++ b/runtime/syntax/make.vim
> @@ -38,8 +38,8 @@ if get(b:, 'make_flavor', s:make_flavor) == 'microsoft'
> endif
>
> " identifiers; treat $$X like $X inside makeDefine
> -syn match makeIdent "\$\$\w*"
> -syn match makeIdent "\$\$\$\$\w*" containedin=makeDefine
> +syn match makeIdent "\$\$\w\+"
> +syn match makeIdent "\$\$\$\$\w\+" containedin=makeDefine
> syn match makeIdent "\$[^({]"
> syn match makeIdent "\$\$[^({]" containedin=makeDefine
> if get(b:, 'make_flavor', s:make_flavor) == 'microsoft'
Still looks broken here.
But this does fix it (dunno if it breaks something else):
```
-syn match makeIdent "\$\$[^({]" containedin=makeDefine
+syn match makeIdent "\$\$[^({\"']" containedin=makeDefine
```
--
Anton Khirnov
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
littlewu2508
littlewu2508 left a comment (vim/vim#19986)But this does fix it (dunno if it breaks something else):
-syn match makeIdent "\$\$[^({]" containedin=makeDefine
+syn match makeIdent "\$\$[^({\"']" containedin=makeDefine
I reproduced this fix. That looks weird that this will make a change. I think it should only apply in makeDefine region, which is clearly not in the MWE.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
elenril
elenril left a comment (vim/vim#19986)> littlewu2508 left a comment (vim/vim#19986)
>
>
> <img width="1118" height="392" alt="Image" src="https://github.com/user-attachments/assets/f1cdc5be-e8f4-4d89-b147-6901df5d8476" />
>
> Using vim shipped by Debian 13 with the make.vim from master (1c299f26316cde3f32ec95b7c440e868ada0cb20)
Strange...
I am using Debian vim package 2:9.2.0338-1, with syntax/make.vim
identical to that from git master, and I see this:
https://up.khirnov.net/nmh.jpg
--
Anton Khirnov
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
littlewu2508
littlewu2508 left a comment (vim/vim#19986)Strange...
I am using Debian vim package 2:9.2.0338-1, with syntax/make.vim
identical to that from git master, and I see this:
https://up.khirnov.net/nmh.jpg
I see... maybe my vim version does not distinguish string highlight from normal command. Nevertheless matching the extra " is the undesired behavior and it surely cause string match to extend beyond ".
-syn match makeIdent "\$\$[^({]" containedin=makeDefine
+syn match makeIdent "\$\$[^({\"']" containedin=makeDefine
This surely fix this specific issue and I guess it won't break others', because I suspect any one will use some variable like $" so this might be the solution.
However this does not substantially change the paradox in #19986 (comment) : whether $$ is meant to just provide a $ and following characters does not have to be highlighted, or they are inseparable part of $$ so they need highlight. I believe this will be a much difficult question
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
elenril
elenril left a comment (vim/vim#19986)> In `define...endef` block and `$$*` that uses secondary expansion, it
> should because `$$(something) $$*` is a joint variable seen by make
> since it is escaped to `$(something) $*`; but if it is in normal rule
> like `"bar$$"` it is just an escape to provide a single $ for shell
> command. It really depends on context, some people may just want to
> provide `$*` so `$$*` is written and `*` should not be highlighted,
> and no one can tell if it is a secondary expansion where `*` should be
> highlighted without understanding the context.
be done in a way that limits the impact of the inaccuracies. So a
localized unhighlighted symbol is IMO less bad than string highlighting
spilling into the rest of the file.
--
Anton Khirnov
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
littlewu2508
littlewu2508 left a comment (vim/vim#19986)I'd argue that if highlighting cannot be done fully correctly, it should
be done in a way that limits the impact of the inaccuracies. So a
localized unhighlighted symbol is IMO less bad than string highlighting
spilling into the rest of the file.
Agree. So in this case I fully support your fix because it fixes your severe inaccuracy while I don't see it introduce regressions to other cases. Looking back, this is also the motivation I create #18403: it introduce a large convenience when I develope inside define..endef functions because there's no highlight previously, and at that time I have no idea that it will break others', but as long as we can fix those regressions it worths.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.