[Top][All Lists]

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

Re: New start up splash screen annoyance...

From: Davis Herring
Subject: Re: New start up splash screen annoyance...
Date: Mon, 24 Sep 2007 09:59:27 -0700 (PDT)
User-agent: SquirrelMail/1.4.8-6.el3.2lanl

>> After all, what is an Emacs frame but a tiled window manager?  We
>> should present it that way to the user.
>   Actually, Emacs windows are an obsolete concept that today brings us
> nothing but additional and unwanted complexity. There should be no
> windows. There should be only frames, and if you like the tiling effect,
> then Emacs should kindly ask the window manager to place and size its
> frames exactly where and how Emacs wants them to be placed and sized.

Creating new frames sometimes takes much longer than creating windows --
with a slow X connection, or when using a window manager like twm where
every frame created requires user interaction.  And Emacs makes good use
of its frames: `other-buffer' considers buffers recently but not currently
visible -- on the current frame.  And it makes no sense at all to support
rolling up or iconifying one of two side-by-side frames linked with
`follow-mode'; having just one frame prevents that.

Some window managers may treat unselected frames less favorably: rendering
them as partially transparent, or preventing a program from automatically
giving them focus (as we would then very often want to do with C-x 5 o, or
rather just C-x o).  Furthermore, reimplementing such things as C-x + to
use frames would be quite complicated, and we would have to have notions
of "frame subtrees" that were entirely invisible to the window manager and
yet critical to sane behavior.  (And what happens if the user moves or
resizes one out of 4 tile-frames, then asks Emacs to
rebalance/resize/delete some of those tiles?  Do we introduce M-x

Finally, of course, there are issues of widget explosion -- giving each
window/frame a toolbar, a menu bar, a title bar, and whatever other
decorations takes up a lot of screen real estate, and neither 20 "Emacs
..." buttons nor one "Emacs (20)" button in a panel or so is useful. 
(Imagine what the Dock on OS X would look like if you iconified them all!)
 Of course, it would be possible to suppress some or all of the
decorations, perhaps including the panel button, but how is a simple Lisp
program that currently calls `display-buffer' supposed to decide whether,
if it creates a new window/frame, that window/frame is supposed to get a
tool bar or not?  Do we introduce levels of toolbar-desire so the user can
say just how badly they want to have tool bars even if they might take up
lots of space for very little use (in, say, *Messages*)?

If you really don't like windows, there are plenty of people (I believe
Stefan is one, and perhaps the Aqaumacs people) who use `pop-up-frames'
and prefer one frame per buffer, and they'd probably be happy to discuss
how to best arrange an all-frames Emacs.  But it seems somewhat confused
to even talk about -removing- windows from Emacs.


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

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