Introducing 'unrecognized and 'ignored

Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

I've spent the last couple of hours looking at this issue.
A reminder: the payoff for getting it right would be another 
significant speedup in (vc-dired-hook), which would translate to 
a faster C-x v d display.

Remarkably, it looks as if the code does not actually depend
in any significant way on the nil return from (vc-state file) meaning
that FILE is unregistered.  Tests that might have used this method
use vc-backend instead.  So introducing an 'unregistered state 
shouldn't actually break anything.

Alex Harsanyi: A cvs-ignorable-file-p would actually be useful, if
you're still interested. Under later systems it's faster to get this 
by doing a bit of estra parsing of rge status report.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

  > I've spent the last couple of hours looking at this issue.
  > A reminder: the payoff for getting it right would be another 
  > significant speedup in (vc-dired-hook), which would translate to 
  > a faster C-x v d display.

Thanks for dealing with this!

  > Remarkably, it looks as if the code does not actually depend
  > in any significant way on the nil return from (vc-state file) meaning
  > that FILE is unregistered.  Tests that might have used this method
  > use vc-backend instead.  So introducing an 'unregistered state 
  > shouldn't actually break anything.

vc-hg-registered depended on vc-hg-state returning nil for unregistered
and ignored files. I fixed it.

Re: Introducing 'unrecognized and 'ignored

[Alexandru Harsanyi]

On 29 Dec 2007, at 2:45 AM, Eric S. Raymond wrote:

> I've spent the last couple of hours looking at this issue.
> A reminder: the payoff for getting it right would be another
> significant speedup in (vc-dired-hook), which would translate to
> a faster C-x v d display.
>
> Remarkably, it looks as if the code does not actually depend
> in any significant way on the nil return from (vc-state file) meaning
> that FILE is unregistered.  Tests that might have used this method
> use vc-backend instead.  So introducing an 'unregistered state
> shouldn't actually break anything.
>
> Alex Harsanyi: A cvs-ignorable-file-p would actually be useful, if
> you're still interested. Under later systems it's faster to get this
> by doing a bit of estra parsing of rge status report.
>

I had a look at the problem last night and wrote the code to load a  
cvsignore file and produce a regexp to match the ignored files,  
however the whole mechanism required by `vc-BACKEND-ignorable-file-p'  
is quite tricky to implement corectly (in a way that both Emacs and  
the backend agree 100% on what files are ignored).  Here are two of  
the problems I found when I looked at an implementation for CVS:

  * CVS will ignore a file only if it is unregistered.  For  
example .o files are ignored from a CVS status listing, but if an .o  
file is registered than that file will show up in the listing.  This  
requires checking whether a file is registered or not, a thing which  
we try to avoid.

  * There's a 'per-repository' cvsignore file at $CVSROOT/CVSROOT/ 
cvsignore which Emacs cannot access directly for remote repositories.


With extended vc-state states I don't think there is a need for `vc- 
ignorable-file-p' at all:  `vc-BACKEND-dir-state' should set the  
state for each registered file and for files it can register.  `vc- 
dired-hook' can than simply look for the vc-state property and if it  
is missing it can assume that the file is ignored.

Best Regards,
Alex.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Alexandru Harsanyi <harsanyi@mac.com>:
> I had a look at the problem last night and wrote the code to load a 
> cvsignore file and produce a regexp to match the ignored files, however the 
> whole mechanism required by `vc-BACKEND-ignorable-file-p' is quite tricky 
> to implement corectly (in a way that both Emacs and the backend agree 100% 
> on what files are ignored).  Here are two of the problems I found when I 
> looked at an implementation for CVS:
>
>  * CVS will ignore a file only if it is unregistered.  For example .o files 
> are ignored from a CVS status listing, but if an .o file is registered than 
> that file will show up in the listing.

That is actually sensible behavior.  From CVS, surprisingly so :-)

>                                      This requires checking whether a 
> file is registered or not, a thing which we try to avoid.

Not necessarily.  See below.

>  * There's a 'per-repository' cvsignore file at $CVSROOT/CVSROOT/cvsignore 
> which Emacs cannot access directly for remote repositories.

That, on the other hand, is kind of a showstopper.

> With extended vc-state states I don't think there is a need for 
> `vc-ignorable-file-p' at all:  `vc-BACKEND-dir-state' should set the state 
> for each registered file and for files it can register.  `vc-dired-hook' 
> can than simply look for the vc-state property and if it is missing it can 
> assume that the file is ignored.

Thinking about it, you're right.  We should consider that what
dir-state does is update the state properties for as many files as it
can, which means we can call (vc-state) on every file in the dired
listing and only get expensive operations for the ones dir-state
didn't report a status on.

Then the problem of speeding up vc-dired-hook will reduce to a simpler
one -- how to make the individual directory-status commands in each
VCS return information for as many files as possible? Ideally, we want
them to return status on *all* files beneath the current directory.

Some VCSes will make this easy. Mercurial, for example, has hg status -A,
which is documented to return status flags for all files.  Now that we 
have 'unregistered and 'ignored, this means that the individual
vc-state calls will never have to do their own check.  Mercurial is
going to be really fast.

Some make it hard; CVS, for example.  I don't know any way to make its
dir-state set 'ignored files, and it will set 'unregistered only if the
stay-local-p test fails and dir-state goes down the path that parses
vc-status output (something we want to avoid because it's dog-slow).

Most are in between.  There is probably a way to beat Subversion into
reporting status on all files, but I don't know what it is yet.

I'll tackle this for Subversion -- would you look at making the CVS
dir-state better?  The goal is to get it to somehow set 'ignored 
and 'unregistered whenever appropriate.

There is also a minor can of worms near 'added.  It's not really a
fully-supported state yet.  It should be.  And 'removed, too.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

> Then the problem of speeding up vc-dired-hook will reduce to a simpler
> one -- how to make the individual directory-status commands in each
> VCS return information for as many files as possible? Ideally, we want
> them to return status on *all* files beneath the current directory.

I disagree.  VC should not do any tree traversal itself.  It shouldn't
"call the backend to do tree traversal to fill some data and then do
tree traversal again hoping to only hit files that were already found".
Instead, the `dir-state' function should somehow return the list of
files found and VC-dired should only display those (at first).

By default, I'd suggest that the dir-state function only returns the
"interesting files" (the ones that are not just uptodate or ignored).

I.e. just present the result of "cvs -n update" rather than try to do
something more clever.  The user may want to request the output of "cvs
status" as well, although in any non-trivial project, this is too long
to be of any use, so it needs to be applicable to just a single subdir
(or even a single file).


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > Then the problem of speeding up vc-dired-hook will reduce to a simpler
> > one -- how to make the individual directory-status commands in each
> > VCS return information for as many files as possible? Ideally, we want
> > them to return status on *all* files beneath the current directory.
> 
> I disagree.  VC should not do any tree traversal itself. 

There's no way to avoid this.

We have a choice between two different sets of circumstances under
which tree traversal will be needed:

1) We can take svn and later systems as a model.  Their status commands
recurse naturally, so none of those backend status commands has to traverse 
trees itself.  If we do this, the CVS and MCVS backend status commands have
to do tree traversal to match the behavior of the SVN and later ones.

2) We can take CVS as the model.  In that case we have to tell the backend 
status commands for later VCSes not to recurse -- and somewhere in the
upper-level calling logic for all backends, *it* has to recurse down
trees.

Right now VC is doing the first alternative.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> > Then the problem of speeding up vc-dired-hook will reduce to a simpler
>> > one -- how to make the individual directory-status commands in each
>> > VCS return information for as many files as possible? Ideally, we want
>> > them to return status on *all* files beneath the current directory.
>> 
>> I disagree.  VC should not do any tree traversal itself.

> There's no way to avoid this.

Of course there is.

> We have a choice between two different sets of circumstances under
> which tree traversal will be needed:

> 1) We can take svn and later systems as a model.  Their status commands
> recurse naturally, so none of those backend status commands has to traverse 
> trees itself.  If we do this, the CVS and MCVS backend status commands have
> to do tree traversal to match the behavior of the SVN and later ones.

I don't understand: CVS's status command recurses just fine and so does
MetaCVS's (not that it matters since this backend can be dropped any day
AFAICT).

The only backends which might need to do tree traversal manually (AFAIK)
are RCS and SCCS, of course, but I think it's fine for them to do the
traversal by hand in the backend code.

> Right now VC is doing the first alternative.

