Re: Editing and formatting characters

[Pablo Saratxaga <pablo mandrakesoft com>]

Kaixo!

On Tue, Nov 14, 2000 at 05:20:41PM -0800, Derek Simkowiak wrote:

> 	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

As formatters won't be displayed, that distinction isn't really that
important for display. It is important however to implement the handling
of the editing. And for that I think the important thing is the same idea
of cell clustering as in Thai: consider the formatter and its associated
char as only one entity, without any possibility to put the cursor 
between them.

Here, there is not really an associated char, but RLE and PDF are associated
eacho other. So I think that for that reason, the cursor could only put
itself on the side of the formatter that is opposed to the other paired
associated formatter, so:

>     [RLE] H E BREW TEX T [HYPHEN] [PDF] 1234
>    ^     ^ ^ ^        ^ ^        ^     ^
>    A     B C D        E F        G     H
 
B and G must not be possible.
A, C, F and H are the ones whe are interested in.
D and E (and all positions in between) are just normal text editing,
out of the scope of this thread.

> 	This is how the markup tags within Microsoft Word (and most other
> English word processors, albeit left to right), and it's quite intuitive.

You are talking about positioning with visual displaying of formatters;
in such case, yes, the cursor must be able to position itself at all
the inter-char positions.

But nothing special need to be done to handle that: if the formatters are
displayed the current editing code is enough I suppose.
So this dicsussion is for when those are *not* displayed. As they are not
displayed, the only way to manipulate somehow is to associate them with
a neighbour char, which implies the cursot can't be put between the formatter
and the associated char.

> 	In this case:
> 
>     [RLE] H [PDF] 1234
>            ^
>            A
> 
> 	...if you hit delete, the H would disappear, but the [RLE] and
> [PDF] would remain:

Ah? That would be *extremely* odd, counter intuitive and not user friendly
at all! Delete is never supposed to delete the previous char, that is what
BackSpace is for.

>     [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

I don't agree.

In mode of invisible formatter, such situation must never happen.
(the impossibility to place the cursor between te formatte and associated
whar guarantees it.)

In visible formatters mode, then they should be treates ad normal chars, that
is hiting Delete key should only delete [PDF] (then the user can insert
a [PDF] char somewhere else). 

-- 
Ki ça vos våye bén,
Pablo Saratxaga

http://www.srtxg.easynet.be/		PGP Key available, key ID: 0x8F0E4975