Why do we need to auto-create 'undodir'?

[nyngwang]

I noticed something inconvenient recently. I have the following lines in my vimrc: (my neovim config is extended from vim's)

set undofile
set undodir=./.vim/undo// " use local undodir.

Whenever I run git commit, neovim(since $EDITOR=nvim) is opened for me for editing the commit message. But as in :h undodir' of neovim: (** by me)

	When writing: The first directory that exists is used.  "." always
	works, no directories after "." will be used for writing.  **If none of
	the directories exist Nvim will attempt to create the last directory in
	the list.**

So the result is that both the .vim/undo/ path folders and the undofile will be created for the .git/COMMIT_EDITMSG. But, in this case, I don't want to create neither.

This is not the case in vim, which reads in :h undodir' of vim:

	When writing: The first directory that exists is used.  "." always
	works, no directories after "." will be used for writing.

Now I'm just curious on the reason(s) we're diverging from vim here? Wouldn't the original behaviour more flexible(and maybe more safe?) since we can control whether or not the two will be created?

[justinmk]

sprinkling files randomly in CWD isn't usually what most people want...

same for 'directory' and 'backupdir'

[nyngwang]

sprinkling files randomly in CWD [...]

I would argue that it doesn't. In vim, these files are only created when one of the undodir does exist. It's actually more easy to cleanup vimfiles only related a project, instead of having a single place for all projects and "delete all" once a while.

Apart from the value of undodir, which is just a personal preference, how would you explain "creating an undo file for .git/COMMIT_EDITMSG" then? Even if it's set to "what most people want", it will still be created for this file, which seems unnecessary.

[ELHart05]

The divergence comes from one sentence Nvim added to 'undodir' that Vim doesn't have. Compare the two docs:

Nvim (:h 'undodir'):

When writing: The first directory that exists is used. "." always works, no directories after "." will be used for writing. If none of the directories exist Nvim will attempt to create the last directory in the list.

Vim (:h 'undodir') stops at "...will be used for writing." with no auto-create.

The reason it exists is tied to the changed default. Vim's default 'undodir' is ., so an undo file only ever lands next to the file you edit. Nvim's default is $XDG_STATE_HOME/nvim/undo// (a single dir that won't exist on a fresh install), so without auto-creation set undofile would silently do nothing out of the box. The "create the last dir" rule makes the default actually work. That is also @justinmk's point above: the default is a single state dir, not files scattered in CWD.

The catch is that the rule keys off your list, not off .. With set undodir=./.vim/undo// your list has exactly one entry, it doesn't exist when you open .git/COMMIT_EDITMSG, so Nvim creates it (and the undo file) right inside the repo. That is working as documented, just not what you want for throwaway buffers.

You can keep your local-undodir setup and just opt those buffers out. Git commit-message files (COMMIT_EDITMSG, MERGE_MSG, TAG_EDITMSG, ...) all resolve to the gitcommit filetype in Nvim, so:

autocmd FileType gitcommit,gitrebase setlocal noundofile

If you'd rather not depend on filetype, match the path instead:

autocmd BufRead,BufNewFile .git/COMMIT_EDITMSG,*/.git/COMMIT_EDITMSG setlocal noundofile

Or, to get back Vim's "only write if the dir already exists" feel everywhere, prepend . and an existing fallback so the list never resolves to a not-yet-existing dir as the last entry:

set undodir=./.vim/undo//,~/.local/state/nvim/undo//

With a . or an existing dir earlier in the list, the first existing one wins and nothing new gets created for one-off files like the commit buffer.

[nyngwang]

Thank you for elaborating on the details and a solution. Firstly, yes I did make sure that I understand the rule of nvim's 'undodir' correctly before posting. Secondly, I do appreciate your autocmd-way, as a workaround for my need. (actually i already know that.) Now I realized that I need to elaborate on my point of view.

I have these questions in my mind:

1. How often do you clean up the default ~/.local/state/nvim/undo?
2. Do you have specific strategy to do so, or just simply "delete all once a while"?
3. How will you deal with this: For some private projects, I do want to take advantages of "vimfiles" (.swap, undo, viminfo, etc) for the features they provide. But, for privacy, I do want to clean-up these files immediately after a "save point" being made.
4. What if I say, since it's apparent on "what most people do", it's very easy for one to find&copy these files from a random computer before they do a cleanup?

For 3, specifically, my current solution is to put all these files close to the project itself. I did use the nvim's default for a while. But I can promise you, for (possibly thousands of) files named like this:

%Users%johndoe%.config%vim%.vim%Sessionx.vim.swp
%Users%johndoe%.config%vim%autoload%my%vim%tabpanel.vim

It will be a nightmare to cleanup "vimfiles, just for XXX project".

I do like the undofile feature, but it's fragile. Every inconsistent follow-up will destroy the old "undo-tree", overwrite it with a new one to keep this "new undo record". That's why, as far as I know, most people don't like it. To me, it's very useful "before reaching a save point". undofiles are robust as I mostly use (n)vim for editing files. It's also helpful to keep those undotrees after a save point has been made. Pressing u for undoing small changes is always faster than doing git-pulls for some rollbacks. In some cases, I use it as a way to recall some contexts easily by reading a few edits I made hours ago.

Anyway, This is my preference, and I appreciate that Bram made it. But I also care about privacy. I don't want to "delete all vimfiles located at some apparent centralized place, once a while". To me, I want to delete exactly "all vimfiles belong to a project" and exactly "the timing that I know it's time to delete these files".

Neovim is cool. I know that people are working on the idea of "project-local nvim/". I'm (well, I have been) interested in that too. That's why I choice an maybe usual path for undodir . And I haven't found/read a plausible reason for the current default. You can only create a patch(e.g. your autocmd-way) after something happened (some unnessary vimfiles already created). It may be apparent in this case, since it's just about a git-related file. But, I believe, there may be cases we cannot anticipate. I don't want that. Currently, only Vim's default makes sense in my case.

---

Nvim's default is $XDG_STATE_HOME/nvim/undo// (a single dir that won't exist on a fresh install), so without auto-creation set undofile would silently do nothing out of the box.

Btw, this is a very weak requirement to me. How hard is it to create a single folder without the help of (n)vim, for a fresh install? Can't we include it into a bash script during installation? More importantly, does one really need to "fresh install" something frequently? Just my opinion, since If one did set undofile, they probably never bother to create the folder themselves.

[ELHart05]

On the cleanup question, honestly: with the central $XDG_STATE_HOME/nvim/undo I never cleaned it on a schedule, it just grew, and that is what pushed me toward the project-local layout you are already using. So I think your instinct is right here, not dumb. Two things worth separating though.

First, your set undodir=./.vim/undo// does not produce the %Users%johndoe%... names you are worried about. That mangling is only the central-dir case: per :h 'undodir', for entries other than . the file name is "the full path of the edited file, with path separators replaced with %". A . entry instead stores the undo file next to the file as .file.txt.un~. So your setup already gives clean, per-project files that you can wipe with a single rm -rf .vim/undo. The privacy goal you describe is basically already met by what you do; the only leak is throwaway buffers like the commit message.

Second, the part I think you have backwards: the FileType gitcommit setlocal noundofile autocmd is not "after the file is created". FileType fires when the buffer is read, and per :h 'undofile' undo history is only written "when writing a buffer to a file". So setting noundofile at FileType time runs strictly before the write, and no undo file is ever created for that buffer. It is a real opt-out, not a cleanup after the fact.

If what you actually want is opt-in (undo only for the projects you choose, off everywhere else), invert the default instead of patching exceptions:

set noundofile
set undodir=./.vim/undo//

'undofile' is local to buffer and 'undodir' is global, so you flip undo on only where you want it. The clean way to scope that per project is 'exrc', which is the project-local config you said you were interested in. With set exrc, and the file trusted via :trust, Nvim runs a .nvim.lua from the project root (:h 'exrc'). Put this in it:

vim.o.undofile = true

Now undo persists only when you launch Nvim inside that project and nowhere else, with no shared dir to clean up. Keep the gitcommit opt-out alongside it so the commit buffer stays excluded even inside those projects.

On the fresh-install point, fair, that one is weak on its own. The actual reason the auto-create exists is that the default undodir is a single dir nobody sets up, so for the majority who just set undofile and never touch undodir it has to materialize or the feature silently does nothing. Your case is the minority that sets undodir explicitly, which is why the rule surprises you.

If the opt-in setup plus the before-the-fact gitcommit exclusion is what you were after, that should cover it. Happy to keep going on the auto-wipe-after-a-save-point idea if you want that too.

[justinmk]

3. But, for privacy, I do want to clean-up these files immediately after a "save point" being made.

~/.local/ is private :

$ ls -ld ~/.local/
drwx------@

but yes, project-local behavior is a goal, and we should consider 'undodir' and friends for that:

• project-local .nvim/ directory which acts like an extension of stdpath() #33214

[nyngwang]

First, your set undodir=./.vim/undo// does not produce the %Users%johndoe%... names you are worried about. [...] So your setup already gives clean, per-project files that you can wipe with a single rm -rf .vim/undo. The privacy goal you describe is basically already met by what you do; the only leak is throwaway buffers like the commit message.

I was complaining about the privacy problem of the default value of 'undodir'. In my case, I wrote a plugin for my own to make sure those weird names (but unique, thus can be centralized) for a project-local centralized.vim/ folder. I'm not "worried about those names" because it's a working solution. The "next to the file" mechanism comes with is . is a known fact, which only works for small project / single file edit. How is it related here? It's not a solution since I don't bother to check out each folder of a project manually for a cleanup.

So my point of this thread is actually to "understand why the default value would make sense?". Not about "whether my workaround would make sense". So I probably don't get your first point. Mind elaborate? @ELHart05

[nyngwang]

Second, the part I think you have backwards: the FileType gitcommit setlocal noundofile autocmd is not "after the file is created" [...]

OK, Now I realized that you don't get my point on this too.

Let's ask ourselves, "When will I know that I need to patch some autocmd for gitcommit"? Only after something had happened, i.e. In my case, I realized that I don't want an undofile for .git/COMMIT_EDITMSG after it has already been created AND I did notice that. Those traits will stay there before either a schedule "delete all" or your "Aha, I need to prevent it!". But this is "too late" from my point of view. (sure, after each autocmd is created, things will work as we intended. You did a good explanation on that)

This is not an automated process. We can't know whether the list of such autocmd's are "complete" or not beforehand. So, you're patching it, not preventing it.

(English is not my native lang; I'll edit my comments frequently for precision. Please do make sure that you read&reply to the latest one...)