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.
>
> But it's needed only for Info-other-window commands,
> not for Info-same-window commands.

Yes, I agree, and I don't need I need repeat mode for too many commands from
other window either; but since I have rebuilt the info mode itself, I have
"only" Info-mode-map, there are no "same-window/other-window" commands, and it
worked just fine with putting repeat mode on all, but that was expected. For the
record, I was able to port Info from version current master back to version 25
today. Only bad deal was a mailformad Info-spec, but everything seems to work 
well
when I test.

>> 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)
>>
>> I would like to not have to use those two define-key statements after the
>> definition.
>
> It seems you found a bug in 'key-valid-p'!
> And indeed it returns nil:
>
>   (key-valid-p "<tool-bar> <C-Back in history>")
>
> Whereas
>
>   (kbd "<tool-bar> <C-Back in history>")
>
> correctly returns [tool-bar C-Back\ in\ history].
>
> This is a clear bug in emacs-29.

Ok. Thanks, good to know. Then I'll keep those two outside of keymap definition.

>> 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?
>
> Yes, there is such way by using the variable 
> 'minibuffer-follows-selected-frame'.

So at least in theory, by let-bidinging it to nil, it should keep prompt
on the original frame. I did just quick naive test, and ended up in debugger:

(defun info-menu-wrapper ()
  (interactive)
  (let ((minibuffer-follows-selected-frame nil))
    (with-selected-window (info-window)
      (call-interactively #'Info-menu))))

but perhaps there are more tweacks to it which I am not familiar with, so I'll
leave it at that.

About wrapping; I agree that it is messy to go through each and every command as
I did to modify them, so for old existing commands, it is definitely easier to
do the wrapping, if possible. I just hope we get a better way for future command
writing. 

Thanks for the answer