Ownership of vim files if running with sudo -E

[ayekat]

When running vim with sudo -E vim, backup-, undo-, swap- and other files (e.g. plugins) are created as root. That is usually not a problem, as the containing directories (~/.local/var/lib/vim/{undo,swap}, ~/.local/run/vim/backup) are usually owned by the regular user.

... that is, if the directories have been created by the regular user. For files under ~/.local/var/lib/vim, that would be the first time after the dotfiles have been set up (so this issue generally doesn't really arise), for files under ~/.local/run/vim the first time after the system has booted (this does happen every now and then).

There should be a way to make sure that the permissions on those directories are correct; for the moment, I regularly find myself chowning ~/.local/run/vim/backup if the first invocation of vim after a system boot-up was with sudo, which is a bit annoying.

[ayekat]

It might be worth looking into setting up a user-instance of tmpfiles.d. This would allow us to get rid of quite a few "make sure the damn path exists"-like configuration, not only for vim (e.g. zsh/shell initialisation comes to mind).

[ayekat]

I think there are multiple issues with running sudo vim, so trying to find workarounds for problems caused by it is the bad approach.

I advise myself to instead use sudoedit (or sudo -e). The downside is that I lose file history tracking for system-wide files, but A that is more of a convenience feature and not the main job of vim, and B there is a semantical issue there anyway (because a file can theoretically be modified through any other means as well, so state information must be expected to become invalidated). And semantical correctness is pretty high-priority for me.

tmpfiles.d is worth looking at (there is still lighttpd, for instance), but that should be addressed in a separate issue.

Closing this one.