From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Redesigh of the VC front end Date: Mon, 5 May 2008 20:39:43 -0400 (EDT) Message-ID: <20080506003943.80ED89F054C@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1210034419 17810 80.91.229.12 (6 May 2008 00:40:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 May 2008 00:40:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 06 02:40:54 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 1JtBEj-0002dX-NF for ged-emacs-devel@m.gmane.org; Tue, 06 May 2008 02:40:54 +0200 Original-Received: from localhost ([127.0.0.1]:44482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtBE1-0003Z4-TP for ged-emacs-devel@m.gmane.org; Mon, 05 May 2008 20:40:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JtBD5-00033B-KM for emacs-devel@gnu.org; Mon, 05 May 2008 20:39:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JtBD0-00031c-H0 for emacs-devel@gnu.org; Mon, 05 May 2008 20:39:11 -0400 Original-Received: from [199.232.76.173] (port=59957 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtBD0-00031Y-9G for emacs-devel@gnu.org; Mon, 05 May 2008 20:39:06 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=snark.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JtBCz-0006mE-8q for emacs-devel@gnu.org; Mon, 05 May 2008 20:39:06 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 80ED89F054C; Mon, 5 May 2008 20:39:43 -0400 (EDT) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:96552 Archived-At: This is a design proposal which I'm posting for comment and critique. Some months ago I rewrote the vc.el backends because the the API to them needed a rethink in order to handle multi-file changeset commmits. More recently, it has become evident that the front end's interface design needs a rethink as well. While it works with multi-file changeset commits, there has been no clean way to specify an operation on a directory or an entire repo. Instead, vc-deduce-fileset has had a tricky set of rules that expanded directories into directory file lists in certain special cases. Presently the rules work like this: 1. If we're in a VC-dired or VC-dir buffer and a nonempty fileset has been marked, return that fileset. 2. Otherwise, if you are in a vc dired buffer, and include-files-not-directories is non-nil, and no fileset is selected, select all files at and below directory level. 3. Otherwise, if we're in a buffer visiting a version-controlled file, the selection set is a singleton containing that file. 4. Otherwise, if we're visiting a change-comment or log buffer, the fileset is the one associated with its parent buffer 5. Otherwise, if allow-directory-wildcard is on-nil, and you're in a dired directory, select all files below the current directory 6. Otherwise, if we're allowing selection of unregistered files and the current buffer is visiting one, return that singleton set. Stefan Monnier thinks rule 5 is a misfeature and he's got a point. Rule 2 is a misfeature for similar reasons; they're both ways to get around the fact that directories aren't really first-class in Dired and cannot be passed back to a Dired client (the client gets all of their files as part of the merked set, instead). More generally, these rules are messy and complicated. They have a functional gap as well; there is no way at all to designate a selection that says "I don't care where we are, operate on the entire repo", which is an important concept when doing (say) commits or log-print requests on any VCS from Subversion onwards. Neither of these problems (selecting directories or selecting the whole repo) can be solved as long as the VC interface is tied to Dired. Dired is just too file-oriented. Fortunately, Dan Nicolaescu and Stefan Monnier have written much of a dired-like browser front end using ewoc. The ewoc code is flexible enough to allow us to select directories as filesets, though it is presently being used only as a sort of Dired emulation. So the Dired code has to go, once the vc-dir code is at functional parity to it. This will take a little more work. Here are the new rules I propose to implement: 1. If we're in a vc-dir buffer and a nonempty fileset has been marked, return that fileset. A fileset may include marked directories. 2. When the backend supports the concept, every vc-dir buffer has a special top-line entry that can be marked to select the entire repo. 3. If we're in a buffer visiting a version-controlled file, the selection set is a singleton containing that file. I plan to get rid of include-files-not-directories and allow-directory-wildcard and pass directory names to the backends when that's what the user selected. This means that file-oriented back ends (SCCS, RCS, CVS) will have to do directory expansion for themselves when it is needed. There is also a bit of murk around the handling of unregistered files. I haven't completely thought that one out yet. I think the code can be rewritten so that filesets of unregistered files are simply passed to the back end, yielding the VCS's own error for this case when the user did not select 'register' as the operation. Finally, anyone interested in working on or just undertstanding this code should note that I have split vc.el in half. The interface logic now lives in vc-dispatcher.el, which knows all about the VC user interface and (almost) nothing about VCSes or back ends. This code could be used for other things, like implementing a Midnight-Commander-style file manager. (By the time I'm done, I expect to be able to remove that "(almost)".) One goal in doing this was to reduce the global complexity of vc.el. That has been achieved; the interface between them is very narrow and well-defined, consisting only about 6 functions. Just as importantly, I did this in order to separate in my own mind the UI issues from the VCS logic. Barring more weirdness like the gastritis thing that put me in the hospital yesterday, I expect to get all this done within the next two weeks. I have put a temporary hold on my other projects to concentrate on it. -- Eric S. Raymond A man who has nothing which he is willing to fight for, nothing which he cares about more than he does about his personal safety, is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better men than himself. -- John Stuart Mill, writing on the U.S. Civil War in 1862