emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Control help- and Info-mode buffers from other buffers


From: Eli Zaretskii
Subject: Re: Control help- and Info-mode buffers from other buffers
Date: Thu, 01 Jun 2023 19:19:47 +0300

> From: Arthur Miller <arthur.miller@live.com>
> Cc: juri@linkov.net,  manuel@ledu-giraud.fr,  emacs-devel@gnu.org
> Date: Thu, 01 Jun 2023 15:45:53 +0200
> 
> If I try to illustrate with an example: consider a two-window setup with 
> scratch
> buffer in first and info buffer in second window. If presses a key to execute
> next command in other window and then 'm'the system will choose commands from
> selected window (self-insert command in scratch buffer) and try to execute 
> that
> command in other window which is info buffer. Tbat is obviously wrong since 
> user
> probably meant to execute Info-menu, by default bound to 'm' in Info-mode.
> 
> I don't know if that can be fixed by perhaps manipulating unrread-key-events
> list or in some other way, perhaps by putting input key back, or by some other
> means. I haven't managed to get it correctly and have given up and instead tre
> to address the problem in more fundamental way by making those functions aware
> of the context they execute in. Also, even if problems could be fixed, I see 
> no
> point of using such method in this particular patch.

I don't understand why you see such complexity.  All we need is a
command that will do

  (with-selected-window (get-buffer-window "*info*")
    BODY...

and then we need to bind it to, say, "C-x 4 h m".  Did I miss
something important?

> But for the suggested patch for help and info, I see no reason to use pre/post
> hook to switch windows, I can just use with-selected-window which does 
> exactly the same switching for me in 90% of cases, and manually fix the few
> cases which needed some extra care.

I didn't say anything about any hooks.

> For example what happends if a command call
> another command and it happen to have post hooks? Will it run after the second
> command call internally (I think it will), which means it will switch back to
> old window prematurely. 

Any post-command-hook should be prepared to deal with commands that
switch buffers and windows, so I see no new problems here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]