emacs-devel
[Top][All Lists]
Advanced

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

Re: Question about minibuffer and child frames (Posframe)


From: martin rudalics
Subject: Re: Question about minibuffer and child frames (Posframe)
Date: Fri, 4 Oct 2024 10:10:33 +0200
User-agent: Mozilla Thunderbird

>> I thought when the two windows are neighbors (which they often enough
>> are) we could flip them.
>
> Flip windows would work to swap when they are sibling windows, and
> neigbor windows can sometimes not be siblings.

Right.  I meant siblings (it was the typical two windows frame I had in
mind).

> I can't comment much cuz I'm not really familiar with these functions,
> but one thing that pops out is would maintaining a dead windows table
> take up lot of resources?

No.  It's already here via the variable 'window-dead-windows-table'.

> Also do you think a function like 'window-rebuild-tree' would be useful,
> and it accepts the a tree like the output of window-tree-pixel-sizes.
> rn this is possible by using the following arguments for
> window--transpose-1:
> (window--transpose-1 tree-you-want (below . left) t)
> However this is not really obvious.
>
> I think it could be useful to add a wrapper with more obvious name

You would have to tell me in more detail what 'window-rebuild-tree'
would do.  One thing 'window-tree-pixel-sizes' should then possibly do
is to include the identity of internal windows so 'window-rebuild-tree'
could resurrect them as well.

martin
> Well, make-terminal-frame has this:
>
>    /* On terminal frames the `minibuffer' frame parameter is always
>       virtually t.  Avoid that a different value in parms causes
>       complaints, see Bug#24758.  */
>    store_in_alist (&parms, Qminibuffer, Qt);
>
> So, no experiments with the minibuffer frame parameter possible.
>
> I think I have to implement the moral equivalent of x-create-frame's
> minibuffer handling first, at least for child frames. I don't think
> it makes sense for root frames. Will probably take me a bit, depending
> what "virtually t" encompasses.

You'll just have to fix that for child frames.  I'd do it both ways:

- Normal frames should be allowed to have their minibuffer on one of
  their child frames.

- Child frames should be allowed to have their minibuffer on another
  child frame with the same parent or on any of their ancestors.

You would, however, have to be careful when reparenting/deleting child
frames

- if the child frame uses its normal frame as the one hosting the
  minibuffer window (reparenting only)

- or if the normal frame uses the child frame as the one hosting the
  minibuffer window.

It's up to you whether you want to do it.  But if users should be given
the same look and feel on ttys as they have on GUIs, I see no other way.
If you have any doubts, please ask.

martin



reply via email to

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