bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 3551 bytes --]

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Eli Zaretskii]

> Date: Fri, 8 Apr 2022 21:44:38 +0200
> From: Christoph Arenz <tiga.arenz@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)))))

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

On 09.04.22 09:34, Eli Zaretskii wrote:
>> Date: Fri, 8 Apr 2022 21:44:38 +0200
>> From: Christoph Arenz <tiga.arenz@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)))))

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Eli Zaretskii]

> Date: Sat, 9 Apr 2022 14:31:06 +0200
> Cc: 54800@debbugs.gnu.org
> From: Christoph Arenz <tiga.arenz@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.

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

On 09.04.22 15:32, Eli Zaretskii wrote:
>> Date: Sat, 9 Apr 2022 14:31:06 +0200
>> Cc: 54800@debbugs.gnu.org
>> From: Christoph Arenz <tiga.arenz@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)))

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Eli Zaretskii]

> Date: Mon, 11 Apr 2022 12:25:24 +0200
> Cc: 54800@debbugs.gnu.org
> From: Christoph Arenz <tiga.arenz@web.de>
> 
> On 09.04.22 15:32, Eli Zaretskii wrote:
> >> Date: Sat, 9 Apr 2022 14:31:06 +0200
> >> Cc: 54800@debbugs.gnu.org
> >> From: Christoph Arenz <tiga.arenz@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.

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Eli Zaretskii]

> Date: Mon, 11 Apr 2022 14:27:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 54800@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)?

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

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

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

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
>
>

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Christoph Arenz]

> 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.

bug#54800: 28.1; calc: Cursor positioned at weird position in calc stack

[Eli Zaretskii]

> Date: Tue, 12 Apr 2022 22:44:16 +0200
> From: Christoph Arenz <tiga.arenz@web.de>
> Cc: 54800@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.