Syntax highlighting broken by Vim 8.2.1703

[kempniu]

Hi there!

For some reason, a certain Vim commit (revision 8.2.1703) back from September 2020 prevents this syntax highlighting module from working - the filetype is set to bind-named for a named.conf file as it should be, but no syntax highlighting takes place. Unfortunately, I do not have any specific hints for fixing things, sorry :(

All I can say is that after I manually reverted the aforementioned change on top of Vim 8.2.2859 sources, this syntax highlighting module immediately started working again.

Please let me know if I can help with any further debugging and/or testing.

Thanks!

[adscriven]

@kempniu Is this still an issue? If you are able to produce a minimal working example of the problem I'd be interested to take a look.

As the author of 8.2.1703 I would say that though the code is simple, a whole bunch of us spent a great deal of time considering the impact of this change on different Vim configurations, and the effect on backwards-compatibility. It really wasn't trivial. The upshot is that the patch likely fixes a long-standing colorscheme problem for 99% of Vim users, but can't be fully backwards-compatible in every single case. Sorry, but maybe you've hit upon one of those cases.

But if you can produce a minimal code example that demonstrates the problem you are having, and if it's possible for me to refine the patch to take that into account, I would love to do that.

Kind regards, --Antony

[kempniu]

@adscriven Thank you for reaching out! Yes, this issue still affects my environment: with Vim 8.2.4747 and the current master branch of this repository, the filetype is set to bind-named for my named.conf files, but the default console color is used for all their contents. hilinks confirms that the syntax stack changes as I move the cursor around in named.conf files.

If by "a minimal working example of the problem" you mean a minimal syntax file triggering this problem (like a heavily stripped down version of bind-named.vim), then I am afraid I have no idea how to prepare it, we would need @egberts here. If I can help in some other way, I am all ears.

For completeness, I am linking the current patch I am using against Vim 8.2.4747 to revert 8.2.1703. This makes the problem go away, i.e. named.conf syntax highlighting using this project works for me again.

[egberts]

Interesting. I have not push ahead with the latest VIM (due to many other projects).

@kempniu , can you pare down the named.conf to just

options { };

and see how the latest Vim fared?

Sidenote: You may have to fill in a few missing options statement based on its version of Bind9.

[kempniu]

Sure! Let me know if you have any further instructions or requests I can help with.

---

Vim 8.2.4747 (vanilla)

---

Vim 8.2.4747 with 8.2.1703 reverted

[egberts]

Ooooooooooh, That is nasty. This means that the Vim aliasing of highlights has gone awry.

Might take a bit of bisecting of the syntax/bind-named.vim with regard to eliminating the nesting of "hi link": such as eliminating the middle aliases between actual name and Vim-offered highlight keyname; namedStmtKeyword => namedHL_Statement => Type

[egberts]

Try this one-line change in hope to be eliminating the highlight aliases bug for the following line in $HOME/.vim/syntax/bind-named.vim:

    hi link namedStmtKeyword namedHL_Statement

with

    hi link namedStmtKeyword Type

in

vim-syntax-bind-named/syntax/bind-named.vim

Line 6710 in 2d18898

hi link namedStmtKeyword namedHL_Statement

And restart Vim session then let us know if the colorization of options { }; is back or not.

[kempniu]

The change above did not cause the colorization of options { }; to work again in unmodified Vim 8.2.4747. Here is the diff for the record:

diff --git a/.vim/syntax/bind-named.vim b/.vim/syntax/bind-named.vim
index 5c5fc8b..2c9f865 100644
--- a/.vim/syntax/bind-named.vim
+++ b/.vim/syntax/bind-named.vim
@@ -6707,7 +6707,7 @@ syn match namedStmt_ZoneNameIdentifier contained /\S\{1,63}/
 " Top-level statment (formerly clause) keywords
 " 'uncontained' statements are the ones used GLOBALLY
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-hi link namedStmtKeyword namedHL_Statement
+hi link namedStmtKeyword Type
 syn match namedStmtKeyword /\_^\s*\<acl\>/ 
 \ skipwhite skipnl skipempty
 \ nextgroup=

I am certain that the change was applied correctly because it changed the highlight color for the options statement in the Vim build containing the revert of 8.2.1703.

[egberts]

I got this.

[egberts]

Out of curiosity, did ANYTHING get colorized in this unit test text-file?

example-9.18-named.conf

[kempniu]

AFAICT, no.

[kempniu]

I feel silly for only coming up with this idea now, but I think I got closer to getting the bottom of this issue by stripping my local Vim environment (~/.vim/, ~/.vimrc) down to the bare basics. Specifically, I ran some experiments in a home directory which contains only the files provided by this repository in ~/.vim/ (specifically in its ftdetect and syntax subdirectories) and no .vimrc file at all. Here is what I figured out.

It seems that this syntax plugin has some issue with adjusting to a new color scheme when that gets set. Here are some screenshots to help explain this. (All of the tests below were carried out using Vim 9.0.0354 installed from an Arch Linux package.)

---

First, to demonstrate proper behavior, let's open a sample Python script in Vim with only the default settings in effect:

(Syntax highlighting is enabled by default in the Vim package I used.)

Now, let's execute the :colorscheme desert command to change the color scheme:

This works as expected.

---

Let's now open a sample BIND 9 configuration file (the one you provided above) with a ~/.vim/ directory only containing the files provided by this repository and no ~/.vimrc file again:

This looks fine. Now, let's execute the :colorscheme desert command:

This does NOT work as expected. It seems that all syntax highlighting is gone.

...or maybe it does work as expected and it's just my expectations that are off? :-)

---

Anyway, dropping colorscheme solarized from my original ~/.vimrc file seems to have enabled this syntax plugin to work again. Hope this helps!

[egberts]

Thats a great narrow down of the problem.

[adscriven]

hiya folks, sorry for the late reply: been trying to set an afk world record thanks for looking into this everyone -- got me thinking that maybe it's something to do with the syntax file so i took a look if the latest version is still the one linked above, try changing ":hi link" to ":hi def link" -- it's the "default" part that causes links to be saved, allowing them to be restored after a ":hi clear"

…

--Antony

On Thu, 6 Oct 2022 at 02:11, Egbert ***@***.***> wrote: Thats a great narrow down of the problem. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABX5FPPVRPG7IME3BDPU43WBYRLNANCNFSM45HDZTQA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[adscriven]

basically syntax files should always "hi def link"
looking at the obvious places in the docs this doesn't seem explicit, and the docs would probably benefit from an update
my guess why this hasn't been a bigger issue is because people tend to copy, paste, modify to make syntax files

[bnilz]

I am layman to linux/vim and have the same problem on a fresh installation of ubuntu 22.04 with vim 8.2.4919 (shown on startup of vim, or 8.2.3995 in ubuntu softwre)
tried upgrading to 9.0 but still didn't show correct syntax highlighting (there is only one color for the text).
any suggestion how to fix it (at least temporarily)? or there is something else wrong? don't know how to revert to an older version (failed to install vim 8.1 due to missing dependencies).

[egberts]

So, should we be doing the def in the hi def link XXX YYY?

vim-syntax-bind-named/syntax/bind-named.vim

Line 146 in 2d18898

hi link namedHL_Statement Keyword