vc-mode-line

vc-mode-line

[Eli Zaretskii]

This function's doc string (and the corresponding portion of the Emacs
manual) does not document all the possible characters that can appear
between the name of the back-end and the revision number.

I will take care of fixing that, but while at that, I'm surprised that
the characters selected to express the various statuses have such a
small mnemonic value.  `-' would be much more appropriate for removed
files, and locally added files should use `+' rather than `@'.  How
entrenched are the current indicators? is it possible to change them,
or will that cause massive breakage elsewhere and/or user outcry?

Re: vc-mode-line

[Andy Moreton]

On Fri 30 Jul 2010, Eli Zaretskii wrote:

> This function's doc string (and the corresponding portion of the Emacs
> manual) does not document all the possible characters that can appear
> between the name of the back-end and the revision number.

Fixing the docs would be useful.

> I will take care of fixing that, but while at that, I'm surprised that
> the characters selected to express the various statuses have such a
> small mnemonic value.  `-' would be much more appropriate for removed
> files, and locally added files should use `+' rather than `@'.  How
> entrenched are the current indicators? is it possible to change them,
> or will that cause massive breakage elsewhere and/or user outcry?

Even more useful would be to replace this with something more like
mode-line-format that allows the user to extend the information
displayed.

For example, it would be useful to display the current branch when
working with files checked out from multiple repositories and branches.

    AndyM

Re: vc-mode-line

[Leo]

On 2010-07-30 12:53 +0100, Eli Zaretskii wrote:
> This function's doc string (and the corresponding portion of the Emacs
> manual) does not document all the possible characters that can appear
> between the name of the back-end and the revision number.
>
> I will take care of fixing that, but while at that, I'm surprised that
> the characters selected to express the various statuses have such a
> small mnemonic value. `-' would be much more appropriate for removed
> files, and locally added files should use `+' rather than `@'. How
> entrenched are the current indicators? is it possible to change them,
> or will that cause massive breakage elsewhere and/or user outcry?

For modern SCMs it makes sense also to hook the modeline info in dired
buffer (and eshell buffer etc.).

For example, if I eval the elisp code below in a dired visiting a git
repo:

(vc-mode-line default-directory
              (ignore-errors
                 (vc-responsible-backend default-directory)))

the char between backend and branch is always :

It'd be nice if you could also improve this. Thanks.

Leo

Re: vc-mode-line

[Stefan Monnier]

>> I will take care of fixing that, but while at that, I'm surprised that
>> the characters selected to express the various statuses have such a
>> small mnemonic value.  `-' would be much more appropriate for removed
>> files, and locally added files should use `+' rather than `@'.  How
>> entrenched are the current indicators? is it possible to change them,
>> or will that cause massive breakage elsewhere and/or user outcry?

> Even more useful would be to replace this with something more like
> mode-line-format that allows the user to extend the information
> displayed.

There are also long-standing requests to use faces (rather than only
special chars) to indicate the VC status of the file.


        Stefan

Re: vc-mode-line

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

> This function's doc string (and the corresponding portion of the Emacs
> manual) does not document all the possible characters that can appear
> between the name of the back-end and the revision number.
>
> I will take care of fixing that, but while at that, I'm surprised that
> the characters selected to express the various statuses have such a
> small mnemonic value.  `-' would be much more appropriate for removed

It seems that '-' is used the same way as the mode line element that
says the file is not modified.
By that logic, then for an edited file we should use '*' not ':'

> files, and locally added files should use `+' rather than `@'.  How

Looks like a good idea.

> entrenched are the current indicators? is it possible to change them,
> or will that cause massive breakage elsewhere and/or user outcry?

Breakage?  Probably not, all the VC backends that do something about
the vc-mode-line would have change at the same time.
Outcry... hard to say...

Re: vc-mode-line

[Miles Bader]

Of course, being in the mode-line adds other constraints -- that
character it also serves as a separator, should not be too obtrusive in
"common" states (both unmodified and modified are common I think),
should not cause confusion with other parts of the modeline, etc.

