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

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

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

Allright; I'll have to learn vc-mode and see how it works in that case; I am not
familiar with that code at all.

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

Ok, I see. A question: is it importnat to keep display on modeline or
elsewhere decoupled from the actual repo query?

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

Can I use to in the meaning "no status display" = "no git query"? That is why I
ask if it is important to keep display decoupled from the query.

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

After looking more at it; what I find problematic is that it is automatic. Also,
use of hooks find-file/after-save (eventually) means either all or nothing.

I looked a bit in vc-hooks and vc-dir, and come up with this little ugly hack:

(define-minor-mode vc-mode
  "vc-mode test"
  :global nil :lighter " vcm "
  (setq-local vc-handled-backends
        (if vc-mode
            '(RCS CVS SVN SCCS SRC Bzr Git Hg)
          nil)))

Since vc-mode is just a dummy function; I per-used it. Now I can keep in my init
file (setq vc-handled-backends nil) and nothing screems after Git when it is not
in the path; and in projects where I wish to work with vc-mode and run vc-dir, I
can start vc-mode and than vc-dir works as expected. 

I also don't see how Emacs could know when to start vc-mode and when not,
without user taking an action. If complete automatic handling of version control
is desired than something like that is not acceptable.

An alternative could be to have another find-file/save-file functions, say
find/save-vc-file, that does the same, but also runs the vc-refresh-status. Than
those who prefer to always see vc status when in a vc repo could use it as
the default find-file function; and those like me, who would prefer it
on-demand, could call it when they need it. But that is not so pretty and
automatic.

Anyway, I think I can personally live with my hack, unless there is something
really nasty I am forseeing there. That achieves what I asked for, without you
needed to change anything.