[Top][All Lists]

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

Re: Rename `mini-' options

From: Eli Zaretskii
Subject: Re: Rename `mini-' options
Date: Sat, 16 May 2009 13:04:54 +0300

> From: "Drew Adams" <address@hidden>
> Date: Fri, 15 May 2009 21:20:54 -0700
> Cc: address@hidden, 'Deniz Dogan' <address@hidden>

Let me say up front that I don't object to have variables whose names
include ``minibuffer'' rather than ``mini'', if that makes someone
happy.  We could add aliases to the currently-named variables, which
should be harmless even at this late stage of the pretest.  We could
also add index entries in the manuals, which is even less harmful,
just to ease searching for them.

But that issue aside, I would like to everybody be on the right page
regarding whether echo are is or isn't a window.

> > You said:
> >
> > > The minibuffer and the echo area share the same screen real
> > > estate. But it's not a window - "window" means something 
> > > specific in Emacs.
> Yes, I did. The echo area is not an Emacs window. See if `select-window' and
> such can handle it. See if the doc ever refers to it as a window. No and no.

You are wrong.  Maybe the documentation is misleading or inaccurate,
but the echo area is indeed just a special use of the minibuffer
window.  This fact is clearly visible from the C code that is the
infrastructure for displaying text in the echo area.  The following
snippet is from xdisp.c:echo_area_display:

  struct frame *sf = SELECTED_FRAME ();

  mini_window = FRAME_MINIBUF_WINDOW (sf);
  w = XWINDOW (mini_window);


      echo_area_window = mini_window;
      window_height_changed_p = display_echo_area (w);
      w->must_be_updated_p = 1;

In plain English, this does the following:

  . finds the currently selected frame
  . then gets the minibuffer window used by that frame
  . and finally, uses that window to display the echo area contents

(For people who are not fluent in reading Emacs C sources: mini_window
and w are two ways of specifying the same window: the former is a Lisp
object that refers to the minibuffer window, the latter is a pointer
to a C data structure which specifies that same window.  The macro
XWINDOW takes a Lisp object for a window and returns a C pointer for
that window.)

So, not only is the echo area using the minibuffer window on the
selected frame, there's also a Lisp object, called echo_area_window,
which specifies that window as long as it is in use.  Which means
that, if the need arises, we could have a Lisp-level binding for that
object, and then Lisp programs could use it in many ways like any
other window.

It is true that this window is special in many ways, which could
explain why the documentation is so vague about it.  But please don't
claim with such certainty that it's not a window, because that's
simply false.

reply via email to

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