[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adjust point to move it off zero-width characters
From: |
Eli Zaretskii |
Subject: |
Re: Adjust point to move it off zero-width characters |
Date: |
Mon, 08 Aug 2011 06:02:56 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sun, 07 Aug 2011 20:50:23 -0400
>
> So you're saying that it should always be fused with the next char?
> Then my question becomes:
> Is there a reason to fuse it with the next char rather than fusing
> it with the preceding char? ;-)
There is a good reason for the directional control characters, see
below. For others, I think it's immaterial.
> > There's one other complication: to _really_ DTRT, there's one
> > directional control that needs to be fused with the preceding
> > character: the PDF, u+202c (POP DIRECTIONAL FORMATTING). That's
>
> That was my impression as well: the fusing should not always be done in
> the same direction.
> I'd still like to hear your reasoning about why it only depends on the
> particular zero-width char and not on the surrounding context.
I explained that, for the directional control characters: the need to
be able to interactively copy/paste text and be sure it displays the
same. The directional controls affect the _following_ characters. If
we "fuse" LRM/RLM/LRO/RLO/LRE/RLE with the previous character, they
can only be copy/pasted with the text that precedes them, where they
have no effect whatsoever. That's why PDF is different: it affects
the characters that precede it.
> > But hard-coding the special treatment of PDF on the C level sounds too
> > kludgey, no?
>
> Without knowing why you think LRM needs to be fused one way and PDF in
> the other way, it's hard to know for sure whether hard-coding them is
> a kludge, but yes: it doe sound likely to be so.
So what are the alternatives? Another char-table?