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.
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.
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.
This introduces the '.vim' folder to my dot-files repository. I'll have
to think about splitting my '.vimrc' file into multiple files inside the
'.vim' folder.
I usually code in C99 and C++17 because that's EPITA's guidelines.
I'll have to check out the new C11/C18 features (notably threading and
type genericity...) someday.
I wanted to try something else, lightline seems more fun than the vanilla
statusline, and easier to modify than airline.
This is the bare minimum of status bar for me, without powerline
separators because I don't like them very much, and with basic
vim-fugitive integration.
Bruno BELANYI