all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
Subject: Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?
Date: Thu, 15 Feb 2024 12:16:35 +0100	[thread overview]
Message-ID: <DU2PR02MB10109137AADD759A9F31786BD964D2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <1331394b-6bbb-47d7-a250-064c41fcecaf@gutov.dev> (Dmitry Gutov's message of "Thu, 15 Feb 2024 00:37:28 +0200")

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 14/02/2024 23:04, Arthur Miller wrote:
>
>>> 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?
>
> Probably, yes. If I understood your question right.
>
>>>> 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.
>
> If we do it this way, it will just be an incremental increase in the complexity
> of the code, and it will support only a part of the applicable use cases. I

Allright, np I understand.

> think I've explained that in one of the previous emails.

You will have to forgive me; I am not familiar with vc-mode and project.el;
perhaps you have explained, but I didn't got it how ti all hangs together and
what are intentions with all this. Better to ask, than to assume wrong.

>>>>> 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.
>
> If you're just looking for a hack for personal use, this one's as good as any.
>
>> 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.
>
> It would be whenever some actual feature requested the vc state to be computed
> because it's going to use it now.
So basically commands would have to auto-start it.

>> 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.
>
> I don't think you're going to have any big problems with the above setup, as
> long as you remember to turn on vc-mode to use any features that require
> VC. Such as diff-hl-mode, for example.
I can just advice or wrap those commands I use, so I guess it is not a problem
for me.

Thanks for the help.
/a



  reply	other threads:[~2024-02-15 11:16 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 10:06 Missing snprintf in ucrt mingw + vc-refresh in find-file hook? Arthur Miller
2024-02-12 13:44 ` Dmitry Gutov
2024-02-12 13:56   ` Arthur Miller
2024-02-12 14:58     ` Dmitry Gutov
2024-02-12 16:49       ` Eli Zaretskii
2024-02-12 18:05         ` Dmitry Gutov
2024-02-12 19:15           ` Eli Zaretskii
2024-02-12 19:25             ` Dmitry Gutov
2024-02-12 19:34               ` Eli Zaretskii
2024-02-13  9:47       ` Arthur Miller
2024-02-13 13:36         ` Eli Zaretskii
2024-02-13 14:30           ` Arthur Miller
2024-02-13 21:26           ` Dmitry Gutov
2024-02-13 23:10             ` Arthur Miller
2024-02-14  3:42               ` Dmitry Gutov
2024-02-14 21:04                 ` Arthur Miller
2024-02-14 22:37                   ` Dmitry Gutov
2024-02-15 11:16                     ` Arthur Miller [this message]
2024-02-14 14:30             ` Eli Zaretskii
2024-02-14 16:36               ` Dmitry Gutov
2024-02-14 16:51                 ` Eli Zaretskii
2024-02-14 17:01                   ` Dmitry Gutov
2024-02-14 17:29                     ` Eli Zaretskii
2024-02-14 21:05                       ` Dmitry Gutov
2024-02-12 14:36 ` Eli Zaretskii
2024-02-13 10:44   ` Arthur Miller
2024-02-13 13:13     ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2024-02-12 17:37 Angelo Graziosi
2024-02-13 10:49 ` Arthur Miller
2024-02-13 19:00 ` Arthur Miller
2024-02-13 20:01   ` Eli Zaretskii
2024-02-13 22:05     ` Arthur Miller
2024-02-14 14:45       ` Eli Zaretskii
2024-02-14 18:43         ` Arthur Miller
2024-02-13 21:26   ` Angelo Graziosi
2024-02-13 22:09     ` Arthur Miller
2024-02-13 22:21       ` Angelo Graziosi
2024-02-13 22:26         ` Arthur Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DU2PR02MB10109137AADD759A9F31786BD964D2@DU2PR02MB10109.eurprd02.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.