bug#19200: Point adjustemnt moves *into* invisible text

[Stefan Monnier]

>> Are you sure you're hitting exactly this same bug?
>> IOW can you circumvent the bug by adding M-: (point) RET ?
> First question: no, I'm not, it's similar, but maybe not exactly the
> same.  But second question: yes!

OK, if M-: (point) RET "fixes" the problem, then it's probably hitting
the same bug.

> The issue in Magit seems to be dependent to the setting
> goal-column -> 0.

I don't think that's very surprising: if goal-column is non-zero, then
point doesn't end in an invisible region since you only have invisible text
in column 0, IIUC.

> And I found that when I replace

>   (if (zerop col)
>       (beginning-of-line)
>     (move-to-column col))
>
> in the definition of line-move-to-column (at the beginning) with just
>
>   (move-to-column col)
>
> the Magit issue is fixed.  I have no clue why, however.

move-to-column moves forward from BOL, whereas beginning-of-line moves
only backward, so the two probably end up at opposite ends of the
invisible region.

BTW, regardless of fixing this bug, I think you have a problem: if the
exact position within the invisible text is so important that it can end up
selecting a different line, then fixing bug#19200 won't do you much
good: there are many cases where point-adjustment won't do what you want
(e.g. it won't move point at all, even though it's somewhere in the
middle of the invisible region) and hence it will end up "at the wrong place".

The way point-adjustment is defined is too conservative for that.
So I suggest you try and make you code more robust w.r.t the position of
point within an invisible region in any case.


        Stefan