Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!walnut.Berkeley.EDU!hastings
From: hastings@walnut.Berkeley.EDU (Mark Hastings)
Newsgroups: comp.emacs
Subject: Re: real X windows support from emacs
Message-ID: <36861@ucbvax.BERKELEY.EDU>
Date: 7 Jun 90 07:22:43 GMT
References: <90May31.100818edt.14538@neat.cs.toronto.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: hastings@walnut.Berkeley.EDU (Mark Hastings)
Organization: University of California at Berkeley
Lines: 116

> From: kramer@cs.toronto.edu ("Bryan M. Kramer")
> Is there any movement towards an emacs that makes real use
> of the capabilities of the X window system?  For example, certain
> sunview textedit features would make editting much more efficient.
> In general, these are features that have been known in various
> editors, each of which makes editting more efficient:

All this discussion of windowing emacs editors has encouraged me to
discuss how our Pan editor (a research project here at UC Berkeley)
addresses these issues.  A rather detailed blurb about Pan written
by a colleague appears at the end of this article.

But first some preliminaries:
	Pan started out as a window-system based editor -- in fact it
must be run under Sunview or X11.  So the original design took
advantage of many of the window system features discussed in this
thread:

> a) scroll bars
> h) use INDEPENT X windows for each window --> this means indepently shapable
> and moveable; allow them to shrink to icons and in cases where they
> display things such as direds or buffer menus, they would update themselves
> when opened. Generally functions such as meta dot, dired, buffer list
> should open new windows rather than change the contents of the current
> window.

A Pan buffer may have any number of windows (zero, one, or more than one),
and each window contains horizontal and vertical scrollbars for navigating
through the entire document.  This brings up the interesting issue of
how tightly emacs binds navigation and editing operations.  With
scrollbars, you are free to scroll away from the insertion point.
Pan keeps this from being confusing with (a) a policy of forcing the
insertion point to be visible when changes occur and (b) providing the
user with a command that scrolls to the point.

With individual windows for each buffer, you can also experiment with
additional status information beyond the normal "mode line" in emacs.

> b) hilighted selections (region between point and mark); secondary selections
> c) copy or cut and paste holding down a key and using the mouse 
> to outline the region to be copied/moved (in Interlisp it was
> called shift-select). I personally like the openwindows style for selections.

Pan indicates selection by underlining the text in the selection.  The
mouse can be used to make the selection (following the Sunview style
of selecting).  Note that this is another area where emacs tightly
binds the current insertion point with the notion of selection.  With
mouse based selection, selections can be far removed from the actual
insertion point.  This makes possible single-step commands like
"copy selection to point" in addition to all the usual ones
supported by Emacs (and Pan).


The following blurb doesn't include a rather lengthy annotated
bibliography of Pan reports, but I can forward that to interested
parties.

Also, we hope to have a source distribution of Pan ready by the end of
the summer.  Compiling Pan will require users to have their own
copy of Franz's Allegro Common Lisp (as most of the system is
written in Common Lisp).  I will announce more details when we get
nearer to completion.

And now for the blurb:


     Pan is an editing and browsing system that supports the
development of complex software components having both textual and
structural aspects.  The primary objects of interest are referred to
generically as documents. Documents include both objects with
formalized structure, such as formal designs and program components,
as well as traditional natural language texts.

     Pan's most notable features are its support for incremental
checking and analysis and its tolerance for errors and anomalies.  It
has a number of other important properties.

+ Pan incrementally builds and maintains a collection of information
about documents that can be shared with other tools.  One kind of
information concerns the presence, location, and description of
document anomalies (traditionally syntax and static-semantic errors).

+ Pan users can freely mix text- and structure-oriented manipulations
in the same visual editing field; no restrictions are placed on the
ability to edit textually.

+ Pan is a multi-window, multiple-font, mouse-based editing system
that is fully customizable and extensible in the spirit of Emacs.

+ A single Pan session may involve multiple languages.

+ Adding new languages by writing language descriptions is just one of
Pan's extension mechanisms.

+ Pan is otherwise a full-featured editor. For example it includes a
rich text-oriented command set, generalized undo, a file system
directory browser, and an integrated online help system.

     Pan runs under the SunView window system, and has recently been
ported to X11.  Pan runs on Sun 3 workstations, and is currently being
ported to DECstation and Sparcstation architectures.

     Pan was developed at the University of California, Berkeley as
one of the PIPER projects.  The current version of Pan, internally
called Pan I, is a fully functional prototype; it is in use for
ongoing research in language description and processing techniques,
user-interface design, advanced program viewing methods, and related
areas.  Research projects based on Pan are in progress both at UC,
Berkeley and at the University of New Mexico.  The design of a
successor to Pan I is also under way.

--Mark Hastings           			(415) 642-4611
  hastings@sequoia.berkeley.edu			..!ucbvax!sequoia!hastings

--Mark Hastings           			(415) 642-4611
  hastings@sequoia.berkeley.edu			..!ucbvax!sequoia!hastings