I'm not really sure why I never turned this on before, but it really
helps to identify exactly the character which I need to differentiate to
continue tab completion.
Printing only an error-type message without information about what
happens afterward is not the most helpful. This commit adds a message
indicating that vscode setup is skipped so that at least that feedback
is provided.
Commit de8ad4ac08 added an include of
~/.user.gitconfig following the global definitions in ~/.gitconfig. What
I had forgotten is that it was included earlier in the
alphabetically-sorted `[include]` section. Oops!
The motivation for this change comes from several reasons and
frustrations with the previous setup used here.
Firstly, the terminfo variables previously provided did not match those
of the familiar-to-me termcap environment variables, not even remotely
close. The color scheme the termcap variables creates is a largely
yellow-and-white theme, while the terminfo variables created a largely
blue-and-white theme. In addition to being unfamiliar, blue tends to be
somewhat hard to read on my dark theme terminals, so it had to go.
Secondly, in my efforts to update the terminfo variables to match the
colors provided by termcap, I found that bright colors (such as the
bright white used for underlined text) did not display correctly, and it
blatantly ignored any attempts to display colors in their default or
bright color variants. Due to the prevalence of underlined text in
manpages, this meant that I could not achieve the desired color scheme
whatsoever.
Finally, maintaining this convoluted `less` version check is something
I'd rather not do. Because terminfo is not universal and I typically use
stable distributions of linux tending away from the bleeding edge, I can
rely on termcap being available for `less` for some time to come, while
terminfo isn't yet available for Debian stable. Given that, I'd like to
maintain only a single set of color mappings for now. And unless I can
overcome the color issue mentioned in the previous paragraph, I doubt
I'll be interested in maintaining a parity between the two.
n.b. In the process of slimming these definitions down, I did a decent
amount of research to find parity in the text types identified by
terminfo and termcap. The following table details those findings. Note
that termcap variables would be set as environment variables in the
format `LESS_TERMCAP_var` and are set to an ANSI escape sequence for a
Select Graphic Rendition (see
https://stackoverflow.com/a/33206814/540162), and terminfo variables are
passed as arguments to `less` in the format `less -Dv` and are set to a
4-bit or 8-bit color string. (see `man less` on systems with `less
--version` >= 580)
| termcap | terminfo | |
|---------|----------|------------------------------------|
| mb | k | blinking text |
| md | d | bold text |
| me | | end bold/blinking text |
| so | s | reverse video (standout) text |
| se | | end reverse video text |
| us | u | underlined text |
| ue | | end underlined text |
| | B | binary characters |
| | C | control characters |
| | E | errors and info messages |
| | M | mark letters in status column |
| | N | line numbers enabled via -N option |
| | P | prompts |
| rs | R | rscroll character |
| | S | search results |
| | W | highlight enabled via -w option |
This bypasses an annoying issue when using both ~/.gitconfig and
~/.user.gitconfig, which is that there is no guarantee of the order
these configs are loaded. This means that configs loaded in
~/.user.gitconfig (which in this case is intended to override
~/.gitconfig) may not actually override those found in ~/.gitconfig. By
using `include.path`, they are loaded a second time, but it guarantees
they are loaded after all the configs in ~/.gitconfig, ensuring they are
used in cases where the key is present in both files.
This alias removes any output which would be generated. By default,
`nohup` generates a `nohup.out` file in the cwd or home directory with
the output from the executed program. Most of the time I don't need to
monitor the program's output, and when I do, I can easily run `\nohup
<program>` to circumvent this alias.
As far as external motd programs go, neofetch seems to be
better-maintained than screenfetch, and has some features I prefer like
incremental printing and a fairly robust configuration.
For a system which does not have a VSCode installation, other parts of
setup should still be attempted even if these particular configs can't
be put in place.
As-is, the `column -t` invocation works very poorly and is effectively
useless as it can't communicate the information it ought to. For the
time being (until the next Debian stable coreutils update) the format
`alias = 'cmd'` is more readable and useful. This commit also expands a
good bit on the ideal command chain of the post-coreutils update alias
and the possible issues left to solve after that implementation is done.
While `/bin/bash` is the default in many systems, it cannot be relied
upon for _all_ systems, particularly ones such as MacOS where the
default `/bin/bash` is a very old version. Instead, use the `bash`
executable from the system's PATH.