Maybe we're not talking about the same "tree traversal".  But AFAICT,
vc-dired uses `ls' somewhere, where I think it should neither use `ls'
nor `directory-files' nor anything equivalent in the generic code.
That would also allow us to get rid of vc-directory-exclusion-list.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

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

  > >> > Then the problem of speeding up vc-dired-hook will reduce to a simpler
  > >> > one -- how to make the individual directory-status commands in each
  > >> > VCS return information for as many files as possible? Ideally, we want
  > >> > them to return status on *all* files beneath the current directory.
  > >> 
  > >> I disagree.  VC should not do any tree traversal itself.
  > 
  > > There's no way to avoid this.
  > 
  > Of course there is.
  > 
  > > We have a choice between two different sets of circumstances under
  > > which tree traversal will be needed:
  > 
  > > 1) We can take svn and later systems as a model.  Their status commands
  > > recurse naturally, so none of those backend status commands has to traverse 
  > > trees itself.  If we do this, the CVS and MCVS backend status commands have
  > > to do tree traversal to match the behavior of the SVN and later ones.
  > 
  > I don't understand: CVS's status command recurses just fine and so does
  > MetaCVS's (not that it matters since this backend can be dropped any day
  > AFAICT).
  > 
  > The only backends which might need to do tree traversal manually (AFAIK)
  > are RCS and SCCS, of course, but I think it's fine for them to do the
  > traversal by hand in the backend code.
  > 
  > > Right now VC is doing the first alternative.
  > 
  > Maybe we're not talking about the same "tree traversal".  But AFAICT,
  > vc-dired uses `ls' somewhere, where I think it should neither use `ls'
  > nor `directory-files' nor anything equivalent in the generic code.
  > That would also allow us to get rid of vc-directory-exclusion-list.

I would go one step further: vc-dired should not be based on dired at
all. 99% of the dired key bindings and functionality are not useful in
vc-dired.  Plus that forces use to use the "v" prefix instead of using
simple key bindings.

vc-dired could instead use something based on ewocs. Looking at git.el,
implementing the status display using ewocs looks simple enough.

Sort term using dired is fine because it provide the much needed
multiple file commit functionality. But medium term it should be nuked
and replaced.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> vc-dired could instead use something based on ewocs. Looking at git.el,
> implementing the status display using ewocs looks simple enough.

Where is ewocs?  I don't find anything including that string in the name
in the CVS tree.

> Sort term using dired is fine because it provide the much needed
> multiple file commit functionality. But medium term it should be nuked
> and replaced.

I'm not attached to retaining dired.  But there are other things that need
to happen first.  I still have more speed tuning to do.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > vc-dired could instead use something based on ewocs. Looking at git.el,
  > > implementing the status display using ewocs looks simple enough.
  > 
  > Where is ewocs?  I don't find anything including that string in the name
  > in the CVS tree.

Because you looked for plural "ewocs" :-). See emacs-lisp/ewoc.el

In fact, here's a quick hack that shows how ewocs can be used.

To be minimally usable for vc-dired it would just need code to
mark/unmark files and to return the list of marked entries.


(require 'ewoc)

(defvar my-vc-status-cookie nil "")

(defun my-vc-status-insert-headers ()
  (insert "Repository : Blah Blah\n")
  (insert "Working dir: ~/WORKING DIR\n\n\n"))

(defun my-vc-status-printer (fileentry)
  (insert fileentry))

(defun my-vc-dir-state (dir)
  "The VC dir-state functions should return a list of file+states like this."
  '(("one" . up-to-date) 
    ("two" . added) 
    ("three" . unregistered)))

(defun my-vc-status ()
  "Prototype for a replacement for vc-dired."
  (interactive)
  (let (buffer-read-only)
    (erase-buffer)
    (set (make-local-variable 'my-vc-status-cookie)
         (ewoc-create #'my-vc-status-printer))
    (my-vc-status-insert-headers)
    (dolist (elem (my-vc-dir-state "ignored"))
      (ewoc-enter-last my-vc-status-cookie 
      (format "   %-20s %s" (cdr elem) (car elem)))))
  (goto-char (point-min))
  (setq buffer-read-only t))

  > > Sort term using dired is fine because it provide the much needed
  > > multiple file commit functionality. But medium term it should be nuked
  > > and replaced.
  > 
  > I'm not attached to retaining dired.  But there are other things that need
  > to happen first.  I still have more speed tuning to do.

Understood. Some of the speed tuning would not be needed if not using
dired though...

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

    I would go one step further: vc-dired should not be based on dired at
    all. 99% of the dired key bindings and functionality are not useful in
    vc-dired.

Unifying them is a big advantag

There may be reasons to separate them which outweigh the advantage
of unification, but we should see them presented and weigh them
before going in that direction.

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     I would go one step further: vc-dired should not be based on dired at
  >     all. 99% of the dired key bindings and functionality are not useful in
  >     vc-dired.
  > 
  > Unifying them is a big advantag
  > 
  > There may be reasons to separate them which outweigh the advantage
  > of unification, but we should see them presented and weigh them
  > before going in that direction.

The disadvantages or using dired: 
 - performance  -- the difference is HUGE
 - clutter - dired has 4 top level menus that are mostly useless in the
            VC context
 - availability of simple key bindings: dired takes most single key
 bindings, forcing vc-dired to use the "v" prefix

 - display flexibility  -- it is much easier to do custom displays as
   needed by VC using ewocs than to retrofit it into dired.  Just look
   at the PCL-CVS display and compare it with vc-dired.

 - future extensibility - VC systems are evolving at a fast pace
   nowadays, being able to easily make changes to accommodate new
   features is very important. 

So IMO, there's no reason to cling onto dired.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> So IMO, there's no reason to cling onto dired.

I think there are some things pushing in the other direction -- 
consistency of interface, mainly.  I really want to hear RMS's reasons
for wanting to retain VC-Dired; it's possible he has some compelling
argument I haven't thought of.

Myself, I'm pretty near neutral on this one and willing to be 
persuaded either way.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

    The disadvantages or using dired: 

Several of these are not persuasive (at least based on what
you've said so far).

     - performance  -- the difference is HUGE

What is the connection between using dired and this slowdown?

     - clutter - dired has 4 top level menus that are mostly useless in the
		VC context

That is not a real problem.
It is easy for a variant of Dired to override them.

     - availability of simple key bindings: dired takes most single key
     bindings, forcing vc-dired to use the "v" prefix

That is not a real problem.  vc-dired could rebind some Dired keys,
and still preserve most of the advantage of commonality with Dired.

     - future extensibility - VC systems are evolving at a fast pace
       nowadays, being able to easily make changes to accommodate new
       features is very important. 

I see no point paying the price today for a benefit that may only
possibly develop.  I'd rather pay that price if and when there is a
real benefit to be gained.  It won't be more work then than it is
today.

On the other hand, this could be a significant reason:

     - display flexibility  -- it is much easier to do custom displays as
       needed by VC using ewocs than to retrofit it into dired.  Just look
       at the PCL-CVS display and compare it with vc-dired.

If custom displays are needed, that probably requires splitting off.

Are custom displays needed?  What would you want to use them for?

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     The disadvantages or using dired: 
  > 
  > Several of these are not persuasive (at least based on what
  > you've said so far).
  > 
  >      - performance  -- the difference is HUGE
  > 
  > What is the connection between using dired and this slowdown?

It is much faster to ask the VCS about the status of the files and just
display those results, rather than what it is done today: ask dired
about all the files in a directory and the ask the VCS about the
status.

  >      - future extensibility - VC systems are evolving at a fast pace
  >        nowadays, being able to easily make changes to accommodate new
  >        features is very important. 
  > 
  > I see no point paying the price today for a benefit that may only
  > possibly develop.  I'd rather pay that price if and when there is a
  > real benefit to be gained.  It won't be more work then than it is
  > today.

It would be, tweaking the dired display is much harder than implementing
a better one from scratch using ewocs. Compare the PCL-CVS display with
vc-dired, IMHO it looks better.

  > On the other hand, this could be a significant reason:
  > 
  >      - display flexibility  -- it is much easier to do custom displays as
  >        needed by VC using ewocs than to retrofit it into dired.  Just look
  >        at the PCL-CVS display and compare it with vc-dired.
  > 
  > If custom displays are needed, that probably requires splitting off.
  > 
  > Are custom displays needed?  What would you want to use them for?

I believe so. One use for displaying no-file related information:
repository name, branch name, the command that is being executed (all
done by PCL-CVS). 

In the future we might want to add some widgets to select the branch to
display. Or to the repository to connect to. Maybe display a short
version of the logs for the last commits in the repository for the files
that need merging. 

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
>   > Are custom displays needed?  What would you want to use them for?
> 
> I believe so. One use for displaying no-file related information:
> repository name, branch name, the command that is being executed (all
> done by PCL-CVS). 
> 
> In the future we might want to add some widgets to select the branch to
> display. Or to the repository to connect to. Maybe display a short
> version of the logs for the last commits in the repository for the files
> that need merging. 

Dan, there are parts of the VC design about which I feel some
territoriality, but this is absolutely not one of them. The
performance of the VC-Dired code is not where I want it to be, your
arguments seem sound, and you seem well motivated to do a good job.
If you think you can rip VC-Dired out and replace it with a better and
faster ewoc-based display layer, you may do so with my blessing and
support.

I say this partly because the code structure should make this experiment
easy to back out if it fails.  But I'm not expecting it to.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

> Dan, there are parts of the VC design about which I feel some
> territoriality, but this is absolutely not one of them. The
> performance of the VC-Dired code is not where I want it to be, your
> arguments seem sound, and you seem well motivated to do a good job.
> If you think you can rip VC-Dired out and replace it with a better and
> faster ewoc-based display layer, you may do so with my blessing and
> support.

Note that there's a middle-way as well: use dired-mode, but fill the
buffer manually from the list of files returned by the backend commands
(probably using code from ls-lisp.el to properly format each lines), so
we don't run `ls' or directory-files at all, but still preserve
everything else.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > >   > Are custom displays needed?  What would you want to use them for?
  > > 
  > > I believe so. One use for displaying no-file related information:
  > > repository name, branch name, the command that is being executed (all
  > > done by PCL-CVS). 
  > > 
  > > In the future we might want to add some widgets to select the branch to
  > > display. Or to the repository to connect to. Maybe display a short
  > > version of the logs for the last commits in the repository for the files
  > > that need merging. 
  > 
  > Dan, there are parts of the VC design about which I feel some
  > territoriality, but this is absolutely not one of them. The
  > performance of the VC-Dired code is not where I want it to be, your
  > arguments seem sound, and you seem well motivated to do a good job.
  > If you think you can rip VC-Dired out and replace it with a better and
  > faster ewoc-based display layer, you may do so with my blessing and
  > support.
  > 
  > I say this partly because the code structure should make this experiment
  > easy to back out if it fails.  But I'm not expecting it to.

