Re: Info-mode patch

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>>> 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?
>
> You can't add repeat symbols on existing Info commands used in Info buffers,
> only wrapper commands with a prefix key should be repeatable.

I am not sure what that means, but I have tried repeat mode now with
my patch and it works out of the box. Both from an info buffer, and from other
buffer. It is kind-a cool, was not familiar with repeat mode before.

Can I get *some* help? When rewriting Info-mode-map definition, so I can use
:repeat keword to skip typing bunch of "put" statements, I couldn't add tool-bar
shortcuts in the map definitions. How do I use those with kbd syntax?

(defvar-keymap Info-mode-map 
  ( ... )
  ;;"<tool-bar> <C-Back in history>"    'Info-history-back-menu
  ;;"<tool-bar> <C-Forward in history>" 'Info-history-forward-menu
  )

(define-key Info-mode-map [tool-bar C-Back\ in\ history]    
'Info-history-back-menu)
(define-key Info-mode-map [tool-bar C-Forward\ in\ history] 
'Info-history-forward-menu)
(put 'Info-beginning-of-buffer :advertised-binding "b")

I would like to not have to use those two define-key statements after the
definition. 

>>>> 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".
>
> You decide what does it mean.  It can be anything that you want.  For
> example, next-window or the most recently used window, it's up to you ;)

:). Ok, so we are getting another "pluggable framework"? "Up to you" s still not
an answer. What will it do out of the box, what is do YOU mean with "nearest",
what will be the default? 

That is an honest consideration. Isn't it better to first *solve* the problem 
and
get understanding of the issues before engineering yet another framework?

>From your response throught this conservaton and I understand that you have not
done the research and don't have understanding of the problems involved. I think
it is a be arrogant and disrespectfull to someone who has put work and testing
like I did to just dismiss it without even trying the solution, but anyway I
have helped you to understand the problems involved. A part of those prombs help
you with those issues was a question you have left unanswered:

> Is there some way to tell interactive  where all propts will be placed, 
> without
> parsing interactive form and checking strings for interactive codes or 
> something
> similar awkward? 

That was an real question, not a trolling, how do you solve that? Is there some
piece in Emacs that can tell in which minibuffer all prompts should appear,
without wrapping prompts into with-selected-frame or something similar? I would
like to know myself.

If there would be an option in Emacs to either let-bind minibuffer for
prompt which with-selected-frame/window & co would ignore, or some option or
whatever. Otherwise, wrapper approach can not deal with this, at least not
what I know, but perhaps you know?

You can if you do a parser for interactive form but I consider that an overkill.