generate 1) virtual index and 2) other pages for Info; 3) S-mouse-2: follow link in new window

generate 1) virtual index and 2) other pages for Info; 3) S-mouse-2: follow link in new window

[Drew Adams]

1. It would be useful to have an Info command, say bound to `I', that would
do for index lookup what `L' (Info-history) does for chronological
navigation. You would type a regexp, and it would show you a buffer similar
to the `Recently Visited Nodes' buffer of `L'.

That buffer would have a list of all index entries that matched your regexp.
As in the existing manual indexes, it would have both the index entry (a
link) and the name of the node it occurs in. IOW, it would be a virtual
index, based on your input.

This would be useful because you would be able to simultaneously examine
multiple entries that are candidates of interest. Info-index (`i') is great,
but it doesn't give you a good picture of all matching entries, and you can
only visit them in sequence. Completion shows you all candidates that match
your input, but they are all prefix matches, which is not as useful here as
a substring or regexp match.

I know it helps to allow regexp matching and to show all matches in such a
way that you can continue to navigate among them in any order while seeing
them all, because Icicles has something similar and it is very handy.
Instead of generating a fixed buffer with links as described above, Icicles
shows you the matching index entries in *Completions*, but you can continue
to see them there as you visit their locations in the manual.

I'm not suggesting to do what Icicles does, but to do what `Info-history'
does, except with index entries.


2. The same implementation could perhaps be leveraged to let users create
their own virtual Info booklets. They would hit some key in Info nodes of
interest, and links to those nodes would be saved in an `Info-history'-like
buffer for later use. IOW, this would be like being able to save an
`Info-history' buffer. But only nodes that you select would be included in
the collection (whereas `Info-history' lists all nodes you have visited).

Yes, I know that bookmarks offer something similar, but the UI would be a
little different and this would be limited to Info nodes.


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. 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?)
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.

Re: generate 1) virtual index and 2) other pages for Info; 3) S-mouse-2: follow link in new window

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

> 1. It would be useful to have an Info command, say bound to `I', that would
> do for index lookup what `L' (Info-history) does for chronological
> navigation. You would type a regexp, and it would show you a buffer similar
> to the `Recently Visited Nodes' buffer of `L'.

> [...]

> 2. The same implementation could perhaps be leveraged to let users create
> their own virtual Info booklets. 

That would be very useful.  

Let me try to sum up this thread.

By "good documentation and software support", we mean something like:

(1) a lot of static information for each feature
(2) a nice navigation system to go through it
(3) a lively community answering with no delay
(4) a personal database aware of my own bias and learning curve

Emacs can't be beaten on (3), even though it's a well known fact that
Emacs people are arrogant, rude with noobs, etc. :)

Emacs is also great on (1), nobody can really complain on that.

Dave first raised a problem that fully belongs to (4) then wanted (2) to
be the culprit (sorry Dave). But this are separate problems. The problem
of not being able to find "revert" when we look for "refresh" should be
solved by a personal help manager, not by the navigation system through
the documentation.

I think "Info booklets" are a good starting point for a "personal help
manager" (please someone rescue me from this awful expression, I'm not
an english native speaker).  

Maybe such a tool could also store every help-* call in a way that it
will store the *path* going from the initial input to the answer.  

It one thing not to be able to know *everything* about Emacs features.
It's another thing not to be able to find the feature we actually need.
And it's again another thing not to be able to *remind* oneself what is
the name of a feature we already used some time ago.

-- 
Bastien

Re: generate 1) virtual index

[Juri Linkov]

> 1. It would be useful to have an Info command, say bound to `I', that would
> do for index lookup what `L' (Info-history) does for chronological
> navigation. You would type a regexp, and it would show you a buffer similar
> to the `Recently Visited Nodes' buffer of `L'.
>
> That buffer would have a list of all index entries that matched your regexp.
> As in the existing manual indexes, it would have both the index entry (a
> link) and the name of the node it occurs in. IOW, it would be a virtual
> index, based on your input.

Since it was proposed in

http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00454.html

instead of implementing `Info-index-occur' I arrived to a different
command name: `info-apropos-current-file'.  I don't know if this is
a better name, but by its functionality this command is very similar
to `info-apropos' that works only on the current Info file.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: generate 2) other pages for Info

[Juri Linkov]

> 2. The same implementation could perhaps be leveraged to let users create
> their own virtual Info booklets. They would hit some key in Info nodes of
> interest, and links to those nodes would be saved in an `Info-history'-like
> buffer for later use. IOW, this would be like being able to save an
> `Info-history' buffer. But only nodes that you select would be included in
> the collection (whereas `Info-history' lists all nodes you have visited).

I had a similar idea but this is far from finishing.  It is uncertain
if is this feature will require a separate package, or it will be simple
enough to add to info.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

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

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

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

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: generate 2) other pages for Info

[Juri Linkov]

> The problem of not being able to find "revert" when we look for
> "refresh" should be solved by a personal help manager, not by the
> navigation system through the documentation.

Could you elaborate why do you think this should be solved by a
personal help manager?  As I see, in a PIM the user adds a link
(or a bookmark) to the information that the user has already found.
But how this will help to find a new information?  I think only adding
various index entries including most synonyms (e.g. "revert", "refresh",
"update", ...) will help to find the entry.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: generate 2) other pages for Info

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>> The problem of not being able to find "revert" when we look for
>> "refresh" should be solved by a personal help manager, not by the
>> navigation system through the documentation.
> 
> Could you elaborate why do you think this should be solved by a
> personal help manager?  As I see, in a PIM the user adds a link
> (or a bookmark) to the information that the user has already found.
> But how this will help to find a new information?  I think only adding
> various index entries including most synonyms (e.g. "revert", "refresh",
> "update", ...) will help to find the entry.

Maybe I can comment a bit on Drews idea. Personally I sometimes bookmark 
web pages for later use if I do not have the time to read through them 
at the moment or think that the links there might be useful.

Re: generate 2) other pages for Info

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>> The problem of not being able to find "revert" when we look for
>> "refresh" should be solved by a personal help manager, not by the
>> navigation system through the documentation.
>
> Could you elaborate why do you think this should be solved by a
> personal help manager?  

