The Future of the Side Pane/Project Manager

From: mitchell <>
Date: Mon, 8 Mar 2010 22:22:11 -0800 (PST)

The side pane seemed really cool when I originally wrote it for
Textadept. It was this all-purpose container that could hold any kind
of heirarchical data structure. In trying to make it as flexible and
unrestrictive as possible though, the implementation is ugly and
counter-intuitive. Writing browsers is annoying to say the least. I
also found that the more I used ta for my development, the less I used
the pane. I only see two useful cases: buffer browser and file
browser. The file browser can be replaced with dragging and dropping
files from a desktop environment file browser (e.g. nautilus, finder,
windows explorer, etc.) The buffer browser represents a bit of a
challenge (search for discussions about implementing tabs), but I have
a solution proposed later.

As for the other existing browsers: ctags and modules, both can be
replaced. A module could be written to parse and open ctags (does
anyone use this anyway?), for example when a line is double-clicked,
and managing modules can (and, in my opinion, should) be done manually
in the filesystem.

My other initial, ambitious ideas for browsers like a project manager
(which I did write but removed in some versions ago because it was
awful) and some sort of revision control interface are not practical.
Project management interfaces are a hot debate and IDE's receive flack
for them (not to mention ta is NOT an IDE). As for revision control,
stick with TortoiseSVN or the good-ol' command line (mercurial); I
don't know what I was thinking.

I found a really cool idea for filtering a list of files in order to
find and open one quickly -- without knowing the full path (e.g. by
typing just a few characters of a filename, directory, etc.)
implemented in GEdit [1] and Scribes [2]. I wanted to expand on this
idea. What I did was add a 'filteredlist' dialog to my gcocoadialog
project [3] that replicates the filtering functionality. An arbitrary
set of data (with column headers) can be passed to the program, and
each keypress filters what data is displayed. Since ta implements
gcocoadialog in textadept.dialog, a list of open buffers could be
given to this 'filteredlist' and typing part of the buffer name you
want to switch narrows the list quickly. Obviously a disadvantage is
that you cannot see what buffers you have open at a quick glance.
However, having the side pane only for the purpose of being able to
display this list of buffers is overkill.

Also as a proof-of-concept, I have used LuaFileSystem (lfs) to produce
a quick open file filter. It gets files in the current buffer's
directory, ta's current working directory, and any directories
specified in a global variable. I must say I'm very impressed.

That said, I'm strongly considering removing the pane completely in a
future version of ta. I do not wish to have it as a compile option
because I'd have to litter the C code with a bunch of #ifdef's, set a
global Lua variable, and litter init.lua et. al. with some if's in
order to skip load pm functionality -- it's too messy.


Received on Tue 09 Mar 2010 - 01:22:11 EST

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:39:44 EST