[mac-lisp-ide] multiple-choice question

Wed Feb 18 13:49:02 UTC 2004

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 18, 2004, at 7:04 AM, Gary Byers wrote:

> Which of the following paradigms would people most like to see in a Mac
> lisp IDE ?  (As used below, the term "window" means what [X]Emacs would
> call a "frame", i.e., a window-system window, and the term "view" means
> about what [X]Emacs would call a "window": some portion of a 
> window-system
> window used to present a buffer and associated info (modeline, etc.)).
>
> a) traditional Mac/Cocoa behavior, where there's typically a 1:1
> relationship between a buffer and a window and usually a single view
> per window; the distinction between a buffer/view/window is often
> nearly (and sometimes completely) blurred.
>
> b) traditional [X]Emacs behavior, where buffers can be presented in
> arbitrary views in arbitrary windows.
>
> c) (a) and (b) aren't mutually exclusive: the two paradigms can be
> integrated in an intuitive, usable fashion (perhaps by noting that
> (a)'s pretty much a proper subset of (b)).  This is an essay question.
>
> d) both (a) and (b) are worth supporting, but they don't mix too well:
> a global preference should give the user a choice between (a) and (b).
>
> e) none of the above
>
> I personally lean towards (c), but I'm still working on the essay
> question.  I think that it's fair to say that (a)'s simpler to fit
> into the Cocoa document-based application model, but I think that
> that model's general enough to support (b) as well.

I think my preference is c with a strong leaning in the "a" direction. 
So I guess I need to supply the essay:

I have talked with several people on #lisp regarding what they like 
about emacs buffer management; for many of them, it boils down to the 
ability to keep many files open at once. However, I question the 
reasons that people want to keep fifty files open, and whether emacs 
buffer management solves this at all.

Let's separate out the various components flying around here so we can 
reduce this problem to its core (if you don't know by now, I am an 
obsessive reductionist :-) :

* Open Files, in-memory constructs containing the contents of a file 
with an associated location on disk where those (possibly edited) 
contents can be saved.
* Anonymous files - just like open files, but no name associated to 
them. Typically manifested as "Untitled 5234235" in most programs.
* Text forms: things which look like text documents but aren't really - 
only part of them is editable, there are buttons mixed in. See emacs's 
"customize" for an example. My instinct is to avoid these - why are 
they necessary in a real Cocoa editor?
* Text presentation by the interface - windows containing primarily 
text that are being abused as a way of presenting some piece of 
information about the editor. For instance, the *Buffer List* buffer 
menu in Emacs. These are a consequence of emacs' text-based nature and 
should be avoided in favor of more visual presentations, I think.
* Emacs buffers with no associated file - mostly like anonymous files, 
except they've got a name, and unsaved changes to them are not noted or 
treated as important by the interface. Bad bad bad bad bad.
* Buffers - emacs's name for open files, text forms, and text 
presentation by the interface. Emacs has no concept of an anonymous 
file. Tools which try to simplify buffer management by necessity deal 
with all of these things.
* Windows - split windows-in-windows in emacs-ese.
* Frames - actual OS windows.

Got all of that?

My complaints about emacs buffer management mostly relate to the 
separation between windows / frames and buffers: opening up a new 
window or frame does not create a new buffer; closing a window or frame 
does not close the buffer. Actually closing the associated window or 
frame creates another problem - unless you have an open buffer list 
window on the screen, the file is no /nowhere/. I consider it Really 
Bad to have something as important to the user as an open document with 
unsaved changes with no on-screen indication that it exists. Even 
obscured windows can be quickly unhidden, but *gone*? That's, er, bad.

So Emacs has this many-to-many mapping between buffers and visible, 
on-screen elements (I'll deal with the concept of buffer list in a 
bit). You can have a buffer in zero or more windows or frames, and 
windows or frames must point at a buffer, but they can all be pointing 
at the same buffer. As a user, I dislike this schizophrenia. The entire 
point of a graphical interface is to provide direct manipulation of the 
underlying components. Emacs buffer management, on the other hand, is 
the complete opposite of direct manipulation - the user-visible 
elements (windows and frames) have nothing to do with buffers!

To rectify this situation I would propose that a set of rules be 
followed regarding buffers:

* Buffers which refer to files or have important user-entered content 
should never be totally invisible or more than an Exposé away.
* Buffers should appear in more than one window only by explicit user 
choice.
* Multiple buffers should appear in one window only by explicit user 
choice.

I'm not excluding the possibility of some kind of smaller 
representation for buffers here! Emacs's buffer list is not that 
direction however - I suspect that most of the people who do have fifty 
buffers open have some kind of grouping on those buffers and would 
prefer to organize them. It would be really nice to be able to organize 
buffers by "project", and use OmniWeb-like persistence on them (more on 
this in a minute). However, the rule for constructing such a buffer 
list is:

* Any on-screen presentation of data whose ordering is chosen by the 
order a user has performed a set of actions and nothing else should be 
rearrangable.

(This means you, Safari tab bar! grumble)

In other words, we should try to maintain the concept of direct 
manipulation here even in the more extreme cases, through explicit 
means of managing larger number of buffers. In the most simple case, 
these rules reduce to option "a", but with more advanced buffer 
management it falls into option "c" territory.

I highly recommend that anybody who wants to chip their two cents in on 
this go download the latest OmniWeb 5 beta and play with it for a while 
- - in particular, the tabs and the workspaces. Of course the tabs 
mechanism really isn't perfect here, but it is an example of allowing 
rearrangement where it ought to be allowed - and perhaps a model for 
multiple-buffers-in-a-window? Also play with the workspaces, and note  
that they can be set to be persistent on a per-workspace basis. Very 
useful, very cool.

Brian
- --
Brian Mastenbrook
bmastenb at cs.indiana.edu
http://cs.indiana.edu/~bmastenb/

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQDNtVmnXQDi0istxEQLnpgCg9cGQ6w46pO7pojfSODxvGCoKCUgAoPIo
Ir4qro2gjjh58rqVDMKgwcVt
=Sbu3
-----END PGP SIGNATURE-----