Hi, Is anybody working on adding automation functionality to TM2 ? I'm currently using TMTOOLS for my personal bundles, but I'd love to have something "official", sharable, and maybe better integrated. I cloned the source base and looking at the code I'm beginning to have a [very] general idea of how it could be implemented. I don't know how TMTOOLS does its magic (sources anywhere?) but something along the lines of the command line "mate" utility could work, maybe just extending its commands beyond just "open"
Thanks for any information. Gualo
On 11 Jul 2013, at 11:25, Eduardo Francos wrote:
Is anybody working on adding automation functionality to TM2 ?
Not something I am aware of.
[…] something along the lines of the command line "mate" utility could work, maybe just extending its commands beyond just "open"
Do you have some specific commands in mind that you would like to see added?
There are of course infinite things that could be exposed, for me personally, I think my number one request ATM is a way to pass compiler errors/warnings to TextMate so that it could show them in the gutter and provide a key binding for next/previous error/warning — of course this could also be used for other stuff than errors and warnings, and I’m sort of thinking it might tie in with “find in folder”, mainly because I’m pretty happy with the UI and ease of navigating between search results, so no need to re-invent that for basically another type of positional results.
Hi, 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, a named or timestamped persistent bookmarks tool that works across documents, a source code tagging and lookup tool (ctags back-end) and finally an annotations tool. The logic of the different functionalities and the HTML based UI requires quite a bit of back-interaction with the editor like calling bundle-defined or ad-hoc dynamically generated commands, setting the cursor position, obtaining information, etc. I'm currently using TMTOOLS to do this type of things, but as you know it is not and may never be compatible with TM2 :-(
error/warning — of course this could also be used for other stuff than errors and warnings, and I’m sort of thinking it might tie in with “find in folder”, mainly because I’m pretty happy with the UI and ease of navigating between search results, so no need
The 'find in folder' UI could indeed be reused elsewhere, by me among others ;-) My bundle includes 4 different browser like interfaces to do just that, and I'd love to be able to somehow send or return the positions list, formatted for the 'find in folder' dialog, and leave the rest of the navigation handling to it. 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
On Jul 15, 2013, at 11:37 PM, Allan Odgaard wrote:
On 11 Jul 2013, at 11:25, Eduardo Francos wrote:
Is anybody working on adding automation functionality to TM2 ?
Not something I am aware of.
[…] something along the lines of the command line "mate" utility could work, maybe just extending its commands beyond just "open"
Do you have some specific commands in mind that you would like to see added?
There are of course infinite things that could be exposed, for me personally, I think my number one request ATM is a way to pass compiler errors/warnings to TextMate so that it could show them in the gutter and provide a key binding for next/previous error/warning — of course this could also be used for other stuff than errors and warnings, and I’m sort of thinking it might tie in with “find in folder”, mainly because I’m pretty happy with the UI and ease of navigating between search results, so no need to re-invent that for basically another type of positional results.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
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.