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.
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.
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).
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/>
ALE can detect if the file you're currently editing is inside a Pipenv
environment, and use the pyls inside your environment to have access to
module definitions.
This doesn't launch pyls inside Pipenv when there's no environment
active for your file.
I want shellcheck to detect which shell is most appropriate on the `sh`
filetype, but explicitly use the `bash` dialect on `bash` and `zsh`
filetypes.
I also really don't like nullary conditions in shell, so I'll screen for
those too.
I might turn on the 'quote-safe-variables' check too, because I think
quoting variables is a good habit to take.
Bruno BELANYI