I checked in some code to do that. I whipped it out quickly, so it's not
complete in any way. It provides a M-x vc-status command which is the
replacement for vc-dired. 

It can only be used with Mercurial for now.

You can mark/unmark files, and vc-deduce-fileset knows about them. So
you can run C-x v commands in the *vc status* buffer and they will
take into consideration the selected files. (I only tested vc-diff).

As you see the code is very simple. Adding faces, more key bindings and
more fancy display should be straight forward.

Now, I cannot lead this development, I don't have the time to do it at
the moment.
But I am happy to help further.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> Now, I cannot lead this development, I don't have the time to do it at
> the moment.
> But I am happy to help further.

Noted.  I'll carve out some time later today or tomorrow to look at it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > Now, I cannot lead this development, I don't have the time to do it at
  > > the moment.
  > > But I am happy to help further.
  > 
  > Noted.  I'll carve out some time later today or tomorrow to look at it.

Have you had a chance to look at vc-status? 
It's in decent shape now. It needs more UI improvements, and polish, but
the main functionality is there.

Thanks

        --dan

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> I checked in some code to do that. I whipped it out quickly, so it's not
Dan> complete in any way. It provides a M-x vc-status command which is the
Dan> replacement for vc-dired. 

Dan> It can only be used with Mercurial for now.

Appended is a patch to make it work with svn.  This patch is kind of a
hack in that, if vc-status ever wants to support "non-terse" mode,
then the function will have to be rewritten (since "svn status" and
"svn status -v" have different formats).

I don't understand how the 'dir' argument works with the existing
vc-hg-dir-status.  The argument is never used in the function.  When I
tried vc-status on a mercurial working directory, I got results for
the whole tree, not the particular subdirectory I requested, which is
also weird.

The resulting buffer is always called *vc-status*, which is
unfriendly.  Perhaps it should be named after the requested directory.

I think it would be best to make vc-status work asynchronously from the
very beginning.  That is what pcl-cvs and psvn do, and it is nicer to
use on larger trees.  I think this is important to do first because it
is simpler to redesign the back end hooks now, if needed.

Tom

2008-01-06  Tom Tromey  <tromey@redhat.com>

	* vc-svn.el (vc-svn-dir-status): New function.

*** vc-svn.el	02 Jan 2008 12:34:31 -0700	1.59
--- vc-svn.el	06 Jan 2008 12:39:14 -0700	
***************
*** 1,6 ****
  ;;; vc-svn.el --- non-resident support for Subversion version-control
  
! ;; Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
  
  ;; Author:      FSF (see vc.el for full credits)
  ;; Maintainer:  Stefan Monnier <monnier@gnu.org>
--- 1,6 ----
  ;;; vc-svn.el --- non-resident support for Subversion version-control
  
! ;; Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
  
  ;; Author:      FSF (see vc.el for full credits)
  ;; Maintainer:  Stefan Monnier <monnier@gnu.org>
***************
*** 157,162 ****
--- 157,185 ----
        (vc-svn-command t 0 nil "status" (if localp "-v" "-u"))
        (vc-svn-parse-status))))
  
+ (defun vc-svn-dir-status (dir)
+   "Return a list of conses (FILE . STATE) for DIR."
+   (with-temp-buffer
+     (let ((default-directory (file-name-as-directory dir))
+ 	  (state-map '((?A . added)
+ 		       (?C . edited)
+ 		       (?D . removed)
+ 		       (?I . ignored)
+ 		       (?M . edited)
+ 		       (?R . removed)
+ 		       (?? . unregistered)
+ 		       ;; This is what vc-svn-parse-status does.
+ 		       (?~ . edited)))
+ 	  result)
+       (vc-svn-command t 0 nil "status")
+       (goto-char (point-min))
+       (while (re-search-forward "^\\(.\\)..... \\(.*\\)$" nil t)
+ 	(let ((state (cdr (assq (aref (match-string 1) 0) state-map)))
+ 	      (filename (match-string 2)))
+ 	  (when state
+ 	    (setq result (cons (cons filename state) result)))))
+       result)))
+ 
  (defun vc-svn-working-revision (file)
    "SVN-specific version of `vc-working-revision'."
    ;; There is no need to consult RCS headers under SVN, because we

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

> Appended is a patch to make it work with svn.  This patch is kind of a
> hack in that, if vc-status ever wants to support "non-terse" mode,
> then the function will have to be rewritten (since "svn status" and
> "svn status -v" have different formats).

If we introduce a new non-dired thingy, I suggest we don't even try to
provide a non-terse mode.  There are so many more important features to
add that we may as well decide from the get go that we'll never get to
that one.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

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

  > > Appended is a patch to make it work with svn.  This patch is kind of a
  > > hack in that, if vc-status ever wants to support "non-terse" mode,
  > > then the function will have to be rewritten (since "svn status" and
  > > "svn status -v" have different formats).
  > 
  > If we introduce a new non-dired thingy, I suggest we don't even try to
  > provide a non-terse mode.  There are so many more important features to
  > add that we may as well decide from the get go that we'll never get to
  > that one.

100% agreement.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>   > > Appended is a patch to make it work with svn.  This patch is kind of a
>   > > hack in that, if vc-status ever wants to support "non-terse" mode,
>   > > then the function will have to be rewritten (since "svn status" and
>   > > "svn status -v" have different formats).
>   > 
>   > If we introduce a new non-dired thingy, I suggest we don't even try to
>   > provide a non-terse mode.  There are so many more important features to
>   > add that we may as well decide from the get go that we'll never get to
>   > that one.
> 
> 100% agreement.

Seems reasonable to me as well, except -- do we really want to show all
uncontrolled files and have no option to suppress them?  

This is sticky, because we need them listed to select for register operations
but typically *don't* want them listed at other times.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > > 
  > >   > > Appended is a patch to make it work with svn.  This patch is kind of a
  > >   > > hack in that, if vc-status ever wants to support "non-terse" mode,
  > >   > > then the function will have to be rewritten (since "svn status" and
  > >   > > "svn status -v" have different formats).
  > >   > 
  > >   > If we introduce a new non-dired thingy, I suggest we don't even try to
  > >   > provide a non-terse mode.  There are so many more important features to
  > >   > add that we may as well decide from the get go that we'll never get to
  > >   > that one.
  > > 
  > > 100% agreement.
  > 
  > Seems reasonable to me as well, except -- do we really want to show all
  > uncontrolled files and have no option to suppress them?  

IMO we should show them.
We might need to add a new back-end command to add the files to the
ignored list.

This is no different when using the VCS from the command line, as long
as you don't explicitly ignore unregistered files (and they are not
ignored by some default rule), they will should up in the output of many
commands.

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

