Re: VC's modeline

["Óscar Fuentes" <ofv@wanadoo.es>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Saying that the file is on a directory that also has a .git (or .bzr, or
>> whatever) directory is almost meaningless.
>
> It indicates which backend would be used if the user wants to perform
> a VC operation.  E.g. for non-managed files, it'd indicate which backend
> will be used for `C-x v i' (vc-register).

Why should you care about the backend? If you wish to register a file,
you do it regardless of the backend.

A user can easily lost 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 :-)

>> You don't know if the file is actually versioned, nor if it is edited,
>
> In my experience 99% of Emacs users have no idea that the ":" between
> the backend name and the "version info" means that the file is
> locally modified.
>
> Of the remaining 1%, some (at least me; and I presume I'm not the only
> one) never look at it and just use `C-x v =' to see what's changed.

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.

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

>> nor the branch that is currently checked out (this last piece of
>> information is specially important on workflows that uses
>> colocated branches.)
>
> That's occasionally useful in Git, indeed.  Luckily it's easy/cheap to
> obtain this info in Git.

Executing a shell command or a M-x command (if there exists one for that
purpose) is never as easy as seeing the info right there when you switch
to the buffer. It also shows that you are not going to edit some stale
buffer that is out of sync with its file after a git operation (this
also applies to the VC file state.)

>> Personally, I find having that information on the modeline a very worthy
>> investment.  In practice, the only problem I experience is when working
>> on MS Windows, where calling git is much slower than on GNU/Linux and it
>> is annoying to wait until all buffers refreshes the VC info after some
>> operation with Magit.
>
> See, we do have a problem.

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

> I'm not opposed to having refined info
> available, but the current setup where this refined info is
> "indispensable" and always needs to be computed eagerly is problematic.
> We should arrange for those things to be computed more lazily (and
> maybe for that we need to change the UI so it's also *displayed* more
> lazily, e.g. only after the user does something).

I agree wholeheartedly here. But please note that there is no "eager
computation" of the VC modeline, AFAIK. It happens by explicit request
from packages like Magit or when the user has auto-revert-mode enabled
on those buffers.