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

[Dmitry Gutov]

On 14/02/2024 01:10, Arthur Miller wrote:

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

That's wouldn't be a big rewrite, I think. So far it seems the required 
changes would be limited, that's why I outlined the idea.

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

The idea behind it was something else: to be able to unify mode-line 
elements (from vc and project).

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

vc-display-status only affects vc's mode-line element.

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

That's not simpler.