0

Every time I upgrade to a new version of Debian (or any other Linux distro), I end up tweaking the blue color in Konsole, which by default is too dark. Here is the screenshot of a portion of a Bash script from Debian 11: Bash script colors on Debian 11

Here is the screenshot of the same (ignore the avconv to ffmpeg change) code snippet from Debian 9 that I have been using since 2.5 years and configured as per my taste: Bash script colors on Debian 9

For sake of context, on both Debian 9 and 11:

  • Konsole color scheme & background setting is White on Black.
  • set bg=dark in ~/.vimrc
  • Font is Noto Mono of size 11.

Notice that the blue is too dark and not very clear (to me). After every fresh install, I manually tweak the Konsole setting and over-ride the color (e.g. #5da3ff) and intense color (e.g. #5daaff) for blue. But this is a manual process and I kind of don't like it.

How can I ensure the same colorscheme across VIM installations on KDE? The blue color issue is not just about VIM. It exists even when looking at directory listing on the terminal. The folks here have much more expertise and understanding of these settings than me. Any suggestion will be appreciated.

1 Answer 1

1

I also find dark blue on black to be unreadable, so I have the following in my ~/.vimrc:

syntax on
set background=dark
hi Comment    term=bold ctermfg=DarkCyan guifg=Blue
hi PreProc    term=underline ctermfg=Cyan guifg=#ff80ff

It tells vim to use DarkCyan in a terminal for Comment and PreProc, which is most (all?) of the things that background=dark normally uses Dark Blue for.


BTW, you really should quote your variables in shell scripts. Curly-braces are not a substitute for quoting (and, aside from their use in arrays and parameter expansion, they're only useful when you need to disambiguate a variable name from surrounding text - e.g. $varx is a variable called varx, while ${var}x is a variable called var followed by a literal x character).

process_nokia() {
    local name
    local ofile
    for f in "$CON_INPUT_DIR"/VID_*.mp4; do
        name="${f##*/}"
        ofile="$CON_OUTPUT_DIR/$(make_output_fname "$name")"
        [ -e "$ofile" ] && continue
        avconv -i "$f" -s "$CON_VIDEO_SIZE" "$ofile"
    done
}

(thanks to gocr for turning that image into editable text)

BTW, as shown above, you can and should nest double-quotes in command substitution. The sub-shell run by command-substitution needs its variables quoted too.

Also BTW, given that process_nokia() is a function, you should probably write it so that you pass either the directory name or a list of filenames to it....perhaps with a default if one is not provided. That would allow you to re-use the same function on any directory. Hard-coding stuff like that in a function and/or making it use a global variable is generally not a good idea. It can have very surprising results if the global var does not exist or does not have the value you expect it to have - sometimes harmlessly surprising, sometimes disastrously. At the very least, if you don't want to pass args to your function, you should check if $CON_INPUT_DIR has a valid value.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .