Because a lot of my mappings use the <Leader> key, this is the only file
that *must* be loaded before all the others, otherwise the value of
leader when the script is read will be erroneous.
I also tried to use `git write-tree` and `git commit-tree` to emulate a
manual octopus merge to preserve the line history for each file. But
honestly that gave a graph that was too ugly for a history that really
did not need that amount of accountability. However it is a fun
exercise, and I recommend to everyone to try it at least once.
See Raymond Chen's blog `The Old New Thing`, with the post titled `How
to split out pieces of a file while preserving git line history: The
hard way with commit-tree`, for an explanation.
The escape sequence to display a title for Xterm and Termite is the
same, and the export for the current directory does not seem to have any
negative impact on Xterm.
The VTE script uses `$HOSTNAME` which is a bashism for `$HOST`, so this
needs a correction in my shell profile.
Instead of re-writing the same condition each time, I put the function
in an autoload plugin instead (which is going to be loaded just about
every time I start writing code, but that's neither here nor there) to
stop repeating myself.
For some reason the script to set-up VTE terminals does not set-up the
precmd which is supposed to display the username, host, and working
directory in Termite's title.
Dunst can overwrite a notification if we give it an id (an integer
value) or a name (a string). This allows for displaying a single
notification when incrementing/decrementing the brightness multiple
times in a quick succession.
I was starting to get annoyed by all the spell-checks happening inside
strings and comments that underlined words which are not mistakes but
also not in the dictionary.
I don't like the colors of the gruvbox theme in lightline because errors
and warnings are not highlighted. I could fix the theme, but I've been
using instead wombat for a while and find that it looks perfectly fine.
This little script will look at your current working directory and its
parent directories to source local configuration files (very useful for
Python projects, or the way I build TC with a local PATH pre-pended).
It works relatively well but still is a very fragile solution that
depends on the order in which the shell has sourced its files. Because
the Termite script kept erasing the previous PROMPT_COMMAND value for
Bash I had to change to source it at the beginning of my configuration
file.
You're supposed to undo the changes that you made to a buffer's
variables when doing filetype-related settings. The variable
'b:undo_ftplugin' contains the commands necessary to revert any changes
that you have made to accomodate this filetype.
I removed the mappings for left and right in a quickfix windows because
I don't use them, and the 'qf' plug-in already maps those (meaning I had
an error when I tried to unmap them after qf already did so).
Sometimes it is useful to also have the base file accessible when
merging branches. This view still has the local file on the left and the
remote branch on the right, with the base in the middle and the result
at the bottom.
The d1o/d2o/d3o take from the local/base/remote for the current file.
I really like the way vim-fugitive show a merge conflict by having our
local index on the left (the target), and the remote changes on the
right (what we're trying to merge with our branch). The result is
obviously the file in the middle.
The d2o and d3o mappings take from local/remote for the current chunk.
It also supports navigating the location list history when inside a
location list.
The autoload plug-in idea was taken from this Vimways article:
<https://vimways.org/2018/colder-quickfix-lists/>
I want the core and the user settings on top, all but the alias sections
and sections added by plug-ins to be in alphabetical order, then the
aliases, followed by plug-in related settings (such as git-lfs).
I like having some colors for the meta-information shown during
diff operations.
Using the `diff-hightlight` script, you can get character-level
highlights of your diffs (just like GitHub and GitLab).
If you don't have this option, less will just start outputting from
wherever your cursor was (so the line where you were writing your
command), but any movement would make it snap to the top of the
terminal.
This makes it clear the screen before doing its first draw, making the
output systematically start from the top.
