Open Bug 433972 Opened 16 years ago Updated 1 year ago
[Mac] Emacs shortcuts parity: Ctrl-t should switch adjacent characters
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051504 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051504 Minefield/3.0pre In a native Cocoa text view, ctrl-t swaps the positions of the characters on either side of the cursor. Exact reference behavior: - If the cursor is in the middle of a paragraph, the characters on either side of the cursor trade positions. The cursor moves forward one character so that it is after both of the characters it just switched. - If the cursor is at the end of a paragraph, the last two characters trade positions. The cursor stays where it is. - If the cursor is at the beginning of the *first* paragraph in the text view, nothing happens. - If the cursor is at the beginning of any paragraph except the first one in the text view, the character after the cursor trades positions with the invisible newline character before the cursor. The cursor moves such that it is after both the newline and the former first character of the paragraph. Visually, this looks as though the cursor stays in the same place and the first character of the paragraph gets "kicked" back up to the previous paragraph. In all honestly, I find this feature to be useless and kind of offensive, and it'd probably be a pain to implement. But I'm doing emacs shortcut parity bugs this afternoon, so I'm including it for completeness' sake. Reproducible: Always
Not an XBL bug. That said, this is by far the most useful of the emacs shortcuts that are missing on Mac. I use it all the time in emacs itself (to fix typos when I've transposed two letters). Oh, and Nicholas, thank you for the very clear description of the expected behavior!
Assignee: nobody → joshmoz
Status: UNCONFIRMED → NEW
Component: XBL → Widget: Cocoa
Ever confirmed: true
QA Contact: xbl → cocoa
Ahaha, good -- I was hoping someone cared about this for reasons other than picture-straightening compulsiveness.
Component: Widget: Cocoa → XBL
This ticket is very old, but this issue remains in Firefox to this day. Any chance of this getting fixed?
Also, I think this is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1280547
(In reply to echosa from comment #3) > This ticket is very old, but this issue remains in Firefox to this day. Any > chance of this getting fixed? If someone who cares takes the time to write a patch and attach it, there's no reason to not fix this. It's a low priority bug, and there's always a lot of more important/urgent work to do.
Rules 1-3 are correct. Rule 4 is not wrong, but it's not really a special case. It's just rule 1 again. That is, it changes this (where |=cursor and nl=newline char): X nl | Y into this: X Y nl | which swaps the two characters around the cursor, and advances it by one, as per rule 1. (Interestingly, both Emacs and standard Mac text areas do this, but Safari does a no-op in this particular case.) The algorithm, then, is pretty simple: - If the cursor is at start-of-document, then do nothing. - Else if you're at the end of a line (character after cursor is newline or end-of-document), then swap the two previous characters. - Else, swap the two characters on either side of the cursor, and then advance the cursor by one position. I'd add: if the user chooses "Undo" after pressing control-T, the characters are returned to their previous state, and both of the transposed characters (whether visible or newline) are selected.
You need to log in before you can comment on or make changes to this bug.