11 Jul
2013
11 Jul
'13
3:25 a.m.
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
15 Jul
15 Jul
3:37 p.m.
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.
16 Jul
16 Jul
6:15 a.m.
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(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
29 Jul
29 Jul
1:44 a.m.
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.
2971
days inactive
2989
days old
3 comments
2 participants
participants (2)
-
Allan Odgaard -
Eduardo Francos