Adventures in Vim: Lee and Jim figure out how to change comment colors

Enlarge / Who would not like cyan feedback of their textual content editor? Lee Hutchinson, that is who.

Jim Salter

One advantageous Monday morning, Ars Technica Senior Expertise Editor Lee Hutchinson got here to me with an issue: the colours in his textual content editor, in his humble opinion, had Begun To Suck.

In Lee’s 20 years or so of Vim utilization, he’d gotten accustomed to remark strains in his code and configuration information being rendered in darkish blue. However after upgrading a machine to Ubuntu 20.04, Vim began rendering feedback in cyan—and because the “Identifier” syntax class additionally rendered in cyan, he was sad sufficient about it to resolve to alter the defaults.

At first blush, Vim appears to stick to roughly the identical configuration commonplace that many if not most Unix-like techniques and purposes do—there is a set of systemwide configurations in /and so forth, which could be overridden individually per person by modifications made in an non-obligatory configuration file in that person’s residence listing. In Vim’s case, that is ~/.vimrc—similar to Bash configurations could be overridden in ~/.bashrc.

However when Lee tried to make his One Easy Change to Vim’s syntax highlighting—flip feedback from the brand new cyan again into the darkish blue, which he most well-liked—issues bought attention-grabbing.

The Hutchinson option to configure remark highlighting

After somewhat googling, the command Lee discovered to alter remark shade appeared to be fairly easy: spotlight remark ctermcfg=19, the place 19 is the colour code Vim makes use of for darkish blue. The issue is, making the change in ~/.vimrc did not really work.

To be extra particular, it did work—briefly—however nearly instantly after opening the file, the feedback modified from darkish blue again to cyan once more. On an area, quick machine, the change occurred too rapidly to note; however Lee was ssh’ing right into a distant machine, and that gave simply sufficient delay to see his shade choice utilized initially however rapidly reverted.

After vital googling, Lee found an unsightly workaround. There is a very previous joke that Vim is not really a textual content editor in any respect—it is an working system in its personal proper, which merely masquerades as a textual content editor. Like most good jokes, this one’s a bit excessive however has a kernel of reality to it—Vim config information do not merely assign values to configuration variables; they’ll really run code in their very own proper.

In Lee’s case, he determined that, since there was a roughly 100ms delay between his darkish blue feedback being utilized and Vim altering them again, he might simply outwait this system by ready 100ms to use the change within the first place:

operate DelayedSetVariables(timer)
    spotlight remark ctermfg=19

let timer=timer_start(16,'DelayedSetVariables')

Positive sufficient, the ugly hack labored: now, as an alternative of seeing darkish blue feedback initially that then flashed again to the hated cyan, Hutchinson noticed cyan feedback that then flashed to his most well-liked darkish blue.

This labored effectively sufficient for his functions… however what is the level of being a senior expertise editor if you cannot run an issue previous a expertise reporter who stories to you?

The mistaken approach… really, a number of mistaken methods

When Lee introduced his kinda-solved drawback to me, it definitely seemed like a bug—I may not be a Vim person myself, however with greater than 20 years of Unix-like OS expertise beneath my very own belt, I additionally anticipated a user-profile configuration file to cleanly overwrite a system-wide configuration. The unhinged ranting coherent, centered drawback report Lee provided me included a warning: there have been, in his phrases, “about 20 totally different locations the place Vim configuration modifications get utilized,” so monitoring down the issue was unusually sticky.

I am not a Vim person myself—I am a kind of heathens who by no means noticed any specific cause to study extra about Vim than the :q! wanted to get the hell out of it—however my quick suspicion was {that a} bug was inflicting Vim configuration information to be utilized out of order. So I googled how one can verify what configurations had been utilized to a operating Vim occasion: turns on the market’s a particular command :scriptnames that can give you precisely that.

  1: /usr/share/vim/vimrc
  2: /usr/share/vim/vim81/debian.vim
  3: /usr/share/vim/vim81/syntax/syntax.vim
  4: /usr/share/vim/vim81/syntax/synload.vim
  5: /usr/share/vim/vim81/syntax/syncolor.vim
  6: /usr/share/vim/vim81/filetype.vim
  7: ~/.vimrc
  8: /usr/share/vim/vim81/plugin/getscriptPlugin.vim
  9: /usr/share/vim/vim81/plugin/gzip.vim
 10: /usr/share/vim/vim81/plugin/logiPat.vim
 11: /usr/share/vim/vim81/plugin/manpager.vim
 12: /usr/share/vim/vim81/plugin/matchparen.vim
 13: /usr/share/vim/vim81/plugin/netrwPlugin.vim
 14: /usr/share/vim/vim81/plugin/rrhelper.vim
 15: /usr/share/vim/vim81/plugin/spellfile.vim
 16: /usr/share/vim/vim81/plugin/tarPlugin.vim
 17: /usr/share/vim/vim81/plugin/tohtml.vim
 18: /usr/share/vim/vim81/plugin/vimballPlugin.vim
 19: /usr/share/vim/vim81/plugin/zipPlugin.vim
 20: /usr/share/vim/vim81/scripts.vim
 21: /usr/share/vim/vim81/syntax/perl.vim
 22: /usr/share/vim/vim81/syntax/pod.vim
Press ENTER or sort command to proceed

Lee hadn’t been kidding in regards to the huge array of configuration information to look via: my system loaded 22 separate configuration information, 15 of which took impact after the .vimrc in my residence listing! Thus started the beginning of a protracted, winding, and finally fruitless primrose path: I needed to seek out cases of the remark shade being modified someplace after my ~/.vimrc, and it turned out that simply wasn’t taking place.

