Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

It builds now so let's get back to your initial request.

> 1/- "Madhu's bug".  Set pop-up-frames to 'graphic-only, do M-!, type
> g TAB, which opens *Completions* in a new frame.  Select something.  The
> *Completions* frame should be deleted, but isn't.
>
> This was a problem in window-deleteable-p (window.el), where if an
> active minibuffer is in a frame, that frame is regarded as not to be
> deleted.  The new minibuffer mechanisms move minibuffers to the new
> frame on a frame change, so this obviously(?) clashed.  I have amended
> window-deleteable-p to take account of
> minibuffer-follows-selected-frame and the new mechanisms.

I leave this to Madhu.  Here the minibuffer frame is not deleted but
gets iconified which is probably due to the default of
'auto-hide-function', something I'm not going to dispute here.

> 2/- From Martin: Start emacs -Q -l foo.el, where foo.el is:
>
> (setq default-frame-alist '((minibuffer . nil)))
>
> (defun foo ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert (format "%s" (selected-frame))))
>
> (global-set-key [(control meta +)] 'foo)
>
> (setq enable-recursive-minibuffers t)
>
> Do C-M-+, type something into the minibuffer, and either selected-frame
> announced *Minibuffer-1*, or there was an error about "Window not being
> in Frame".  Both of these problems are now fixed.

Confirmed.  At least I can't reproduce them any more.

>
> 3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers
> to t.   Do C-x C-f  C-x 5 o twice, then C-x C-f a third time.  It was
> possible to enter filenames for and visit files for the innermost two
> minibuffers, but not the outermost one.  This has (I believe) been
> fixed.

I'm not sure what's missing here, probably a C-x 5 2 to get the frame
C-x 5 o can act upon.  So I let Gregory tell whether this has been
fixed.  What I see is that with 'enable-recursive-minibuffers' t C-x 5 2
followed by two C-x C-f C-x 5 o

- doesn't get me _always_ into the minibuffer window of the frame
  switched too (I'm not sure whether it should and under which
  circumstances - this should be clarified), and

- typing C-g to quit an inner invocation of C-x C-f sometimes gets me a
  catatonic minibuffer window where either nothing is displayed or just
  a simple "Quit" appears - I have to get out of it via C-x o.

> 4/- With minibuffer-follows-selected-frame nil, and
> enable-recursive-minibuffers t, there were problems caused by editing
> outer level minibuffers whilst an inner level buffer was still active.
> I've tried to fix this by giving outer level MBs the keymap
> minibuffer-inactive-mode-map temporariliy whilst a recursive MB is
> active.

How do I edit an outer level minibuffer whilst an inner level buffer is
active?

> One bug which I haven't fixed, and doesn't appear to be to do with these
> changes, is:
>
>
> 5/- emacs -Q, enter the following into *Scratch*:
>
> (defun bar ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert "window: %s ... frame: %s"

... which is probably missing a "format" here ...

>            (selected-window) (selected-frame)))
>
> , evaluate it, then evaluate (bar).  The window announced under "window:"
> is *Scratch*, that under "frame:" is *Minibuf-1*.  It seems they should
> match.
>
> I think the problem is that frame->name doesn't get appear to get set on
> a set-frame-selected-window call.  I think the command loop sets
> frame->name, and the recursive command loop in read_minibuf sets it to
> *Minibuf-1*, and nothing else changes it until the next iteration of the
> main command loop.
>
> Also, this bug was in the version of master just before I made my first
> commit in this area.

That's probably part of the select window/frame mystery.  You just can't
have them both - 'select-window' and 'select-frame' - and hope that they
will live happily ever after.  Maybe a

      wset_redisplay (XWINDOW (window));

after the

      fset_selected_window (XFRAME (frame), window);

is due so that the redisplay mechanism knows what title to draw in that
frame but I don't think we should care much.

martin