Previously we would set a mark, mutate the buffer, and then restore selection based on how the mark was moved.
When a mutation was changing the buffer to its existing value (e.g. toggling case of a space character) then the buffer would effectively ignore the mutation, and the mark would not be properly updated, meaning for “toggle case of character” the caret would not be moved forward.
Additionally we previously always moved to the end of a mutation, even if it was done on a user selection. We now only move to the end if the user didn’t select anything (but ran the mutation on an implicitly selected unit, like a word). The “toggle case of word” action is affected by this.
For example selecting a column of numbers and selecting “Add Numbers in Selection” will now always insert the result at a logical position rather than on the defined end points of the selection.
This is generally desired when the indent of a new line does not (necessarily) depend on lines above it, but where we otherwise do want indent corrections, e.g. HTML.
For example in ruby inserting ‘env⇥’, deleting the initially selected letter, and typing B or S, would insert an additional caret (it was actually inserted in the previous step, but not visible since it was overlapping the existing caret).
The API lack proper support for returning the new caret range so we are using a heuristic to figure out which of the returned ranges correspond to our caret. Ideally the API would be updated.
Previously if there was whitespace to the left and right of the caret, the entire sequence of whitespace was given as input to the command. This was not the case for TextMate 1.x so it broke the format commands in the LaTeX bundle (bold, italic, and teletype).
The output will be inserted corresponding to the subsets selected on each line.
If the output has less lines than the column selection then the additional selected lines are cleared.
If the output has more lines than the column selection then the additional output lines are dropped.
It should be safe to assume that clipboard data is valid UTF-8, but I’m seeing crashes related to creating a CFString (from buffer content) after a paste operation, so the assumption might not be valid.
When selecting multiple lines, but not including the newline on the last line of the selection, TextMate still consider it a “full line” and will insert a newline when pasting, unless pasting on an empty line.
Previously the check to see if the line was empty, would not account for a non-empty but selected line, which would effectively be empty since the selected text is deleted before pasting.
We now convert the output to a hex-dump incase it is not valid UTF-8. Ideally we would present the user with a dialog, but for now a hex-dump will do and prevents a potential crash.
Since we now run the shell code directly (via ‘/bin/sh -c «command»’) we no longer source ‘TM_SUPPORT_PATH/lib/bash_init.sh’.
I don’t think any code embedded in snippets rely on things setup by this file, but if they do, I’d prefer we update the snippets to explicitly source the file.
Generally we should always provide a base environment, since the scoped variables are format strings. The filtering scope selector is however optional, and we do not have one when executing commands outside an fi;e/editor context.
