emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc-*-root finctions


From: Thien-Thi Nguyen
Subject: Re: vc-*-root finctions
Date: Thu, 21 Feb 2008 16:33:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() Dan Nicolaescu <address@hidden>
() Wed, 20 Feb 2008 10:50:41 -0800

   Allowing the user to look at the status from the root of the VC tree
   seems like a good idea.  But is this the right UI for it?  It does not
   seem very intuitive to me...

It's just a shortcut for M-x vc-status RET <ROOT> RET.  In the following
updated patch, all subdirs from root downward are buttonized (not just root).

     > ! ;;   for the files in DIR.  This function is called twice,
                                                   ^^^^^^^^^^^^^^^^
   Can you please explain why?

     > ! ;;   time with KICKP t, the second time, with KICKP nil.

   What's the meaning of KICKP ? 

There is now a lengthy comment in vc-status-refresh that addresses
these questions.

     > ! ;;   If the backend workings are asynchronous,

   Why bother making the backend synchronous?

To support asynchronous behavior well, we wish to keep the user informed,
i.e, updating some visible status at the asynchronous boundaries (twice).
If the backend is very fast (completes below some threshold, say 0.5 sec),
this double update appears as a flickering, and is not only uninformative,
it may be downright bewildering.  Thus, a friendly backend may choose to
operate synchronously if it is confident that it can do its job under some
other reasonable threshold for user patience (say 3-5 seconds).  This is the
backend's business; vc.el should not presume to know.

You can see this consideration in play in vc-git-dir-status, which eschews
asynchronous operation completely, so confident it is.  On the other hand,
in vc-svn-dir-status, i have placed a TODO comment where someone who knows
subversion better can add code to dynamically determine how to DTRT there.

   The current API can be used by a synchronous backend too.  It just needs
   to call the UPDATE-FUNCTION when done processing.

Yes, but removing the need to specify UPDATE-FUNCTION is better.

   - (defun vc-status-headers (backend dir)
   -   (concat
   -    (format "VC backend : %s\n" backend)
   -    "Repository : The repository goes here\n"
   -    (format "Working dir: %s\n" dir)))
   - 

   Why remove this? 

For several reasons (w/ current patch):
 - For some backends, "working dir" and "repository" are one and the same.
 - Which backend is reflected in the mode line (re-using var vc-mode).
 - The vc-BACKEND-dir-status return value now allows the backend to
   include arbitrary backend- and/or dir-specific metainfo.
   See vc-svn-dir-status for an example.

     > !                    (format "  Updated: %s -- %s working...\n"

   Is this the time when vc-status was last run?  That might be confusing
   for the user, he might think that "Updated:" means the last time he
   updated the his sources from the VC system.

Good point.  I have modified vc-status-refresh to constrain itself to the
first line; second line and onward completely up to the backend.

   This function is much more complicated now, it's not obvious why.
   Can you please explain?

"It takes a tough man to get a tender chicken" (or something along those
lines ;--).  Please see comment in vc-status-refresh.

thi


______________________________________________________________
changelog entries same as before

full munging

Attachment: .ttn.diff
Description: full munging


reply via email to

[Prev in Thread] Current Thread [Next in Thread]