[Openmcl-devel] hemlock

[Gary Byers]

On Sat, 7 Aug 2004, Hamilton Link wrote:

> Don't do the top-level-window thing. Why? Tabbed views are modal by
> default. Modal views are bad GUI design for most things, and
> programming is one of those things IMHO. You could do it for editors
> (tabbed view, tearable tabs), but leave the listeners, inspectors,
> backtrace, etc. as separate windows. I really can't emphasize this
> enough.
>
> The programming environments I like best make separate windows for
> everything. You can see more, and you can have the things that you
> _want_ to see at the same time, _visible_ all at the same time.
>
> Emacs gets away with modality for two reasons: (1) it's a legacy mode
> for terminals and is often used in that way, (2) emacs has split panel
> and independent window modes that are easy to invoke, and it's totally
> easy to switch between buffers without reaching for the mouse. Oh, and
> (3) we want something that is _better_ than the emacs+slime package.
>

Sorry if this is rambling and anecdotal.  But ...

I tend to use (and mostly like) [X]Emacs's CVS interface (PCL-CVS).
It's spartan and a little funky, but it's generally good at presenting
important information concisely (what files are locally modified, remotely
modified, have conflicts  ...) and is fairly well-integrated with Emacs
itself and with other tools.

One thing that it's very -bad- at is managing screen real estate: it's
not uncommon to select a locally modified file from the pane ("window",
in Emacs-ese) that displays file status and indicate that one wants
to commit one's changes.  The window ("frame", in Emacs-ese) splits
into two panes, showing the file status pane and a selected pane/buffer
into which one can enter a log comment.  So far, so good.

I find that when entering that log comment I often want to review the
changes I've made.  No problem: simply selecting the file from the
status pane and pressing a single key will run "cvs diff" for you,
and put the diff results in a viewable buffer and displays that buffer ...
... instead of the "commit" buffer

It's certainly possible that after a few C-X b's and C-X 2's, one
can rearrange things so that the most relevant things are displayed
simultaneously; it's also unfortunately likely that the next CVS
operation (selecting another file to commit) will clobber this
arrangement and force the user to do a few more C-X b's /C-X 2's.

I don't know that this necessarily means that the "top-level window
displaying multiple panes" paradigm can't be made to work better in
this regard (to somehow pay more attention to existing logical layout
or to heuristally lay things out more intelligently), but I think that
it's fair to say that if these issues are ignored (as they are by many
Emacs utilities) the results are suboptimal.

The other extreme - the "single window for everything" approach -
seems to at least partly avoid some of these problems.  (Yes, it's
still possible for a new window to obscure another interesting window,
but it's probably more likely that the user can organize things
reasonably and less likey that a programming tool will completely
clobber that organization every time one tries to use it.)

One problem with the single-window-for-everything approach is that it
can lead to excessive clutter.  Commercial MCL's inspector opens a new
window for every new object it encounters.  This might be OK if every
object you had to navigate through to get to what you were interested
in was as interesting as that target; I generally find that that's not
the case (and used to wind up with a screenful of uninteresting
inspector windows obscuring the interesting ones.)  If an inspector's
both a "navigation tool" and a "presentation tool", it doesn't seem
unreasonable for it to use different approaches to navigation and
presentation.

[There was a brief but interesting discussion of these issues on the
"mac-lisp-ide at common-lisp.net" mailing list several months ago.]