emacs-devel
[Top][All Lists]
Advanced

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

Re: About the 'minibuffer' frame parameter


From: martin rudalics
Subject: Re: About the 'minibuffer' frame parameter
Date: Sat, 06 Aug 2016 11:33:55 +0200

> We could simply change the above code to follow suit.

Change what?  Initially I only wanted to simplify code like

(FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f))

because once f has been created, FRAME_HAS_MINIBUF_P (f) and
!FRAME_MINIBUF_ONLY_P (f) invariantly hold for the entire lifetime of f.
A bit field telling whether a frame owns a minibuffer or is
minibuffer-only/-less seems more practical instead of these macros.  The
value stored in that bit field would have to reflect the value stored in
the 'minibuffer' frame parameter.  But for a minibuffer-less frame we
OT1H store the minibuffer window in that parameter and OTOH we report
the value nil for that parameter in ‘frame-parameters’.

We could either modify that code in store_frame_param

  if (EQ (prop, Qminibuffer) && WINDOWP (val))
    {
      if (! MINI_WINDOW_P (XWINDOW (val)))
        error ("Surrogate minibuffer windows must be minibuffer windows");

      if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f))
          && !EQ (val, f->minibuffer_window))
        error ("Can't change the surrogate minibuffer of a frame with its own 
minibuffer");

      /* Install the chosen minibuffer window, with proper buffer.  */
      fset_minibuffer_window (f, val);
    }

to store Qnil instead of the minibuffer window or do away with the
special treatment of the 'minibuffer' parameter in ‘frame-parameters’ as
I mentioned earlier.

The former should be sane because so far C-code always goes for the
value of FRAME_MINIBUF_WINDOW to find the minibuffer window of a frame.
However, we'd still have to explain that ‘set-frame-parameter’ can
change a frame's minibuffer window without reflecting the change in the
return value of ‘frame-parameters’.

As mentioned before, removing the special treatment of the 'minibuffer'
parameter in ‘frame-parameters’ would imply that Elisp code relying on
the values we report currently might be broken in the future.  The doc
change required for this solution would be marginal.

Things would be much clearer if we had provided some orthogonality of
‘minibuffer-window’ and ‘set-minibuffer-window’.

martin




reply via email to

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