Let's take an example.  

Imagine someone is looking for the command that add a ChangeLog entry.
Here are a few different searching paths he might go through:

1. His first reflex is to go to the Emacs manual. Great! It's there.

2. He thinks he can use `finder-by-keyword' (C-h P) for that. If he is
   brave enough to go to the end of the list, he will find "tools", then
   add-log.el, then he will stumble on "This facility is documented in
   the Emacs Manual." Okay, then he should have gone there first.

3. He is used to `apropos-command' (C-h a). He tries that and look for
   "ChangeLog". Bad luck. He will find this:

   log-edit-add-to-changelog     M-x ... RET
   log-edit-insert-changelog     M-x ... RET
   
   He didn't look for "log" because he thought there would be too many
   matches (in fact, the first match for this query is okay.)

   Let's say that he finally found `add-change-log-entry'. Now he might
   want to find documentation using `Info-goto-emacs-command-node' but
   C-h F add-change-log-entry doesn't yield any result (though C-h F
   add-change-log-entry-other-window).

In all these three scenarii, all that the user want to access to is:
"add a changelog entry" -> "the Change Log manual page in Emacs manual".

Scenario 1 is obviously the best one here, but that may not be always
the case. He might have to go through something like 2 or 3 for other
queries. In fact, different kinds of information live in different
places and it would be nice to have a separate place for information
that we *already found* in the past. 

So here is what a personal help manager could store:

| searched              | found                | manual                    |
|-----------------------+----------------------+---------------------------|
| Add a ChangeLog entry | add-change-log-entry | (info "(emacs)Change Log) |

(This is actually what I'm trying to use inside my org-mode file.)

> As I see, in a PIM the user adds a link (or a bookmark) to the
> information that the user has already found.

This is it.

> But how this will help to find a new information? 

This won't. But this will be a way not to lose information we already
found.

> I think only adding various index entries including most synonyms
> (e.g. "revert", "refresh", "update", ...) will help to find the entry.

The main job of the personal help manager would be to be able to find
these synonyms. I guess different people would use different synonyms
sets (not mentionning language-dependant issues).

-- 
Bastien

RE: generate 1) virtual index

[Drew Adams]

> > 1. It would be useful to have an Info command, say bound to
> > `I', that would do for index lookup what `L' (Info-history)
> > does for chronological navigation. You would type a regexp,
> > and it would show you a buffer similar
> > to the `Recently Visited Nodes' buffer of `L'.
> >
> > That buffer would have a list of all index entries that matched
> > your regexp. As in the existing manual indexes, it would have
> > both the index entry (a link) and the name of the node it
> > occurs in. IOW, it would be a virtual index, based on your input.
>
> Since it was proposed in
>
> http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00454.html
>
> instead of implementing `Info-index-occur' I arrived to a different
> command name: `info-apropos-current-file'.  I don't know if this is
> a better name, but by its functionality this command is very similar
> to `info-apropos' that works only on the current Info file.

I'm not sure, but I think we are saying the same or similar things. Is that
right? I had forgotten your proposal cited in the link above, but it seems
about the same. Is there a difference or something additional that you are
saying?

Anyway, IIUC, I am comfortable with what I think you're suggesting. You too
seem to be saying that it would be good to have a command that accepted a
regexp and built a buffer of matching index entries (links) and their node
descriptions.

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.

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

[Lennart Borgman (gmail)]

Drew Adams wrote:
> 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.

I am for S-mouse-1 to open the link a new frame (mouse-1 follow link of 
course) since that is what most users would expect.

Re: generate 2) other pages for Info

[Eli Zaretskii]

> From: Bastien <bzg@altern.org>
> Date: Sun, 23 Sep 2007 16:17:40 +0200
> Cc: drew.adams@oracle.com, emacs-devel@gnu.org
> 
> Imagine someone is looking for the command that add a ChangeLog entry.
> Here are a few different searching paths he might go through:
> 
> 1. His first reflex is to go to the Emacs manual. Great! It's there.
> 
> 2. He thinks he can use `finder-by-keyword' (C-h P) for that. If he is
>    brave enough to go to the end of the list, he will find "tools", then
>    add-log.el, then he will stumble on "This facility is documented in
>    the Emacs Manual." Okay, then he should have gone there first.
> 
> 3. He is used to `apropos-command' (C-h a). He tries that and look for
>    "ChangeLog". Bad luck. He will find this:
> 
>    log-edit-add-to-changelog     M-x ... RET
>    log-edit-insert-changelog     M-x ... RET

My personal recommendation is use the Help commands in a different
order:

  1. Info-index (`i' in Info mode)

  2. M-x apropos

  3. M-x apropos-documentation

