* minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links @ 2006-06-11 0:29 Drew Adams 2006-06-11 2:24 ` Bob Rogers 0 siblings, 1 reply; 4+ messages in thread From: Drew Adams @ 2006-06-11 0:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links 2006-06-11 0:29 minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links Drew Adams @ 2006-06-11 2:24 ` Bob Rogers 2006-06-17 20:52 ` Drew Adams 0 siblings, 1 reply; 4+ messages in thread From: Bob Rogers @ 2006-06-11 2:24 UTC (permalink / raw) Cc: Emacs-Devel 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links 2006-06-11 2:24 ` Bob Rogers @ 2006-06-17 20:52 ` Drew Adams 2006-06-17 21:12 ` Drew Adams 0 siblings, 1 reply; 4+ messages in thread From: Drew Adams @ 2006-06-17 20:52 UTC (permalink / raw) 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.] ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links 2006-06-17 20:52 ` Drew Adams @ 2006-06-17 21:12 ` Drew Adams 0 siblings, 0 replies; 4+ messages in thread From: Drew Adams @ 2006-06-17 21:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-06-17 21:12 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-06-11 0:29 minor enhancements for links: open Info link in new window; mouse-3 menu for buffers with links Drew Adams 2006-06-11 2:24 ` Bob Rogers 2006-06-17 20:52 ` Drew Adams 2006-06-17 21:12 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).