The Old Joel on Software Forum: Part 4 (of 5) - Text-editor as Application-Scripting-Framework

Text-editor as Application-Scripting-Framework

I'm not personally crazy about the emacs text editor. I use it periodically, and it's my default choice of text editors whenever I'm working on a *nix machine. But I feel much more at home in an editor like TextPad (here: http://textpad.com ).

Everyone has their own favorites.

Horses for courses.

[NOTE: please do not let this thread turn into a best-text-editor-ever flamewar ]

But, what I _really_ like about the concept of emacs (and what I want to discuss in this thread) is that, deep in its heart, emacs isn't really a text editor: it's a lisp interpreter, on which text-editing tools have been built. So, if you're a lisp programmer, you can build fantastic things on top of emacs. You can build _exactly_ the kind of text editor that most suits your needs.

Unfortunately, I'm not a lisp programmer.

And I'm not interested in learning lisp. Not at all.

But I like the concept of using a general interpreter framework as the core of a text editor (or as the core of a whatever-editor).

What I'd like even more would be if the scripting framework was abstracted away from the text-editor layer. I'd like to be able to swap out a lisp interpreter for a Python or Perl or JavaScript or php interpreter.

In an ideal, magical world, I'd like to be able to write a page or two of code in Python or Perl, to turn TextPad into a specialized XML editor. Or maybe I’d like to add a WSDL wizard. Or a spreadsheet editor (much like ses is a spreadsheet editor for emacs; see it here: http://mywebpages.comcast.net/jyavner/ses/ )

Frankly, it surprises me that something like this hasn't been developed yet. Emacs was originally written in 1976, and by 1978 it was re-implemented in MacLisp, making it easy for users to extend the application by writing their own lisp routines. So the concept of text-editor-as-application-scripting-framework has been around for over 25 years, but I don't think anyone else has done much since then to advance the concept to newer and more developer-accessible (read: non-lisp) applications.

Thoughts?

Benji Smith
Friday, February 20, 2004

To clarify...

There are lots of text-editors that have scripting-languages grafted onto them after-the-fact, allowing users to write some of their own custom functions.

But that's not really what I'm talking about here.

Other than emacs, I know of no other tool that makes its _entire_ object model accessible to user-scripts, so that plugin-authors can drastically modify the core behavior of the application, without having to touch the original source code of the core engine.

That's what I'd like to see. But I'd like to see it in something other than lisp.

Benji Smith
Friday, February 20, 2004

Interesting that you bring this up ...

I have a common library that I use for many projects, which includes a Lisp interpreter that I've written. In addition to the Lisp interpreter, I've written a parser generator that takes arbitrary context free grammars as input. Then I put the two together, so you can define arbitrary CF grammars in Lisp and do your programming in whatever language you like (which essentially gets translated into Lisp code).

It's a very common pattern, I'm sure that other people make frequent use of it too.

K
Friday, February 20, 2004

Slickedit is pretty much built like that. It is all written in Slick-C, even much of the GUI elements. However the bad part is I don't like this specialized language, it would have been nicer if it was an existing language. And the code is very procedural and cryptic.

But, I have to say, the editor is VERY fast, though almost all of it was written in this interpreted language.

Roose
Friday, February 20, 2004

Check out jEdit at http://www.jedit.org

It's not as customisable as Emacs, but it's a very good text editor. As it's Java, you can get it for a wide range of OSes, and it's the same one each.

C Rose
Friday, February 20, 2004

What you do is build a framework for editing, indepenent of editor. And a program (in any language) could be written to convert them into LISP for emacs.

Surfer
Friday, February 20, 2004

Actually, I think jEdit is almost as customizable as Emacs is. And you can use either Jython or BeanShell to script its *complete* object model, since all the objects are written in Java.

jEdit plugins have to be written in Java, but those plugins are also scriptable from Jython and BeanShell.

Phillip J. Eby
Friday, February 20, 2004

How about customising MS Word! Almost its entire object model is exposed in VBA.

Matthew Lock
Saturday, February 21, 2004

