You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, in romainl/vim-malotru, I have a short "verbatim" block that forcibly sets &fillchars.
Today I was trying to make that block less intrusive, which involved making a backup of the existing &fillchars value, when I noticed that the block was copied for every variant (explicit or, in my case, implicit):
It means that the code in the block is executed at least 2 times: a first time because it is at root of the file and a second time as part of the contextually relevant variant. It wasn't such an issue when the block only had one :set line because it was imperceptible but, now that I am defining variables and adding conditionals and such, it makes things more complicated than they should be.
For reference, this is the first iteration of the new code:
where I save the current &fillchars before changing it to the desired value. Because the code is executed twice, g:malotru_save_fillchars is defined a second time with the customized &fillchars, which makes resetting impossible.
Now, I could add more checks but a) that means more fragility and complexity, and b) the current behavior is quite unintuitive.
The text was updated successfully, but these errors were encountered:
Does it work for you if you move the verbatim block towards the top of the file, before the first Variant and Background directive, in what the help file calls the “global section” (see :help colortemplate-structure?
You've put the block in the scope of Variant: gui 256 16: that is why it appears in every variant. Either put it at the top, as suggested above, or add Variant: gui before it to limit the scope to the GUI variant (whose statements are executed unconditionally). I agree that this is not particularly intuitive, though.
For Colortemplate v3 I plan to allow only one optional verbatim section that always appears at the beginning of a color scheme. That, combined with “discriminators”, which is a new feature, covers all the cases I can think of.
Unless there is a specific reason why you would want to execute arbitrary statements after the highlight groups have been defined.
Hello, in romainl/vim-malotru, I have a short "verbatim" block that forcibly sets
&fillchars
.Today I was trying to make that block less intrusive, which involved making a backup of the existing
&fillchars
value, when I noticed that the block was copied for every variant (explicit or, in my case, implicit):It means that the code in the block is executed at least 2 times: a first time because it is at root of the file and a second time as part of the contextually relevant variant. It wasn't such an issue when the block only had one
:set
line because it was imperceptible but, now that I am defining variables and adding conditionals and such, it makes things more complicated than they should be.For reference, this is the first iteration of the new code:
where I save the current
&fillchars
before changing it to the desired value. Because the code is executed twice,g:malotru_save_fillchars
is defined a second time with the customized&fillchars
, which makes resetting impossible.Now, I could add more checks but a) that means more fragility and complexity, and b) the current behavior is quite unintuitive.
The text was updated successfully, but these errors were encountered: