[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: |
Stefan Monnier |
Subject: |
Re: Adjust point to move it off zero-width characters |
Date: |
Sun, 07 Aug 2011 20:50:23 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>> > + 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