[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: minor enhancements for links: open Info link in new window; mouse-3
RE: minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links
Sat, 17 Jun 2006 13:52:43 -0700
1. Define commands `Info-follow-nearest-node-new-window' and
`Info-mouse-follow-nearest-node-new-window'. These just follow
a link in a new Info window (clone). I bind these to `S-RET'
and `S-mouse-2'. Both are handy.
2. These could be generalized to follow any link whose
destination Emacs understood (e.g. URL). In buffers with links,
the same key bindings (`S-RET', `S-mouse-2') might be appropriate.
Is there such a generic follow-link command already (one for
RET at point and one for mouse click)? Wouldn't that be useful?
In Info, it would follow an Info link. It would recognize a URL
and follow that. And so on, recognizing as many types of links
as possible, depending, for instance, on the buffer mode.
Sounds more or less like find-file-at-point to me.
Well, it's true that ffap does try to do something similar, but I find ffap
intrusive and not very useful. I was thinking more along the lines of
something that recognizes (only) well-defined Emacs links. Ffap doesn't even
recognize Info links, AFAICT, and it tries to interpret string of text as a
link. Not what I had in mind.
There is no single way to specify that some text in Emacs represents a link,
but there are some almost conventional ways - e.g. `follow-link' text
property or event binding. These could perhaps be exploited for such a
Some of the existing ffap code might then be reused (adapted) to figure out
how to follow a given kind of link. Another possibility would be to use the
`follow-link' property (or another) to specify the link-following method to
The particular non-nil value of `follow-link' might indicate whether the
link was Info, a URL, a file, or whatever. The value could be a link-handler
function, for instance, or a link-type argument for a general link handler.
That would eliminate most of the ffap-like guesswork. When a programmer
creates a well-defined link in Emacs s?he knows what kind of link it is.
In sum, instead of the ffap approach of guessing all the time what any
arbitrary section of text could potentially "link" to, rely upon
well-defined link areas, with well-defined link-interpretation handlers.
3. In buffers that have links, provide a mouse-3 context menu
for a link.
Any interest in such enhancements for after the release? #1 is trivial.
Together, 1-3 give you what you already have in most Web browsers: use Shift
to open a link in a new window, and use mouse-3 for a link context menu.
[I mention `follow-link' only because it provides a way to tell that some
linked text (but not all) is a link. IIUC, `follow-link' is really intended
to specify that mouse-1 can act like mouse-2 for the text in question.
AFAIK, there is no conventional way to define a link for, say, just
`mouse-2'. That's too bad, I think. It would be good to make it easy to
identify 1) that any given string of text is a link and 2) what kind of link
it is - how to follow it. The question of how to activate the link (mouse-1,
mouse-2) is orthogonal to this.]