[arch-projects] Modular Text Editor

Lukas Sabota punkrockguy318 at comcast.net
Sat Oct 8 12:46:40 EDT 2005

Dusty Phillips wrote:

>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
>-- 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
>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,
>arch-projects mailing list
>arch-projects at archlinux.org
I really like the idea of this project.  I would be willing put out some 
lines of code for this.

God Bless,

More information about the arch-projects mailing list