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

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

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

I didn't suggest to rebuild everything :). Just an option to remove the update
for those who don't want the update (I guess I am the only one). 

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

It would be one's own responsibility to keep track if it is needed by other
applicaitons or not. This why I asked, if there is something else than modeline
that needs this.

I see defcustom declaration fo vc-display-status is changed from what it was in
29.2 to what is now in the master. I guess you (or someone) is already planning
something in this direction? Was it meant that vc-refresh (or something in the
chain of call) decide to call git or not based on the value of that variable?
Looks to me like that was the plan, but I don't know the intentions.

> 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 I though yesterday of it, it is more like: do what you do now, the way you do
now, when you do it, just let me turn it off.

However, while I saw find-file-hook and was thinking in terms of just removing
vc-refresh from the hook, perhaps there is a better way: As you (or whomever)
seem to have prepared vc-display-status with choice of 'backend, 'status or
nothing, so hook can be always called and it can decide if it will call git or
not based the value of that variable?

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

In case when list of files are checked, one can let-binding vc-display-status
to nil in vc-refresh (or the responsible one) so to not trigger git? 

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

When they request for the backend state; they could do so asyncrhonously to, by
starting a timer? The update will not be immideate; run first when Emas is idle,
if it is just the modeline; but third party apps, if there are such, can be more
picky.