CLIM mail archive
[Prev][Next][Index][Thread]

CLIM based EMACS

Concerning the CLIM/EMACS discussion:
>> 
>> I'd like to support this view and to add that when NOT using Genera, an integrated,
>> extensible and customizable editor is often missing. Although using Emacs 
>> on UNIX workstations may be an alternative [which has been choosen by
>> several Lisp Vendors for their development environments], the impact on portability and difficulties
>> with the integration are important arguments against this approach.
>>
>
>Actually, I think the approach that Franz has taken by providing an
>editor protocol and hooks to emacs is the right route. Vendors who
>don't support emacs have been chastised severely. By providing the
>hooks from the implementation the user can use whatever editor they want.

I'm afraid I haven't been very precise with the term "is missing". I didn't think so
much of the development environment itself but of applications requiring integration with a text editor.
The approach taken by Franz is fine as far as the development environment is concerned. [Actually I consider
the Allegro CL/Emacs integration as very good.] But when developing an application that itself
requires a text editor, a CLIM based solution would offer portability and tight integration.
Without it, you either have to sacrifice portability for tight integration [since there's ZMACS on Symbolics,
the MCL editor FRED on the Macintosh, EMACS on UNIX systems with presumably different interfaces for
Allegro CL and Lucid CL and so forth] or to sacrifice tight integration for portability [e. g. by restricting 
the interface to file exchange] or to develop your own text editor on top of CLIM. Therefore having a CLIM
based text editor in the CLIM library [or perhaps available as a commercial product with a protocol
specification supporting customization] would be very desirable.
 
>> Tools going beyond text editing [such as hypertext systems] could also significantly facilitate 
>> application development.
>> 
>
>Aie. I'd propose that a hypertext system is beyond the scope of CLIM, and is
>properly an application. It's a non-trivial task, and adding that to the stuff
>that the CLIM vendors must support at this level is really going to either
>skyrocket the price or bankrupt them. Since I use a hypertext system as a
>part of my development environment I certainly agree that it facilitates
>that process, however I'm not convinced that I would expect my CLIM vendor to
>support the product. I use a mail system every day too, and I certainly don't
>expect my CLIM vendor to support it. We're getting back to the argument that
>expecting too much functionality from CLIM is gonna kill us all.
>
>..arun

I agree that a hypertext system is clearly an application [as well as e. g. a text editor].
I didn't want to propose to include a  hypertext system into CLIM directly, but I'd like
to have it in the CLIM library [or perhaps available as a commercial product with a protocol
specification supporting customization]. Again I think more of integration with an application
than of improving the development environment.


Kind regards, Frank Plassmeier
	
fplass%ernohb@uni-dortmund.de (or fplass@ernohb.uucp)

 

0,,
Main Index | Thread Index