Re: VC's modeline

[Stefan Monnier]

>> What I think is wrong the level of detail expected in the status line.
>> E.g. I think it'd be fine for VC to just display "Bzr" (or "Hg", or
>> "Git", or what have you) instead.  I think it'd even be fine to do that
>> without checking whether the file is really under that VCS's control or
>> not (i.e. without checking whether the file is ignored).  IOW, a file
>> opened in a directory with a ".git" somewhere in the parents could just
>> say "Git", without any other check.
> 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).

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

So this info is not of very high value.

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

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


        Stefan