In particular, I think "*" might not be such a good choice, because
using "*" for the VCS indicator would dilute the impact of the standard
"buffer modified" indicator.  Right now, the buffer-modified indicator
stands out, as "*" is a fairly noticeable character; the more "*"s with
_different_ meanings we add to the modeline, the less noticeable it
becomes (and noticing whether the buffer is modified or not is important
I think).

I agree that "+" for "newly added file" seems better than @.

If changing everything is OK, how about:

   ":"          unmodified but already in repo
   "="          modified (emacs commonly associates "=" with "diff")
   "+"          added, but not yet committed
   "-"          deleted, but not yet committed

If that's too radical a change, how about (avoids redefining old chars):

   "-"          [existing] unmodified but already in repo
   "="          modified (emacs commonly associates "=" with "diff")
   "+"          added, but not yet committed
   "#"          deleted, but not yet committed

-Miles

-- 
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.

Re: vc-mode-line

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

> If changing everything is OK, how about:
>
>    ":"          unmodified but already in repo

Flipping the meaning of : from modified to unmodified sounds like it
might generate confusion...


>    "="          modified (emacs commonly associates "=" with "diff")
>    "+"          added, but not yet committed
>    "-"          deleted, but not yet committed
>
> If that's too radical a change, how about (avoids redefining old chars):
>
>    "-"          [existing] unmodified but already in repo
>    "="          modified (emacs commonly associates "=" with "diff")
>    "+"          added, but not yet committed
>    "#"          deleted, but not yet committed

These sets are not complete, vc-default-mode-line-string has all the current uses:

    (propertize
     (cond ((or (eq state 'up-to-date)
           (eq state 'needs-update))
               (setq state-echo "Up to date file")
                   (concat backend-name "-" rev))
                      ((stringp state)
                          (setq state-echo (concat "File locked by" state))
                              (concat backend-name ":" state ":" rev))
           ((eq state 'added)
            (setq state-echo "Locally added file")
            (concat backend-name "@" rev))
           ((eq state 'conflict)
            (setq state-echo "File contains conflicts after the last merge")
            (concat backend-name "!" rev))
           ((eq state 'removed)
            (setq state-echo "File removed from the VC system")
            (concat backend-name "!" rev))
           ((eq state 'missing)
            (setq state-echo "File tracked by the VC system, but missing from the file system")
            (concat backend-name "?" rev))
           (t
            (setq state-echo "Locally modified file")
            (concat backend-name ":" rev)))

All possible states can be seen using C-h f vc-state RET.

Re: vc-mode-line

[Stephen J. Turnbull]

Miles Bader writes:

 > If changing everything is OK, how about:
 > 
 >    ":"          unmodified but already in repo
 >    "="          modified (emacs commonly associates "=" with "diff")

I don't find that persuasive.  Before I scrolled to see this part I
was already thinking "=" is unmodified, "*" is fine for modified since
that's what it means for buffers.  If you think that the Emacs
association of "=" with diff is too strong (I don't have a problem
keeping those straight, actually; in modes where quick access to diff
is useful I pronounce "=" as "equalp", YMMV, but that's my mnemonic),
how about "#" for modified (looks like "not equal"), or "!"?

 >    "+"          added, but not yet committed
 >    "-"          deleted, but not yet committed

2 * (+1)

Re: vc-mode-line

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 05 Aug 2010 13:55:39 +0900
> 
>    ":"          unmodified but already in repo
>    "="          modified (emacs commonly associates "=" with "diff")
>    "+"          added, but not yet committed
>    "-"          deleted, but not yet committed

FWIW, I like Dan's proposal better.

Re: vc-mode-line

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Miles Bader writes:
>
>  > If changing everything is OK, how about:
>  > 
>  >    ":"          unmodified but already in repo
>  >    "="          modified (emacs commonly associates "=" with "diff")
>
> I don't find that persuasive.  Before I scrolled to see this part I
> was already thinking "=" is unmodified, "*" is fine for modified since
> that's what it means for buffers.  If you think that the Emacs
> association of "=" with diff is too strong (I don't have a problem
> keeping those straight, actually; in modes where quick access to diff
> is useful I pronounce "=" as "equalp", YMMV, but that's my mnemonic),
> how about "#" for modified (looks like "not equal"), or "!"?

Is something like (if (char-displayable-p ?≠) "≠" "#") going to work
reliably?  However, I am not sure I consider it appropriate since
equality is not the same as being unmodified.

-- 
David Kastrup

Re: vc-mode-line

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

> In particular, I think "*" might not be such a good choice, because
> using "*" for the VCS indicator would dilute the impact of the standard
> "buffer modified" indicator.  Right now, the buffer-modified indicator
> stands out, as "*" is a fairly noticeable character; the more "*"s with
> _different_ meanings we add to the modeline, the less noticeable it
> becomes (and noticing whether the buffer is modified or not is important
> I think).

Given that the * would be placed close to the CVS/GIT/SVN/etc string,
IMO it would be quite clear that it refers to the VC context.
That seems better than a new context-free symbol...

Re: vc-mode-line

[Miles Bader]

Dan Nicolaescu <dann@gnu.org> writes:
> Given that the * would be placed close to the CVS/GIT/SVN/etc string,
> IMO it would be quite clear that it refers to the VC context.

I'm not sure people generally look that hard at the mode-line, but
rather tend to glance at it.  "*" stands out even at a glance, which is
good in some ways but bad in others...

I agree that the "-" vs. ":" is probably too subtle; arguably, "=" may
have the same problem.  In my mind, it stands out because it's a little
"weird" (whereas "-"/":" are both totally natural separators that one
might not realize have any meaning at all), but I think Stephen noted it
could be confused for "equals the revision XX".

Anyway, there seems to be a preferences for "*" amongst responders so
far...

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: vc-mode-line

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

[snip]

> Anyway, there seems to be a preferences for "*" amongst responders so
> far...

Whatever you decide, please consider allowing for some colorized
clue. Associating background faces to VC states, for instance, so the
user can customize "green for unmodified, red for modified" etc.

I guess that asking for images would be too contentious ;-)

Re: vc-mode-line

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Whatever you decide, please consider allowing for some colorized
> clue. Associating background faces to VC states, for instance, so the
> user can customize "green for unmodified, red for modified" etc.

I experimented a bit assigning a face to the text inserted into the
modeline by vc-default-mode-line-string. The result is great, IMHO.

It's trivial to make a patch for adding a configurable face for each VC
state. The question is: should they default to the current face, so the
modeline looks the same way as it does now, or should I use some
imagination and choose some (possibly horrible) defaults?

Re: vc-mode-line

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> Anyway, there seems to be a preferences for "*" amongst responders so
>> far...
>
> Whatever you decide, please consider allowing for some colorized
> clue. Associating background faces to VC states, for instance, so the
> user can customize "green for unmodified, red for modified" etc.
>
> I guess that asking for images would be too contentious ;-)

I suppose that having an user-customizable alist for the mapping would
be a good thing, and it could support propertized strings; lisp code
shouldn't be looking at the mode-line indicators anyway (it should look
at the actual state symbols).

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: vc-mode-line

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> It's trivial to make a patch for adding a configurable face for each VC
> state. The question is: should they default to the current face, so the
> modeline looks the same way as it does now, or should I use some
> imagination and choose some (possibly horrible) defaults?

I think a face for each state is excessive and not actually so flexible
(because it only allows the face to be customized).

Better just have a user-customizable alist that supports propertized strings.

-Miles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: vc-mode-line

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> It's trivial to make a patch for adding a configurable face for each VC
>> state. The question is: should they default to the current face, so the
>> modeline looks the same way as it does now, or should I use some
>> imagination and choose some (possibly horrible) defaults?
>
> I think a face for each state is excessive and not actually so flexible
> (because it only allows the face to be customized).
>
> Better just have a user-customizable alist that supports propertized strings.

What I have in mind is to apply the face to all the VC text on the
modeline ("Git-branchname" or "SVN:1020") not just to the state char, as
I pretended at first. Dunno how/if customizable propertized strings fits
that scenario.

OTOH it would be convenient to concentrate the user-visible info
associated to a VC state into a single function or list, instead of
being hard-coded into vc-default-mode-line-string:

(defun vc-info-for-state (state)
   (cond ((eq state 'up-to-date)
          '("Up to date" ":" vc-up-to-date-state-face))
...

This way if a backend FOO defines vc-FOO-mode-line-string it can use
that function for keeping consistentency with the other backends.

Re: vc-mode-line

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 06 Aug 2010 08:52:53 +0200
> 
> What I have in mind is to apply the face to all the VC text on the
> modeline ("Git-branchname" or "SVN:1020") not just to the state char, as
> I pretended at first.

What would be displayed for the VC text, then?

Re: vc-mode-line

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> What I have in mind is to apply the face to all the VC text on the
>> modeline ("Git-branchname" or "SVN:1020") not just to the state char, as
>> I pretended at first.
>
> What would be displayed for the VC text, then?

Not sure I don't understand your question.

I'm talking about applying a face to the VC text, not about replacing it.

Re: vc-mode-line

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> What I have in mind is to apply the face to all the VC text on the
>> modeline ("Git-branchname" or "SVN:1020") not just to the state char, as
>> I pretended at first.
>
> What would be displayed for the VC text, then?

Not sure I understand your question.

I'm talking about applying a face to the VC text, not about replacing it.

Re: vc-mode-line

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 06 Aug 2010 18:33:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What I have in mind is to apply the face to all the VC text on the
> >> modeline ("Git-branchname" or "SVN:1020") not just to the state char, as
> >> I pretended at first.
> >
> > What would be displayed for the VC text, then?
> 
> Not sure I understand your question.
> 
> I'm talking about applying a face to the VC text, not about replacing it.

I was asking how it will be displayed after applying the face(s).

Re: vc-mode-line

[David House]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On 5 August 2010 23:38, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Whatever you decide, please consider allowing for some colorized
> clue. Associating background faces to VC states, for instance, so the
> user can customize "green for unmodified, red for modified" etc.
>
> I guess that asking for images would be too contentious ;-)

For a while now, I've been using the following customization to
display a green circle for an unmodified file and an orange square for
a modified one (versus the repository, I mean):

(setq-default
 mode-line-format
 '(...
   (vc-mode (:eval (vc-icon)))
   ...)

;; Display a coloured square indicating the vc status of the current file
(defun vc-icon ()
  (let ((icon (if (vc-workfile-unchanged-p (buffer-file-name))
                  "in-vc.png"
                "modified-vc.png"))
        (bg (face-attribute 'mode-line :background)))
    (propertize
     "  "
     'display (find-image
               `((:type png :file ,icon :ascent center :background ,bg))))))

It relies on the attached two PNG images (I presume sending
attachments to this mailing list works; if not, email me and I'll
place them on imgur or somewhere similar).

[-- Attachment #2: in-vc.png --]
[-- Type: image/png, Size: 725 bytes --]

[-- Attachment #3: modified-vc.png --]
[-- Type: image/png, Size: 433 bytes --]

Re: vc-mode-line

[Óscar Fuentes]

David House <dmhouse@gmail.com> writes:

> On 5 August 2010 23:38, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Whatever you decide, please consider allowing for some colorized
>> clue. Associating background faces to VC states, for instance, so the
>> user can customize "green for unmodified, red for modified" etc.
>>
>> I guess that asking for images would be too contentious ;-)
>
> For a while now, I've been using the following customization to
> display a green circle for an unmodified file and an orange square for
> a modified one (versus the repository, I mean):

That's what psvn.el does. I prefer to colorize the VC text, as it is
more easily customizable and adaptable to more states (`conflict' is one
that specially interests me.)

> It relies on the attached two PNG images [snip].

psvn.el doesn't need external image files. It builds the icon with a few
lines of code. Look for svn-status-state-mark-modeline-dot on psvn.el
The file is available from here:

http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/emacs/psvn.el

Re: vc-mode-line

[Ted Zlatanov]

On Tue, 10 Aug 2010 17:43:41 +0200 Óscar Fuentes <ofv@wanadoo.es> wrote: 

ÓF> psvn.el doesn't need external image files. It builds the icon with a few
ÓF> lines of code. Look for svn-status-state-mark-modeline-dot on psvn.el
ÓF> The file is available from here:

ÓF> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/emacs/psvn.el

SVG can also be used (if compiled in) and will probably produce a nicer
icon than XPM since it has scalable fill gradients, shapes, paths, and
text.

Ted