all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: lekktu@gmail.com, deniz.a.m.dogan@gmail.com, emacs-devel@gnu.org
Subject: Re: Rename `mini-' options
Date: Sat, 16 May 2009 13:04:54 +0300	[thread overview]
Message-ID: <83fxf5qs6x.fsf@gnu.org> (raw)
In-Reply-To: <003101c9d5dd$b4a5e730$0200a8c0@us.oracle.com>

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 15 May 2009 21:20:54 -0700
> Cc: emacs-devel@gnu.org, 'Deniz Dogan' <deniz.a.m.dogan@gmail.com>

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	other threads:[~2009-05-16 10:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-16  1:47 Rename `mini-' options Davis Herring
2009-05-16  2:11 ` Drew Adams
2009-05-16  2:22   ` Juanma Barranquero
2009-05-16  2:32     ` Drew Adams
2009-05-16  3:09       ` Juanma Barranquero
2009-05-16  4:20         ` Drew Adams
2009-05-16 10:04           ` Eli Zaretskii [this message]
2009-05-16 19:20             ` Drew Adams
2009-05-16 19:47           ` Juanma Barranquero
2009-05-16  6:43         ` Stephen J. Turnbull
2009-05-16  7:13           ` Miles Bader
2009-05-16  8:24             ` Drew Adams
2009-05-16  9:21               ` Miles Bader
2009-05-16 19:21                 ` Drew Adams
2009-05-17  1:59                   ` Miles Bader
2009-05-16  9:18             ` Stephen J. Turnbull
2009-05-17  4:10             ` Stefan Monnier
     [not found] <AcnVoAMCDVZ2cc3/RpaKtCkusD8ZRg==>
2009-05-15 20:59 ` Drew Adams
2009-05-16  0:12   ` Deniz Dogan
2009-05-16  0:21     ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83fxf5qs6x.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=deniz.a.m.dogan@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.