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

From: mitchell <c....at.caladbolg.net>
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 <briancsch....at.gmail.com> 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
month.

>
> - '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.

mitchell

[1]: http://groups.google.com/group/textadept/browse_thread/thread/f364d45ba281dfd3/e76353c276ba24f2
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