RE: Neat features in Eclipse editor

[Drew Adams]

> Drew's OneOnOne efforts have pushed in the direction of 
> moving away from a collection of emacs managed windows
> within a single frame. But IIUC the model he is pursuing
> tends towards a bunch of overlapping (cascaded?)
> shrunk-to-fit frames.  Nonetheless, Drew has identified
> a number of ways in which emacs remains seriously biased
> toward reusing a small number of windows within a
> single frame.

Thanks for the plug, John. ;-)
http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs

To be clear, my own preference is for buffers to be displayed in their own
frame, _by default_. 

"By default" means that (1) I still switch buffers in a frame (windows are not
all dedicated, as in Stefan's case, IIUC) and (2) I split windows sometimes. 

IOW, nothing in my approach prevents you from using different buffers in the
same frame, and nothing prevents you from having multiple windows in a frame.
It's just that, by default, when a buffer is displayed, it gets its own
window-manager (wm) window.

In the parlance of the sites you cited, this apparently means that I use
"floating", as opposed to tiled, wm windows. As those sites recognize, floating
wm windows give users and applications the greatest liberty in frame sizing and
positioning.

Each of the sites you cited apparently supports not only tiled wm windows but
floating windows, and two of the sites (which are apparently related) even use
floating wm windows by default for some kinds of wm windows ("popup" windows).

This indicates that while some people like tiling for some wm windows in some
contexts, tiling is apparently not appropriate for all contexts. That's my view
too: (1) multiple Emacs windows within a frame are of course tiled, and (2) I
provide code for tiling frames across or down your screen (yes, that is not as
general as the tiling referred to above). I use frame tiling, for instance, for
ediff.

My only point wrt Emacs development is that Emacs is biased toward displaying
buffers in windows but not in their own frame. This bias manifests itself in
temporary buffer displays such as *Help* and *Completions* and in other ways.

The single, crude control knob that users have for changing this behavior is
option `pop-up-frames'. But simply setting that to non-nil will not give a
workable one-buffer-per-frame Emacs. 

In fact, it will bring you a host of secondary problems - vanilla Emacs just
doesn't play very well with non-nil `pop-up-frames'. Some of the problems have
to do with frame focus, but not all. Assumptions about UI interactions that are
inappropriate for use with one-buffer-per-frame seem to be hard-coded. Hence
battles over disposing of unneeded buffers and windows (buffer burying vs
killing, view-mode quitting, etc.).

It is also true that if you adopt an approach of using wm windows for buffers,
then to some extent Emacs loses control and you have to deal with the particular
wm you have. Some focus problems are in this category.

Anyway, I've been using Emacs this way since the days of Epoch, which also
introduced me to a standalone minibuffer frame. I haven't looked back since. I
don't recall having had any of the frame-related problems I see in GNU Emacs
when I used Epoch - it just worked. But that was a long time ago, and I might
simply have forgotten the problems. Also, I was on Unix, not Windows, back then
- perhaps that made a difference too. In any case, as they say, "Finie, la Belle
Epoque!"