bug#19188: point adjustemnt moves *into* invisible text

[Stefan Monnier]

tags 19188 notabug
thanks

>    However point is not were the cursor is
>      M-: (point) => 3
> The problem is in the code that is supposed to move point *out* of an
> invisible region, does the opposite when moving backward places point
> on the first character after an invisible region.  It moves to the
> beginning of the preceding invisible region.

That is a common misunderstanding.  The fact that point is equal to
3 means that point is *between* character 2 and character 3.  So it's not
*inside* an invisible text, but is right at the boundary.

The position 5 (i.e. between character 4 and character 5) is at the
other end of the boundary.

The reason why Emacs decided to put point at position 3 rather than
leave it at position 5 is because the boundary at position 3 is "less
invisible" than the boundary at position 5.
You can check it with

  M-: (list (get-pos-property 3 'invisible) (get-pos-property 5 'invisible)) RET

This is because text-properties by default are front-non-sticky and
rear-sticky, so if point is at position 5 and you type a character, that
character will inherit the invisible property, whereas if you're at
position 3 and you type a character this character will not inherit the
invisible property.

If you want point to be at position 5 rather than position 3, then you
need to change the front/rear-stickiness of this invisible
property accordingly.

> When point adjustment is disabled (non-nil disable-point-adjustment or
> global-disable-point-adjustment) then this does not happen.

I assume you know why ;-)

> It also does not happen when moving forward, e.g. starting at "1"
> C-p C-f places the cursor on "5" *and* point is also 5.

C-p C-f doesn't do it for me (it doesn't even reach the invisible part of the
text), and if I change the recipe to C-f C-f it doesn't work either
(point stays at position 3).

But indeed C-n gets me to position 5, which is wrong (and doing M-: (point)
returns 5 but moves me to position 3, so doing it again returns 3 :-( ).
So we do have a bug here.


        Stefan