* If you're in a left-aligned RTL paragraph, and press Ctrl+RShift - you get right-alignment. * If you're in a right-aligned (or justified, or centered) RTL paragraph, and press Ctrl+RShift - nothing happens. * If you're in a left-aligned LTR paragraph, and press Ctrl+RShift - you get a direction change to RTL and right-alignment. * If you're in a right-aligned (or justified, or centered) LTR paragraph, and press Ctrl+RShift - you get a direction change to RTL. The possible inconsistency in the above set of responses is in what happens when you start with RTL+Left-alignment or LTR+Right-alignment. Consider the first of these. If you first Ctrl+RShift, then Ctrl+LShift - you may expect to end up in the same state you started in: These are the typical key combinations for switching direction back and forth. In fact, you will have switched the alignment, but gone back to the original direction. It's the same for the other state, when you press Ctrl+LShift, then Ctrl+RShift, losing the right-alignment. I am not sure whether to suggest that these keys never affect alignment. But I would like to get some thoughts on whether that's a good idea or not.
If we were to comprehensively resolve bug 131192, this would probably be resolved, since we would need to define the intended behavior of these keys in all of Left, Right, Start and End. And since most of the time, the user would actually choose to align-start or align-end, then Ctrl+RShift and Ctrl+LShift would naturally keep the conceptual alignment while switching it back and forth between right and left, depending on where the start and end lie.
We discussed the topic in the design meeting. Ctrl+l/r-shift are not effective as long CTL/CJK is not enabled. Otherwise it changes the text direction from RTL to superordinate object setting (might depend on the actual scenario). Latin-only users may argue that shortcuts must not be hard-coded and the commands are available individually (ctrl+shift+a/d for LTR/RTL) so consequently to remove the code. RTL users are however familiar with the shortcut. The expectation is, for LTR text, that pressing ctrl+l-shift a) aligns left and b) keeps/sets the superordinate direction, and ctrl+r-shit a) right aligns and b) changes the text direction to RTL; and vice versa for RTL source. Removing the code might be reasonable after bug 163675 (or bug 131192) about an additional start/end alignment is introduced.
(In reply to Heiko Tietze from comment #2) > We discussed the topic in the design meeting. We (= Heiko and myself) did, but apparently I did not take care to properly phrase my part of the minutes, and so some of Heiko's comment does not reflect what I thought we were saying... First, this bug is not about the hard-coding of the shortcut. That's a separate issue, and if someone opens a bug I'll talk about it there. Now, > RTL users are however familiar with the shortcut. The expectation is, for > LTR text, that pressing ctrl+l-shift a) aligns left and b) keeps/sets the > superordinate direction, and ctrl+r-shit a) right aligns and b) changes the > text direction to RTL; and vice versa for RTL source. Not really... RTL users _certainy_ expect: Ctrl+LShift to change the direction to LTR and Ctrl+RShift to change the direction to RTL this is written in stone. Everyone always expects that. The alignment is where expectations get messy. Typically, when one switches away from LTR, Left-aligned text, one wants to also change the alignment to Right (and vice-versa when starting with RTL Right-aligned text). This is because in the typical case, we want to align text to the _start_ of the paragraph - and since we don't have that possibility, we use either Left or Right alignment as the case may be; and we need to flip the alignment along with the direction. But - sometimes, that's not what we wanted, and we really do mean to keep the alignment we set; and that's the case where current behavior frustrates our intent, by intricating the direction and alignment change. And then there is the case of inconsistency, and the back-and-forth direction switch which effectively discards the choice of alignment. > Removing the code might be reasonable after bug 163675 (or bug 131192) about > an additional start/end alignment is introduced. Not removing the code, but rather - removing the alignment-flipping effect of the direction switch; because in that future - we will longer need this "assist", we will express what we want directly.
Silly of me not to notice that this issue is exactly the same with the direction switch buttons, it's not limited to just the keyboard shortcuts. They too force both Right and Left alignment to one of the two options based on the new paragraph direction.