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: Re: Redesigh of the VC front end Date: Tue, 6 May 2008 04:48:57 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20080506084857.GE23773@thyrsus.com> References: <20080506003943.80ED89F054C@snark.thyrsus.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1210064339 27789 80.91.229.12 (6 May 2008 08:58:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 May 2008 08:58:59 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 06 10:59:34 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 1JtJ1G-00014Z-Cd for ged-emacs-devel@m.gmane.org; Tue, 06 May 2008 10:59:30 +0200 Original-Received: from localhost ([127.0.0.1]:50220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtJ0Y-0001jh-MI for ged-emacs-devel@m.gmane.org; Tue, 06 May 2008 04:58:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JtIqQ-0004yR-Hp for emacs-devel@gnu.org; Tue, 06 May 2008 04:48:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JtIqP-0004wL-4X for emacs-devel@gnu.org; Tue, 06 May 2008 04:48:17 -0400 Original-Received: from [199.232.76.173] (port=57175 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtIqO-0004wA-PL for emacs-devel@gnu.org; Tue, 06 May 2008 04:48:16 -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 1JtIqO-0003Ir-KH for emacs-devel@gnu.org; Tue, 06 May 2008 04:48:16 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 6DC589F054C; Tue, 6 May 2008 04:48:57 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.17+20080114 (2008-01-14) 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:96573 Archived-At: Stefan Monnier : > > 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. > > This is bad. It should simply return the "file or directory under > point". Agreed. I've already scheduled that change. > > 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. > > In PCL-CVS we list subdirectories, including ".", which is hence not > particularly special. But maybe there's a difference between "." and > "the entire repo". As I've previously remarked, if we wire the two together the iron law of perversity guarantees we will immediately discover a case in which they have to be treated differently. > > 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. > > In many respects the vc-dir code will never be at parity with vc-dired, > unless we make a special effort to merge it again with dired. I.e. we > shouldn't forget that some people liked to do dired operations from > vc-dired. > > For what it's worth, I don't think that merging the two is necessarily > a bad idea. But it seems terribly difficult to be able to do such > a combined mode that's both as good as dired and as good as vc-dir. You're probably right. What controls my decision here is simply that Dired has no way to return a directory as a selection. Given where I want to go with the simplification of the UI, that's a showstopper. > > 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. > > Actually, CVS handles directories just fine in most respects. If you think that's so, then I'll arrange directory expansion for SCCS and RCS only and wait to see if we get any CVS bug reports establishing that it's required for particular commands. Since we're all using CVS I expect any problem cases will become apparent pretty rapidly. > > 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. > > 100% agreement, especially because there may be good reasons for the > user to do that (e.g. if Emacs's notion of registration is buggy, or > out-of-date, or because the backend includes special semantics for them > (e.g. its "commit" operation may automatically add the unregistered > files mentioned on the command line). This will also be a near-future change. There's a more general point here. Some of the VC front-end design is a relic of days when the VCS's own error messages were quite ugly and uninformative. Remember that I originally wrote this 15 years ago for SCCS; back then, it was good UI design to prevent the user from seeing VCS error messages as much as possible, doing fairly strict checking of the user's actions instead and detecting error cases at Lisp level before going to the backend. Nowadays the tradeoffs have changed. Modern VCSes give much clearer guidance when an operation is invalid, so it makes more sense to just shove commands at the backend and let it complain informatively when something is not right. Pushing unregistered files at a VCS command other than register is pretty clearly one of the cases we can punt. -- Eric S. Raymond