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.