Make LispM code FREE (fwd)

[Rainer Joswig]

At 12:44 31.03.98 -0800, Mike McDonald wrote:

>  CLIM is only portable IF your comercial lisp vender deams to provide
>it for your platform.

Franz: CLIM 2 on Unix and Windows.
Harlequin: CLIM 2 on Unix and Windows.
Digitool: CLIM 2 on Mac OS, soon.
Symbolics: CLIM 2 on Genera and Open Genera.

In ancient times vendors shared the source for CLIM.
All CLIM implementations came from a common source base.

> And if you can afford it.

Harlequin's version on Windows is not that expensive.

Symbolics Genera 8.3 comes with CLIM source. Digitool might
sell CLIM source for MCL for an additional price.

>With Franz preparing
>to release their version for Linux, that should help alot.

Yep. Good move by Franz.

>>Yes.
>>
>
>  Why? I'm serious. Why would you want to implement Emacs using CLIM?

Because I want every editable gadget to be a full Emacs (ala Macintosh
Common Lisp, where FRED (FRED resembles emacs deliberately)
implements buffers, text editor fields and editor windows in
one common substrate). I also would want to use the CLIM mechanisms
in an editor (integration into presentations, command tables,
menus, ...).

>I hope you're not thinking of presenting each character/word.

Sure not. But for example on a Symbolics you can do
(accept 'some-presentation-type) and get the object
from an editor buffer. Once all windows are on the
same level, you can use their objects, too. I'm
often splitting the screen in a editor and a listener.
You also can press suspend in an editor and a
listener opens from the top. All editor items are
mousable according to the current input context.
I cannot imagine why one want to lose the
functionality of integrating presentations and
presentation parsing from editor buffers. You also
could layer a presentation structure on top of an
CLIM based Emacs. Some Emacs/XEmacs buffers are providing
CLIM-like highlighting and context sensitive mouse-right
menus. Very valuable. CLIM already has the infrastructure.
Example: Dired could display lines of presentations.

> I can
>understand implementing a web browser using CLIM but not Emacs. Please
>enlighten me!

W3 is implemented in Emacs. Once you can have have a Web browser,
you want to edit (markup) files. The Symbolics had a Document Examiner
for the documentation (with a lot web browser like features) and
a Zmacs extension for writing the documentation (Concordia). The
latter used a markup view. Integrating this would be interesting.
Wysiwyg editor for files with markup (HTML, Scribe, XML, whatever, ...).

>>- CLIM Emacs
>>-- integrates Editor, Shell, Mail, News, Telnet
>
>  Ouhh! Yuck! That seems like Unix thinking again. Let them be
>separate apps that can communicate easily with each other. We don't
>have to go the kitchen sink route again! (Things like one common,
>global kill ring help to integrate separate apps.)

But the Lisp OS is the kitchen sink route. Maximize reuse.
The system is a soup of objects. Large units are components.

Tell me how the applications will work together? How
will classes inherit from other classes?
I guess the global kill ring is not a very good communication
mechanism. The Mac for example has an infrastructure for
interapplications commnunication and scripting:
Open Scripting Architecture, AppleEvents, AppleScripts, ...
This would be an alternative. Corba? COM?
Distributed Objects/Classes? Distributed agents?

>>- File Browser
>>-- browse directories, rename files, create files, delete files,
>>   edit files, change properties, find files, open files,
>>   move and copy files
>>
>
>  On my Symbolics, I found that once the Lisp Listener had
>presentation types, I hardly ever used the File Editor. (Except to
>find out how many free records were left.) It was easier to just do a
>:Show Directory in the listener.

This often works. Drawbacks: views are not updating themselves(!!), you
are generating a lot of views on the same data, you are
scrolling a lot around, every command invocation brings
your view to the bottom of the listener, etc. An intuitive
Finder (ala Macintosh) view often is much more manageable.

>>- Inspector
>>-- can inspect every Lisp object
>>-- provides special views for common object types
>
>  Once again, once you have presentation types in the lisp listener, a
>windowed inspector becomes redundant. Just middle click on any lisp
>object and it gets described. Right click on one of the slots and get
>the chance to modify it. Left click on any other object on the screen
>to use that for the new value. Life's good!

Again. Having information in place and updating helps navigating
in the information.

>>- Apropos
>>-- search through the various namespaces (variables, functions, packages,
>>   modules, applications, ...)
>
>  Hmm, I always found (apropos 'foo) to work just fine.

Personally I'm preferring (Find Symbol). Very valuable is also
the Apropos dialog in MCL. Makes peeking around very easy
and convenient.

>>- Class Browser
>>- Function Browser
>>- Package Browser
>
>  All can be done in the lisp listener with presentation types.

Again. the Navigation aspect. Also the aspect that you can link tools
like in LispWorks, Apple Dylan or SK8. Providing explicit tools
with their own windows (still implemented with presentations)
makes it more accessible. Don't put everything
into the Listener. Once the task is complex enough there
is reason to provide a tailored tool.