Skip to content

suy/configs

Repository files navigation

Personal configurations

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.

Micro Vim plugins

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.

Usage notes

Update dictionary files

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.

Set up in a new machine

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.

Get updates from the depot

  • git pull

  • git submodule update --init --rebase

Update from upstream repositories

  • 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.

Switch to your fork of a plugin

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.

Remove a plugin/submodule

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:

  1. Delete the relevant line from the .gitmodules file.

  2. Delete the relevant section from .git/config.

  3. Run git rm --cached path_to_submodule (no trailing slash).

  4. Commit the superproject.

  5. Delete the now untracked submodule files.

Or, if you install git-extras, the git remove-submodule command is provided.

Other important tools to install

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

LSP setup

  • 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).

Modernization and leveraging Neovim

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:

To do

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:

To rethink a bit the fonts choice, or even the deployment to each installation of the fonts, consider putting in a submodule: