Re: [textadept] Textadept needs to play catch-up (But more serious)

From: mitchell <>
Date: Sun, 3 Apr 2011 21:43:27 -0400 (EDT)

Hi, Steve,

On Fri, 1 Apr 2011, steve donovan wrote:

> On Fri, Apr 1, 2011 at 7:22 AM, Brian Schott <> wrote:
>> The next release is going to be awesome! I can't wait!
> Here are things which I think would not add 50,000 lines and could be
> very useful. I've been one of the dozens of people who contributed to
> SciTE (as has Mitchell) and did a fair number of tools, often working
> around a less-than-perfect Lua interface. Here are some of my scripts
> which I would like to adapt to TextAdept:
> - For SciTE, there's a script ctagsdx.lua, which looks for a ctags
> file in the current directory (or the parent) and reads it in; the
> user can then use a shortcut like ctrl- on the current source buffer.
> to go to a tag and alt-. to go back.[1] It parses full Exuberant ctags
> files which embed searchable patterns, so they it isn't so fooled by
> edits. If there are multiple tags (common in C++) it will present a
> drop-down. For TA, we have the further option to open in another view,
> etc.

Adeptsense can read ctags and allow you to jump to them using a filtered
list. It also supports the pattern syntax. Maybe you can just add some key
commands that hook into Adeptsense's ctags store.

> - Spawning interactive processes: if TA could do this, then things
> like debugger support becomes straightforward. With SciTE, I wrote an
> external C module which did the appropriate platform-specific stuff;
> in TA it would be a matter of using pthreads [2] or native Windows
> threads, and use GTK+ async i/o for the communication.
> The whole of scite-debug is built on top of this hundred or so lines
> of C. A fast route would be to implement a GDB interface, using the
> Emacs-mode where the output is more tool-friendly. Then other
> languages can be implemented by making fake GDB interfaces, e.g. my
> lua-gdb which fools Emacs into debugging Lua.[3]

I experimented with a spawn extension[1] some time ago but had some
problems with reading stdout on Win32. I may revisit it sometime this

> - 'Open in Other Instance'. Cool in theory, but it does require
> inter-process communication. On Unix-like systems SciTE does this in a
> really straightforward way with pipes, no special plumbing required.
> On Windows it sends messages, so some platform-specific code is
> required. However, this is a another good candidate for a little
> external C extension, so that the core remains small and uncluttered.
> (An alternative to using communicating processes is teaching TA to
> open multiple windows; naturally there are some serious bookkeeping
> implications. But TA instances are so lightweight that it's sufficient
> to just do IPC)
> For POSIX systems at least, the pipe stuff can be done with plain jane
> Lua I/O. The equivalent exists on Windows, but as usual is more
> complicated.

There is a single-instance patch on the wiki using DBus for Linux. I tried
doing some simple Mutex stuff on Win32 but didn't get too far. Not sure
how to do it on OSX either... Patches are welcome.


Received on Sun 03 Apr 2011 - 21:43:27 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 12:04:56 EST