[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DrScheme as Emacs-like kitchen sink



Quoting Bill Richter:
> DrScheme seems a great opportunity to start over, break free from all
> the over-engineered Emacs Lisp code.  How I've wanted to junk fill.el
> and write a new one!

Yes, that's what I wanted to do from the start with DrScheme --- or,
more precisely, with MrEd (hence the "Ed"). Consequently, DrScheme's
editor core is especially flexible.

The actual editor that DrScheme users see is inflexible. As Matthias,
Shriram, and Robby have pointed out, the inflexibility intentional, in
the same way that the restrictions in the default language are
intentional. But there's no reason that the editor couldn't grow with
a user, in the same way that language levels do.

Quoting Jerzy Karczmarczuk:
> There is more to the process known as "editing" than what *typical* Emacs
> scripts offer. Look at the Amaya/Thot project. We need more and more
> editors of highly structured information. Not just syntax colouring of
> programs, but some syntax checkers during editing. Not just simple macros,
> but a full template language.
> 
> Ease of user scripting? Look at XCoral.
> (OK, I admit I am promoting French products, but there are other as well.)
> 
> Also, selective presentation of information, e.g. headers only. Or section
> titles only, or a particular section of text tagged as "visible". The editing
> of HTML needs sometimes to find the dimensions of an included image or applet.
> 
> Not only texts are edited. Dataflow diagrams. Small, simple-minded databases,
> not requiring fully-fledged DBMs. The assembly of animated images (GIF, MNG)
> which don't need any image-processing software, just a structured editor.

Yes - these are the sort of directions that I had in mind, too.

I still think MrEd's editor classes are a great start for a next
generation "Emacs". (We've lived with the editor library long enough
to see its warts, but it's also held up pretty well --- better than
the previous two editors I'd written.)

Of course, the reason the PLT never got far (in terms of actual
editors) is that building a general, user-extensible editing system is
difficult and time-consuming, and we have other difficult and
time-consuming goals. We'd all be happy to see someone (or some group)
take up the challenge.

Matthew