bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

[Lennart Borgman]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

>>>>>>>>>>>>>>>>>>>>
posn-at-point reports bad (X . Y) when on a 'displa part of an invisible
overlay.

This makes line-move-visual behave strange. (A workaround for this could
be to step back one char in line-move-visual, but this is of course not
the correct fix.)
<<<<<<<<<<<<<<<<<<<<

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/u/090801/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-08-01
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'


PS: Is it by intention that the bug mail message now includes the
information for the submitter? It did not work that way before. I have
left that information in the message above (but marked my real
message) so you can see what I mean. Perhaps this has something to do
with that I am using w32 where the message is copied to clipboard?

bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

[Lennart Borgman]

Some more thoughts: There seem to be several small inconsistencies
around here. I guess the intended behaviour is

For invisible overlays (and dito buffer text, but it is overlays I
have been looking at now):

- The "stop" point on the display string property should be the first
character. That seems to be the case now, but often the first char is
missed/jumped over, see below.

- When calling forward-char or backward char they should stop there.
Forward char often does that, but not always. Backward char does not
seem to do that.

- Similar problem with vertical-motion. It often misses the first char
and goes to the column after the display string instead.

bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

[Lennart Borgman]

Forgot to say that this seems to be some problem with the interaction
with the display engine and display update. When you try to debug this
the problem is sometimes gone.


On Sun, Aug 9, 2009 at 9:38 PM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:
> Some more thoughts: There seem to be several small inconsistencies
> around here. I guess the intended behaviour is
>
> For invisible overlays (and dito buffer text, but it is overlays I
> have been looking at now):
>
> - The "stop" point on the display string property should be the first
> character. That seems to be the case now, but often the first char is
> missed/jumped over, see below.
>
> - When calling forward-char or backward char they should stop there.
> Forward char often does that, but not always. Backward char does not
> seem to do that.
>
> - Similar problem with vertical-motion. It often misses the first char
> and goes to the column after the display string instead.
>

bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

[Chong Yidong]

> posn-at-point reports bad (X . Y) when on a 'displa part of an invisible
> overlay.
>
> This makes line-move-visual behave strange. (A workaround for this could
> be to step back one char in line-move-visual, but this is of course not
> the correct fix.)

Please provide a precise, step-by-step recipe to reproduce this,
starting with `emacs -Q'.

bug#4094: 23.1.50; posn-at-point gets upset by overlays with 'invisible and 'display

[Glenn Morris]

Closed due to lack of response.

Chong Yidong wrote:

> Please provide a precise, step-by-step recipe to reproduce this,
> starting with `emacs -Q'.