[TxMt] Re: Automation

[Allan Odgaard]

On 16 Jul 2013, at 14:15, Eduardo Francos wrote:

> It's not just a thing of adding specific commands, but a 
> communications system and API allowing for a better integration and 
> interaction between the editor and its outside, including the bundles.
> My immediate needs come from a bundle I developed, Navigator, that in 
> short provides four navigation related tools: a push/pop position 
> stack tool […]

Though with TextMate being open source, it’s worth considering if the 
features added are “minority features”, e.g. specific to a given 
language or person, in which case doing them as plug-ins / bundles is 
the way to go, or if they are of general use.

For example a push/pop stack is a common request and something that 
should probably be added to TextMate, I’m inclined to say the same 
about some sort of tag-based navigation system (ctags).

Of course it’s not either/or, just saying, a first step might be to 
add the code required directly to TextMate, and then later adding the 
required APIs to allow factoring out things that doesn’t need to be in 
the core, rather than start with the goal of coming up with a flexible 
API.

> […] The 'find in finder' could be defined as "just" another type of 
> output so that the bundle only needs to print the list. This doesn't 
> seem very complicated is it? And it does not depend on an automation 
> system. and
> fits into the current output handling system

That is certainly an option — what I had in mind was allowing piping 
into it via mate, allowing things like:

     grep -nr foo .|mate --parse-find-results

Technically a command could do the same, i.e. pipe to mate ($TM_MATE) 
— this makes me think that instead of setting output option for 
commands and using the exit codes to change it, we could instead have 
$TM_OUTPUT which takes arguments like --html, --search-results, 
--new-window, and reads the content from stdin.