Make LispM code FREE (fwd)

[Mike McDonald]

>Date: Tue, 31 Mar 1998 23:32:31 +0200
>To: lispos@math.gatech.edu
>From: Rainer Joswig <joswig@lavielle.com>
>Subject: Re: Make LispM code FREE (fwd)


>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.

  Unix is a pretty broad sword here!

>> And if you can afford it.
>
>Harlequin's version on Windows is not that expensive.

  Being a Unix weenie, I'm more interested in that. Last time I
checked one of the above vendors for a version for a Unix version, the
base implementation was $4000 and CLIM ws another $3000 on top. That's
a bit out of my range for toys. (And yes, I'm playing!)

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

  Heck, my XL1201 didn't even come with CLIM period. I had to bug them
about it and got a binary only version on a separate CD. No sources
for anything! And now that they're belly up again, not which hope of
rectifying that either. :-((

>>  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, ...).

  Ah, you want a emacs-pane. OK, that's good. (I implemented one for
Dynamic Windows years ago on the Symbolics for this very reason.)

>>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.

  OK, I understand. As long as your going to provide your own
presentation parser for the emacs-pane, sounds great. 

>>>- 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?

  How about shared memory? All of my LispOS apps a threads running in
the same address space. Want to communicate with some app? Call it!

>
>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.

  True, they do tend to get mixed in with everything else when it's
all being done in the lisp listener. I guess that's why I'm a frequent
user of :Clear Output History. Windowed versions shouldn't be hard to
implement either once you have CLIM in place.

>>>- 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.

  Can't wait to see your implementation! :-)

>
>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.

  Sounds good as long as I can still do basic stuff in the lisp
listener too. (Which I should be able to given the use of
presentations.)

  Mike McDonald
  mikemac@mikemac.com