From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: Introducing 'unrecognized and 'ignored Date: Tue, 01 Jan 2008 20:45:31 -0800 Message-ID: <200801020445.m024jWU2008538@oogie-boogie.ics.uci.edu> References: <20071228174512.66834830BC9@snark.thyrsus.com> <17EA38DF-BCC1-4565-8510-5DD10DD667E3@mac.com> <20071229114551.GD9794@thyrsus.com> <20080102021907.GA15494@thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199249322 28030 80.91.229.12 (2 Jan 2008 04:48:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2008 04:48:42 +0000 (UTC) Cc: esr@thyrsus.com, "Eric S. Raymond" , Alexandru Harsanyi , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 02 05:49:01 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J9vXI-0002R0-7j for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 05:49:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9vWw-0004L7-1d for ged-emacs-devel@m.gmane.org; Tue, 01 Jan 2008 23:48:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9vWq-0004GE-Sl for emacs-devel@gnu.org; Tue, 01 Jan 2008 23:48:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9vWp-0004C9-Cw for emacs-devel@gnu.org; Tue, 01 Jan 2008 23:48:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9vWo-0004Bo-Vm for emacs-devel@gnu.org; Tue, 01 Jan 2008 23:48:31 -0500 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J9vWo-0000oJ-N9 for emacs-devel@gnu.org; Tue, 01 Jan 2008 23:48:30 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id m024jWU2008538; Tue, 1 Jan 2008 20:45:32 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Tue, 01 Jan 2008 23:16:52 -0500") Original-Lines: 47 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.763, required 5, autolearn=disabled, ALL_TRUSTED -1.44, J_CHICKENPOX_32 0.60, TW_SV 0.08) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85853 Archived-At: Stefan Monnier 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.