The twiddle command (cntrl-T or Text:Convert:Transpose) is most often used with no selection or with two letters selected to reverse the order of two characters either side of an insertion point.
If a bunch of text is selected, twiddle returns the reverse of the char string.
I wonder if it might not be more functional, if words are selected, to return the words reversed, but preserving letter order? i.e.,
"validity and" -> "and validity"
rather than the current "dna ytidilav"
Does anybody get value from the current multi-char reverse string behaviour?
cheers, tim
Timothy Bates wrote:
The twiddle command (cntrl-T or Text:Convert:Transpose) is most often used with no selection or with two letters selected to reverse the order of two characters either side of an insertion point.
If a bunch of text is selected, twiddle returns the reverse of the char string.
I wonder if it might not be more functional, if words are selected, to return the words reversed, but preserving letter order? i.e.,
"validity and" -> "and validity"
rather than the current "dna ytidilav"
Does anybody get value from the current multi-char reverse string behaviour?
Cocoa text fields in general (and TextMate's), have a "transposeWords:" selector, in addition to the "transpose:" selector. You could assign it to any desired [keystroke][1] you like.
On 21. Jul 2007, at 03:11, Jacob Rus wrote:
Timothy Bates wrote:
[...] Does anybody get value from the current multi-char reverse string behaviour?
There actually is a ‘rev’ shell command that does exactly the same. I have used it only for two tasks:
1. Sorting based on suffix rather than prefix 2. Processing text from the right and moving toward the left (e.g. inserting thousand separators)
Though neither of this should be suitable for “live editing”.
You could maybe use it for reversing ASCII drawings, like -~= this =~- or similar ;) But the behavior just seems consistent with the rest…
Cocoa text fields in general (and TextMate's), have a "transposeWords:" selector, in addition to the "transpose:" selector. You could assign it to any desired [keystroke][1] you like.
Actually, I do not implement that one. I did initially, and I used it for when I got RectFill/FillRect wrong (Java, Cocoa, and AmigaOS all either have a RectFill or FillRect call, for Cocoa it’s (NS) RectFill, yet Cocoa also has NSEraseRect (i.e. rect last), so I used to get that wrong a lot, and placing caret between the two (sub) words and transposing fixed it, *except* the NS-prefix (and in Java it’s camelCase, so here I’d have to do two extra case conversions) -- so when some things changed in the code-base, and it got a little complex to fix the transpose words, I didn’t bother with it.
But re-implementing that would likely be more appropriate than changing the ⌃T behavior.
On 21. Jul 2007, at 01:40, Timothy Bates wrote:
[...] Does anybody get value from the current multi-char reverse string behaviour?
I already sort of said no here, but then today I am faced with a possible little/big endian bug in some third-party software which for testing involves reversing several four-letter ASCII strings ;)
-
Allan Odgaard -
Jacob Rus -
Timothy Bates