From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Hagelberg Newsgroups: gmane.emacs.devel Subject: Re: Hyperlinks in *vc-change-log* Date: Thu, 10 Apr 2008 22:48:27 -0700 Message-ID: <874pa9djro.fsf@hagelb.org> References: <87fxtvng9t.fsf@hagelb.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207893042 25705 80.91.229.12 (11 Apr 2008 05:50:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2008 05:50:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 11 07:51:16 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 1JkCAM-00021i-D0 for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2008 07:51:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JkC9i-0003Hn-Eb for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2008 01:50:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JkC7l-0002k1-Nf for emacs-devel@gnu.org; Fri, 11 Apr 2008 01:48:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JkC7k-0002jX-0s for emacs-devel@gnu.org; Fri, 11 Apr 2008 01:48:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JkC7j-0002jS-QL for emacs-devel@gnu.org; Fri, 11 Apr 2008 01:48:31 -0400 Original-Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=spunkymail-a1.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JkC7k-0000jx-18 for emacs-devel@gnu.org; Fri, 11 Apr 2008 01:48:32 -0400 Original-Received: from dynabook (75-172-31-48.tukw.qwest.net [75.172.31.48]) by spunkymail-a1.g.dreamhost.com (Postfix) with ESMTP id 8C548100065; Thu, 10 Apr 2008 22:48:28 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 09 Apr 2008 15:59:00 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:94944 Archived-At: Stefan Monnier writes: >> I've written up some code that I find quite useful for working with >> VC. The code below adds buttons to each commit entry in *vc-change-log* >> buffers, essentially making them hyperlinks to the revision mentioned >> using vc-find-revision. > > Doesn't seem like a bad idea. But it should be generalized to show not > only files but also diffs. I'm not sure what you mean by this. When I follow a hyperlink labelled with a given commit ID, I would expect to see the file revision of the file as it was in that commit. I'm guessing this means that it would also be handy to be able to see a diff between the given revision and the previous one, or perhaps the given revision and the current one. But I'm not sure how that would work in terms of the UI. This is all implemented using buttons, so I am only tying functionality to text that already exists in the buffer. Perhaps another binding could be used? RET to visit a revision, and C-RET to view the diff between that revision and the last? >> * The button actions use closures and thus require the cl library. As I >> understand it, this dependency would have to be removed for it to be >> included in Emacs. I consider this to be somewhat disappointing as it >> will add complexity to the code, but I respect this choice of the >> maintainers. > > Not a problem, you misunderstood the requirement. That's great; I love having closures available. I still might have a few things in there that need cl at runtime, but biggest thing is the lexical-let. > For multifile logs, the best option would be to popup a menu of files. > BTW this is specific to the display of files. For `diffs', this problem > wouldn't occur. That makes perfect sense; good idea. I would expect a keyboard invocation of the hyperlink would cause the choice to be given in the minibuffer, while a mouse invocation would cause a contextual menu much like the one you see with C-mouse-1. Is there any way to create such a menu in a unified fashion? I am only familiar with the minibuffer route. -Phil http://technomancy.us