Re: [code] @Mitchell: state and further development of TextAdept

From: Mitchell <>
Date: Sat, 26 Jan 2013 20:56:31 -0500 (EST)


> But what I'm interested in is what's the further planned development?

I haven't really thought about it too much now that the ncurses port is
stable. I am contemplating JITing lpeg to make lexing faster, but that's
likely to be a time-consuming effort.

> My current editor is VIM stuffed with lots of plugins, but still not being
> as functional and comfortable as I would expect it to be.
> So now I'm looking at TextAdept as a base for the following changes:
> 1. Add Python scripting support (because Python is more expressive and rich
> language, no one says Lua will be dropped).

Python would bloat up Textadept considerably, so this is not possible.
(Where do you draw the line on libraries, etc.) Also as Steve mentioned,
Python is a pain to integrate.

> 2. Tabs. I've seen authors thoughts on this, but still I think that it
> won't be a bad decision to implement them.
> (Everyone have it, people use it, so why not?).

Do you have a counter-argument/proposal against my thoughts on this? I'm
very open to hearing about it.

> 2. Even more extensibility: expose UI objects to scripts.

To what extent? The UI objects are already extensible. (Show/hide find and
command entry, imitate button presses, hook into UI events, set titlebar
text, etc.)

> 3. Completely extensible file browser implementation.

There was a project-manager-style treeview in pre-2.2 that among other
things supported a file browser. I removed it because the treeview model
was both too limited and problematic/buggy. I created a text-based file
browser[1] that you can improve upon if you'd like.

> 4. VIM mode (yes, once you get used to it you can never quit).

If you're interested in writing one, please share it. I have no interest
in such a thing myself.

> 5. Port of Code Intelligence from Komodo Edit or similar (like the one for
> Sublime Text 2:

Komodo's Code Intelligence is bloated and complex. I haven't looked at
Sublime's, but I don't think it's as elegant as Adeptsense. Adeptsense is
around 350 lines of code and most languages can create accurate senses
with around a dozen more. Is there something Adeptsense has that you need?
Implementing some things like return value completions are quite complex
and would not be accurate enough to be useful in my opinion.

> 6. More pluginzzz!!! at least bare minimum: VCS/RCS integration, file
> templates, ack integration/python rewrite, completion, tags,
> documentation browser and similar for programming.

I have a VCS module[2] that you can build off of. It supports most
Mercurial commands and some Subversion ones. I find it easier to use the
command line or a dedicated tool like TortoiseHg though.

As for completion, tags, and documentation, again there is Adeptsense
unless you find something lacking.

> For this from what I see in current source following steps should be taken:
> 1. Moving code base from functional to object-oriented paradigm (GObject).

This would be pretty much rewriting the editor, no?

> 2. Utilizing libpeas (with engine for lua) or moving to Gtk3 and using
> GObject Introspection.

I am reluctant to include another library as a dependency. I'd like to
stick with just GTK or ncurses. Also, would the ncurses version need to
have libpeas? If not, would the feature set be the same? Seems like a lot
to think about.

> 3. Implementing VIM engine (I bet it can be ported from evil (emacs) or
> some another open source implementation).

But Textadept is not VIM nor does it want to be...

> 4. Modifing existing Lua scripts core according to #1. Because of direct
> interaction with UI components code can be simplified
> and gain more control over what's going on.

Again, wouldn't this be pretty much rewriting the editor?

> This is a very raw and high level list (such things like plugin event
> system so plugins could interact and emit/receive custom events,
> common settings storage, alternative dialogs, etc.. are not mentioned).
> What I would like to ask is what does author think about changes described?
> Maybe some of them are planned (like moving to Gtk3 and GObject)?
> Or could be implemented for project (like VIM keybindings, modes and some
> basic commands and tabs)?

Thanks for the suggestions. However, most of them would be pushing
Textadept in a direction it was never intended to go in the first place.
Textadept's strengths are its differences from other mainstream editors.
I wouldn't want to write another VIM-like editor; I would just use VIM.



You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sat 26 Jan 2013 - 20:56:31 EST

This archive was generated by hypermail 2.2.0 : Sun 27 Jan 2013 - 06:28:07 EST