[arch-projects] Modular Text Editor
rasat at pacific.net.sg
Mon Oct 17 09:51:10 EDT 2005
Dusty, nice idea. If you/we get a modular editor, it make spark an
interest in developing other common sofwares in modular form as well.
The current style of developing small/simple programs don't suite
everyone when range of option and features are few. But as modular, its
what they make it.
On Sat, 2005-10-08 at 10:34 -0600, 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
More information about the arch-projects