> Seems reasonable to me as well, except -- do we really want to show all
> uncontrolled files and have no option to suppress them?  

I don't understand: every VCS I know has some way to label files as "to
be ignored".  So there is always an "option to suppress them".


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > Seems reasonable to me as well, except -- do we really want to show all
> > uncontrolled files and have no option to suppress them?  
> 
> I don't understand: every VCS I know has some way to label files as "to
> be ignored".  So there is always an "option to suppress them".

Yes, but you sure don't want to have to set an ignore property by hand 
on every member of a huge tree you happen to have in your working
directory and *don't* want to be in the repo.

This case is already annoying me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> > Seems reasonable to me as well, except -- do we really want to show all
>> > uncontrolled files and have no option to suppress them?  
>> 
>> I don't understand: every VCS I know has some way to label files as "to
>> be ignored".  So there is always an "option to suppress them".

> Yes, but you sure don't want to have to set an ignore property by hand 
> on every member of a huge tree you happen to have in your working
> directory and *don't* want to be in the repo.

I don't see a problem here: you set the "ignore" property on the tree
itself, of course, not on each individual file.

In any case, I don't understand what this has to do with VC: no matter
which front-end you're going to use, you'll hit the same problem, and
the answer is always the same: use the "ignore" property.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

    >   > If we introduce a new non-dired thingy, I suggest we don't even try to
    >   > provide a non-terse mode.

What does "non-terse mode" mean in this context?

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     >   > If we introduce a new non-dired thingy, I suggest we don't even try to
>     >   > provide a non-terse mode.
> 
> What does "non-terse mode" mean in this context?

Showing unregistred files, basically.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> >   > If we introduce a new non-dired thingy, I suggest we don't even try to
>> >   > provide a non-terse mode.
>> 
>> What does "non-terse mode" mean in this context?

> Showing unregistred files, basically.

I thought "non-terse" mostly means to show "all" files, including the
up-to-date ones.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

    >     >   > If we introduce a new non-dired thingy, I suggest we don't even try to
    >     >   > provide a non-terse mode.
    > 
    > What does "non-terse mode" mean in this context?

    Showing unregistred files, basically.

If this feature is disconnected from Dired, I guess there is no need
to implement that mode.  It follows there is an advantage in staying
with Dired: continuing to offer that mode.

Re: Introducing 'unrecognized and 'ignored

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Showing unregistred files, basically.
>
> If this feature is disconnected from Dired, I guess there is no need
> to implement that mode.  It follows there is an advantage in staying
> with Dired: continuing to offer that mode.

The thing is that purely using a "VCS-centric" view of what files are
available is usually _much_ more efficient.  The VCS usually can
efficiently tell you about an "interesting subset" (non-ignored) of
unregistered files, and I think that's enough -- there's no need to read
the filesystem directly.

[Indeed, reading the filesystem directly would both require a lot more
programming effort, and probably be much, much slower (remember that one
of the big problems with vc-dired historically is that it's so slow as
to be basically unusable for non-trivial projects).]

-Miles

-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > I don't understand how the 'dir' argument works with the existing
  > vc-hg-dir-status.  The argument is never used in the function.  When I
  > tried vc-status on a mercurial working directory, I got results for
  > the whole tree, not the particular subdirectory I requested, which is
  > also weird.

It's a bug in vc-hg-dir-status (and in vc-hg-dir-state). I fixed it.
Thanks!

  > The resulting buffer is always called *vc-status*, which is
  > unfriendly.  Perhaps it should be named after the requested directory.

No opinion here. PCL-CVS calls it *cvs*, and it does not seem like a big
issue when using it.

  > I think it would be best to make vc-status work asynchronously from the
  > very beginning.  That is what pcl-cvs and psvn do, and it is nicer to
  > use on larger trees.  I think this is important to do first because it
  > is simpler to redesign the back end hooks now, if needed.

Good idea. Not sure what is the best way to do this. Feel free to change
it.

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> No opinion here. PCL-CVS calls it *cvs*, and it does not seem like a big
Dan> issue when using it.

FWIW, pcl-cvs isn't super friendly here, but it does make numbered
buffers when you have more than one.

Tom

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

Dan> No opinion here. PCL-CVS calls it *cvs*, and it does not seem like a big
Dan> issue when using it.

> FWIW, pcl-cvs isn't super friendly here, but it does make numbered
> buffers when you have more than one.

Actually PCL-CVS makes significant efforts to do better than that,
My PCL-CVS buffers are called "*cvs*" but they get uniquified like file
buffers, so if I have more than 1 they get names like "*cvs* | emacs"
and "*cvs* | haskell-mode" etc...


        Stefan

PCL-CVS buffers (was: Introducing 'unrecognized and 'ignored)

[Reiner Steib]

On Mon, Jan 07 2008, Stefan Monnier wrote:

>> FWIW, pcl-cvs isn't super friendly here, but it does make numbered
>> buffers when you have more than one.
>
> Actually PCL-CVS makes significant efforts to do better than that,
> My PCL-CVS buffers are called "*cvs*" but they get uniquified like file
> buffers, so if I have more than 1 they get names like "*cvs* | emacs"
> and "*cvs* | haskell-mode" etc...

Hm, I do this by means of `uniquify-buffer-name-style'.  Is there a
(better?) facility in PCL-CVS for naming buffers?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: PCL-CVS buffers

[Stefan Monnier]

>>> FWIW, pcl-cvs isn't super friendly here, but it does make numbered
>>> buffers when you have more than one.
>> 
>> Actually PCL-CVS makes significant efforts to do better than that,
>> My PCL-CVS buffers are called "*cvs*" but they get uniquified like file
>> buffers, so if I have more than 1 they get names like "*cvs* | emacs"
>> and "*cvs* | haskell-mode" etc...

> Hm, I do this by means of `uniquify-buffer-name-style'.

So do I.

> Is there a (better?) facility in PCL-CVS for naming buffers?

No, it's the same.  But since PCL-CVS buffers aren't plain old
file-buffers, uniquify needs some help from PCL-CVS.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > 2008-01-06  Tom Tromey  <tromey@redhat.com>
  > 
  > 	* vc-svn.el (vc-svn-dir-status): New function.

Sorry, I was convinced that this was checked in, but it was not. It is
now. 
But it needs to be updated to work with the asynchronous interface. Can
you please do that? 

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> Sorry, I was convinced that this was checked in, but it was
Dan> not. It is now.

Thanks.

I've been meaning to ping the list about all the patches I have sent
but that have not been committed or reviewed.  In GCC-land we tell
people to ping after a week... what is the accepted time for Emacs?

Dan> But it needs to be updated to work with the asynchronous
Dan> interface. Can you please do that?

I will try to get to it soon.  BTW I noticed that the new dir-status
back end hook is not documented.

Tom

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > Dan> Sorry, I was convinced that this was checked in, but it was
  > Dan> not. It is now.
  > 
  > Thanks.
  > 
  > I've been meaning to ping the list about all the patches I have sent
  > but that have not been committed or reviewed.  In GCC-land we tell
  > people to ping after a week... what is the accepted time for Emacs?

No idea if there's an official policy, but 1 week sounds reasonable.

  > BTW I noticed that the new dir-status back end hook is not
  > documented.

Sort of intentional. Given that its still subject to change, just trying
to minimize the effort put into this before the approach is accepted.

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> But it needs to be updated to work with the asynchronous
Dan> interface. Can you please do that?

Here's a patch.

I'm not really sure about using generate-new-buffer-name here.
Presumably each vc-status buffer should have a single vc "work" buffer
as well.

After trying this a couple times, I think the user needs an indication
of whether anything is running.  pcl-cvs puts this nicely in the
buffer... anyway, if you run vc-status on a directory with no changes,
it can be a little confusing as-is.

Finally, I wonder if it makes sense to call the callback with partial
results, and build up the buffer contents incrementally.  With large
directories, both pcl-cvs and psvn pause noticeably when "rendering".
I suppose this would only help if the underlying tool works this way
itself.

