RE: generate 3) S-mouse-2: follow link in new window

[Drew Adams]

> > 3. It would also be helpful to bind `S-mouse-2' in Info to a
> > command that follows an Info link in a new window.
>
> Or better to use bindings like in Web browsers: `S-mouse-1' to follow
> a link in a new frame, `C-mouse-1' to follow a link in a new window
> (or a tab when tabs will be implemented in Emacs).

a. Perhaps we can get agreement about the functionality first, then about
the binding. It sounds as if at least you and I agree about this part.

b. Wrt the binding, I do disagree. I set `mouse-1-click-follows-link' to nil
(I think that should be the default, BTW). I want `mouse-2' to be the
standard link-following binding. I want commands such as the proposed one to
be on `mouse-2' with modifiers. To me, it was an aberration to introduce
`mouse-1' linking to Emacs as anything other than an option (i.e. not the
default).

No, I don't want to reopen that discussion; I mention it here because I
think it is relevant. `mouse-2' is still the standard link-follower - there
is no option to remove it, as there is for `mouse-1'. The modifier bindings
should be made accordingly: to `mouse-2'.

If there are many voices for `S-mouse-1' etc., then I'd ask that
`mouse-1-click-follows-link' act for them as well, but, still, `S-mouse-2'
would be the standard, following the Emacs `mouse-2' convention.

> > That way, a user could keep the `L' or the `I' buffer (or a TOC or an
> > index or any other node) open while visiting its links in another window
> > (or frame, with non-nil pop-up-frames).
> >
> > I have used this definition:
> >
> > (defun Info-mouse-follow-nearest-node-new-window (click)
> >     "Open the link at the mouse pointer in a new window."
> >     (interactive "e")
> >     (Info-mouse-follow-nearest-node click t)) ; t no good now
> >
> > But that particular implementation no longer works, because
> > someone over the course of Emacs 22 development removed the
> > optional FORK argument to
> > `Info-follow-nearest-node' and `Info-mouse-follow-nearest-node'. (Why?)
>
> `Info-mouse-follow-nearest-node' never had the FORK argument.
> `Info-follow-nearest-node' still has it, but there were plans to
> remove it.

You're right, on both counts. I think I left in the above code hoping that
FORK would be added in response to my request for it: 2006-01-08, Subject
"Info-mouse-follow-nearest-node should take prefix arg to fork". I had
forgotten that thread. Richard's response was to wait until after the
release (22). Your response was that FORK was a deprecated feature
(presumably you were referring to the non-mouse command).

So let me repeat my 2006 request, since the release is now out: Let's add
the FORK arg - or else find some other way to implement
`Info-mouse-follow-nearest-node-new-window'. It is a useful command.

> > Regardless of how it is implemented, it would be useful. You
> > can do the same thing by cloning the buffer and then following
> > a link, but it is particulaly
> > handy to do this with just a mouse click.
>
> This is a question of implementation.  We can implement a command that
> will clone the current manual, follow the requested node in a new copy,
> and display it accordingly to the command arguments.

Fine. I really don't care how the behavior I described is implemented. I'm
speaking as a user here, saying that I think this functionality would be
useful. People use it all the time when surfing the Web, however their
browser might let them open a link in another window. In IE, for instance,
you can choose "Open in New Window" in the right-click context menu.