emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hyperlinks in *vc-change-log*


From: Phil Hagelberg
Subject: Re: Hyperlinks in *vc-change-log*
Date: Thu, 10 Apr 2008 22:48:27 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Stefan Monnier <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]