Tom

ChangeLog:
2008-01-19  Tom Tromey  <tromey@redhat.com>

	* vc-svn.el (vc-svn-after-dir-status): New function.
	(vc-svn-dir-status): Run svn asynchronously.

Index: vc-svn.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/vc-svn.el,v
retrieving revision 1.64
diff -u -r1.64 vc-svn.el
--- vc-svn.el	18 Jan 2008 23:45:03 -0000	1.64
+++ vc-svn.el	19 Jan 2008 06:30:23 -0000
@@ -158,28 +158,34 @@
       (vc-svn-command t 0 nil "status" (if localp "-v" "-u"))
       (vc-svn-parse-status))))
 
-(defun vc-svn-dir-status (dir)
-  "Return a list of conses (FILE . STATE) for DIR."
-  (with-temp-buffer
-    (let ((default-directory (file-name-as-directory dir))
-	  (state-map '((?A . added)
-		       (?C . edited)
-		       (?D . removed)
-		       (?I . ignored)
-		       (?M . edited)
-		       (?R . removed)
-		       (?? . unregistered)
-		       ;; This is what vc-svn-parse-status does.
-		       (?~ . edited)))
-	  result)
-      (vc-svn-command t 0 nil "status")
-      (goto-char (point-min))
-      (while (re-search-forward "^\\(.\\)..... \\(.*\\)$" nil t)
-	(let ((state (cdr (assq (aref (match-string 1) 0) state-map)))
-	      (filename (match-string 2)))
-	  (when state
-	    (setq result (cons (cons filename state) result)))))
-      result)))
+(defun vc-svn-after-dir-status (callback buffer)
+  (let ((state-map '((?A . added)
+		     (?C . edited)
+		     (?D . removed)
+		     (?I . ignored)
+		     (?M . edited)
+		     (?R . removed)
+		     (?? . unregistered)
+		     ;; This is what vc-svn-parse-status does.
+		     (?~ . edited)))
+	result)
+    (goto-char (point-min))
+    (while (re-search-forward "^\\(.\\)..... \\(.*\\)$" nil t)
+      (let ((state (cdr (assq (aref (match-string 1) 0) state-map)))
+	    (filename (match-string 2)))
+	(when state
+	  (setq result (cons (cons filename state) result)))))
+    (funcall callback result buffer)))
+
+(defun vc-svn-dir-status (dir callback buffer)
+  "Run 'svn status' for DIR and update BUFFER via CALLBACK.
+CALLBACK is called as (CALLBACK RESULT BUFFER), where
+RESULT is a list of conses (FILE . STATE) for directory DIR."
+  (with-current-buffer (get-buffer-create
+			(generate-new-buffer-name " *vc svn status*"))
+    (vc-svn-command (current-buffer) 'async nil "status")
+    (vc-exec-after
+     `(vc-svn-after-dir-status (quote ,callback) ,buffer))))
 
 (defun vc-svn-working-revision (file)
   "SVN-specific version of `vc-working-revision'."

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > Dan> But it needs to be updated to work with the asynchronous
  > Dan> interface. Can you please do that?
  > 
  > Here's a patch.

Thanks, checked in.

  > I'm not really sure about using generate-new-buffer-name here.
  > Presumably each vc-status buffer should have a single vc "work" buffer
  > as well.

IMO yes. I did it that way for vc-hg. But it still needs some
management: warn if the buffer already exist and refuse to start a new
status command, remove the buffer after it has been processed.

  > After trying this a couple times, I think the user needs an indication
  > of whether anything is running.  pcl-cvs puts this nicely in the
  > buffer... anyway, if you run vc-status on a directory with no changes,
  > it can be a little confusing as-is.

Yep. vc-status-refresh and vc-update-vc-status-buffer can insert some
start/end messages similar to PCL-CVS.

It would be nice if we had something more general that is easily
visible for buffers that use VC async commands. 

Something like changing the background of a mode-line entry for VC
buffers that are waiting for a command to compile. This should make it
very easy to spot a buffer that is still executing some command.

log, diff and annotate could all use this functionality.

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> I'm not really sure about using generate-new-buffer-name here.
>> Presumably each vc-status buffer should have a single vc "work" buffer
>> as well.

> IMO yes. I did it that way for vc-hg. But it still needs some
> management: warn if the buffer already exist and refuse to start a new
> status command, remove the buffer after it has been processed.

Yes, maybe Tom is right, sorry for telling you to always use
a new buffer.  Part of the PCL-CVS could probably be reused here because
it shouldn't have any CVS dependency, but then again, it may not be
worth the trouble.

>> After trying this a couple times, I think the user needs an indication
>> of whether anything is running.  pcl-cvs puts this nicely in the
>> buffer... anyway, if you run vc-status on a directory with no changes,
>> it can be a little confusing as-is.

> Yep. vc-status-refresh and vc-update-vc-status-buffer can insert some
> start/end messages similar to PCL-CVS.

> It would be nice if we had something more general that is easily
> visible for buffers that use VC async commands. 

> Something like changing the background of a mode-line entry for VC
> buffers that are waiting for a command to compile. This should make it
> very easy to spot a buffer that is still executing some command.

There's the mode-line-process entry, but it's not visible enough.
Also the PCL-CVS way of putting the actual command in the buffer turned
out to be very useful to double-check what it is doing (and even more
so when several commands are running at the same time).

> log, diff and annotate could all use this functionality.

Indeed, they could use `mode-line-process'.

As for on-the-fly updating rather than updating in the end.  It's been
on my todo list for PCL-CVS, but I never got to it.  It'd probably be
a good idea to add this from the beginning because it substantially
changes the way things work: you have to use a process filter rather than
a sentinel, you have to check whether the partial output you have is
enough to parse it reliably or whether we need to way for more output,
and you have to be able to update the display incrementally.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Sat, 19 Jan 2008 14:40:20 -0500

   There's the mode-line-process entry, but it's not visible enough.

with this, it is quite visibile (to me):

      (setq mode-line-process
            (propertize " (incomplete / in progress)"
                        'face 'compilation-warning))


(in vc-exec-after, see my other message in this thread.)

thi

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > () Stefan Monnier <monnier@iro.umontreal.ca>
  > () Sat, 19 Jan 2008 14:40:20 -0500
  > 
  >    There's the mode-line-process entry, but it's not visible enough.
  > 
  > with this, it is quite visibile (to me):
  > 
  >       (setq mode-line-process
  >             (propertize " (incomplete / in progress)"
  >                         'face 'compilation-warning))
  > 
  > 
  > (in vc-exec-after, see my other message in this thread.)

Thanks Thi, this seems to be the right thing to do. If it works, why not
check it in?

Re: Introducing 'unrecognized and 'ignored

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Sun, 20 Jan 2008 09:18:04 -0800

   seems to be the right thing to do.
   If it works, why not check it in?

i have now checked it in.

thi

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

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

  > > log, diff and annotate could all use this functionality.
  > 
  > Indeed, they could use `mode-line-process'.
  > 
  > As for on-the-fly updating rather than updating in the end.  It's been
  > on my todo list for PCL-CVS, but I never got to it.  It'd probably be
  > a good idea to add this from the beginning because it substantially
  > changes the way things work: you have to use a process filter rather than
  > a sentinel, you have to check whether the partial output you have is
  > enough to parse it reliably or whether we need to way for more output,
  > and you have to be able to update the display incrementally.

For doing incremental updates the needed changes for vc.el changes are
quite small. Just pass to the `dir-status' backend function another
function that is called when the asynchronous process finishes.
AFAICT vc-update-vc-status-buffer can work incrementally, the backend
just needs to call it with partial results when they are available.

Like this:

--- vc.el.~1.516.~      Fri Jan 18 15:05:37 2008
+++ vc.el               Sun Jan 20 08:52:48 2008
@@ -2627,6 +2627,11 @@
                  (vc-status-create-fileinfo (cdr entry) (car entry))))
     (ewoc-goto-node vc-status (ewoc-nth vc-status 0))))
 
+(defun vc-status-command-finished (successp buffer)
+  ;; This is called when dir-status finished processing the
+  ;; asynchronous output from the status command.
+  )
+
 (defun vc-status-refresh ()
   "Refresh the contents of the VC status buffer."
   (interactive)
@@ -2639,7 +2644,8 @@
     ;; the results.
     (vc-call-backend 
      backend 'dir-status default-directory 
-     #'vc-update-vc-status-buffer (current-buffer))))
+     #'vc-update-vc-status-buffer #'vc-status-command-finished
+     (current-buffer))))
 
 (defun vc-status-next-line (arg)
   "Go to the next line.

The backend changes to use a process filter are probably a bit more
complex, patches showing how to do that would be most welcome!

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

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

Stefan> There's the mode-line-process entry, but it's not visible enough.
Stefan> Also the PCL-CVS way of putting the actual command in the buffer turned
Stefan> out to be very useful to double-check what it is doing (and even more
Stefan> so when several commands are running at the same time).

Yes, I agree.  I rather like the PCL-CVS approach.  I've got a patch
to do this for vc-status, I'll send it after I test it a bit more.  I
hook into vc-do-command... I'm not sure if that is really a good idea.
I guess that's why we have patch review :-)

Stefan> As for on-the-fly updating rather than updating in the end.
Stefan> It's been on my todo list for PCL-CVS, but I never got to it.
Stefan> It'd probably be a good idea to add this from the beginning
Stefan> because it substantially changes the way things work: you have
Stefan> to use a process filter rather than a sentinel, you have to
Stefan> check whether the partial output you have is enough to parse
Stefan> it reliably or whether we need to way for more output, and you
Stefan> have to be able to update the display incrementally.

Yeah.  I think it is probably worth doing -- we know it is a potential
problem, and we have few dependencies to rewrite right now.

It is also worth considering if we really want to clear the ewoc
before re-running 'status' (or, eventually, 'update').  I suspect we
don't want to.  This seems to be what PCL-CVS does, and it has the
nice effect of preserving the user's marks and point during
operations.

I think that means we need a nice way to insert a new element into the
proper position in the ewoc; maybe a new ewoc method is needed.  (This
is different than updating the display incrementally, since right now
we just assume the back end hook provides the files in the right order
and we just insert them into the ewoc in that order.)

Tom

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

> I hook into vc-do-command... I'm not sure if that is really a good idea.
> I guess that's why we have patch review :-)

I general it doesn't sound like a bad idea, but I'll reserve my judgment
until I see the code.

> It is also worth considering if we really want to clear the ewoc
> before re-running 'status' (or, eventually, 'update').  I suspect we
> don't want to.  This seems to be what PCL-CVS does, and it has the
> nice effect of preserving the user's marks and point during
> operations.

PCL-CVS used to clear the ewoc, so I obviously believe it's worth the
effort to not clear it, so as to preserve mark and such.  Also because
you want to work on parts of a vc-status display (some backends don't
like it as much as CVS, but it's still pretty common).

> I think that means we need a nice way to insert a new element into the
> proper position in the ewoc; maybe a new ewoc method is needed.  (This
> is different than updating the display incrementally, since right now
> we just assume the back end hook provides the files in the right order
> and we just insert them into the ewoc in that order.)

Can't remember how I do it in PCL-CVS.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Tom Tromey]

>> I hook into vc-do-command... I'm not sure if that is really a good idea.
>> I guess that's why we have patch review :-)

Stefan> I general it doesn't sound like a bad idea, but I'll reserve
Stefan> my judgment until I see the code.

Here's the patch I've got.

Note there is a bug fix to vc-update-vc-status-buffer in here... this
should go in even if the rest of the patch does not.  You can see this
bug by running vc-status in a directory with no modifications and no
unrecognized files.

Stefan> PCL-CVS used to clear the ewoc, so I obviously believe it's
Stefan> worth the effort to not clear it, so as to preserve mark and
Stefan> such.

Yeah.  In general I think vc-status should follow PCL-CVS unless there
is a really good reason to be different.

Tom

2008-01-20  Tom Tromey  <tromey@redhat.com>

	* vc.el (vc-status-report-buffer): New variable.
	(vc-do-command): Display command in vc-status buffer.
	(vc-status-headers): Add 'command' argument.
	(vc-status-footers): New function.
	(vc-status-mode): Create footer.
	(vc-status-refresh): Bind vc-status-report-buffer.
	(vc-status-start-command): New function.
	(vc-status-command-finished): Likewise.
	(vc-update-vc-status-buffer): Avoid error if no nodes in ewoc.

Index: vc.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/vc.el,v
retrieving revision 1.516
diff -u -c -r1.516 vc.el
cvs diff: conflicting specifications of output style
*** vc.el	18 Jan 2008 23:32:57 -0000	1.516
--- vc.el	20 Jan 2008 20:11:34 -0000
***************
*** 1020,1025 ****
--- 1020,1028 ----
    ;; FIXME what about file names with spaces?
    (if (not filelist) "."  (mapconcat 'identity filelist " ")))
  
+ ;; This is let-bound when vc-do-command should report the command.
+ (defvar vc-status-report-buffer nil)
+ 
  ;;;###autoload
  (defun vc-do-command (buffer okstatus command file-or-list &rest flags)
    "Execute a VC command, notifying user and checking for errors.
***************
*** 1050,1055 ****
--- 1053,1064 ----
  		  " "
  		  (vc-delistify (mapcar (lambda (s) (if (> (length s) 20) (concat (substring s 0 2) "...")  s)) flags))
  		  " " (vc-delistify files))))
+     ;; Update the vc-status buffer, if requested.  Only do this for
+     ;; async commands; for synchronous commands the normal message is
+     ;; enough.
+     (if (and vc-status-report-buffer (eq okstatus 'async))
+ 	(with-current-buffer vc-status-report-buffer
+ 	  (vc-status-start-command full-command)))
      (save-current-buffer
        (unless (or (eq buffer t)
  		  (and (stringp buffer)
***************
*** 1091,1097 ****
  		(set-process-filter proc 'vc-process-filter)
  		(vc-exec-after
  		 `(if vc-command-messages
! 		      (message "Running %s in background... done" ',full-command))))
  	    ;; Run synchrously
  	    (if vc-command-messages
  		(message "Running %s in foreground..." full-command))
--- 1100,1110 ----
  		(set-process-filter proc 'vc-process-filter)
  		(vc-exec-after
  		 `(if vc-command-messages
! 		      (message "Running %s in background... done" ',full-command)))
! 		(if vc-status-report-buffer
! 		    (vc-exec-after
! 		     `(with-current-buffer ,vc-status-report-buffer
! 			(vc-status-command-finished)))))
  	    ;; Run synchrously
  	    (if vc-command-messages
  		(message "Running %s in foreground..." full-command))
***************
*** 2543,2553 ****
  
  (defvar vc-status nil)
  
! (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)))
  
  (defun vc-status-printer (fileentry)
    "Pretty print FILEENTRY."
--- 2558,2579 ----
  
  (defvar vc-status nil)
  
! (defun vc-status-headers (backend dir command)
    (concat
     (format "VC backend : %s\n" backend)
     "Repository : The repository goes here\n"
!    (format "Working dir: %s\n" dir)
!    "\n"
!    (if command (concat "-- Running: " command " ...")
!      "")
!    "\n"))
! 
! (defun vc-status-footers (command)
!   (concat
!    "\n--------------------- End ---------------------\n"
!    (if command (concat "-- Last command: " command " --")
!      "")
!    "\n"))
  
  (defun vc-status-printer (fileentry)
    "Pretty print FILEENTRY."
***************
*** 2615,2621 ****
      (erase-buffer)
      (set (make-local-variable 'vc-status)
  	 (ewoc-create #'vc-status-printer
! 		      (vc-status-headers backend default-directory)))
      (vc-status-refresh)))
  
  (put 'vc-status-mode 'mode-class 'special)
--- 2641,2648 ----
      (erase-buffer)
      (set (make-local-variable 'vc-status)
  	 (ewoc-create #'vc-status-printer
! 		      (vc-status-headers backend default-directory nil)
! 		      (vc-status-footers nil)))
      (vc-status-refresh)))
  
  (put 'vc-status-mode 'mode-class 'special)
***************
*** 2625,2638 ****
      (dolist (entry entries)
        (ewoc-enter-last vc-status
  		       (vc-status-create-fileinfo (cdr entry) (car entry))))
!     (ewoc-goto-node vc-status (ewoc-nth vc-status 0))))
  
  (defun vc-status-refresh ()
    "Refresh the contents of the VC status buffer."
    (interactive)
    ;; This is not very efficient; ewoc could use a new function here.
    (ewoc-filter vc-status (lambda (node) nil))
!   (let ((backend (vc-responsible-backend default-directory)))
      ;; Call the dir-status backend function. dir-status is supposed to
      ;; be asynchronous.  It should compute the results and call the
      ;; function passed as a an arg to update the vc-status buffer with
--- 2652,2668 ----
      (dolist (entry entries)
        (ewoc-enter-last vc-status
  		       (vc-status-create-fileinfo (cdr entry) (car entry))))
!     (let ((node (ewoc-nth vc-status 0)))
!       (if node
! 	  (ewoc-goto-node vc-status node)))))
  
  (defun vc-status-refresh ()
    "Refresh the contents of the VC status buffer."
    (interactive)
    ;; This is not very efficient; ewoc could use a new function here.
    (ewoc-filter vc-status (lambda (node) nil))
!   (let ((backend (vc-responsible-backend default-directory))
! 	(vc-status-report-buffer (current-buffer)))
      ;; Call the dir-status backend function. dir-status is supposed to
      ;; be asynchronous.  It should compute the results and call the
      ;; function passed as a an arg to update the vc-status buffer with
***************
*** 2641,2646 ****
--- 2671,2691 ----
       backend 'dir-status default-directory 
       #'vc-update-vc-status-buffer (current-buffer))))
  
+ (defun vc-status-start-command (command)
+   "Update the vc-status header with the current back-end command."
+   (let ((backend (vc-responsible-backend default-directory)))
+     (set (make-local-variable 'vc-running-command) command)
+     (ewoc-set-hf vc-status
+ 		 (vc-status-headers backend default-directory command)
+ 		 (vc-status-footers nil))))
+ 
+ (defun vc-status-command-finished ()
+   "Update the vc-status footer with previous command, and clear the header."
+   (let ((backend (vc-responsible-backend default-directory)))
+     (ewoc-set-hf vc-status
+ 		 (vc-status-headers backend default-directory nil)
+ 		 (vc-status-footers vc-running-command))))
+ 
  (defun vc-status-next-line (arg)
    "Go to the next line.
  If a prefix argument is given, move by that many lines."

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >> I hook into vc-do-command... I'm not sure if that is really a good idea.
  > >> I guess that's why we have patch review :-)
  > 
  > Stefan> I general it doesn't sound like a bad idea, but I'll reserve
  > Stefan> my judgment until I see the code.
  > 
  > Here's the patch I've got.
  > 
  > Note there is a bug fix to vc-update-vc-status-buffer in here... this
  > should go in even if the rest of the patch does not.  You can see this
  > bug by running vc-status in a directory with no modifications and no
  > unrecognized files.
  > 
  > Stefan> PCL-CVS used to clear the ewoc, so I obviously believe it's
  > Stefan> worth the effort to not clear it, so as to preserve mark and
  > Stefan> such.
  > 
  > Yeah.  In general I think vc-status should follow PCL-CVS unless there
  > is a really good reason to be different.

IMHO displaying the command that is running is overkill.  I don't think
VC users would care about it, they just want to see that something is
happening. Generic messages like Updating/Committing/Reading Status
should be enough. (PCL-CVS does print the command, but I personally
never payed attention to what it prints there...).  
Coupled with something that displays the running status in the mode-line
(like it is now done for diff/log/annotate).

About the footer message: I am afraid that it would get the same
opposition as the text at the end of vc-diff recently got.

Re: Introducing 'unrecognized and 'ignored

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Sat, 19 Jan 2008 09:05:24 -0800

   It would be nice if we had something more general that is
   easily visible for buffers that use VC async commands.

we can use `mode-line-process'.  below is a sketch.  works for me.
(would need to be adapted to latest vc.el, of course.)

thi


________________________________________________________
*** vc.el.~1.513.~	Mon Jan 14 18:53:10 2008
--- vc.el	Sat Jan 19 21:00:42 2008
***************
*** 958,963 ****
--- 958,967 ----
  
  (defun vc-process-sentinel (p s)
    (let ((previous (process-get p 'vc-previous-sentinel)))
+     (setq mode-line-process
+           (let ((status (process-status p)))
+             (unless (eq 'exit status)
+               (format " (%s)" status))))
      (if previous (funcall previous p s))
      (with-current-buffer (process-buffer p)
        (let (vc-sentinel-movepoint)
***************
*** 998,1003 ****
--- 1002,1008 ----
        (eval code))
       ;; If a process is running, add CODE to the sentinel
       ((eq (process-status proc) 'run)
+       (setq mode-line-process " (background)")
        (let ((previous (process-sentinel proc)))
          (unless (eq previous 'vc-process-sentinel)
            (process-put proc 'vc-previous-sentinel previous))

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>   (defun vc-process-sentinel (p s)
>     (let ((previous (process-get p 'vc-previous-sentinel)))
> +     (setq mode-line-process
> +           (let ((status (process-status p)))
> +             (unless (eq 'exit status)
> +               (format " (%s)" status))))

This can't be right: we have no idea what buffer we're in at this point.

> +       (setq mode-line-process " (background)")

The problem with this is that it's not necessarily clear that we're
changing mode-line-process in the right buffer either, here.  Also the
habit is to use something like ":run" or ":%s".


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Sun, 20 Jan 2008 14:24:57 -0500

   This can't be right: we have no idea what buffer we're in at this point.

you're right.  i have just installed a `with-current-buffer' wrapper.

   > +       (setq mode-line-process " (background)")

   The problem with this is that it's not necessarily clear that we're
   changing mode-line-process in the right buffer either, here.

PROC is taken from (current-buffer).  is that not reliable?

thi

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>    This can't be right: we have no idea what buffer we're in at this point.

> you're right.  i have just installed a `with-current-buffer' wrapper.

>> +       (setq mode-line-process " (background)")

>    The problem with this is that it's not necessarily clear that we're
>    changing mode-line-process in the right buffer either, here.

> PROC is taken from (current-buffer).  is that not reliable?

It's reliable in that we know which buffer it is, but that doesn't mean
it's the right buffer.  Isn't it often a hidden buffer like *vc* rather
than the vc-status buffer itself?


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

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

  > >    This can't be right: we have no idea what buffer we're in at this point.
  > 
  > > you're right.  i have just installed a `with-current-buffer' wrapper.
  > 
  > >> +       (setq mode-line-process " (background)")
  > 
  > >    The problem with this is that it's not necessarily clear that we're
  > >    changing mode-line-process in the right buffer either, here.
  > 
  > > PROC is taken from (current-buffer).  is that not reliable?
  > 
  > It's reliable in that we know which buffer it is, but that doesn't mean
  > it's the right buffer.  Isn't it often a hidden buffer like *vc* rather
  > than the vc-status buffer itself?

Yep, this seems to work for things like log, diff, annotate, but for
vc-status it does not, because as you say, the status command does not
run in vc-status buffer, but in a hidden temporary buffer.
It seems that a different mechanism is needed for that case.

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> >    This can't be right: we have no idea what buffer we're in at this point.
>> 
>> > you're right.  i have just installed a `with-current-buffer' wrapper.
>> 
>> >> +       (setq mode-line-process " (background)")
>> 
>> >    The problem with this is that it's not necessarily clear that we're
>> >    changing mode-line-process in the right buffer either, here.
>> 
>> > PROC is taken from (current-buffer).  is that not reliable?
>> 
>> It's reliable in that we know which buffer it is, but that doesn't mean
>> it's the right buffer.  Isn't it often a hidden buffer like *vc* rather
>> than the vc-status buffer itself?

> Yep, this seems to work for things like log, diff, annotate, but for
> vc-status it does not, because as you say, the status command does not
> run in vc-status buffer, but in a hidden temporary buffer.
> It seems that a different mechanism is needed for that case.

Yes, I guess the change is fine, and just needs to be supplemented with
some special code for vc-status.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Mon, 21 Jan 2008 10:18:02 -0500

   It's reliable in that we know which buffer it is, but that doesn't
   mean it's the right buffer.  Isn't it often a hidden buffer like *vc*
   rather than the vc-status buffer itself?

I don't know.  I tested w/ vc.el using `C-x v g' so there was no
vc-status buffer.  (Am i missing something?)

What is the scenario where there is a vc-status buffer to worry about?
The change is checked in; please try it and let me know w/ a concrete
(non-hypothetical) test case, for problems you encounter.

Note that the most recent change (checking liveness in then sentinel)
should have nothing to do w/ the original setq mode-line-process.

thi

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

      >      - performance  -- the difference is HUGE
      > 
      > What is the connection between using dired and this slowdown?

    It is much faster to ask the VCS about the status of the files and just
    display those results, rather than what it is done today: ask dired
    about all the files in a directory and the ask the VCS about the
    status.

If you don't want VC dired to show non-VCS-managed files, it could
initialize the buffer contents based on the VCS output alone, and that
would get the same speedup.

So I think that speedup is not a factor in dciding whether to
disconnect this from Dired.

I think we concluded that we want to offer the user the option
to show or not show the non-VCS-managed files.

    I believe so. One use for displaying no-file related information:
    repository name, branch name, the command that is being executed (all
    done by PCL-CVS). 

    In the future we might want to add some widgets to select the branch to
    display. Or to the repository to connect to.

Those sound like useful features.

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> I don't understand: CVS's status command recurses just fine and so does
> MetaCVS's (not that it matters since this backend can be dropped any day
> AFAICT).

Hm.  On inspection, you're right.  Looking at the history, I used to have it
doing tree traversal, then discovered I could get rid of that necessity by 
removing the -l option from the command.

> The only backends which might need to do tree traversal manually (AFAIK)
> are RCS and SCCS, of course, but I think it's fine for them to do the
> traversal by hand in the backend code.

And now they are in fact the only backends doing that.

> Maybe we're not talking about the same "tree traversal".  But AFAICT,
> vc-dired uses `ls' somewhere, where I think it should neither use `ls'
> nor `directory-files' nor anything equivalent in the generic code.

I think this is no longer true.  I looked for directory-files throughout
the VC files; none of the uses are within vc-dired-hook anymore,
except in Arch where they're necessary because of the odd way Arch
represents working-directory state.

So I think we've actually achieved what you want.

> That would also allow us to get rid of vc-directory-exclusion-list.

Not unless we want to wire an equivalent back into speedbar.el.
It's also genuinely needed in vc-next-action.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> Maybe we're not talking about the same "tree traversal".  But AFAICT,
>> vc-dired uses `ls' somewhere, where I think it should neither use `ls'
>> nor `directory-files' nor anything equivalent in the generic code.

> I think this is no longer true.  I looked for directory-files throughout
> the VC files; none of the uses are within vc-dired-hook anymore,

vc-directory calls dired-internal-noselect which does the directory
listing (typically using `ls').

> So I think we've actually achieved what you want.

Not yet.

>> That would also allow us to get rid of vc-directory-exclusion-list.

> Not unless we want to wire an equivalent back into speedbar.el.

That's a good idea in any case: speedbar shouldn't need to rely on VC
for that.

> It's also genuinely needed in vc-next-action.

I don't see it used there.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> vc-directory calls dired-internal-noselect which does the directory
> listing (typically using `ls').

Oh, so we can only get rid of that by no longer using dired at all.
Right.  That may be a way to go in the future.  Dan's idea of using
ewoc may work well, I'm going to make time to look into it.

> >> That would also allow us to get rid of vc-directory-exclusion-list.
> 
> > Not unless we want to wire an equivalent back into speedbar.el.
> 
> That's a good idea in any case: speedbar shouldn't need to rely on VC
> for that.

But the alternative is for speedbar and all other modes that have to
be VCS-aware to have their own separate lists of special
version-control directories.  This seems wrong to me, violating what
database people call the SPOT (Single Point Of Truth) rule.  

I think it's better to have that list be in vc-hooks where speedbar.el
and other things can see it.  That way they will automatically get
smarter whenever the code that manages VCSes becomes aware of 
another one.

> > It's also genuinely needed in vc-next-action.
> 
> I don't see it used there.

Sorry, seems I misread a grep hit.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> vc-directory calls dired-internal-noselect which does the directory
>> listing (typically using `ls').

> Oh, so we can only get rid of that by no longer using dired at all.

Right.

> > That's a good idea in any case: speedbar shouldn't need to rely on VC
> > for that.
> But the alternative is for speedbar and all other modes that have to
> be VCS-aware to have their own separate lists of special
> version-control directories.

speedbar doesn't actually want a list of "admin dirs used by VCS".
Instead it wants a list of "directories not to show in speedbar",
e.g. "dirs used for things like meta-data".  VCS are probably the most
common users of meta-data directories, but not the only ones.
E.g. SML/NJ's "CM" subdirectories are others I've had to live with.

> This seems wrong to me, violating what database people call the SPOT
> (Single Point Of Truth) rule.

Just because it's not in VC doesn't mean it can't be put in a single
spot, right?  ;-)


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> speedbar doesn't actually want a list of "admin dirs used by VCS".
> Instead it wants a list of "directories not to show in speedbar",
> e.g. "dirs used for things like meta-data".  VCS are probably the most
> common users of meta-data directories, but not the only ones.

Right.  If those other classes of metadata directories have elisp packages
that naturally own them, them I think speedbar ought to refer back to those
packages.

> > This seems wrong to me, violating what database people call the SPOT
> > (Single Point Of Truth) rule.
> 
> Just because it's not in VC doesn't mean it can't be put in a single
> spot, right?  ;-)

Certainly not.  But, since VC needs the information anyway, where else
would you put them?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Stefan Monnier]

>> speedbar doesn't actually want a list of "admin dirs used by VCS".
>> Instead it wants a list of "directories not to show in speedbar",
>> e.g. "dirs used for things like meta-data".  VCS are probably the most
>> common users of meta-data directories, but not the only ones.

> Right.  If those other classes of metadata directories have elisp packages
> that naturally own them, them I think speedbar ought to refer back to those
> packages.

>> > This seems wrong to me, violating what database people call the SPOT
>> > (Single Point Of Truth) rule.
>> 
>> Just because it's not in VC doesn't mean it can't be put in a single
>> spot, right?  ;-)

> Certainly not.  But, since VC needs the information anyway, where else
> would you put them?

VC doesn't really need the info.  It only uses it because of its
original mistake to use dired (and hence `ls').  Once this mistake is
corrected it won't need it any more.

Where else, then?  In simple.el or subr.el or some other global file.
Then VC backends can add to that variable and so can any other
elisp package.  This way speedbar doesn't need to refer to any of
those packages.


        Stefan

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> VC doesn't really need the info.  It only uses it because of its
> original mistake to use dired (and hence `ls').  Once this mistake is
> corrected it won't need it any more.
> 
> Where else, then?  In simple.el or subr.el or some other global file.
> Then VC backends can add to that variable and so can any other
> elisp package.  This way speedbar doesn't need to refer to any of
> those packages.

I'm not opposed to this, but it's conditional on changing VC so it doesn't use
Dired any more.  RMS is opposed to that; I'd like to know why before I
make a decision.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Introducing 'unrecognized and 'ignored

[Richard Stallman]

    I'm not opposed to this, but it's conditional on changing VC so it doesn't use
    Dired any more.  RMS is opposed to that; I'd like to know why before I
    make a decision.

I'm not dead-set against it.  Dired and VC-Dired are similar in general,
so if the implementations are totally different, that would mean
(1) two different implementations of the same thing, and (2) a tendency
for the user interfaces to become incompatible.

It is possible for sufficiently strong reasons to outweigh that one.

Re: Introducing 'unrecognized and 'ignored

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca>:
  > > vc-directory calls dired-internal-noselect which does the directory
  > > listing (typically using `ls').
  > 
  > Oh, so we can only get rid of that by no longer using dired at all.
  > Right.  That may be a way to go in the future.  Dan's idea of using
  > ewoc may work well, I'm going to make time to look into it.
  > 
  > > >> That would also allow us to get rid of vc-directory-exclusion-list.
  > > 
  > > > Not unless we want to wire an equivalent back into speedbar.el.
  > > 
  > > That's a good idea in any case: speedbar shouldn't need to rely on VC
  > > for that.
  > 
  > But the alternative is for speedbar and all other modes that have to
  > be VCS-aware to have their own separate lists of special
  > version-control directories.  This seems wrong to me, violating what
  > database people call the SPOT (Single Point Of Truth) rule.  

Unfortunately we have another violation of that:
grep-find-ignored-directories :-(

Re: Introducing 'unrecognized and 'ignored

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
>   > But the alternative is for speedbar and all other modes that have to
>   > be VCS-aware to have their own separate lists of special
>   > version-control directories.  This seems wrong to me, violating what
>   > database people call the SPOT (Single Point Of Truth) rule.  
> 
> Unfortunately we have another violation of that:
> grep-find-ignored-directories :-(

Thanks for the tip; I'll fix it.

Note to Stefan: this fix is a good idea even if we move 
vc-directory-exclusion-list out of vc-hooks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>