minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links

minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links

[Drew Adams]

Some minor link enhancements for consideration after the release.

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.

3. In buffers that have links, provide a mouse-3 context menu for a link.

In a typical Web browser, you can right-click on a link and get a popup menu
appropriate to the link. In IE6 with the Google toolbar, for instance, I see
this as the link menu:

 Open
 Open In New Window
 Save Target As...
 Print Target
 ------------
 Cut
 Copy
 Copy Shortcut
 Paste
 ------------
 Add to Favorites...
 ------------
 Backward Links
 Cached Snapshot of Page
 Similar Pages
 Translate Page into English
 ------------
 Properties

Two menu items that it would be particularly good to have are Open In New
Window and Backward Links. In Info, Open in New Window would do the same
thing as `Info-follow-nearest-node-new-window'.

Backward Links is a Google thing that is sometimes quite handy. In Emacs
Info, it would open a window of links to other Info nodes that also linked
to the destination of the clicked link. The same functionality would be
available for the current node (as opposed to the target of a link): show
all nodes that link to it. Backward links for the current-node could be
bound to a key sequence.

minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links

[Bob Rogers]

   From: "Drew Adams" <drew.adams@oracle.com>
   Date: Sat, 10 Jun 2006 17:29:21 -0700

   Some minor link enhancements for consideration after the release . . .

   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.

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

RE: minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links

[Drew Adams]

       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
feature.

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
use.

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.]

RE: minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links

[Drew Adams]

I forgot "every" (in brackets):

    Ffap doesn't even recognize Info links, AFAICT, and it tries to
    interpret [every] string of text as a link. Not what I had in mind.