bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

Dmitry Gutov
1. Enable display-line-numbers-mode.
2. Move point to the beginning of some line.
3. Evaluate (posn-x-y (posn-at-point))

=> The value in CAR will be > 0 (to account for the columns taken by
d-l-n-m).

4. Do the same thing on a line that belongs to an overlay. For example,
the overlay in the bug reporting buffer (move point to the line with
"This bug report...").
5. The return value will be like (0 . 180).

The expected behavior: the column should still account for the offset by
the d-l-n-m.

I'd really like to see this fixed in Emacs, it makes positioning of
popups unpredictable when display-line-numbers-mode is enabled:
https://github.com/company-mode/company-quickhelp/issues/106



Reply | Threaded
Open this post in threaded view
|

bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

Eli Zaretskii
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 25 Jun 2020 16:29:21 +0300
>
> 1. Enable display-line-numbers-mode.
> 2. Move point to the beginning of some line.
> 3. Evaluate (posn-x-y (posn-at-point))
>
> => The value in CAR will be > 0 (to account for the columns taken by
> d-l-n-m).
>
> 4. Do the same thing on a line that belongs to an overlay. For example,
> the overlay in the bug reporting buffer (move point to the line with
> "This bug report...").
> 5. The return value will be like (0 . 180).

The bug-report buffer doesn't use an overlay, it uses a display
property string.  Do you have an example with an overlay where this
problem happens, or is it limited to display strings?



Reply | Threaded
Open this post in threaded view
|

bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

Dmitry Gutov
On 25.06.2020 20:42, Eli Zaretskii wrote:
> The bug-report buffer doesn't use an overlay, it uses a display
> property string.  Do you have an example with an overlay where this
> problem happens, or is it limited to display strings?

Good question. It doesn't happen with just any overlay, so here's a full
example:

1. Create an overlay, e.g.

(setq o (make-overlay (point) (1+ (point))))

The buffer contents seem unimportant. It can cover some text, or a
newline, or multiple lines. But it should start at bol (if it doesn't
start at bol, the result will also be unexpected, but not 0).

So the buffer text can just be a bunch of newlines, for the sake of this
example.

2. Put a display string on it that (important!) ends with a newline:

(overlay-put o 'display "abc\ndef\n")

3. Eval

(car (posn-x-y (posn-at-point (overlay-start o))))

It will evaluate to 0 even if display-line-numbers-mode is enabled.



Reply | Threaded
Open this post in threaded view
|

bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

Eli Zaretskii
> Cc: [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 25 Jun 2020 21:35:59 +0300
>
> 2. Put a display string on it that (important!) ends with a newline:
>
> (overlay-put o 'display "abc\ndef\n")
>
> 3. Eval
>
> (car (posn-x-y (posn-at-point (overlay-start o))))
>
> It will evaluate to 0 even if display-line-numbers-mode is enabled.

So this _is_ triggered only by display strings.  Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#42039: 27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode

Eli Zaretskii
In reply to this post by Dmitry Gutov
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 25 Jun 2020 16:29:21 +0300
>
> 1. Enable display-line-numbers-mode.
> 2. Move point to the beginning of some line.
> 3. Evaluate (posn-x-y (posn-at-point))
>
> => The value in CAR will be > 0 (to account for the columns taken by
> d-l-n-m).
>
> 4. Do the same thing on a line that belongs to an overlay. For example,
> the overlay in the bug reporting buffer (move point to the line with
> "This bug report...").
> 5. The return value will be like (0 . 180).
>
> The expected behavior: the column should still account for the offset by
> the d-l-n-m.
>
> I'd really like to see this fixed in Emacs, it makes positioning of
> popups unpredictable when display-line-numbers-mode is enabled:
> https://github.com/company-mode/company-quickhelp/issues/106

Your wish has been granted: this should now be fixed on the emacs-27
branch.