dotvim VS chezmoi

I have a whole file full of mappings like this that let Vim recognize various special key combinations from any terminal emulator I've used in the last 20 years. It's a mess: https://github.com/mgedmin/dotvim/blob/master/plugin/keyboard-workarounds.vim

https://github.com/mgedmin/dotvim, accumulated over many years.

So, three out of four? https://github.com/mgedmin/dotvim

Assuming I understood your desire correctly? I have a function to jump to the original (or patched) file when I press Enter on a line of diff: https://github.com/mgedmin/dotvim/blob/master/ftplugin/diff.vim

I use a custom foldexpr. I've been using it for many years, and polished it to do the right thing on all the codebases I've used it on.

My ~/.vim/ is a Git repository and I make it support older versions of Vim by checking for the existence of features before using them, because I couldn't stand my .vimrc emitting any errors on Vim startup. If you're interested, it's here: https://github.com/mgedmin/dotvim/

The primary reason why I need timeout/ttimeout is to have a working Escape key, when you also want to have custom bindings for various key combinations (e.g. ctrl+shift+arrows) that aren't natively recognized for your terminal for some reason, and thus you end up creating compatibility mappings for them.

My ~/.vim is here, if you're curious about the details: https://github.com/mgedmin/dotvim/

I'm perfectly happy with ~/.vim in a separate git repository (mine), with all the plugins installed via vim-plug.

My vimrc is, uhh, big, but I've tried to keep it commented.

> A warning, not an admonishment: Use Apple services in a novel or unsupported manner and you're asking for trouble.

+1

I've always had sync issues with iCloud Drive when storing developer projects and related things there. It ends up stuck or confused or conflicted but tries to resolve the merge conflicts opaquely and it's hard to know there's a problem in real time vs until later when you find something broken. I keep all dev things out of iCloud after getting burned by this enough times over the years.

To OP: Consider a repo dotfiles setup like using Chezmoi or similar. Transitioning to it was less friction than I expected and the only downside really is having to remember to commit changes across devices.

https://github.com/twpayne/chezmoi

chezmoi (<https://chezmoi.io> or <https://github.com/twpayne/chezmoi>) has a couple dozen txtar tests. They are both amazing and completely frustrating to use, but I don't think that there would be a better way to test most of what chezmoi does without them.

Tom Payne (the creator and primary developer of chezmoi) has added some extra commands to the txtar context which makes things easier for certain classes of testing.

Thanks, I never heard of it before and it looks really interesting.

However, it seems that it does not cover all of my needs: https://github.com/twpayne/chezmoi/discussions/1510#discussi...

once i need a more complex solution (eg. for machine specific stuff), i'll probably switch to chezmoi which has more features and native windows support

I’ve been using chezmoi, which uses git, to manage my dot files and have different branches for these types of experiments.

https://chezmoi.io is a dotfile manager that is runs on multiple OSes (including Windows) while handling differences from machine to machine, allows you to store your secrets in your password manager (so you don't have to store secrets in your dotfile repo), and it even supports the NO_COLOR environment variable. Check it out! Disclaimer: I'm the author.

There's a comprehensive list of the most popular dotfile managers at https://dotfiles.github.io/utilities/.

/autoload/ **/autoload//* /plugged/ **/plugged//* */yankring_history.txt ``` Discussion

chezmoi

Checkout yadm or chezmoi. They work great.