[TxMt] Re: odd pymate output bug

[Bill Bumgarner]

On Nov 1, 2006, at 6:27 PM, Jacob Rus wrote:
> IMO, pymate could use some reworking.  It would be nice to bring it  
> up to using Soryu's nice css, and putting some hyperlinks in  
> tracebacks to the lines with errors, etc.  I am unfortunately not  
> very interested in working on it any time in the near future (like  
> the next couple of months at least), but it might be valuable to  
> have a discussion on this list about the best way to architect a new  
> pymate, and maybe a more general framework for these script runner  
> commands, which are useful in many many languages.

Agreed.  There are three major features that I'd like to have right  
about now:

(1) be able to trigger pymate (scriptmate or whatever the new thing is  
called) to run a sort of "designated driver script" at the root level  
of a project directory.   Specifically:  I'm editing a unit test in my  
testsuite/ subdirectory and I want to hit a single command sequence to  
cause the run-tests.py script (found in the top level "project"  
directory -- top level directory resulting from a 'mate .' at the  
command line) to be executed.

(2) Be able to do (1) such that the path to the file I'm editing is  
passed as an argument to the sub command.  Specifically:  I want to be  
able to run the test I'm current editing.

	(2a) Be able to select some random chunk of text and have it passed  
as arguments to the script from (1).  This would let me type the name  
of a handful of the potentially dozens of tests I want to run and  
invoke them directly.

(3) Allow (1) to be executed even without a file being selected and  
displayed in the editor section of the window+drawer

I also see no particular reason why pymate should be python  
specific.   One could easily imagine that the above mechanism, plus a  
couple of additional features, could be a generically useful way of  
dealing with a collection / hierarchy of files with a Top Level  
processing script of some kind.

Something like:

- bless a top level file as the "mate driver"

- once blessed, (1), (2), and (3) would all execute that driver script  
with the appropriate additional behavior.

- parse the output and hyperlink anything that falls into a standard  
sort of "refers to this file:line:" kind of format.   gcc's output  
seems like the obvious starting point that most people use.

I don't have a surplus of time on my hands, either, but the above  
would greatly accelerate my work and, as such, I might dig up the time  
to work on it.

b.bum