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 On Mac, the ctrl-a (beginning of paragraph), ctrl-e (end of paragraph), and ctrl-k (delete from cursor to end of paragraph) shortcuts all act on lines instead of on paragraphs. I assume this was due to technical limitations in the 1.8 code when these shortcuts debuted in 1.8 (see bug 229473). It's still wrong, though, and now that paragraph-by-paragraph selection (triple-click; bug 16203) has been implemented, I wonder if it's feasible to get these three emacs shortcuts working correctly. Does anyone know this code? Is this possible for Fx 3.0? Reproducible: Always Steps to Reproduce: 1. Type a paragraph that wraps across multiple lines into a text box. 2. Place cursor in the middle of that paragraph. 3. Hit ctrl-a, ctrl-e, or ctrl-k. Actual Results: Cursor goes to beginning of paragraph, cursor goes to end of paragraph, or everything after the cursor disappears, depending on what you hit. Expected Results: Action of cursor/deletion is limited to current line.

Hmm. Interesting. In Emacs, the shortcuts definitely work on lines. You're saying on Mac ctrl-k works across explicit newline characters? So if I type "abc" then a newline, then "def", then put the caret after the 'a' and hit ctl-k all the rest of the stuff goes away? > Does anyone know this code? If editor is involved, probably not so much (though someone should really learn it, or something). If it's just widget code, then maybe. In any case, not an XBL issue. > Is this possible for Fx 3.0? Not really: 3.0 is code-frozen unless something serious enough to respin the builds comes up in final release-candidate testing.

> You're saying on Mac ctrl-k works across explicit newline characters? Naw; I just failed to be as unambiguous as I should have been. What I meant was, Firefox's emacs shortcuts are acting on *display* lines, whereas the native Cocoa emacs shortcuts act on *logical* lines. (I went with "paragraph" to refer to logical lines because that's the term that was used in bug 16203.) Neither Firefox nor TextEdit (for example) will traverse an explicit newline, but Firefox will fail to traverse the wrap boundary, whereas TextExit will act on the entire run of text between newlines. That is to say: Firefox's emacs shortcuts incorrectly consider word wrap boundaries to be the same as explicit newlines. (I don't reckon either of them work exactly like Emacs. But it's been a while since I've used it, so I couldn't say.)

Also, sorry for incorrectly marking this as XBL -- that's what bug 229473 was filed under, so I just copied it. If anyone knows what this should be, I'll correct it (and my other emacs bugs).

Emacs shortcuts also work on logical lines, but emacs will auto-convert display lines to logical lines in auto-fill mode. I wonder whether it would make sense to have a pref for this, at least in wrap="hard" cases where on submit the same conversion will happen... And I think bug 229473 was just misfiled, effectively.

Whether C-a and C-e act on lines in Emacs depends on the configuration and the flavor of Emacs. As for Emacs 23 (which is still being worked on), and that includes the Cocoa CVS build cited here, this particular issue has not been finalized; Emacs has a new soft-wrapping ability where C-a would sensibly jump to the beginning of a visual rather than file line. Pretty much all native software on the Mac uses soft wrapping now, and there are good reasons to do so.

> Pretty much all native software on the Mac uses soft wrapping now, and there are good reasons to do so. That's not what I've seen. For example, TextEdit, Safari, and all (seemingly-)standard multiline text widgets I could find still jumped to the beginning/end of the paragraph, OS X 10.5.6. Same applies to custom widgets like TextMate's. As there's already the cmd-arrow shortcuts to jump to visual line positions, I don't see much point in duplicating behavior and losing functionality for them. (This behavior is supposedly adjustable via a few keybinding config files, anyway)