"What I'd like even more would be if the scripting framework was abstracted away from the text-editor layer. I'd like to be able to swap out a lisp interpreter for a Python or Perl or JavaScript or php interpreter."

You might want to read up on Apple's Open Scripting Architecture. (Wrong platform, I know, but it may give you some ideas.) One of their more misunderstood, misrepresented and often neglected technologies (not helped by frequently lousy documentation and various design/implementation flaws that were never thrashed out; probably not helped by Apple mgt killing the dev team shortly after the initial release). Some terrific ideas behind it though, and can be wonderful when it works right.

Here's a good introduction/overview:

http://www.cs.utexas.edu/users/wcook/papers/AppleScript/AppleScript95.pdf

Basically, the Apple Event Manager provides a high-level inter-/intra-application RPC mechanism. AEM defines a bunch of basic data types, plus a query-based mechanism for representing application object models. Any language that can talk to the AEM can control any application that provides an Apple event-based scripting interface.

The OSA component is used to componentise scripting languages (see also the Mac OS Component Manager, which appeared in System 7) and provide a standard API for applications to load/execute/store scripts written in any OSA-compatible language, send events to them, etc.

--

One of my favourite examples of the OSA's [largely unrealised] potential is the Smile application.

http://www.satimage-software.com/

Nominally marketed as an AppleScript editor, it's really a platform for building custom applications (the company that develops it, Satimage Software, use it in CAM systems). Based around a relatively small C/C++ core with a fairly large and flexible scripting interface, much of the Smile application itself is implemented as script and GUI objects attached to this. Somewhat eccentric in appearance and design, but surprisingly deep and powerful - and its OSA support means you can hook it up to any other OSA-compatible applications and/or languages as you like. If you can blag a Mac sometime, it'd be worth a poke around its innards for a rough feel of how it's put together [1]. Or d/l the developer docs and have a browse through those for your interest.

--

BTW, you'll often see the whole OSA architecture misleadingly referred to as "AppleScript", btw. In fact, AppleScript is merely one of a number of scripting languages that has AEM and OSA support; it just happens to be the de-facto standard language for doing Mac IAC, having shipped with the OS as standard since 7.5.

The AppleScript language is also heavily bug-ridden and severely underpowered (not really surprising given years of neglect), with a wide range of design flaws from minor to severe [1], but don't let this put you off OSA itself; it's much better than this unfortunate historical mal-association suggests. Besides, positive developments are starting to happen on the third-party front: Perl's Mac::Glue is starting to get some attention (see the recent perl.com article on it for starters); and various folk are quietly working on nicer frontends to AEM and the OSA component. (e.g. I'm working on a Python-AEM bridge myself - see http://freespace.virgin.net/hamish.sanderson/appscript.html - plus a generic spec for developing AEM bridges for other languages.)

--

[1] The scripting's all done in slightly eccentric and poorly commented AppleScript code that takes some effort to read in detail, but a quick overview's all you need.

[2] Including - but by no means limited to - clever-clever compiler trickery that frequently backfires on users, far-too-premature name binding, muddy semantics, atrocious whack-a-mole namespace pollution, scads of syntactic synonyms and homonyms, no native module mechanism. (Admittely, there are some nice ideas behind it, but the actual implementation is a right old lemon.)

has
Saturday, February 21, 2004

And the real point these days is that there are *great* stamdardlanguages for doing text processing, like Perl and Ruby and Python, so there's no need to write a custom language for doing this sort of thing. What's really needed is a display engine that can shell out to Perl or Python or Ruby or the language of your choice to do the text processing.

One way to do this would be to write a little stand-alone application for displaying colored text in a window, and for reading the keyboard. Then a Perl program can communicate with that application via sockets.

Does anyone know of a Windows application or DLL that can be used to provide a simple text-based interface (not the command console--yuck!) and get simple events? Something with fixed-width fonts, where you can say "put a red 'B' at character coordinates 23,14. Sort of like a glorified Commodore 64, really.

Junkster
Monday, February 23, 2004