Re: Info-mode patch

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>>> Please note that risk of prompting user more than once doesn't exist in case
>>> of using wrapper commands.  Only the wrapper command prompts the user.
>>> Then all other intermediate functions called recursively or via
>>> function call chain don't need to prompt the user again because
>>> they all work in the right window.
>>
>> Yes, that is expected since you are calling old command from a new function. 
>> A
>> new function is a clean slate, so yepp, I am aware of that and I was aware 
>> that
>> you want to pre-select window before calling the original command. So yes, 
>> that
>> is a positive thing with wrapper approach, you get that one for free. I just
>> clarified what commands needed the optional window and why, since you seemed 
>> to
>> think that I meant all commands need it.
>
> Another advantage of wrapper commands is that you can implement what
> Manuel asked you to do to make key sequences for another window repeatable.
> This is possible only when you have separate wrapper commands like
> Info-directory-other-window and a separate keymap with them like
> Info-other-window-map.

What exactly would not make my patch work with repeating commands?

>>> I see an extra map as an advantage because users will be able
>>> to put both help-other-window and info-other-window commands
>>> on the same prefix map.  Then e.g. 'M-i l' will go back either
>>> in the nearest Help or Info window.
>>
>> What does that mean? You are building some general
>> "go-back-in-help-or-info-mode" command that will work specifically for info 
>> and
>> help and switch based on window buffer, or what is your plan there?
>
> Yes, you can build combined commands, so users need to bind only 1 key.

I can also build entire Emacs if I want, that wasn't the question :). Of course
I can build new commands, if I wanted that I would release a 3rd patry package
and wouldn't want to alter the core info and help-mode files that get into
dumped image. I didn't want to have bunch of spaghetti stuff you are suggesting.

>> How will you deal with 's' which does two completely different things,
>> search and view source? Are you building some key dispatcher into your 
>> wrapper?
>> Under which name will users file the command in that collective map?
>
> You can implement 's' with something like this
>
>   (defun Info-search-or-help-view-source-other-window ()
>     (with-selected-window (help-or-info-window)
>       (if (derived-mode-p 'help-mode)
>         (help-view-source)
>       (Info-search)))
>
> But such convenience is optional, this is just an example to demonstrate
> flexibility of the wrapper commands approach.

That is not a convenience, this is classical inheritance entaglement you are
suggesting here. Any user who would want to bind a thrid mode would have to
write their own mode and re-wrap your stuff in his/her own wrapper.

Idea of combined method is actually not so bad, it is also a sort of automation,
but there is a better way to do it, with or without my patch.

>> I am not sure I understand you there. How am I supposed to go back in info
>> buffer, if help window is nearest, or how am I supposed to go back in some 
>> other
>> info buffer than the nearest one? What does "nearest" even mean?
>
> The nearness can be defined by the combined help-or-info-window
> that handles both modes.

"Can be defined" is not an answer on "what does it mean".