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.
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.
It's cleaner to only export my modified PATH when I'm logging in,
instead of doing it at each shell launch.
Because Zsh and Bash don't use the same mechanism to let you know you
are in a login session, you gotta check both separately. But that
doesn't matter because lightdm doesn't launch `sh` as a login shell
anyway... So the condition is super messy.
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.
Using 'line-length=80' and flake8-bugbear's B950 warning, I respect
black's formatting of 88 columns max.
The T4 category is related to mypy lints, using the 'flake8-mypy`
plugin.
The max complexity is supposed to make you write shorter functions with
less complexity, using the cyclomatic complexity heuristic.
This file is almost directly taken from black's own flake8
configuration, because I'm using it as a linter and I mostly agreed with
its settings.
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.
Groups needs to have a command-list ending in a semi-colon to register
the ending brace. I did not encounter this issue with Zsh but do have an
error when sourcing the file with Bash.
I want to try it out for a bit, see which one I prefer.
I'll keep my own dmenu theme for now though, because I still think it
might be more adapted in certain use-cases.
Bruno BELANYI