The one place I might discover the place remark shade was set to Cyan was in /usr/share/vim/vim81/syncolor.vim, a few areas forward of my private .vimrc. In concept, the change in ~/.vimrc ought to have overridden the one in syncolor.vim—however in observe, with out Lee’s ugly timer hack, the one approach I might discover to alter the remark shade was inside syncolor.vim itself.

" Many terminals can solely use six totally different colours (plus black and white).
" Subsequently the variety of colours used is saved low. It would not look good with
" too many colours anyway.
" Cautious with "cterm=daring", it modifications the colour to shiny for some terminals.
" There are two units of defaults: for a darkish and a light-weight background.
if &background == "darkish"
  SynColor Remark      time period=daring cterm=NONE ctermfg=Cyan ctermbg=NONE gui=NONE guifg=#80a0ff guibg=NONE

Altering ctermfg=Cyan inside syncolor.vim to ctermfg=19—or, higher but, ctermfg=DarkBlue, which produced an easier-to-read shade of blue—labored as anticipated, and it produced the output Lee needed with out the god-awful timer hack. Nevertheless it utilized the change systemwide, not simply to Lee’s personal person account—and extra importantly, it did not clarify how or why the unique change in ~/.vimrc refused to work as anticipated.

I nonetheless smelled an out-of-order bug, so I dug additional.

" Vim syntax assist file
" Maintainer:   Bram Moolenaar 
" Final Change:  2001 Sep 12

" This file units up the default strategies for highlighting.
" It's loaded from "synload.vim" and from Vim for ":syntax reset".
" Additionally used from init_highlight().

In accordance with the feedback on the prime of syncolor.vim, the modifications inside that file have been utilized in three circumstances—when synload.vim is parsed throughout Vim initialization, when the person points the command :syntax reset, and throughout the Vim operate init_highlight(). I knew neither Lee nor I used to be calling for :syntax reset, so I proceeded to seek out the invocation of syncolor.vim from inside synload.vim.

" Set the default highlighting colours.  Use a shade scheme if specified.
if exists("colors_name")
  exe "colours " . colors_name
  runtime! syntax/syncolor.vim

If I put the easy spotlight remark ctermfg=19 again into my ~/.vimrc, and commented out the runtime! syntax/syncolor.vim in synload.vim, I believed every little thing ought to work correctly: this could nonetheless qualify as an unsightly hack, in fact, however it could slim down the place the issue habits was coming from and permit me to write down a extra precise bug report back to file with the Vim undertaking.

Sadly, it did not work that approach: even with runtime! syntax/syncolor.vim commented out, the Cyan feedback that file specified overrode the easy setting in my ~/.vimrc. This meant the configurations there have been being referred to as by Vim’s init_highlight() operate after it parsed ~/.vimrc.

On the one hand, this definitely nonetheless smelled like a bug to me: I could not override a easy configuration setting from my user-level rc file. Then again, did I point out the 20+ years of open supply expertise? I wanted to make sure I wasn’t lacking one thing apparent that will trigger a bug report to only get rejected with a #WONTFIX as a result of I would missed some deliberate Vim idiosyncrasy.

Discovering the best approach

Since Vim’s configuration information had self-documenting feedback, the time had come to learn them extra totally. I would already realized that the contents of syncolor.vim have been utilized by init_highlight() and synload.vim—however I wanted to dig additional.

I could not get any additional with the documentation feedback on the prime of synload.vim or syncolor.vim, however the subsequent clue got here from the code in syncolor.vim itself:

if syntax_cmd == "allow"
    " ":syntax allow" retains any present colours
    command -nargs=* SynColor hello def 
    command -nargs=* SynLink hello def hyperlink 
  elseif syntax_cmd == "reset"
    " ":syntax reset" resets all colours to the default
    command -nargs=* SynColor hello 
    command -nargs=* SynLink hello! hyperlink 
    " Consumer outlined syncolor file has already set the colours.

Clearly, there was some correct option to set user-defined colours, since this if block particularly prevented setting them up if a “person outlined syncolor file” already had. So the following step was to Google “vim person outlined syncolor file.” The highest search end result was the supply for syncolor.vim itself on Github, however the second end result introduced me to Vim documentation at SourceForge.

Performing a ctrl-F syncolor in-browser search on this 5,128-line doc finally bought me to the knowledge I wanted, about 90 % of the best way down the web page:

If you wish to use totally different colours for syntax highlighting, you'll be able to add a Vim
script file to set these colours.  Put this file in a listing in
'runtimepath' which comes after $VIMRUNTIME, in order that your settings overrule
the default colours.  This fashion these colours can be used after the ":syntax
reset" command.

For Unix you should use the file ~/.vim/after/syntax/syncolor.vim.

Lastly, I would discovered the proper reply to the deceptively easy query “How do I modify remark shade inside Vim?”: after creating ~/.vim, ~/.vim/after, and ~/.vim/after/syntax, you’ll be able to lastly create the file ~/.vim/after/syntax/syncolor.vim—and modifications made to syntax spotlight colours there utilized the best way that Lee and I anticipated them to.

Petting the shaggy canine

Hopefully, you’ve got realized one thing alongside the best way as you learn this god-awful shaggy dog story of configuring a Linux utility. Perhaps you, too, simply needed to alter some colours in a textual content editor—by which case I’ve led you down an absurdly lengthy path simply to get to a comparatively brief reply.

However extra importantly, I hope the train in full can function a broader train in troubleshooting. Completely satisfied Linux-ing!

Source link
Compare items
  • Total (0)
Shopping cart