> So here is what a personal help manager could store:
> 
> | searched              | found                | manual                    |
> |-----------------------+----------------------+---------------------------|
> | Add a ChangeLog entry | add-change-log-entry | (info "(emacs)Change Log) |
> 
> (This is actually what I'm trying to use inside my org-mode file.)

After 10 years of using Emacs, this index will become so huge that it
will be unusable, I'm pretty sure.

> > I think only adding various index entries including most synonyms
> > (e.g. "revert", "refresh", "update", ...) will help to find the entry.
> 
> The main job of the personal help manager would be to be able to find
> these synonyms. I guess different people would use different synonyms
> sets (not mentionning language-dependant issues).

We could collect those synonyms for them (we actually do that today,
in the index entries we place in the manual, please take a look).

Re: generate 1) virtual index

[Juri Linkov]

>> Since it was proposed in
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00454.html
>>
>> instead of implementing `Info-index-occur' I arrived to a different
>> command name: `info-apropos-current-file'.  I don't know if this is
>> a better name, but by its functionality this command is very similar
>> to `info-apropos' that works only on the current Info file.
>
> I'm not sure, but I think we are saying the same or similar things.
> Is that right?  I had forgotten your proposal cited in the link above,
> but it seems about the same. Is there a difference or something
> additional that you are saying?

Below is a simple patch that implements this:

Index: lisp/info.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/info.el,v
retrieving revision 1.505
diff -c -w -b -r1.505 info.el
*** lisp/info.el	28 Aug 2007 10:15:23 -0000	1.505
--- lisp/info.el	23 Sep 2007 20:40:07 -0000
***************
*** 2931,2940 ****
  	(progn (beginning-of-line) t)  ;; non-nil for recursive call
        (goto-char (point-min)))))
  
  ;;;###autoload
! (defun info-apropos (string)
    "Grovel indices of all known Info files on your system for STRING.
! Build a menu of the possible matches."
    (interactive "sIndex apropos: ")
    (unless (string= string "")
      (let ((pattern (format "\n\\* +\\([^\n]*%s[^\n]*\\):[ \t]+\\([^\n]+\\)\\.\\(?:[ \t\n]*(line +\\([0-9]+\\))\\)?"
--- 2931,2947 ----
  	(progn (beginning-of-line) t)  ;; non-nil for recursive call
        (goto-char (point-min)))))
  
+ (defun info-apropos-current-file (string)
+   "Search indices of the current Info file for STRING.
+ Build a menu of the possible matches."
+   (interactive "sIndex apropos current Info file: ")
+   (info-apropos string t))
+ 
  ;;;###autoload
! (defun info-apropos (string &optional current)
    "Grovel indices of all known Info files on your system for STRING.
! Build a menu of the possible matches.
! If CURRENT is non-nil, search indices only in the current Info file."
    (interactive "sIndex apropos: ")
    (unless (string= string "")
      (let ((pattern (format "\n\\* +\\([^\n]*%s[^\n]*\\):[ \t]+\\([^\n]+\\)\\.\\(?:[ \t\n]*(line +\\([0-9]+\\))\\)?"
***************
*** 2943,2950 ****
--- 2950,2960 ----
  	  (ohist-list Info-history-list)
  	  (current-node Info-current-node)
  	  (current-file Info-current-file)
+ 	  (supports-index-cookies Info-file-supports-index-cookies)
  	  manuals matches node nodes)
        (let ((Info-fontify-maximum-menu-size nil))
+ 	(if current
+ 	    (setq manuals (list Info-current-file))
  	  (Info-directory)
  	  ;; current-node and current-file are nil when they invoke info-apropos
  	  ;; as the first Info command, i.e. info-apropos loads info.el.  In that
***************
*** 2959,2965 ****
  	(while (re-search-forward "\\*.*: *(\\([^)]+\\))" nil t)
  	  ;; add-to-list makes sure we don't have duplicates in `manuals',
  	  ;; so that the following dolist loop runs faster.
! 	  (add-to-list 'manuals (match-string 1)))
  	(dolist (manual (nreverse manuals))
  	  (message "Searching %s" manual)
  	  (condition-case err
--- 2969,2975 ----
  	  (while (re-search-forward "\\*.*: *(\\([^)]+\\))" nil t)
  	    ;; add-to-list makes sure we don't have duplicates in `manuals',
  	    ;; so that the following dolist loop runs faster.
! 	    (add-to-list 'manuals (match-string 1))))
  	(dolist (manual (nreverse manuals))
  	  (message "Searching %s" manual)
  	  (condition-case err
***************
*** 2991,2996 ****
--- 3001,3009 ----
  	(with-current-buffer (get-buffer-create " *info-apropos*")
  	  (erase-buffer)
  	  (insert "\n\^_\nFile: apropos, Node: Index, Up: (dir)\n")
+ 	  (when supports-index-cookies
+ 	    (insert "\0\b[index\0\b]\n")
+ 	    (set (make-local-variable 'Info-file-supports-index-cookies) supports-index-cookies))
  	  (insert "* Menu: \nNodes whose indices contain `" string "':\n\n")
  	  (dolist (entry (nreverse matches))
  	    (insert
***************
*** 3177,3182 ****
--- 3190,3196 ----
    (define-key Info-mode-map "g" 'Info-goto-node)
    (define-key Info-mode-map "h" 'Info-help)
    (define-key Info-mode-map "i" 'Info-index)
+   (define-key Info-mode-map "I" 'info-apropos-current-file)
    (define-key Info-mode-map "l" 'Info-history-back)
    (define-key Info-mode-map "L" 'Info-history)
    (define-key Info-mode-map "m" 'Info-menu)

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Drew Adams]

> > 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.
>
> I am for S-mouse-1 to open the link a new frame (mouse-1 follow link of
> course) since that is what most users would expect.

1. `mouse-1' does not follow a link, "of course" - that behavior is
user-configurable, and so should be the behavior of `S-mouse-1'. That was my
point.

Personally, I am against `mouse-1' following links by default, and likewise
`S-mouse-1', but I can live with a counter decision. But in any case, this
must be user-controllable with a user option. I proposed to use
`mouse-1-click-follows-link' to control both.


2. And I proposed that we revisit the default value of
`mouse-1-click-follows-link', now that people have had ample opportunity to
try it. We made the default value what it is for the reason you gave, IIRC:
it "is what most [new] users would expect". But those same new users might
prefer the opposite configuration if they were aware of it.

There are many cases where we prefer and choose a different default behavior
from what people might be used to outside of Emacs, because the Emacs
behavior is superior. I, for one, think this is the case for `mouse-2' and
links. It is really not difficult to figure out that you click `mouse-2' to
follow text that is highlighted when you mouseover it.

I think this is a case of pandering to external habit with no real benefit.
Honestly, how many of you (not new users) keep the default value of
`mouse-1-click-follows-link'? Outside of Emacs, there is not the same need
for the normal use of `mouse-1' to set point. Yes, we have found a mostly
workable way for `mouse-set-point' to coexist with following links. But I
find it to be a poor juggling of conflicting behaviors and a poor substitute
for the superior behavior of `mouse-1' to set point and `mouse-2' to follow
links.

Why is there not such a conflict between `mouse-2's role in pasting and its
role in following links? I suppose it's because you paste less often than
you set point, and you don't paste into a link. Honestly, pre-Emacs 22, did
you ever run into a UI conflict between pasting and following a link? And
just as honestly, with Emacs 22 have you ever accidentally followed a link
when you just wanted to select a buffer or window or move the cursor?

Re: generate 2) other pages for Info

[Richard Stallman]

    But how this will help to find a new information?  I think only adding
    various index entries including most synonyms (e.g. "revert", "refresh",
    "update", ...) will help to find the entry.

I think we should add such index items in the cases where they are
clearly useful.  If you know of such cases, please add them.

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

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> how many of you (not new users) keep the default value of
> `mouse-1-click-follows-link'?

I sure don't.

-- 
Johan Bockgård

Re: generate 2) other pages for Info

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> | searched              | found                | manual                    |
>> |-----------------------+----------------------+---------------------------|
>> | Add a ChangeLog entry | add-change-log-entry | (info "(emacs)Change Log) |
>> 
>> (This is actually what I'm trying to use inside my org-mode file.)
>
> After 10 years of using Emacs, this index will become so huge that it
> will be unusable, I'm pretty sure.

The user could keep such a history till he feels himself confident
enough to get rid of it.

>> The main job of the personal help manager would be to be able to find
>> these synonyms. I guess different people would use different synonyms
>> sets (not mentionning language-dependant issues).
>
> We could collect those synonyms for them (we actually do that today,
> in the index entries we place in the manual, please take a look).

I have, and this is great. 

The good thing about a user-based help history is that it lets you store
erroneous search paths. There is no place for search errors inside the
standard documentation, even by using fuzzy matching of synonyms.

I found out that, not being able to find the correct answer is often a
matter of putting the query in the wrong words, and chances are very
little that these wrong words are synonyms of the a relevant query.

-- 
Bastien

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

[Stefan Monnier]

> Honestly, how many of you (not new users) keep the default value of
> `mouse-1-click-follows-link'?

I do keep it as default, because I want to suffer like the most naive user,
to make sure that it's a bearable suffering (and yes, I find it bearable,
although I do get bitten on a somewhat regular basis clicking on an email
address in a header or a URL when I only meant to place point there).


        Stefan "I don't do that for each and every option, mind you"

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

[Drew Adams]

> > Honestly, how many of you (not new users) keep the default value of
> > `mouse-1-click-follows-link'?
>
> I do keep it as default, because I want to suffer like the most
> naive user, to make sure that it's a bearable suffering (and yes,
> I find it bearable, although I do get bitten on a somewhat
> regular basis clicking on an email address in a header or a URL
> when I only meant to place point there).
>
>         Stefan "I don't do that for each and every option, mind you"

"Bearable" and getting "bitten on a somewhat regular basis" hardly
constitute a ringing endorsement. I wouldn't buy an insect repellent based
on that testimonial. ;-)

We should reward your spirit, anyway. Chapeau! Please accept this honorific
hair shirt for going above and beyond. As another reward, take a 3-month
vacation from `mouse-1' following links. You deserve it, and you'll feel
much better.

RE: generate 1) virtual index

[Drew Adams]

> Below is a simple patch that implements this:

Good. [I typed "forward" as the input regexp.]

I realize this was a first try, and here is some feedback. Compared to a
normal Index page such as Concept Index, I see these formatting differences
(drawbacks):

1. It says `File: apropos' instead of `File: emacs' (for the Emacs manual).
`File:' should point to the manual being indexed.

2. `Node: Index' is not quite correct. It would be better to use `Node:
Index for `forward'', where `forward' is the regexp input by the user, which
defines this particular virtual index. [BTW, `Node' for `L' says `Top',
which is not correct either (it should be something like `History').]
Together, `File:' and `Node:' would then uniquely identify a virtual index
(node).

3. The `Up:' link is `(dir)'. It should be `Top', to send you to the top of
the manual that is being indexed.

4. The description "Nodes whose indices contain `forward':" should come
before, not after, `* Menu:'.

5. That description should say "Index entries that match `forward':". (a) It
is the index entries that match, not the whole indexes. (b) It is the index
entries that are listed (the nodes are also listed, but the index entries
are primary). (c) It is regexp matching that is used, not necessarily
substring containment, IIUC.

Actually, I think you could dispense with the description line altogether,
if the `Node:' name is descriptive, as suggested in #2: `Node: Index for
`forward''.

6. Each menu item should be formatted as in a normal index: (a) no file name
written next to either the index entry or the node name, (b) alignment using
tabs, not a space. IOW, use this:

 * search-forward:		Nonincremental Search.

not this, which is what I see:

 * search-forward [c:/Emacs-22.1/info/emacs]:
(c:/Emacs-22.1/info/emacs)Nonincremental Search.


#3 and #6 make me think that you are perhaps intending this for use across
multiple books. Is that right?

Such a feature might be useful, but if it exists it should have a different
command name and a different binding. When used within a manual, `I' should
produce a virtual index for only that manual. In this case, I hit `I' in the
Emacs manual, so only the Emacs manual should be used for this virtual
index.

But if `I' is hit in `(dir)', then you could fall back to the multi-book
command, which would ask which books to use. If multiple manuals are used,
then you could include the Info file indication in the menu items, but it
should be listed only once, next to the node name, not the index entry, and
it should use the standard Info file format, e.g. `(emacs)', not an absolute
file name.

Question: Once such a virtual node has been created, couldn't it be
referenced in the history? `l' and `r' do access it properly, but it does
not seem to get registered with `L'. It's important that `L' be able to
access all visited nodes, including such virtual nodes.

HTH, and thanks; this is useful.

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

[Richard Stallman]

    "Bearable" and getting "bitten on a somewhat regular basis" hardly
    constitute a ringing endorsement. I wouldn't buy an insect repellent based
    on that testimonial. ;-)

This feature was set up as it is to provide compatibility with many
other graphical interfaces.  We expected this to be good for
beginners.  If helps beginners start using Emacs, it is worth keeping.
Experienced people can customize it.

Whether it really achieves that goal, I don't know.  It would be nice
to get some real data about that, but that is not a trivial task.

info.el patch to open node in new window [was: generate 3) S-mouse-2: follow link in new window]

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

> > > (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).

I was wrong. I had forgotten that I had (trivially) redefined
`Info-mouse-follow-nearest-node' to accept the optional FORK arg and pass it
to `Info-try-follow-nearest-node'. The reason my code was no longer working
was that I had made another, conflicting mouse binding elsewhere - my bad.

It works fine now. Attached are patches for info.el and etc/NEWS to add
these two commands:

* Info-follow-nearest-node-other-window
* Info-mouse-follow-nearest-node-other-window

It binds the former to `S-RET' and the latter to `S-down-mouse-2'.

Change log entry:

* info.el (Info-follow-nearest-node)
  (Info-mouse-follow-nearest-node): New commands,
  bound to S-RET, S-down-mouse-2.





[-- Attachment #2: info-2007-09-25.patch --]
[-- Type: application/octet-stream, Size: 3337 bytes --]

*** info-CVS-2007-09-25.el	Tue Sep 25 16:07:54 2007
--- info-patched-2007-09-25.el	Tue Sep 25 16:14:40 2007
***************
*** 3079,3094 ****
  		(t
  		 (error "No %s around position %d" errorstring pos))))))))
  
! (defun Info-mouse-follow-nearest-node (click)
    "\\<Info-mode-map>Follow a node reference near point.
! Like \\[Info-menu], \\[Info-follow-reference], \\[Info-next], \\[Info-prev] or \\[Info-up] command, depending on where you click.
! At end of the node's text, moves to the next node, or up if none."
!   (interactive "e")
    (mouse-set-point click)
!   (and (not (Info-try-follow-nearest-node))
         (save-excursion (forward-line 1) (eobp))
         (Info-next-preorder)))
  
  (defun Info-follow-nearest-node (&optional fork)
    "Follow a node reference near point.
  If point is on a reference, follow that reference.  Otherwise,
--- 3079,3102 ----
  		(t
  		 (error "No %s around position %d" errorstring pos))))))))
  
! (defun Info-mouse-follow-nearest-node (click &optional fork)
    "\\<Info-mode-map>Follow a node reference near point.
! Like \\[Info-menu], \\[Info-follow-reference], \\[Info-next], \\[Info-prev] or \\[Info-up] \
! command, depending on where you click.
! At end of the node's text, moves to the next node, or up if none.
! 
! With a prefix argument, open the node in a separate window."
!   (interactive "e\nP")
    (mouse-set-point click)
!   (and (not (Info-try-follow-nearest-node fork))
         (save-excursion (forward-line 1) (eobp))
         (Info-next-preorder)))
  
+ (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))
+ 
  (defun Info-follow-nearest-node (&optional fork)
    "Follow a node reference near point.
  If point is on a reference, follow that reference.  Otherwise,
***************
*** 3111,3116 ****
--- 3119,3129 ----
  	    t)))
        (error "Point neither on reference nor in menu item description")))
  
+ (defun Info-follow-nearest-node-new-window ()
+   "Open the link near the text cursor in a new window."
+   (interactive)
+   (Info-follow-nearest-node t))
+ 
  ;; Common subroutine.
  (defun Info-try-follow-nearest-node (&optional fork)
    "Follow a node reference near point.  Return non-nil if successful.
***************
*** 3151,3156 ****
--- 3164,3170 ----
    (define-key Info-mode-map "." 'beginning-of-buffer)
    (define-key Info-mode-map " " 'Info-scroll-up)
    (define-key Info-mode-map "\C-m" 'Info-follow-nearest-node)
+   (define-key Info-mode-map [S-return] 'Info-follow-nearest-node-new-window)
    (define-key Info-mode-map "\t" 'Info-next-reference)
    (define-key Info-mode-map "\e\t" 'Info-prev-reference)
    (define-key Info-mode-map [(shift tab)] 'Info-prev-reference)
***************
*** 3200,3205 ****
--- 3214,3220 ----
    (define-key Info-mode-map "," 'Info-index-next)
    (define-key Info-mode-map "\177" 'Info-scroll-down)
    (define-key Info-mode-map [mouse-2] 'Info-mouse-follow-nearest-node)
+   (define-key Info-mode-map [S-down-mouse-2]  'Info-mouse-follow-nearest-node-new-window)
    (define-key Info-mode-map [follow-link] 'mouse-face)
    )
  

Diff finished.  Tue Sep 25 16:17:34 2007

[-- Attachment #3: NEWS-23-2007-09-25.patch --]
[-- Type: application/octet-stream, Size: 624 bytes --]

*** NEWS-23-2007-09-25.txt	Tue Sep 25 16:30:12 2007
--- NEWS-23-2007-09-25-patched.txt	Tue Sep 25 16:35:12 2007
***************
*** 97,102 ****
--- 97,107 ----
  ** The new command `display-time-world' starts an updating time display
  using several time zones, in a buffer.
  
+ ** Info mode has new commands
+ Info-follow-nearest-node-other-window and
+ Info-mouse-follow-nearest-node-other-window, bound to S-RET and
+ S-down-mouse-2, respectively.
+ \f
  * Startup Changes in Emacs 23.1
  
  ** New user option `initial-buffer-choice' specifies what to display

Diff finished.  Tue Sep 25 16:35:43 2007

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: info.el patch to open node in new window [was: generate 3) S-mouse-2: follow link in new window]

[Juri Linkov]

> I was wrong. I had forgotten that I had (trivially) redefined
> `Info-mouse-follow-nearest-node' to accept the optional FORK arg and pass it
> to `Info-try-follow-nearest-node'. The reason my code was no longer working
> was that I had made another, conflicting mouse binding elsewhere - my bad.
>
> It works fine now. Attached are patches for info.el and etc/NEWS to add
> these two commands:
>
> * Info-follow-nearest-node-other-window
> * Info-mouse-follow-nearest-node-other-window

I think we should remove the FORK argument, clone Info buffer in
`Info-follow-nearest-node-new-window' and call `Info-follow-nearest-node'
without arguments.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: info.el patch to open node in new window [was: generate 3) S-mouse-2: follow link in new window]

[Drew Adams]

> I think we should remove the FORK argument, clone Info buffer in
> `Info-follow-nearest-node-new-window' and call `Info-follow-nearest-node'
> without arguments.

Why?

I'm not tied to a particular implementation, but I don't see what the
problem is with this implementation. You've said 3 times now that FORK must
go, but you haven't yet given any reason, AFAICT.

I suggested these commands and bindings long ago. Please add them, however
you want to implement them.

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

[Drew Adams]

>     "Bearable" and getting "bitten on a somewhat regular basis" hardly
>     constitute a ringing endorsement. I wouldn't buy an insect
>     repellent based on that testimonial. ;-)
>
> This feature was set up as it is to provide compatibility with many
> other graphical interfaces.  We expected this to be good for
> beginners.  If helps beginners start using Emacs, it is worth keeping.
> Experienced people can customize it.
>
> Whether it really achieves that goal, I don't know.  It would be nice
> to get some real data about that, but that is not a trivial task.

Here's a thought -

Have `ask' be the default value of `mouse-1-click-follows-link', and have a
behavior similar to that of `disable-command':

If the value is `ask', then the first time (only) that a user clicks a link
with `mouse-1', s?he is asked this:

 "You have clicked a link using `mouse-1'. In Emacs, clicking
 `mouse-2' follows links, and `mouse-1' has other uses.
 Do you also want clicking `mouse-1' to follow links?"

If the answer is "yes", then the value is changed to 450 (the current
default value). Otherwise, it is changed to nil. The new value is saved
(Customize). A message echoes the new value and the option name, for future
reference.

This behavior has these advantages:

* It tells the user which button `mouse-1' is ("You have clicked...").

* It makes the user aware of what the choices are and what the variable is
that governs them.

* It requires an explicit user choice. It does so at the right time: first
link click.

* It states that `mouse-2' is standard for following links and it will
continue to follow links in any case. It does not explicitly refer to any
disadvantages for `mouse-1' following links, but `mouse-2' as the "standard"
might lead some new users to give it a try. Many new users are open to
learning the Emacs way.

* It has zero impact on anyone who has already customized the option. It has
negligeable impact on anyone who has not - a user need answer the question
at most once.

WDOT?

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> Here's a thought -
>
> Have `ask' be the default value of `mouse-1-click-follows-link', and have a
> behavior similar to that of `disable-command':
>
> If the value is `ask', then the first time (only) that a user clicks a link
> with `mouse-1', s?he is asked this:
>
>  "You have clicked a link using `mouse-1'. In Emacs, clicking
>  `mouse-2' follows links, and `mouse-1' has other uses.
>  Do you also want clicking `mouse-1' to follow links?"
>
> If the answer is "yes", then the value is changed to 450 (the current
> default value). Otherwise, it is changed to nil. The new value is saved
> (Customize). A message echoes the new value and the option name, for future
> reference.
>
> This behavior has these advantages:
>
> * It tells the user which button `mouse-1' is ("You have clicked...").
>
> * It makes the user aware of what the choices are and what the variable is
> that governs them.
>
> * It requires an explicit user choice. It does so at the right time: first
> link click.
>
> * It states that `mouse-2' is standard for following links and it will
> continue to follow links in any case. It does not explicitly refer to any
> disadvantages for `mouse-1' following links, but `mouse-2' as the "standard"
> might lead some new users to give it a try. Many new users are open to
> learning the Emacs way.
>
> * It has zero impact on anyone who has already customized the option. It has
> negligeable impact on anyone who has not - a user need answer the question
> at most once.
>
> WDOT?

Very bad idea.  Emacs should be usable out of the box.  People should
not be _forced_ to customize anything to make it so.  It is a
particularly bad mistake to force a _beginner_ to make a decision
about his future working habits and then casting this decision in
stone (it will be much harder to figure out how to change it then it
was to set it).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan Monnier]

> WDOT?

Doesn't sound bad.  Except for the -Q use where being asked every time would
be annnoying.  I.e. only ask the question if the result *can* be saved for
future use.


        Stefan

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

[Drew Adams]

> Doesn't sound bad.  Except for the -Q use where being asked every
> time would
> be annnoying.  I.e. only ask the question if the result *can* be saved for
> future use.

Good point.

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

[Drew Adams]

> If the value is `ask', then the first time (only) that a user
> clicks a link with `mouse-1', s?he is asked this:

It occurred to me that I should have drawn attention to the "with `mouse-1'
here. A user who never clicks a link with `mouse-1' is never asked the
question.

Only a user who naively expects `mouse-1' to follow a link will be informed
that standard Emacs behavior is to use `mouse-2' and asked to confirm that
s?he wants `mouse-1' to also follow links.

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

[Richard Stallman]

    Have `ask' be the default value of `mouse-1-click-follows-link', and have a
    behavior similar to that of `disable-command':

I can't believe beginners would prefer that.

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

[Drew Adams]

>     Have `ask' be the default value of
>    `mouse-1-click-follows-link', and have a
>     behavior similar to that of `disable-command':
>
> I can't believe beginners would prefer that.

Why not? If you have never used an application, and you just do what you are
used to doing, but there is a better, alternative behavior that is in fact
the standard behavior in that application, wouldn't you want to know about
it?

These are the alternatives:

1. Have both m-1 and m-2 follow links, by default.

A newbie who tries m-1 doesn't learn about m-2. S?he later encounters some
difficulties because of the m-1 peculiarities. M-1 is not quite what s?he
expected, and s?he will not have been told about those differences. S?he
doesn't know about m-2 and s?he doesn't really understand this special m-1
either.

2. Have only m-2 follow links, by default.

The newbie discovers that m-1 doesn't follow links, but s?he doesn't learn
that m-2 follows links or that s?he can configure m-1 to also follow links.

3. Do what I suggested.

The first time (only) the newbie tries m-1 on a link, s?he is informed about
both m-2 and the possibility of having m-1 also follow links.

#1 is Emacs 22.  #2 is more or less pre-22.  #3 should be Emacs 23.  Let the
user know more to control more.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>>     Have `ask' be the default value of
>>    `mouse-1-click-follows-link', and have a
>>     behavior similar to that of `disable-command':
>>
>> I can't believe beginners would prefer that.
>
> Why not?

Because Emacs is configured right from the start not to work, but
rather force the user to configure things and make permanent decisions
before he even has a chance to get acquainted with Emacs and form an
opinion.

It also means that if some sysadmin calls Emacs on another user's
account, he only has the choice to avoid using mouse-1, or to
permanently reconfigure the user's Emacs, taking his choice from him
in future.

It is not like I haven't explained this already once.  Do you ignore
negative input on purpose?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Juri Linkov]

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

Can we adopt this to Info?  mouse-3 is bound to mouse-save-then-kill,
but in most other programs the equivalent function is bound to S-mouse-1
which in Emacs is bound to mouse-set-font which is useless on the mouse
button because it is not context-dependent and affects the whole frame,
not the position pointed by the mouse.  It's better to add the font menu
to the main frame menu.

This suggestion is of course not for changing the default key bindings,
but for compatibility key bindings defined by packages like cua.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

> 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. 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 now understood that you mean something different than I thought.
It seems you want something like the "target" HTML link attribute,
where clicking on different links in the index visits each link
in the same separate window from the index window.  If it is what
you meant, I'm unsure how feasible it is.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: info.el patch to open node in new window

[Juri Linkov]

> I'm not tied to a particular implementation, but I don't see what the
> problem is with this implementation. You've said 3 times now that FORK must
> go, but you haven't yet given any reason, AFAICT.
>
> I suggested these commands and bindings long ago. Please add them, however
> you want to implement them.

Ok, the FORK argument of existing Info commands can't be removed for
compatibility reasons.  I also think that adding the FORK argument
to all Info navigation commands like `u' (Info-up), `t' (Info-top-node),
`d' (Info-directory), etc makes no sense because they might make a better use
of the prefix argument and it's just easy to type `M-n u', `M-n d' etc.

However, I agree that `Info-follow-nearest-node' and `Info-mouse-follow-nearest-node'
are exceptions since they are general commands to follow a "link" (i.e.
an Info reference or an Info menu/index item) and most browsers have a key
to open a link in another window, so user will except Emacs to do the same.
I think Info-mouse-follow-nearest-node should be the last command where
we add the FORK argument.

I noticed that in your patch the new command names have the `-new-window'
suffix.  I think `-other-window' is a better suffix.  Also perhaps
it should be bound to [S-mouse-2] instead of [S-down-mouse-2].

-- 
Juri Linkov
http://www.jurta.org/emacs/

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. 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 now understood that you mean something different than I thought.
> It seems you want something like the "target" HTML link attribute,
> where clicking on different links in the index visits each link
> in the same separate window from the index window.  If it is what
> you meant, I'm unsure how feasible it is.

Now maybe I'm misunderstanding ;-). What you describe sounds like what I
mean. But it is also exactly what I sent in the patch. That's what
`Info-mouse-follow-nearest-node' does: it follows the link it's clicked on
in a new window. Maybe I don't understand you - how is what you now think I
mean different from `Info-mouse-follow-nearest-node'?

RE: info.el patch to open node in new window

[Drew Adams]

> > I'm not tied to a particular implementation, but I don't see what the
> > problem is with this implementation. You've said 3 times now
> > that FORK must go, but you haven't yet given any reason, AFAICT.
> >
> > I suggested these commands and bindings long ago. Please add
> > them, however you want to implement them.
>
> Ok, the FORK argument of existing Info commands can't be removed for
> compatibility reasons.  I also think that adding the FORK argument
> to all Info navigation commands like `u' (Info-up), `t' (Info-top-node),
> `d' (Info-directory), etc makes no sense because they might make
> a better use
> of the prefix argument and it's just easy to type `M-n u', `M-n d' etc.
>
> However, I agree that `Info-follow-nearest-node' and
> `Info-mouse-follow-nearest-node'
> are exceptions since they are general commands to follow a "link" (i.e.
> an Info reference or an Info menu/index item) and most browsers have a key
> to open a link in another window, so user will except Emacs to do
> the same.
> I think Info-mouse-follow-nearest-node should be the last command where
> we add the FORK argument.
>
> I noticed that in your patch the new command names have the `-new-window'
> suffix.  I think `-other-window' is a better suffix.  Also perhaps
> it should be bound to [S-mouse-2] instead of [S-down-mouse-2].

It sounds like the two of us, at least, generally agree about this.

`-other-window': I guess you're thinking that is consistent with some other
command names. This is a bit different in that in all cases it creates a new
window. I don't have a strong opinion about the name, in any case.

S-down-mouse-2: I use that because I generally have S-down-mouse-2 bound to
something else that tracks mouse movement: `mouse-scan-lines-or-M-:'. Using
the same binding here overrides cleanly and prevents interference. A
tracking function needs to be bound to a down event (the up event removes
the highlighting).

I sent a patch to include `mouse-scan-lines-or-M-:' in Emacs on 2007-07-13,
Subject "mouse.el patch to flash yank position and highlight line". It
highlights the line under the pointer as long as the mouse button is
depressed; the highlighting tracks the pointer.

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

[Drew Adams]

> > 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.
>
> Can we adopt this to Info?  mouse-3 is bound to mouse-save-then-kill,
> but in most other programs the equivalent function is bound to S-mouse-1
> which in Emacs is bound to mouse-set-font which is useless on the mouse
> button because it is not context-dependent and affects the whole frame,
> not the position pointed by the mouse.  It's better to add the font menu
> to the main frame menu.
>
> This suggestion is of course not for changing the default key bindings,
> but for compatibility key bindings defined by packages like cua.

I like Emacs's mouse-3 binding for selecting text - including in Info. I'd
prefer that we keep the context menu on C-mouse-3, in Info as in other
buffers where it is available. That fits better with Emacs, IMO. Emacs users
can learn soon enough where it is, and it's good that its location be
relatively consistent.

I like the idea of getting rid of the S-mouse-1 font-dialog binding. I use
S-mouse-1 clicks (in most buffers) to enlarge the frame font, and I use
`C-S-mouse-1' clicks to shrink the frame font. But that's just a personal
binding and I agree that, other things being equal, it's good to save mouse
bindings for things that can take advantage of the specific mouse location.

More discussion on this might help. I don't see why we shouldn't discuss
changing default bindings as well - S-mouse-1 in particular.

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

[Drew Adams]

> Because Emacs is configured right from the start not to work,

It sure is. That's why I proposed something that would make it work. ;-)

> but rather force the user to configure things
> and make permanent decisions
...
> permanently reconfigure the user's Emacs,
> taking his choice from him in future.
...
> casting this decision in stone   [from your preceding mail]

Permanent decisions? Permanently reconfigure? Nothing permanent about it.
Stop your scare tactics, please. By your same logic, such a "permanent
decision" is made now by you for the user - before s?he even starts up.

It is not my proposal that reduces user awareness, choices, and the ability
to control things - on the contrary. It will let users know: (1) that the
behavior can be changed and (2) which option to change. Currently, they
haven't got a clue.

> Do you ignore negative input on purpose?

I don't shy away from logical argument. Stefan, for instance, offered a
correction regarding the behavior with emacs -Q. Other arguments might
convince me that I'm completely wrong.

It's even happened that you, David, have presented an argument or two that
was convincing and made me change my mind. And I have not hesitated to show
my support when I agree with you on some issue. I don't particularly care
about you one way or the other, personally; it's the ideas that interest me,
yours or anyone else's. I do care about you, however, in that I sincerely
appreciate your service to Emacs and the Emacs community.

Although I don't avoid negative argument, I do try to ignore your
"permanently configured" knee-jerk slurs and vitriol. Alas, I don't always
succeed. I try not to take your nastiness personally; it is reassuring to
see you act similarly with others. ;-) Anyway, if I don't reply to your
negative input, it's likely that that is the reason - I perceive too much
heat, not enough light.

Technical arguments welcome. Save the bullying for the playground.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Because Emacs is configured right from the start not to work,
>
> It sure is. That's why I proposed something that would make it work. ;-)
>
>> but rather force the user to configure things
>> and make permanent decisions
> ...
>> permanently reconfigure the user's Emacs,
>> taking his choice from him in future.
> ...
>> casting this decision in stone   [from your preceding mail]
>
> Permanent decisions? Permanently reconfigure? Nothing permanent
> about it.  Stop your scare tactics, please. By your same logic, such
> a "permanent decision" is made now by you for the user - before s?he
> even starts up.

But it isn't the user that is forced to make a decision.  The decision
has been made by knowledgable people after long discussions, agreeing
on the most likely useful default.  We have long discussions here in
order to arrive at an Emacs useful out of the box for everyone.

In contrast, the amount of information regarding Emacs' standard
interfaces and conventions to a user is close to zero for a beginner.
A beginner does not _want_ to make semi-permanent decisions before
getting acquainted with the system.

> It is not my proposal that reduces user awareness, choices, and the
> ability to control things - on the contrary. It will let users know:
> (1) that the behavior can be changed and (2) which option to
> change. Currently, they haven't got a clue.
>
>> Do you ignore negative input on purpose?
>
> Although I don't avoid negative argument, I do try to ignore your
> "permanently configured" knee-jerk slurs and vitriol.

Sorry, but that's ridiculous.  Just because the effects are quite
negative for a beginner and I describe them as such, this does not
make my response a knee-jerk or vitriol.

> Anyway, if I don't reply to your negative input, it's likely that
> that is the reason - I perceive too much heat, not enough light.
>
> Technical arguments welcome. Save the bullying for the playground.

This is a technical argument.  And not addressing it does not
particularly improve the impression that you have thought this
through.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Drew Adams]

> >> but rather force the user to configure things
> >> and make permanent decisions
> > ...
> >> permanently reconfigure the user's Emacs,
> >> taking his choice from him in future.
> > ...
> >> casting this decision in stone   [from your preceding mail]
> >
> > Permanent decisions? Permanently reconfigure? Nothing permanent
> > about it.  Stop your scare tactics, please. By your same logic, such
> > a "permanent decision" is made now by you for the user - before s?he
> > even starts up.
>
> A beginner does not _want_ to make semi-permanent decisions before
> getting acquainted with the system.

From "permanent" to "semi-permanent" - that's progress. Soon maybe you will
recognize that there's nothing semi-, quasi-, or in even the slightest bit
permanent about it. It's simply a customizable setting, just as it is today.

Help the user be aware of that setting the first time s?he tries to use
mouse-1 for a link - that's the idea.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >> but rather force the user to configure things
>> >> and make permanent decisions
>> > ...
>> >> permanently reconfigure the user's Emacs,
>> >> taking his choice from him in future.
>> > ...
>> >> casting this decision in stone   [from your preceding mail]
>> >
>> > Permanent decisions? Permanently reconfigure? Nothing permanent
>> > about it.  Stop your scare tactics, please. By your same logic, such
>> > a "permanent decision" is made now by you for the user - before s?he
>> > even starts up.
>>
>> A beginner does not _want_ to make semi-permanent decisions before
>> getting acquainted with the system.
>
> From "permanent" to "semi-permanent" - that's progress. Soon maybe
> you will recognize that there's nothing semi-, quasi-, or in even
> the slightest bit permanent about it.

Oh yes, there is: the newbie has no clue how he can ever change this
setting again.  It will take quite a lot of learning to undo this
change, a change which he is forced to make.

> It's simply a customizable setting, just as it is today.

But the user is not forced to change the pristine default today.

> Help the user be aware of that setting the first time s?he tries to
> use mouse-1 for a link - that's the idea.

"be aware" is quite different from "be forced to make a decision about
it".  So you probably should try another way of realizing your idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

I have the feeling that this discussion has become a drain on the
attention of the people participating in it (which does not include
me), and I tend to think it won't lead to accomplishing anything.