[arch-projects] Modular Text Editor

[Dusty Phillips]

If this has been done, I'd really like to see where. I'm really
getting tired of the messy hacks that text editors tend to be, with
features I never use and so forth. I want to build a text editor that
allows you to install features one at a time (sounds like the archwm
philosophy, eh?)

I don't have time to do this, I was wondering if I could gain support.
Basically, here's what I'm thinking:

There is an extremely simple main editor component (written in
python). This provides basic text editing and an
extension/plugin/macro language.

Then you can use import statements in a config to import editor
modules that you are interested in. Such modules would provide syntax
highlighting, keyboard shortcuts, menubars (I'd never install this,
but somebody else might), toolbars (ditto), code completion,
abbreviations, search and replace etc.

Finally, you can have usually very short configuration scripts that
provide additional customizations (set up your keyboard shortcuts,
syntax colours, etc) or macro-like features in your home directory. If
possible, it would be cool if these short scripts could be scripted in
languages other than python

Question 1: How is this different from <insert-favourite-text-editor>?

Answer 1: Maybe its not. Maybe you have an editor that I would like to
use. I really don't want to write my own editor, but none of the
existing tools are elegant enough for me. Please tell me about it,
especially if its not a common editor.

Answer 2: There is an editor that is similar to what I want. Its known
as vim. I have some issues with vim though -- its a real pain to
configure, its syntax is what I consider ugly. I don't want to learn
yet another language just to configure my editor (Actually, I know how
to script vim so I don't have to learn it, but neither do I want to
look it up).

Answer 3: There is an editor that is similar to what I want. Its known
as emacs. Same issues. I mean... Lisp???

Answer 4: There is an editor that is similar to what I want. Its known
as JEdit. I've been using JEdit for years. But I'd like something
that's a little more streamlined. JEdit has a beautiful Java plugin
architecture, and a beautiful beanshell macro interpreter. I don't see
why plugins and macros should be different, for example. It also
suffers from the same issues as the previous answers -- I mean....
Java? I would borrow a lot of cool ideas from JEdit though if I could.

Answer 5: The key thing about my vision of an editor is that each
feature is totally optional. It doesn't have "built-in" anything. BUT
installing a feature should be as easy as importing some python
module. keep it SIMPLE SIMPLE SIMPLE. The main reason for this is I
like to rebind practically ALL my keyboard shortcuts, and usually the
ones I like are bound to actions I never use, and unbinding them
is.... tricky.

Question 2: Why reimplement the wheel?

Answer 1: Its all been done. This frustrates me. I really don't want
to waste time implementing a text editor right now, but I spend so
much time in my editor, I'd like something that's got even better HCI
than JEdit. That does exactly what I want, not just almost exactly
what I want.

I've looked at several editors, focusing on python editors lately.
There's apparently nothing that suits me. But I don't want to start
from scratch. I'm thinking of borrowing from xerces2's lazy-edit
(http://xerxes2.1go.dk/python/python_start.php?kap=program.html), and
a project nobody's worked on for a while called pyeditor
(http://www.rexx.com/~dkuhlman/#special-purpose-scriptable-text-editors)
-- the idea behind this project is almost exactly what I want, it just
didn't get finished.

Answer 2: I really don't want to create an IDE. I want a text editor.
Terminals have a purpose, you don't have to embed them into your
editor, for god's sake! Debuggers can be run externally. Code
navigators..... ok, maybe. The point is, if somebody else wants one of
these things, they can create a new module to provide that
functionality *without* causing me any pain -- I just won't install
it!

Question 3: Who's involved?

Answer: If nobody would join me, I can't do this on my own at this
time, too busy. :-(

 At this point, I'd like to BEG xerces2 to take an interest in this
project, because he's pretty good with PyGTK and has done an editor
already. I'd also like to see Mr. Green on board because he's got a
pretty good grasp on what sucks in an interface. As an HCI student,
I'm learning that those of us who call ourselves programmers are not
the best people to be designing user interfaces. Actually, I've been
repeatedly beat over the head with this fact... but I digress.

I think it would be wonderful to see phrakture and cactus join me, but
phrakture is a C++ guy. He's got all that free time though, so maybe
he'd make some C++ modules to be embedded in the python
interpretter.... Cactus.... well I'd really like to have somebody
helping that could help make ruby and python cooperate in this project
so that it would fully satisfy both python and ruby programmers.

I'd also like to see Xentac and iphitus (python programmers) join me,
but I think I'm starting to ask for too much now. Wishful thinking can
only go so far. ;-)

Question 4: How would you proceed?

Assuming I can get at least one good programmer interested in the
project (begging xerces2 again, plus anybody else... lol I have no
shame), I think I would do the following:

Start with lazy-edit and refactor it to allow for fully modular
extensions. The extension interface is pretty much the *only* property
of the editor itself, besides support for a buffer. I would take out
syntax highlighting and the tabbed interface and put them in
extensions of their own. This would help test the extension interface.
The extension interface would be comprised of allowing extensions
protected access to the user interface itself, and providing some sort
of 'actions' framework to allow extensions to register actions that
could be called back somehow.

I would then go on to enhance the syntax highlighting module. It would
be nice if it were not necessary to rewrite 'edit modes' for every
syntax available. The cool thing would be to steal edit modes from
some other editor... JEdit has XML based edit modes; I'm toying with
that idea, but I'm not too fond of XML.

Then I would work on a totally generic keyboard shortcuts module. It
should be fully chainable and beautiful.... configurable in Python.
The #1 worst thing in every single editor I have ever used is the
horrible GUI interface for customizing keyboard shortcuts.

Once I have these two things, I have the two things that I consider
really important in a text editor. At that point, I will probably
start adding little things here and there as I need them, since I will
be using the editor full time.

I'm not terribly excited about this project. Its just something I feel
resigned to do because no editor I currently use behaves in the way I
think it should. I want to believe nobody else likes their editor
either, and that our connection (The Arch Philosophy) will allow you
to think that this is a good idea.

Suggestions are definately welcome.

Thanks for your time,
Dusty