Re: Info-mode patch

[Arthur Miller <arthur.miller@live.com>]

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

Juri Linkov <juri@linkov.net> writes:

> I have read all your mails and whole patch carefully (but can't test it
> because your patch does not apply to master/emacs-29).  Now it's difficult
> to read this mail because quotes are no more highlighted in Gnus.
> I don't know if this is because you mail is too long, or there is
> some bug in Gnus, but this is a minor problem.

I also use Gnus, and it works fine for me, but the mail did got very long. I
have removed old parts in the response, and just left those of your last
question/comments on which I have answered. I have put this one on top, it was
somewhere in the middle; the rest is as they come in your last response.

>> Yes with-selected-frame does switch focus to a freame; I have also used it in
>> the patch, for the same purpose to switch focus back to user frame.
>
> Well, it works for you.  I don't know why it's not supported for any WM.

I believe there is a missunderstanding here. I didn't meant that
with-selected-frame is not supported; it is, I used it myself.

I mean if you switch to an info window in your wrapper, then the focus will be
on that frame by the time original command executes. Now if I have focus follow
mouse, or mouse autoselct, or something, then if the mouse cursor is in the old
frame, then the minibuffer will popup in info frame, but system will switch
focus on old frame where mouse cursor is, so I can't type in the minibuffer in
info frame. I don't know if that clears confusion :).

I have actually wrapped the prompt in interactive form(s) into
with-selected-frame in some place to correct for that bahvour, so it switches
minbibuffer to the old frame. Hopefully it is not too confusing. I think you
will have that problem with the wrapper approach. 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?

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

> I have read all your mails and whole patch carefully (but can't test it
> because your patch does not apply to master/emacs-29).

Hmm ?

When I sent the first patch, it built without any warnings or errors in current
master. Then when I built earlier today after fixing that plist hack, window.el
got stuck in loadup.el when building dump file, because of cl-lib. So I reworked
it without cl-lib. That is the one I sent last, with the help commands too, it
should build without errors, I am typing from Emacs with that patch. I have
attached patched files if you want to just eval them and test. I am not sure if
I pulled from the git today. 

>> The minibuffer does use nothing. If it is enough with just switching to the
>> buffer or you need to switch to the window depends on the work in interactive form.
>>
>> Obviously some functions need access to the content of info-buffer. For example
>> Info-menu need acces to the text of an info buffer to create a menu that will be
>> presented to the user. Obviously in that case it is enough to just switch to the
>> buffer, and since you are just using the buffer you don't need to switch to
>> other frame so input is left on the user frame. You can use with-selected-window
>> instead, if you take care of focus and input.
>
> Yes, this would be better instead of with-selected-frame.

Because with-selected-window will also make visible buffer current and select
frame as well. Notice also that you can have more than one window visible, so just
selecting the frame might not work correctly, while with-selected-window
probably will.

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

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 patch is massive because diff has shifted a lot of code; perhaps if I
>> stashed my functions on the end of info.el, the change would be less massive? :)
>
> Yes, probably a short section of autoloaded wrapper commands at the end of info.el
> would look nicer.

I thought it was about good work and improving things, not about looks and magic pedals.

>> I don't know, I understand your motiv, but I don't really think that is the best
>> way to do things, but seems like I am the only one :).
>
> This is just my opinion.

In my opinion, what you suggest is a good for old code and in case of few commands,
as a first aid. But you seem to want to use wrappers as some general tool in all
cases, which means lots of unnecessary duplication if that will be the only tool
offered.

I think if we just take care how to write commands in the future, no magic
pedals would be needed, so at least put a few words in the manual on things to
think about when writing commands, and possibly create a macro that abstracts
those parts that make a command callable from other window. That would benefit
Emacs in longer run much better in my opinion. With other words, to wrapper
approach you suggest certainly has its place, but I wouldn't use it as a general
tool for the future commands, and I wouldn't throw away written and tested work,
just to replace it with the generated code.

>                           If people would think your patch is a good way
> to go, that would be fine with me.

My patch was not some general suggestion; I have just rewrote info and help modes
specifically, but I certainly don't think rewriting each and every command is "a
way to go". Interested that Eli said I was looking for some generic solution.

I do suggest automation in form of a codegen, a little macro helper, as said in
pevious discussion, some sort of define-command, similar to define-minor-mode,
but I didn't want to do it as part of this patch.

I am ok to help, and the patch was a suggestion; I have done it for myself
anyway. I would probably just skipped the frames part, since I don't use
multiple frames.

Anyway, attached is patched version of files if anyone is interested to try it, if
the prevously sent patch does not apply. If you find a bug let me know. 


[-- Attachment #2: window.el --]
[-- Type: application/emacs-lisp, Size: 468020 bytes --]

[-- Attachment #3: help-mode.el --]
[-- Type: application/emacs-lisp, Size: 44814 bytes --]

[-- Attachment #4: info.el --]
[-- Type: application/emacs-lisp, Size: 237477 bytes --]