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

[Dmitry Gutov <dmitry@gutov.dev>]

On 14/02/2024 16:30, Eli Zaretskii wrote:
>> Date: Tue, 13 Feb 2024 23:26:42 +0200
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 13/02/2024 15:36, Eli Zaretskii wrote:
>>>
>>> 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.
> 
> What is the purpose of such a change?  Does it target users who don't
> want vc-refresh-state in find-file-hook, but still want the VC info
> shown on the mode line?

Those in particular won't see an immediate benefit, but, to reiterate:

   As a result, we could have Emacs that's a little bit faster for users
   with custom mode-lines [that don't show VCS status or backend].

   And also [for all users:] any find-file-noselect calls performed in
   the background (sometimes those are even done on a list of files)
   won't fetch the VCS status eagerly until the buffer is displayed.

 > That sounds like a strange preference, since
 > find-file-hook is called just once per file buffer, whereas showing
 > the info on the mode line can potentially cause vc-refresh-state (or
 > something similar) to be called much more frequently, right?

The backend and the state are cached in vc-file-prop-obarray, so it 
shouldn't result in more process calls, no matter the scenario. It's 
mostly about how early we fetch this information.

> So before we discuss such a move, even as an experiment, I'd like to
> understand better what would be the intended effect in user-facing
> terms, and make sure we indeed consider such a behavior change
> reasonable.  Because this kind of changes is likely to cause
> unintended problems, so I'd like to be sure we really want it before
> we start investing time and efforts in it.  Likewise, I would like to
> avoid the situation where Arthur (or someone else) spends time and
> efforts in experimenting with such a setup, only to be told later
> that we don't think the results makes sense to us.

For me, it really depends on the execution: whether it will actually 
require a moderate amount of changes (as I imagined), and whether the 
perceived improvement in user experience is there. And the appearance of 
"unintended problems", of course.