Re: textadept 2.0 ideas/suggestions

From: mitchell <>
Date: Mon, 29 Jun 2009 04:59:02 -0700 (PDT)


> 1.* a lua or c++ implementation to get real-time output from run.execute
> (or at least fork it into another process, so it won't freeze ta)

I believe this was brought up before, but I have yet to find a way to
do so. I'm open to patches!

> 2.* either bring back the project manager, or create a better session
> management implementation

You're welcome to grab it from an earlier ta release if you so desire,
but I'm not sure how stable it is. Define 'better session management'.
I think a lot of people disagree on this one ;)

> 3. ta should remember pm position throughout sessions


> 4. block comments should be available to all lexers (i'm not sure if
> this is already done, but it seems to only works in lua)

Block comments are currently defined in language modules, but can be
defined anywhere really. Take a look at 'modules/lua/commands.lua'.

> 5.* a make target install for ta, (see my Archlinux package to get an
> idea:

The linux install really needs work for portability. I'll work on

> 6.* a LaTeX/TeX module, that allows building and previewing documents
> among other things

I have no experience with such things so a user-written module
contribution would be best.

> 7. documentation files/links should be accessible from the main menu

Good idea! I hadn't thought about this. I'll have to find a platform
independent way of doing this though.

> 8.* maybe move user's init file (~/.ta_modules) to a better location
> (e.g. ~/.textadept/init.lua) and make it easier for users to overwrite
> global settings (i.e. key commands, menu, mime types, build/go commands,
> etc..)

I like this idea.

> 9. adding new lexers and altering existing ones shouldn't require root
> access, lexer.lua and menu.lua should be able to read lexers from user's
> home directory as well (e.g. ~/.textadept/lexers/?.lua), override them
> if necessary

In principle this is a good idea; I will consider it.

> 10.* pm interface should be available to modules, so you can, for
> example, load special browsers per module

How is this not possible? What implementation are you looking for?

Thanks for your suggestions!
Received on Mon 29 Jun 2009 - 07:59:02 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:38:15 EST