Re: Editing and formatting characters

[Owen Taylor <otaylor redhat com>]

Derek Simkowiak <dereks realloc net> writes:

> ->    HEBREW TEXT [HYPHEN] [RLM] 1234
> ->                        ^     ^
> ->                        A     B
> [...]
> -> I think the correct cursor position is at B - that is, the mark should
> -> be associated with the logically-preceding character.
> 
> 	Question: Why does the 'B' position correspond to the
> "logically-preceding character"?  It would seem to me that 'A' would be
> logically preceding...?

What I am saying is that by putting the cursor position at B, we group
the RLM with the preceding char (HYPHEN), not the following char (1).
 
> ->    [RLE] HEBREW TEXT [HYPHEN] [PDF] 1234
> ->                                    ^
> ->                                    B
> -> 
> -> Again the cursor cursor position should be at B, but when we delete at
> -> B, we don't want to simply delete the PDF, we instead want to delete
> -> the HYPHEN and leave the [PDF]. Then when we get to:
> ->  
> ->    [RLE] H [PDF] 1234
> ->                 ^
> ->                 B
> -> 
> -> Hitting delete would then delete PDF, H and RLE.
> 
> 	I didn't quite understand your first example, but for this second
> example, I would argue that the cursor position should be at 'A', not 'B':
> 
>     [RLE] HEBREW TEXT [HYPHEN] [PDF] 1234
>                               ^     ^
>                               A     B
> 
> 	This is how the markup tags within Microsoft Word (and most other
> English word processors, albeit left to right), and it's quite intuitive.

Symmetry says that you don't remove any fundemental problems by
switching the cursor from A to B, you just switch them from the end of
the embedding group to the beginning of the embedding group.  That is,
if we put the cursor at A, then hitting forward-delete before the
[RLE] has to delete the H and leave the [RLE] untouched.

However, it is possible that this is more intuitive, and does in fact
correspond not only to what word processors do, but also to the way
marks function in the new GtkText widget.

So, I do like the idea that insertions happen before the
paired-formatting character. Does this mean that they also should
happen before non-paired formatting characters? I'm not sure.

The argument for is that in the case of:
 
  HEBREW TEXT [HYPHEN] [RLM] 1234

The user probably thinks of this as a region of strong-right-to-left
extending from the hebrew text past the HYPHEN, so another neutral
character inserted after the HYPHEN would naturally extend this region.

Tenatively, I think you've convinced me that invisible formatting
characters should be associated with the character after.

However, I'd be interesting in hearing from speakers of RTL languages
- I assume that there must be existing practice in this area.

> 	By putting the cursor at 'A', we don't need any special-case
> delete rules for when the cursor is right next to a [PDF].  Hitting
> delete would delete [HYPHEN], just as one would expect and just like
> any other character.  New characters would be inserted between the
> [RLE] and [PDF].

> 	In this case:
> 
>     [RLE] H [PDF] 1234
>            ^
>            A
> 
> 	...if you hit delete, the H would disappear, but the [RLE] and
> [PDF] would remain:
> 
>     [RLE] [PDF] 1234
>          ^
>          A
> 
> 	The cursor is now in a special state; if you enter a new
> character, it would be between the [RLE] and [PDF], but if you hit delete,
> both of them would disappear (along with the visible character that the
> delete would normally apply to).  Or, if you hit an arrow key, then the
> [RLE]/[PDF] pair would disappear, and the cursor would move to the
> appropriate visible character.  Again, this is modelled on English word
> processors.

This "special state" just isn't possible within the framework of
plain-text.  A PangoLayout object has no idea of a cursor position -
it just draws a paragraph.

A framework building on top of Pango could possibly do it, though I
doubt we'd want to do it for GtkTextView - when you close up a tag to
nothing in GtkTextView, it vanishes immediately.

(Its not impossible to implement this for both directional embedding
and tags - it would be ~100 lines of code.  Though if this is the way
Word works, well, I never figured it out as a user; I was just always
confused by when formatting styles would get saved or not; about the
only way I ever got things to behave was by turning on visible
formatting codes....)

Regards,
                                        Owen