GNU bug report logs - #54800
28.1; calc: Cursor positioned at weird position in calc stack

Previous Next

Package: emacs;

Reported by: Christoph Arenz <tiga.arenz <at> web.de>

Date: Fri, 8 Apr 2022 19:45:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.1

Done: Eli Zaretskii <eliz <at> gnu.org>

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 54800 in the body.
You can then email your comments to 54800 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Fri, 08 Apr 2022 19:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Arenz <tiga.arenz <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 08 Apr 2022 19:45:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; calc: Cursor positioned at weird position in calc stack
Date: Fri, 8 Apr 2022 21:44:38 +0200
[Message part 1 (text/plain, inline)]
When the content of the calc stack inclusive top-of-stack symbol `.'
gets larger in height than the calc window, the cursor is positioned at
a weird position in the upper half of the stack window. When
line-numbering is on, the cursor is positioned at the beginning of the
line at the line number. Calling `calc-realign' does not change the
cursor postion.

How to reproduce:
1. emacs -Q
2. C-x * * (to start calc)
3. enter a number and RET
4. repeat No. 3 until the stacks grows and the symptom appears

Expected behavior for the cursor is to be placed on the `.' symbol,
representing the top of the stack.

5. After pressing `o' [calc-realign], the expected behavior would also
be for the cursor to be positioned at the top of the calc stack.

Debugging the function calc-align-stack-window with edebug, the symptom
goes away when placing a breakpoint at the line
(calc-cursor-stack-index 0) just after the set-window-start call, and
then continuing from there.

The following patch fixes the problem for me, but I do not fully
understand the NOFORCE option of the set-window-start function.

Thanks, Christoph

1 file changed, 1 insertion(+), 1 deletion(-)
lisp/calc/calc.el | 2 +-

modified   lisp/calc/calc.el
@@ -1816,7 +1816,7 @@ calc-align-stack-window
           (progn
         (calc-cursor-stack-index 0)
         (vertical-motion (- 2 (window-height win)))
-        (set-window-start win (point)))))
+        (set-window-start win (point) 'noforce))))
     (calc-cursor-stack-index 0)
     (if (looking-at " *\\.$")
         (goto-char (1- (match-end 0)))))


In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30,
cairo version 1.15.10)
of 2022-04-05 built on M92p
Repository revision: 5a223c7f2ef4c31abbd46367b6ea83cd19d30aa7
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.6 LTS

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
value of $LC_MONETARY: de_DE.UTF-8
value of $LC_NUMERIC: de_DE.UTF-8
value of $LC_TIME: de_DE.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix

[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Sat, 09 Apr 2022 07:35:02 GMT) Full text and rfc822 format available.

Message #8 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Arenz <tiga.arenz <at> web.de>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1;
 calc: Cursor positioned at weird position in calc stack
Date: Sat, 09 Apr 2022 10:34:44 +0300
> Date: Fri, 8 Apr 2022 21:44:38 +0200
> From: Christoph Arenz <tiga.arenz <at> web.de>
> 
> When the content of the calc stack inclusive top-of-stack symbol `.' 
> gets larger in height than the calc window, the cursor is positioned at 
> a weird position in the upper half of the stack window. When 
> line-numbering is on, the cursor is positioned at the beginning of the 
> line at the line number. Calling `calc-realign' does not change the 
> cursor postion. 
> 
> How to reproduce: 
> 1. emacs -Q 
> 2. C-x * * (to start calc) 
> 3. enter a number and RET 
> 4. repeat No. 3 until the stacks grows and the symptom appears 
> 
> Expected behavior for the cursor is to be placed on the `.' symbol, 
> representing the top of the stack. 
> 
> 5. After pressing `o' [calc-realign], the expected behavior would also 
> be for the cursor to be positioned at the top of the calc stack. 
> 
> Debugging the function calc-align-stack-window with edebug, the symptom 
> goes away when placing a breakpoint at the line 
> (calc-cursor-stack-index 0) just after the set-window-start call, and 
> then continuing from there. 
> 
> The following patch fixes the problem for me, but I do not fully 
> understand the NOFORCE option of the set-window-start function. 

Thanks, but I think using NOFORCE is not the best solution here,
because that causes Emacs to recenter the stack window, thus showing
fewer stack entries than possible.

I think the bug is actually off-by-one error, because the
vertical-motion call doesn't take the header-line into account.  So I
suggest the following patch instead, please see if it solves the
problem:

diff --git a/lisp/calc/calc.el b/lisp/calc/calc.el
index 81677d7..900940d 100644
--- a/lisp/calc/calc.el
+++ b/lisp/calc/calc.el
@@ -1815,8 +1815,8 @@ calc-align-stack-window
 	  (if win
 	      (progn
 		(calc-cursor-stack-index 0)
-		(vertical-motion (- 2 (window-height win)))
-		(set-window-start win (point)))))
+		(vertical-motion (- 3 (window-height win)))
+		(set-window-start win (point) 'noforce))))
 	(calc-cursor-stack-index 0)
 	(if (looking-at " *\\.$")
 	    (goto-char (1- (match-end 0)))))




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 09 Apr 2022 10:20:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Sat, 09 Apr 2022 12:32:02 GMT) Full text and rfc822 format available.

Message #13 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Sat, 9 Apr 2022 14:31:06 +0200
On 09.04.22 09:34, Eli Zaretskii wrote:
>> Date: Fri, 8 Apr 2022 21:44:38 +0200
>> From: Christoph Arenz <tiga.arenz <at> web.de>
>>
>> When the content of the calc stack inclusive top-of-stack symbol `.'
>> gets larger in height than the calc window, the cursor is positioned at
>> a weird position in the upper half of the stack window. When
>> line-numbering is on, the cursor is positioned at the beginning of the
>> line at the line number. Calling `calc-realign' does not change the
>> cursor postion.
>>
>> How to reproduce:
>> 1. emacs -Q
>> 2. C-x * * (to start calc)
>> 3. enter a number and RET
>> 4. repeat No. 3 until the stacks grows and the symptom appears
>>
>> Expected behavior for the cursor is to be placed on the `.' symbol,
>> representing the top of the stack.
>>
>> 5. After pressing `o' [calc-realign], the expected behavior would also
>> be for the cursor to be positioned at the top of the calc stack.
>>
>> Debugging the function calc-align-stack-window with edebug, the symptom
>> goes away when placing a breakpoint at the line
>> (calc-cursor-stack-index 0) just after the set-window-start call, and
>> then continuing from there.
>>
>> The following patch fixes the problem for me, but I do not fully
>> understand the NOFORCE option of the set-window-start function.
> Thanks, but I think using NOFORCE is not the best solution here,
> because that causes Emacs to recenter the stack window, thus showing
> fewer stack entries than possible.
>
> I think the bug is actually off-by-one error, because the
> vertical-motion call doesn't take the header-line into account.  So I
> suggest the following patch instead, please see if it solves the
> problem:

Your patch solves the problem and shows maximum content of the stack
in the window.
Note that it still contains the NOFORCE while the off-by-one fix also
works without it.

> diff --git a/lisp/calc/calc.el b/lisp/calc/calc.el
> index 81677d7..900940d 100644
> --- a/lisp/calc/calc.el
> +++ b/lisp/calc/calc.el
> @@ -1815,8 +1815,8 @@ calc-align-stack-window
>   	  (if win
>   	      (progn
>   		(calc-cursor-stack-index 0)
> -		(vertical-motion (- 2 (window-height win)))
> -		(set-window-start win (point)))))
> +		(vertical-motion (- 3 (window-height win)))
> +		(set-window-start win (point) 'noforce))))
>   	(calc-cursor-stack-index 0)
>   	(if (looking-at " *\\.$")
>   	    (goto-char (1- (match-end 0)))))




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 09 Apr 2022 13:33:02 GMT) Full text and rfc822 format available.

Notification sent to Christoph Arenz <tiga.arenz <at> web.de>:
bug acknowledged by developer. (Sat, 09 Apr 2022 13:33:02 GMT) Full text and rfc822 format available.

Message #18 received at 54800-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Arenz <tiga.arenz <at> web.de>
Cc: 54800-done <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Sat, 09 Apr 2022 16:32:15 +0300
> Date: Sat, 9 Apr 2022 14:31:06 +0200
> Cc: 54800 <at> debbugs.gnu.org
> From: Christoph Arenz <tiga.arenz <at> web.de>
> 
> > I think the bug is actually off-by-one error, because the
> > vertical-motion call doesn't take the header-line into account.  So I
> > suggest the following patch instead, please see if it solves the
> > problem:
> 
> Your patch solves the problem and shows maximum content of the stack
> in the window.

Thanks, I installed the fix on the emacs-28 branch.

> Note that it still contains the NOFORCE while the off-by-one fix also
> works without it.

Right, I removed it before committing.  Thanks for pointing that out.

And with that, I'm closing this bug report.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Mon, 11 Apr 2022 10:26:01 GMT) Full text and rfc822 format available.

Message #21 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Mon, 11 Apr 2022 12:25:24 +0200
On 09.04.22 15:32, Eli Zaretskii wrote:
>> Date: Sat, 9 Apr 2022 14:31:06 +0200
>> Cc: 54800 <at> debbugs.gnu.org
>> From: Christoph Arenz <tiga.arenz <at> web.de>
>>
>>> I think the bug is actually off-by-one error, because the
>>> vertical-motion call doesn't take the header-line into account.  So I
>>> suggest the following patch instead, please see if it solves the
>>> problem:
>> Your patch solves the problem and shows maximum content of the stack
>> in the window.
> Thanks, I installed the fix on the emacs-28 branch.
>
I noticed that while the patch fixes the problem in most cases,
depending on the height of the calc stack window, there can be the case
that the cursor is not positioned on the top-of-stack symbol `.' but one
line
above, at the beginning of the line with the first stack entry.

This can be changed by using the number 4 instead of 3 in the patch.
Not sure if this is the best fix.

(vertical-motion (- 4 (window-height win)))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Mon, 11 Apr 2022 11:28:02 GMT) Full text and rfc822 format available.

Message #24 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Arenz <tiga.arenz <at> web.de>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Mon, 11 Apr 2022 14:27:35 +0300
> Date: Mon, 11 Apr 2022 12:25:24 +0200
> Cc: 54800 <at> debbugs.gnu.org
> From: Christoph Arenz <tiga.arenz <at> web.de>
> 
> On 09.04.22 15:32, Eli Zaretskii wrote:
> >> Date: Sat, 9 Apr 2022 14:31:06 +0200
> >> Cc: 54800 <at> debbugs.gnu.org
> >> From: Christoph Arenz <tiga.arenz <at> web.de>
> >>
> >>> I think the bug is actually off-by-one error, because the
> >>> vertical-motion call doesn't take the header-line into account.  So I
> >>> suggest the following patch instead, please see if it solves the
> >>> problem:
> >> Your patch solves the problem and shows maximum content of the stack
> >> in the window.
> > Thanks, I installed the fix on the emacs-28 branch.
> >
> I noticed that while the patch fixes the problem in most cases,
> depending on the height of the calc stack window, there can be the case
> that the cursor is not positioned on the top-of-stack symbol `.' but one
> line
> above, at the beginning of the line with the first stack entry.
> 
> This can be changed by using the number 4 instead of 3 in the patch.
> Not sure if this is the best fix.
> 
> (vertical-motion (- 4 (window-height win)))

Can you show a reproducible recipe starting from "emacs -Q", so I
could investigate?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Mon, 11 Apr 2022 11:46:02 GMT) Full text and rfc822 format available.

Message #27 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: tiga.arenz <at> web.de
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1;
 calc: Cursor positioned at weird position in calc stack
Date: Mon, 11 Apr 2022 14:45:56 +0300
> Date: Mon, 11 Apr 2022 14:27:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 54800 <at> debbugs.gnu.org
> 
> > I noticed that while the patch fixes the problem in most cases,
> > depending on the height of the calc stack window, there can be the case
> > that the cursor is not positioned on the top-of-stack symbol `.' but one
> > line
> > above, at the beginning of the line with the first stack entry.
> > 
> > This can be changed by using the number 4 instead of 3 in the patch.
> > Not sure if this is the best fix.
> > 
> > (vertical-motion (- 4 (window-height win)))
> 
> Can you show a reproducible recipe starting from "emacs -Q", so I
> could investigate?

And while at that, would the below fix the problem in the rare cases
where you saw them?

  (vertical-motion (- 3 (window-height win 'ceiling)))

That is, ask window-height to produce the smallest integer number
greater than the window's height (in case the height in line units is
not integer)?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Mon, 11 Apr 2022 14:54:02 GMT) Full text and rfc822 format available.

Message #30 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Mon, 11 Apr 2022 16:53:50 +0200
On 11.04.22 13:45, Eli Zaretskii wrote:
>>> I noticed that while the patch fixes the problem in most cases,
>>> depending on the height of the calc stack window, there can be the case
>>> that the cursor is not positioned on the top-of-stack symbol `.' but one
>>> line
>>> above, at the beginning of the line with the first stack entry.
>>>
>>> This can be changed by using the number 4 instead of 3 in the patch.
>>> Not sure if this is the best fix.
>>>
>>> (vertical-motion (- 4 (window-height win)))
>> Can you show a reproducible recipe starting from "emacs -Q", so I
>> could investigate?
> And while at that, would the below fix the problem in the rare cases
> where you saw them?
>
>    (vertical-motion (- 3 (window-height win 'ceiling)))
>
> That is, ask window-height to produce the smallest integer number
> greater than the window's height (in case the height in line units is
> not integer)?

Seems 'ceiling does not fix it, but 'floor does, like so:

  (vertical-motion (- 3 (window-height win 'floor)))

How to reproduce -- I could not find a way to do so automatically,
here is for a manual way:

1. emacs -Q
2. C-x * *
3. enter some numbers to fill calc stack window, and some more
4. o (calc-realign)
5. watch where the cursor is placed: on the top-of-stack symbol, or
on the beginning of the line with the first stack entry.
6. increase the stack window height by minimally moving the mode line
above the stack window with the mouse; only increase height by
sub-line-height amount
7. repeat 4. to 6. until you can observe the symptom






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Tue, 12 Apr 2022 15:46:01 GMT) Full text and rfc822 format available.

Message #33 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Tue, 12 Apr 2022 17:45:42 +0200
On 11.04.22 16:53, Christoph Arenz wrote:
>
> On 11.04.22 13:45, Eli Zaretskii wrote:
>>>> I noticed that while the patch fixes the problem in most cases,
>>>> depending on the height of the calc stack window, there can be the
>>>> case
>>>> that the cursor is not positioned on the top-of-stack symbol `.'
>>>> but one
>>>> line
>>>> above, at the beginning of the line with the first stack entry.
>>>>
>>>> This can be changed by using the number 4 instead of 3 in the patch.
>>>> Not sure if this is the best fix.
>>>>
>>>> (vertical-motion (- 4 (window-height win)))
>>> Can you show a reproducible recipe starting from "emacs -Q", so I
>>> could investigate?
>> And while at that, would the below fix the problem in the rare cases
>> where you saw them?
>>
>>    (vertical-motion (- 3 (window-height win 'ceiling)))
>>
>> That is, ask window-height to produce the smallest integer number
>> greater than the window's height (in case the height in line units is
>> not integer)?
>
> Seems 'ceiling does not fix it, but 'floor does, like so:
>
>   (vertical-motion (- 3 (window-height win 'floor)))

And there are still cases where above does not work correctly.
E.g. when using a theme which has different line heights for header line
and mode line than for text lines,
say M-x load-theme leuven .

Approaching it differently seems to cover those cases as well:

    (vertical-motion (- 1 (window-body-height)))

>
> How to reproduce -- I could not find a way to do so automatically,
> here is for a manual way:
>
> 1. emacs -Q
> 2. C-x * *
> 3. enter some numbers to fill calc stack window, and some more
3a. Even finer-grained risizing and watching the effects can be achieved by
M-: (setq window-resize-pixelwise t)
> 4. o (calc-realign)
> 5. watch where the cursor is placed: on the top-of-stack symbol, or
> on the beginning of the line with the first stack entry.
> 6. increase the stack window height by minimally moving the mode line
> above the stack window with the mouse; only increase height by
> sub-line-height amount
> 7. repeat 4. to 6. until you can observe the symptom
>
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Tue, 12 Apr 2022 20:45:02 GMT) Full text and rfc822 format available.

Message #36 received at 54800 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Arenz <tiga.arenz <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54800 <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Tue, 12 Apr 2022 22:44:16 +0200
> And there are still cases where above does not work correctly.
> E.g. when using a theme which has different line heights for header
> line and mode line than for text lines,
> say M-x load-theme leuven .
>
> Approaching it differently seems to cover those cases as well:
>
>     (vertical-motion (- 1 (window-body-height)))

N.B.
This works for me as long as line-spacing is nil.
For non-nil there seems to be a bug in window-body-height.
I have opened bug report #54894 for that.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54800; Package emacs. (Wed, 13 Apr 2022 13:12:02 GMT) Full text and rfc822 format available.

Message #39 received at 54800-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Arenz <tiga.arenz <at> web.de>
Cc: 54800-done <at> debbugs.gnu.org
Subject: Re: bug#54800: 28.1; calc: Cursor positioned at weird position in
 calc stack
Date: Wed, 13 Apr 2022 16:11:04 +0300
> Date: Tue, 12 Apr 2022 22:44:16 +0200
> From: Christoph Arenz <tiga.arenz <at> web.de>
> Cc: 54800 <at> debbugs.gnu.org
> 
> 
> > And there are still cases where above does not work correctly.
> > E.g. when using a theme which has different line heights for header
> > line and mode line than for text lines,
> > say M-x load-theme leuven .
> >
> > Approaching it differently seems to cover those cases as well:
> >
> >     (vertical-motion (- 1 (window-body-height)))
> 
> N.B.
> This works for me as long as line-spacing is nil.
> For non-nil there seems to be a bug in window-body-height.
> I have opened bug report #54894 for that.

Thanks, I think people who use line-spacing in Calc stack window, or
otherwise change the default height of a window-line, should know what
they are doing and what would be the result.

I installed the change to use the 'floor' argument to window-height,
and I think this works well enough in the "usual" use cases;
everything else would be a non-trivial enhancement.  So I'm closing
this bug.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 12 May 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 40 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.