GNU bug report logs -
#42039
27.0.91; (posn-x-y (posn-at-point)) inconsistent with display-line-numbers-mode
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Thu, 25 Jun 2020 13:30:02 UTC
Severity: normal
Found in version 27.0.91
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42039 in the body.
You can then email your comments to 42039 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Thu, 25 Jun 2020 13:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 25 Jun 2020 13:30:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Thu, 25 Jun 2020 14:19:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 42039 <at> debbugs.gnu.org (full text, mbox):
Sorry,
On 25.06.2020 16:29, Dmitry Gutov wrote:
>
> I'd really like to see this fixed in Emacs, it makes positioning of
^ in Emacs 27
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Thu, 25 Jun 2020 17:44:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 42039 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Thu, 25 Jun 2020 18:37:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 42039 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Thu, 25 Jun 2020 19:15:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 42039 <at> debbugs.gnu.org (full text, mbox):
> Cc: 42039 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Fri, 26 Jun 2020 12:05:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 42039 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Fri, 26 Jun 2020 12:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 42039 <at> debbugs.gnu.org (full text, mbox):
On 26.06.2020 15:04, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> 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.
Thank you.
It's working fine now in the cases I really care about (so we can close
the report), but here's one you seem to have missed:
1. M-x report-emacs-bug.
2. Toggle display-line-numbers-mode on.
3. Move point to the second display string ("If Emacs crashed...").
4. Evaluate (posn-x-y (posn-at-point)).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42039
; Package
emacs
.
(Fri, 26 Jun 2020 13:39:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 42039 <at> debbugs.gnu.org (full text, mbox):
> Cc: 42039 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 26 Jun 2020 15:55:31 +0300
>
> > Your wish has been granted: this should now be fixed on the emacs-27
> > branch.
>
> Thank you.
>
> It's working fine now in the cases I really care about (so we can close
> the report), but here's one you seem to have missed:
>
> 1. M-x report-emacs-bug.
> 2. Toggle display-line-numbers-mode on.
> 3. Move point to the second display string ("If Emacs crashed...").
> 4. Evaluate (posn-x-y (posn-at-point)).
It worked in a previous version of the fix, but then I decided to be
over-cautious...
Fixed.
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
You have taken responsibility.
(Fri, 26 Jun 2020 16:01:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
bug acknowledged by developer.
(Fri, 26 Jun 2020 16:01:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 42039-done <at> debbugs.gnu.org (full text, mbox):
On 26.06.2020 16:37, Eli Zaretskii wrote:
> It worked in a previous version of the fix, but then I decided to be
> over-cautious...
>
> Fixed.
Thanks!
Looking good now.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 25 Jul 2020 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 332 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.