Re: How about making `set-minibuffer-window' obsolete?

[martin rudalics]

>> Rather `set-minibuffer-window' should take as argument a frame to set
>> the 'minibuffer-window' parameter of that frame.  This way it would
>> become the counterpart of `minibuffer-window' which takes as argument a
>> frame and returns that frame's minibuffer window.
>
> I'm okay with extending this function that way (assuming the
> additional parameter is made &optional).

Setting the minibuffer window of some frame is completely different from
fiddling with minibuf_window directly.  IMO none of the variables like
selected_frame, selected_window or minibuf_window must be set by Lisp
code.

>> The current semantics of `set-minibuffer-window' is of no practical use.
>
> Why not? how is it different from the C code doing the same?

The C code has to do it in a very controlled way, just like setting
selected_window or selected_frame.  Think of how redisplay struggles to
keep the window it selects for redisplay selected after Lisp code
interventions.

>> Lisp code should never deal with minibuf_window directly.
>
> This seems to contradict what you propose above, doesn't it?  Or what
> am I missing?

The function would set the frame's minibuffer window (aka
f->minibuffer_window) just like setting the 'minibuffer-window' frame
parameter does.  minibuf_window would remain unaffected.

>> However, every minibuffer interaction should be aware of the fact
>> that any frame's minibuffer window might change via
>> fset_minibuffer_window under its feet.
>
> Yes, using these facilities is not for the faint at heart.  But that
> doesn't mean it can never be useful, IMO.

It's already hard enough to handle setting a particular frame's
minibuffer window.  But handling setting minibuf_window from Elisp is
much harder.

martin