This repository contains configurations of several of the tools that I use, and that I try to share and have in sync with different machines. Sharing your configurations (specially your vimrc file) on a public Git repository is quite common, but I finally dared to do it thanks to a great Vim and Git promoter, Drew Neil, who made a great screencast on keeping in sync your Vim configuration with Git and Github.
Warning
|
This configurations, and even this README file is not in its best shape right now. Since 2016, I had to work on a quite convoluted C++ project which involved too much work to make Vim and its ecosystem work properly. In addition, I had some highly time consuming personal and familiar duties, which made things worse. Since then, I switched to Neovim (which has a much better, but rapidly changing ecosystem), but I did so gradually, and not always being up to date with the latest versions (even though I managed to contribute a small feature to Neovim myself!). So there is still a lot of legacy in my settings and plugins. Even in my notes about the plugins that I want to look into, there is cruft pending to be cleaned. Apologies if something is confusing, and don’t hesistate to ask me questions. |
Besides some little things in the vimrc
file, I started putting some things
that eventually could grow to a plugin in it’s own in the plugin directory. For
example, foldcomments.vim
tries to imitate a feature that I’ve learnt to love
from Qt Creator: fold the first comment of a file (because
it tipically is a copyright notice which might contain lots of repetitive
information from the same project). Look at them in dotvim/plugin
.
I also have a Neovim-only "remote plugin" written in ruby, which allows to sort
lines based on a certain "header". Like when a list of items in Asciidoc needs
to get sorted alphabetically, but each entry spans more than one line. Or when
you want to sort some blocks of code of switch
/case
based only on the line
containing the case
(and everything below it should be respected). A somewhat
valid alternative would be the
AdvancedSorters plugin, which is just VimL, but seems a mess to install, with
two dependencies for such a simple thing (and doesn’t seem to be officially on
Github, Gitlab or any other project management system).
In other dotvim
subdirectories there might be some personal or even common
sense settings. Or plain fixes to the lack of completeness of the file type
support in Vim. Blame the stupidity of the Vim development model for not sending
the changes upstream.
I always keep forgetting how dictionaries work. The usual place where I find the
help is the Vimcasts episode on
spell checking and the linked article. However, the linked article mentions
dictionaries in aff
and dic
formats, while I just did:
:mkspell en /usr/share/dict/american-english
And then moved the en.utf-8.spl
file to the spell
subdirectory.
Get the files and set symbolic links like the following:
-
git clone --recursive [email protected]:suy/configs.git
-
ln -s configs/vimrc .vimrc
-
ln -s configs/dotvim .vim
-
ln -s configs/bashrc .bashrc
-
ln -s configs/screenrc .screenrc
-
ln -s configs/inputrc .inputrc
Etc.
I automated it a bit by adding a Makefile, so I normally just do:
-
make setup-unix
But you can choose which ones to get. I used to have a setup-windows
, but I no
longer use Windows that much.
The odd setup for gitconfig is because coworkers used to clone my repo and use it right away without really understanding what were doing, and they had trouble with the user name and email.
-
git submodule foreach git pull
-
git add dotvim/bundle && git commit
You maybe want to be safe, and do git fetch instead of git pull. Then check the changes using something like git log master..origin/master.
If you want to provide a patch for a plugin that you are using, and you want to use that patch right away, you might need to switch the URL of the repository to the one of your fork. You will have to add your remote to the repository, create the branch, do the fix, commit and push to a public place. Now you will have to update the .gitmodules file (since now your commit is in a different URL), and do git submodule sync to make the .git/config file in sync with .gitmodules. When you receive updates with git pull, you might need to do also a git submodule sync before the update, or otherwise it will be impossible for Git to find the commit in the old repository.
Removing a submodule used to be a bit tedious with older git versions. Newer
ones seem to be more convenient and a simple git rm submodule
works does it
all.
Since I end up searching for the recipe online just in case I forget something, here is it, copied from the Git Wiki:
-
Delete the relevant line from the .gitmodules file.
-
Delete the relevant section from .git/config.
-
Run git rm --cached path_to_submodule (no trailing slash).
-
Commit the superproject.
-
Delete the now untracked submodule files.
Or, if you install git-extras, the git remove-submodule command is provided.
Externally available, typically:
Packaged:
-
aptitude
-
tmux, tmuxinator
-
neovim, neovim-qt, wl-clipboard, xclip
-
git
-
build-essential, clang, cmake, ninja
-
clangd
-
icecc, icecc-monitor
-
vlc
-
silversearcher-ag
-
Install nvim-lspconfig
-
Install clangd
-
Make clangd symlink to clangd-12
-
Add
lua require('lspconfig').clangd.setup{}
to vimrc (or a much more involved function that actually makes mappings).
This is like a to-do (which the next section is also about), but more up to date with current priorities and moving to Neovim.
-
Move more things packages from the pathogen setup, if needed. I need to think about the "conditional" support of some plugins, that with pathogen I’m able to blacklist. Probably the solution is just to put stuff which might be loaded or not on the "opt" directory, then load it normally. Don’t assume that stuff in "start" is the new default.
-
Smart input, pairs of characters, etc. Consider smartinput vs lexima vs endwise vs who knows what.
-
See also :help file-change-detect (:help watch-file in Nvim 0.5). (neovim/neovim#1936 (comment)).
-
I’ve found that
packagepath
is huge. There are directories for flatpak and other stuff that is surely not gonna be ever used. Where are this defaults coming from? There are paths that mention KDE and Plasma, so what’s the deal with that? I think we just need one for the user, one for the system, plus the two "after"-suffixed ones.
Further reading:
I still have much to learn, and there is still too much that isn’t exactly like I want it to be. Lately I’ve been using Vim a lot, so I have many things to tweak in my vimrc. Here are some notes for self reference:
-
Use syntastic properly: learn more about the specific syntax checkers.
-
Tweak viminfo and swapfile configuration.
-
Reorder and reorganize.
-
Test plugins from Kana Natsuno. He has great things there.
-
Add (and learn) stuff for nice C++ completion and refactoring (e.g. neocomplcache).
-
Syntax highlighting for template engines that mix code and markup. Is possible to do it in a generic way? What about context-commentstring, context_filetype, etc?
Evaluate the following plugins:
-
https://github.com/Iron-E/nvim-libmodal (submode-like)
-
https://github.com/frabjous/knap creating as-you-type previews of LaTeX, markdown, and others
-
https://github.com/kana/vim-operator-siege versus https://github.com/rhysd/vim-operator-surround
-
https://github.com/tommcdo/vim-ninja-feet versus https://github.com/thinca/vim-textobj-between
-
https://github.com/wsdjeg/vim-fetch Handle line and column numbers in file names!
To rethink a bit the fonts choice, or even the deployment to each installation of the fonts, consider putting in a submodule: