Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 13/02/2024 15:36, Eli Zaretskii wrote:
> > From: Arthur Miller <arthur.miller@live.com>
> > Cc: emacs-devel@gnu.org
> > Date: Tue, 13 Feb 2024 10:47:33 +0100
> >
> > I wasn't even aware this was going on, untill yesterday. I understand that some
> > users like to see diverse stuff in their modeline, statusbars, powerlines,
> > command prompts and other widgets. That is fine; if users want it, give it to
> > them.
> >
> > But I am not such a user, and this feels a bit too much to have it auto
> > on. This can get triggered automatically in save places; for example I have save
> > place on, so when I open a file, Emacs will display cursor at the same place
> > where I left. I see that it gets triggred in some places with Helm
> > completion. Basically everything I have nowdays is in Git, inclusive my entire
> > emacs.d folder. That means I am constantly starting and killing git processes,
> > and I don't even care about that info on my modeline. I look barely at modeline;
> > sometimes I take a look at the clock or line/column number.
>
> I understand your POV, but this is turned on by default in Emacs long
> ago.  So the default cannot be changed just because you personally
> dislike it.  Instead, I suggest that you change the default value of
> mode-line format locally.  Or remove vc-refresh-state from
> find-file-hook.  Or try playing with the value of vc-display-status.
> Or some other change that could do what you want; look in vc-hooks.el
> for ideas.

We could try dropping the forced refresh from find-file-hook. Then we'd 
have a function there that should be called differently, which would 
just reset the saved backend/status for the file, and the cached value 
for vc-mode (the mode-line element).

Then, if the user disabled showing the VC state in the mode-line, and 
doesn't have any other packages installed that use the status, Git won't 
be called, at least not right away.

Apparent downsides:

- As you noted in another thread, errors in the mode-line don't trigger 
the debugger. Any problems with fetching the VCS state will become 
somewhat more difficult to debug. Although someone would just have to 
evaluate (vc-state ...) to trigger that outside of mode-line context.

- Prompting the user whether to follow "symbolic link to %s-controlled 
source file" would become a lot more difficult if the code that's 
supposed to do that, again, runs in the context of the mode-line.

The latter seems like more of a problem, but we could fall back to the 
current functionality when the file is a symlink and vc-follow-symlinks 
is non-nil (fetch the backend eagerly).

As a result, we could have Emacs that's a little bit faster for users 
with custom mode-lines. And also for any find-file-noselect calls done 
in the background (we do those, sometimes on a list of files) won't 
fetch the VCS status eagerly. That seems like a win.

So I would welcome such an experiment, especially if one is careful to 
retain support for vc-follow-symlinks.

vc-after-save could similarly avoid doing the full refresh until the 
file's backend/state are requested again.