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: emacs-devel@gnu.org
Subject: Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?
Date: Tue, 13 Feb 2024 10:47:33 +0100	[thread overview]
Message-ID: <DU2PR02MB101094006BC52A0FE5CD0C8FE964F2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <207528e2-6bec-436e-8868-8e7b707133f6@gutov.dev> (Dmitry Gutov's message of "Mon, 12 Feb 2024 16:58:52 +0200")

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 12/02/2024 15:56, Arthur Miller wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> 
>>> On 12/02/2024 12:06, Arthur Miller wrote:
>>>> Also, calling vc-refresh obviously results in a quite expensive call to git
>>>> process everytime I open a file from git repo. Is it really a good default
>>>> option? At least I interpret it so since emacs -q has vc-refresh in
>>>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>>> To have the mode-line indicator up-to-date, I imagine.
>> (setq vc-handled-backends nil) solved it. I would prefer such an expensive
>> feature to be opt-in not opt-out, or at least better advertised so I don't have
>> to find by a chance what Emacs is doing in the background; thanks.
>
> The fact of the matter is, it's relatively expensive only on certain platforms,
> but much less so on the main one that we keep in mind when developing Emacs
> (GNU/Linux).

To me, this is expensive regardless of the platform.

It is not so much about the speed of process spawning, more about the fact that
I am spending CPU cycles and battery on something I don't care about.

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.

As a note, doesn't people normally use gitstatusd for this?

https://github.com/romkatv/gitstatus (GPL3 software)

> You might be curious to hear that visiting a file controlled by Git under MS
> Windows was ever slower in the past, and yours truly spent some effort reducing
> the number of process calls we take to compute a file's status (about 10 years
> ago or so).

I trust you, and I have no doubts that you have done a good job. Ten years ago,
I wasn't even using git myself.

If you consider that people are complaining quite a lot about Emacs been too
slow on Windows, than I would consider if this is something that has to be on by
default.

>>>                                              I imagine.
>> I would appreciate if you leave sarcasm out of your answers.
>
> No sarcasm here.

If you end with "I imagne" than it implies it is self-evident. For me it
obviously wasn't :). I got aware of it from that backtrace.

As a side note: I am really grateful to whomever wrote the debugger and edebug
so I can just click on a function name and jump to the implementation instrument
it with edebug and just step through. It is really handy.

> No sarcasm here. Your question is valid: why not defer the process calls until
> some operation actually requests the file's status.
>
> The answer stems from the UI considerations. And if we show it in the mode-line,
> we have to update the file's VCS status eagerly.

I understand and agree that running a git process in modeline update would be
even worse, we don't want that :-).

Can we have it optional to update modeline, but to have the rest of
vc-mode active?

Seems that setting vc-backend to nil shuts down everything.

If it is used just for the modeline update, than we can safely (and optionally)
remove it from the find-file hook to start with? Something like this:

#+begin_src emacs-lisp
(defcustom vc-display-status t
  "If non-nil, display revision number and lock status in mode line.
If nil, only the backend name is displayed.  When the value
is `no-backend', then no backend name is displayed before the
revision number and lock status."
  :type '(choice (const :tag "Show only revision/status" no-backend)
                 (const :tag "Show backend and revision/status" t)
                 (const :tag "Show only backend name" backend)
                 (const :tag "Don't show any revision info" nil))
  :set
  (lambda (symbol new)
    (set-default symbol new)
    (if (not new)
        (setq find-file-hook (delq 'vc-refresh-state find-file-hook))
      (add-hook 'find-file-hook 'vc-refresh-state)))
  :group 'vc)
#+end_src

When saving files, it is implemented differently, basic-save-buffer triggers
everything by calling vc-backend. Is it some special reason why vc-refresh-state
is called directly and now in after-save-hook for example? I add
vc-refresh-state to after-save-hook and hack the needed places, could that work,
or are the some other considerations? Sorry, I am not familiar with
vc.el/project.el so I don't know how everything hangs together in that regard.

Thanks for the help.
/arthur



  parent reply	other threads:[~2024-02-13  9:47 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 [this message]
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
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=DU2PR02MB101094006BC52A0FE5CD0C8FE964F2@DU2PR02MB10109.eurprd02.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=dmitry@gutov.dev \
    --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.