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.
Gary Byers gb@clozure.com
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".
I'm not sure I understand why (c) is an essay question ...
-Duncan
Gary Byers gb@clozure.com
mac-lisp-ide site list mac-lisp-ide@common-lisp.net http://common-lisp.net/mailman/listinfo/mac-lisp-ide
I vote for (c) as well. As a long-time Mac user, I prefer (a), but (b) is occasionally useful. As long as I can set things up so that, by default, I get a new window every time I open a file, I'm happy. When I want multiple buffers in a window, something like a split-pane bar that I can drag down is very natural.
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.
Gary Byers gb@clozure.com
mac-lisp-ide site list mac-lisp-ide@common-lisp.net http://common-lisp.net/mailman/listinfo/mac-lisp-ide
-----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@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
On Feb 18, 2004, at 4: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.
(c), sort of. Primarily, the IDE's text windows should act like traditional Mac/Cocoa windows, but should add those parts of Emacs behavior that are not better handled by the normal Mac behavior, and that can be handled in a civilized fashion (about which more below).
Things to cherry-pick from Emacs are being able to split a window so that you can see different parts of the same document in the window at the same time, or being able to split a window and see two different documents side-by-side.
Things not to take from Emacs are text windows full of buttons and widgets for setting preferences, text windows used as menus, text windows used as UI for structured and linked documents, and so on. There are better ways with good support in Cocoa and wide currency in use.
The area where Emacs really annoys me is in the use of panes in windows for 'inferior processes'. Presumably, a Lisp IDE will be concerned only about listeners and lisp processes. When I'm working in Emacs I generally keep a frame split, with an inferior lisp in the lower pane. That's not because it's the way I'd prefer it; I'd prefer to have the listener in a separate frame. However, if I do that, then inevitably some command I execute in the Lisp source buffer persuades Emacs that I would really prefer to have the inferior lisp displayed in a big honking pane in my source window. This is so annoying that I just knuckle under and let the stupid inferior lisp pane stay in the main window, thus defeating the purpose of having a separate listener frame, so I lose that frame.
In general, Emacs does not respect the uses to which I put its various panes. It is forever deciding that it needs to take over some pane that I'm using for something else, in order to display something that it thinks is so important that I don't need to see the contents of my pane any more. We don't need to do stupid things like that; we have an entire taxonomy of UI widgets and customs that enable us to interact richly with the user without commandeering the user's windows.
I would like to be able to split windows and see different text side-by-side. I would not like the IDE to, emacs-like, become confused about which things I want displayed in which frames. I would like to set up my working environment and have the windows obey my setup. I would not like to play musical panes.
Gary Byers writes:
Which of the following paradigms would people most like to see in a Mac lisp IDE ?
I'd like to see (c), but with everything configured for (a). GNU Emacs can almost do (a), but it makes such heavy use of aweful pop-to- and switch-to- functions in such a variety of contexts, with so many dynamic variables affecting the outcome... that it's not quite possible to pull off (a). A focus on having (a) be the prefered state, with (b) as a supported alternative, would probably help in avoiding the Emacs situation.
I'm not actually a big fan of (b). A useful variation is to have a 1:1 view:window relationship, with the possiblility of having a buffer in any number of view/windows. This is what Hemlock/X11 does by default.
-
Brian Mastenbrook -
Duncan Rose -
Gary Byers -
mikel evins -
Randall Beer -
Thomas F. Burdick