At 11:38 PM 4/23/02 -0400, Havoc Pennington wrote: >I would postulate: > - it should work just like the Delete key on the target platform > >So if on Windows XP or GTK+, the delete key blows away the whole >combined cluster, then undo should also treat them as a unit. If >not, then undo should not.
Thanks for the suggestion. The "undo == platform-specific backspace" principle is admirably simple and easy to understand. However... 1. I'm not sure this principle helps. -------------------------------------- We currently control the semantics of the delete and backspace keys in XP code. (In fact, that's what we're debating on the selections thread, IIRC.) How would we fall back to some platform-specific notion of delete semantics here? More to the point: why should we? I *like* the idea that you don't necessarily have to know what platform you're on in order to type "properly" in AbiWord. That way, we're defining the "word processor" semantics of typing large amounts of text. I'm leery of letting that user experience vary on a platform-specific basis. After all, it's not like MSWord confines their user experience to what the RichEdit32 control supports. ;-) 2. I'm not sure it's right. ---------------------------- Given the ways Jeff wound up tuning our existing Undo coalescing behaviors, I'm not at all convinced that Backspace and Undo should always have the exact same semantics. It may sound good in theory, but you really have to see how it feels in real life. For example, one way to transform a fairly convenient infinite undo feature into a major headache is to turn off all of Jeff's change-record coalescing tweaks and *force* you to march back through every individual character you typed. Trust me, it's miserable. Jeff never was totally happy with certain subtle details of the final result, but the net effect is much, much better than no coalescing at all. 3. My half-baked intuition. ---------------------------- As I tried to suggest elsewhere in this thread, I have a general intuition that, if anything, we may want undo to glob at a *less* granular level than selections. Of course, that would in turn depend on how granular the selections are, which is why I tried to lay out some specific screw cases from the W3C document Karl found for us: http://www.abisource.com/mailinglists/abiword-dev/02/Apr/0721.html The nice thing about screw cases is they allow everyone to understand how various proposed rules actually work in practice. 4. My half-baked idea of where Andrew's coming from. ----------------------------------------------------- For the sake of completeness, I should mention that Andrew's intuition seems to be tugging him in both directions: http://www.abisource.com/mailinglists/abiword-dev/02/Apr/0730.html For example A2, he'd have: - three keystrokes (one a deadkey) - two characters inserted - two backspaceable, selectable characters - two undo operations For example A3, he'd have: - nine romanji keystrokes (in the IME) - three kangi characters inserted (as a single insert) - three backspace-able, selectable characters - one undo operation Whereas for example A4, he'd have: - five keystrokes - six characters inserted (in five steps) - six backspaceable, selectable characters - five undo operations Or at least I think that's what he means. As anyone familiar with the EV_Keyboard <--> EditMethod codepath knows, the notion of a "user keypress" is kept deliberately hidden from the undo mechanism. The piece table just cares that one or more characters got added, deleted, or formatted at a given offset in the document. So far, these examples all sound consistent with my intuition. Yet later in the same post, when it comes to Vietnamese -- he doesn't discuss the Tamil example -- well, I get lost. I think in this case he wants coarser selections, and finer undo. 5. Where Andrew and I get confused? ------------------------------------ I *think* the net effect is that due to a historical artifact, Andrew's notion of "keystrokes" blurs into the mechanics of the actual characters encoded. Call me incredibly naive, but I'm concerned about a user experience which makes cases A2 and A5 look and feel the same for selection purposes -- presuming we go with stacked or cluster boundaries -- but different for undo purposes. In short, in both cases, as far as the user's concerned, isn't the simplest mental model that they just have two kinds of keystrokes: - ones that directly add characters, and - ones that decorate other characters? The net effect is that they may have to type some "extra" keystrokes to assemble the exact character glyphs they want. However, it's not at all clear why the undo semantics for A2 and A5 should thus be any different. Why should an AbiWord user's mental model have to reflect distinctions such as: - deadkeys, - precombined characters, and - combining characters? Is there a user-visible difference worth capturing here -- for example, how it feels to type (or select) each of the examples? If so, what is it, and how does it work? Or are we just creating a user experience that mirrors the underlying mechanics of the character encoding? If so, that may be easier to program, but it feels we've gotten the design backwards. Where feasible, I'd rather have us paper over any lingering encoding artifacts in favor of a consistent typing and editing experience. But then again, I've never typed in most of the languages in question, so what do I know? Paul
