[mac-lisp-ide] multiple-choice question

mikel evins mikel at evins.net
Wed Feb 18 16:53:04 UTC 2004


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.





More information about the Mac-lisp-ide mailing list