Hello :)
When writing bundles, the current environment contains the variables TM_INPUT_START_(LINE|LINE_INDEX) to contain the corresponding data from the beginning of the selection. If I need to have a look at the text at the beginning and end of the selection I would use these variables for the start and TM_LINE_(NUMBER|INDEX) for the end.
Fine - as long as I just select downwards (placing the selection start-point to the left and/or higher than the selection end-point. If I do an upward selection this will leave me with no information about the (lower) end-point at all as the current position equals the start position.
Is it possible to have some additional TM_INPUT_END_(LINE|INDEX) variables to definitely catch the end-point data no matter what kind of selection (downward/upward) has been used? It would also be convenient having both the start-/end-point line content (not only the current) as an environment setting which saves reading the whole document for one of two lines again.
thanks so far Wolfgang
On Feb 4, 2007, at 4:24 AM, Wolfgang Machert wrote:
Is it possible to have some additional TM_INPUT_END_(LINE|INDEX) variables to definitely catch the end-point data no matter what kind of selection (downward/upward) has been used?
I suppose having TM_SELECTED_TEXT would allow you to determine the end of the selection. Not ideal, but possible probably.
It would also be convenient having both the start-/end-point line content (not only the current) as an environment setting which saves reading the whole document for one of two lines again.
I would suggest filing these as feature requests with the ticket system: http://macromates.com/ticket/ Make sure to provide practical use-cases that show the need for these.
thanks so far Wolfgang
Haris
On 04.02.2007, at 14:36, Charilaos Skiadas wrote:
Is it possible to have some additional TM_INPUT_END_(LINE|INDEX) variables to definitely catch the end-point data no matter what kind of selection (downward/upward) has been used?
I suppose having TM_SELECTED_TEXT would allow you to determine the end of the selection. Not ideal, but possible probably.
Although you are right at this point (and the effort doing so is indeed pretty zero - using stdin for larger selections seems like the proper approach) it doesn't seem... appropriate... to me to recalculate some data that is already there - at least in TextMate. Though if I'm the only one having the need for this it might be simpler just calculating the endpoint.
It would also be convenient having both the start-/end-point line content (not only the current) as an environment setting which saves reading the whole document for one of two lines again.
I would suggest filing these as feature requests with the ticket system: http://macromates.com/ticket/ Make sure to provide practical use-cases that show the need for these.
My intention is to check the first character left of the selection and the first character right of the selection on alphanumeric-ness. AsciiDoc, for which I'm writing a bundle at the moment, differentiates between normal and inline formating (i.e. normal *bold*, or inline **bold**nes) - and I'd like to handle the difference automagically by one single command.
greetings Wolfgang
On Feb 4, 2007, at 9:20 AM, Wolfgang Machert wrote:
On 04.02.2007, at 14:36, Charilaos Skiadas wrote:
Is it possible to have some additional TM_INPUT_END_(LINE|INDEX) variables to definitely catch the end-point data no matter what kind of selection (downward/upward) has been used?
I suppose having TM_SELECTED_TEXT would allow you to determine the end of the selection. Not ideal, but possible probably.
Although you are right at this point (and the effort doing so is indeed pretty zero - using stdin for larger selections seems like the proper approach) it doesn't seem... appropriate... to me to recalculate some data that is already there - at least in TextMate.
Oh I agree, I also would like a lot more ways of telling TM commands what to accept as input and where to output and such, I was just offering a possible workaround until the time that such things get added. Allan is working full-time on the 2.0 release, so if it's not already on his plans for that it might take a while until you see this added, even if you manage to build a case for that.
I've thought many times that it might be nice to have a Ruby library that does these computations once and then we can all reuse them, but I haven't gotten around to writing it yet. I think this is a much more manageable idea, that we as bundle developers could implement without requiring changes in the core TM program. I am envisioning a module that would have a bunch of methods returning line and column numbers for all sorts of things, as well as the text before and after the current selection, the current scope etc. In other words, a module offering even more convenient access to the dynamic environment variables and what they allow us to compute.
Though if I'm the only one having the need for this it might be simpler just calculating the endpoint.
It would also be convenient having both the start-/end-point line content (not only the current) as an environment setting which saves reading the whole document for one of two lines again.
I would suggest filing these as feature requests with the ticket system: http://macromates.com/ticket/ Make sure to provide practical use-cases that show the need for these.
My intention is to check the first character left of the selection and the first character right of the selection on alphanumeric-ness. AsciiDoc, for which I'm writing a bundle at the moment, differentiates between normal and inline formating (i.e. normal *bold*, or inline **bold**nes) - and I'd like to handle the difference automagically by one single command.
Interesting, I wonder if you could somehow utilize the scope system for that, and manage to have a different scope selector for the two cases. That would mean changing your grammar to some extend, and I don't even know if it would be possible then. Once we get dynamic scopes, it might perhaps become possible.
In any case, you only need to read and replace at most the current line, which is still much better than what I've had to do in a lot of my commands, which is read and replace the entire document ;).
greetings Wolfgang
Haris
-
Charilaos Skiadas -
Wolfgang Machert