Duncan Rose wrote: On Wednesday, February 18, 2004, at 12:04 PM, 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'd vote for (c) too. Failing that, (b) alone would be my preference. But then, I've only recently started using Macs so maybe I'll change my mind with more exposure to "the Apple way".

Another vote for (c) here, with the note that (a) is not a subset of (b) unless you implement it that way. My concern is to have transparent access to the stuff in the windows from whatever lisp code I happen to hack together, and in my limited experience the very tempting route of using the cocoa text-handling functions to get something working quickly can make that transparency difficult.

paul