Re: VC's modeline

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Why should you care about the backend?

E.g. because there may be various valid options (see vc-switch-backend).

> A user can easily lose track of the state of a buffer (is it edited?
> does it corresponds with the contents of the file on disk? to which
> branch does in belong?) But if the user forgets about which VCS he is
> using (suppossing that that info is relevant to him) he has more serious
> problems than Emacs being slow :-)

Could be.  Basically, the "Git" (or "Bzr" ...) would mostly mean "Hey,
VC noticed that there's a VCS in use around here".  So, yes we could
replace it with a red pulsating dot which means that VC is "activated".
But to decide whether to put the red pulsating dot we end up necessarily
finding out which backend is in use, so we may as well display the
backend's name instead.  It also has the advantage that the user will
probably instinctively know that this "Git" thingy means that Emacs
found something out in relation to a VCS, whereas we'd have to explain
what the red pulsating dot means (same thing if we use "VC" since the
user may not necessarily know that Emacs's builtin generic VCS support
is called "VC").

> The info that the VC state gives you is that something changed.  Using
> C-x v = for just checking if the file contains changes is quite a lot of
> work.

I just described what I do.  I rarely (never?) only care if the file is
modified or not.  If it is modified I pretty much always want to see
what is changed.  So I never look at the modeline and just always use
`C-x v =' instead.

>> So this info is not of very high value.
> It is of high value for me. And indeed the colon is hard to notice.
> That's why I added faces to each of those VC states.

As mentioned, I do think it's good that this info can be displayed.
What I think is wrong is to compute this info eagerly/unconditionally by
default.
E.g. we compute this info even if the file is never displayed.
Of course this gets worse if find-file-noselect is called in a loop to
collect info about various files none of which are ever displayed.

> It is a problem for some users. For me and many others it is just an
> annoyance on certain specific circunstances.

Indeed.  It's also a problem that we have to write ad-hoc code to try
and parse internal Bzr/Hg/... data to try and avoid those performance
problems, which in turn implies more maintenance.  Reducing the amount
of detail in the VC modeline would also be a problem for some users.

So we should try and find some solution that avoids *all* those problems.

> I agree wholeheartedly here. But please note that there is no "eager
> computation" of the VC modeline, AFAIK.

I think there is, in vc-find-file-hook.


        Stefan