[EMAIL PROTECTED] wrote:
This is intended as reply to Robin Dunn's excellent post:
I loved that post -- it's almost as if he scanned my brain when writing it.
However, in a little of the discussion I've since seen, I think the
problem is that a lot of folks want some pieces of what Emacs gives
them, but we all want different pieces.
As a thought experiment, I would like to ask, suppose we waved a magic
wand and produced a complete (whatever that means) Python (swig?)
wrapper for Emacs: the *real* Emacs. Would that be what Robin wants?
If not, why not?
hmm -- rather than answer that questions (not for Robin, but for me),
I'll tell you what I want, and you can decide if wrapping emacs is the
way to get it.
In particular, what is the "25-year-old nearly dead technology" to
which Robin refers. Is it elisp? Is it the c implementation?
Well, I won't comment in what is or isn't dead technology, but I know I
want to be able to script my editor in python, not lisp, so that needs
to be possible (and convenient, and clean). Can you write a python
wrapper for elisp that will feel like python?
Something else?
For me, aside from scriptability in Python, the other think I want that
is different from emacs is a UI that conforms to modern GUI conventions
-- I spend much of my day in my code editor, but the rest of it in other
apps that all use the same keystrokes for the basic stuff like copy,
cut, paste, etc -- I want my editor to be the same as that. I also want
to be able to get at things I use less frequently with menus, toolbars,
etc. Somehow it just feels wrong to use Emacs on a Macintosh, so I never
have.
Emacs does support custom key bindings, so there is no real reason one
couldn't do a full re-map to a different paradigm, but I think you'd
break a lot of extensions in the process, and the extensions are the
real reason I use emacs. (actually Xemacs, but the point is the same).
In other words, suppose we could access all of Emacs *itself* from
Python. Would that be sufficient?
Maybe -- if there was total access -- but is this really easier than
building something on STC and other existing python modules?
The biggest win was being able to think in
terms of Emacs-like commands. I have lost track of the times that
being able design at the level of do-this, do-that, do-another-thing
has clarified my thinking.
A agree with this, and I think that's one of the key things I want in an
editor -- frankly, I wish all software was built with a scripting
interface first, and GUI second (or at least a full scripting interface
at some point!). It kind of reminds me of the KDE application
configuration philosophy (I don't know if they still stick to this):
- All configuration will be held in user-readable text files
- All configuration will have a GUI to manipulate it.
You really need BOTH of these. I this case it's:
- All functionality will have a scripting interface
- All functionality will have a GUI accessor (though I could relax
that to "most", or even "much")
Anyway, Robin's post list a bunch of must-have features, most of which I
agree with. However, with a good scripting interface, we can get most
specific features by writing a script, so I'll give a short list:
- Good scripting interface (in python, natch) -- what this means is
that every action one might do to text is some kind of function or method.
- Completely customizable key bindings (and a default set that matches
modern GUI standards)
- multiple views of the same buffer, and multiple top-level windows.
- A concept of "Modes" to support different languages, etc.
- soft-wrapping of text (this is the ONE thing that Emacs doesn't do
well!)
Sound like emacs? yup , expect for the modern UI and python scripting,
so maybe wrapping emacs is the way to get there. However, Peppy, and a
few other python editors are getting really close, so I don't know that
adding the big dependency and the complexity of wrappers really is the
best way to go.
that's my thoughts....
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
