Re: Adjust point to move it off zero-width characters

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > +	      if (EQ (glyphless_method, Qzero_width))
>> > +		{
>> > +		  SET_PT (PT > BEGV && PT < last_pt ? PT - 1 : PT + 1);
>> > +		  check_glyphless = 1;
>> > +		  check_composition = check_display = check_invisible = 1;
>> > +		}
>> This means that point is placed either after the LRM or before the char
>> preceding the LRM, depending only on the direction of the movement of
>> the last command.  I.e. the LRM gets "fused" with the preceding char.
>> Is there a reason to fuse it with the preceding char rather than fusing
>> it with the next char?
> I think you are right.  I will rework the patch to do that.

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? ;-)
The answer needs to be in the source code's comments.
 
> Actually, there could be a problem here: "C-x =" will tell point is on
> an LRM, which will confuse users, because they see the cursor on the
> following character.

Yes, that's a general problem with point adjustments.

> Do we need to change "C-x =" as well?

Yup.  C-x h already handles compositions, but it should be extended to
show invisible text (and zero-width glyphs) immediately before and
after point.  This is not directly related to your suggestion, tho.

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

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


        Stefan