bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Ashton Wiersdorf]

Reproducing the bug from emacs -Q

I had this as my `early-init.el`:

    (setq package-enable-at-startup nil)
    (setq frame-resize-pixelwise t)

and this as `init.el`:

    (pixel-scroll-precision-mode)

Then, when Emacs started, I resized the window so it wasn't a 
multiple
of a full character's height.

Next, I ran `M-x eshell` and went to an Elixir project where I ran 
`mix
test`. This bit shouldn't be important, but it's the most reliable 
way I
could find to trigger the bug, unfortunately. I'll report back if 
I find
another easily reproducible command that trigger the behavior.

When the command finished, the Eshell prompt was almost entirely
obscured by the modeline.

The bug does not manifest when I turn off 
`pixel-scroll-precision-mode`.
It returns when I turn `pixel-scroll-precision-mode` back on.

In GNU Emacs 30.0.92 (build 2, aarch64-apple-darwin24.1.0, NS
 appkit-2575.20 Version 15.1 (Build 24B83)) of 2024-11-05 built on
 vulcan.local
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.1

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus@30/30.0.92/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@30/30.0.92 --with-xml2
 --with-gnutls --with-native-compilation=aot 
 --without-compress-install
 --with-dbus --with-imagemagick --with-modules --with-rsvg 
 --with-webp
 --without-pop --with-xwidgets --with-ns 
 --disable-ns-self-contained
 'CFLAGS=-O2 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT
 -I/opt/homebrew/opt/gcc/include 
 -I/opt/homebrew/opt/libgccjit/include'
 'LDFLAGS=-L/opt/homebrew/lib/gcc/14 
 -I/opt/homebrew/opt/gcc/include
 -I/opt/homebrew/opt/libgccjit/include''

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS IMAGEMAGICK JPEG LCMS2 LIBXML2 
MODULES
NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Eshell

Minor modes in effect:
  eshell-prompt-mode: t
  eshell-pred-mode: t
  eshell-hist-mode: t
  eshell-cmpl-mode: t
  eshell-proc-mode: t
  eshell-arg-mode: t
  pixel-scroll-precision-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr compile comp-run comp-common emacsbug 
message
mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util 
time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev 
gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils cl-seq pcmpl-unix cl-extra help-mode rx em-unix em-term 
term
disp-table shell ehelp em-script em-prompt text-property-search 
em-pred
em-ls em-hist em-glob em-extpipe em-cmpl em-dirs em-basic 
em-banner
em-alias esh-mode esh-var eshell esh-cmd generator cl-loaddefs 
cl-lib
esh-ext esh-opt esh-proc esh-io byte-opt gv bytecomp byte-compile
esh-arg pcomplete comint ansi-osc ansi-color esh-module
esh-module-loaddefs esh-util files-x pixel-scroll cua-base ring 
subr-x
rmc iso-transl tooltip cconv eldoc paren electric uniquify 
ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode 
lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch 
easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang 
vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew 
greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button 
loaddefs
theme-loaddefs faces cus-face macroexp files window 
text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget 
keymap
hashtable-print-readable backquote threads xwidget-internal 
dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process 
native-compile
emacs)

Memory information:
((conses 16 107402 9344) (symbols 48 8995 0) (strings 32 25963 
2526)
 (string-bytes 1 865352) (vectors 16 16688)
 (vector-slots 8 212549 7121) (floats 8 179 59) (intervals 56 579 
 0)
 (buffers 992 14))

-- 
Ashton Wiersdorf
https://lambdaland.org/

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

> From: Ashton Wiersdorf <ashton@wiersdorfmail.net>
> Date: Mon, 18 Nov 2024 10:52:27 -0700
> 
> 
> Reproducing the bug from emacs -Q
> 
> I had this as my `early-init.el`:
> 
>     (setq package-enable-at-startup nil)
>     (setq frame-resize-pixelwise t)
> 
> and this as `init.el`:
> 
>     (pixel-scroll-precision-mode)
> 
> Then, when Emacs started, I resized the window so it wasn't a 
> multiple
> of a full character's height.
> 
> Next, I ran `M-x eshell` and went to an Elixir project where I ran 
> `mix
> test`. This bit shouldn't be important, but it's the most reliable 
> way I
> could find to trigger the bug, unfortunately. I'll report back if 
> I find
> another easily reproducible command that trigger the behavior.
> 
> When the command finished, the Eshell prompt was almost entirely
> obscured by the modeline.
> 
> The bug does not manifest when I turn off 
> `pixel-scroll-precision-mode`.
> It returns when I turn `pixel-scroll-precision-mode` back on.

Po Lu and Jim, could you look into this, please?

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Jim Porter]

On 11/21/2024 2:53 AM, Eli Zaretskii wrote:
>> From: Ashton Wiersdorf <ashton@wiersdorfmail.net>
>> Date: Mon, 18 Nov 2024 10:52:27 -0700
>>
>> When the command finished, the Eshell prompt was almost entirely
>> obscured by the modeline.
>>
>> The bug does not manifest when I turn off
>> `pixel-scroll-precision-mode`.
>> It returns when I turn `pixel-scroll-precision-mode` back on.
> 
> Po Lu and Jim, could you look into this, please?

I'm only dimly aware of how 'pixel-scroll-precision-mode' works, but I 
seem to recall that it sets the window's vscroll to allow scrolling past 
*part* of a line. On the Eshell side, I believe the relevant function is 
'eshell-postoutput-scroll-to-bottom', which calls 'recenter' to scroll 
the window.

I'm guessing these interact badly, and what we actually want to do is to 
reset the vscroll when Eshell calls 'recenter'. However, I'm not sure 
what the best way to do this would be. Is there some better function 
Eshell can call that would handle this case correctly?

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Porter <jporterbugs@gmail.com> writes:

> I'm only dimly aware of how 'pixel-scroll-precision-mode' works, but I
> seem to recall that it sets the window's vscroll to allow scrolling
> past *part* of a line. On the Eshell side, I believe the relevant
> function is 'eshell-postoutput-scroll-to-bottom', which calls
> 'recenter' to scroll the window.
>
> I'm guessing these interact badly, and what we actually want to do is
> to reset the vscroll when Eshell calls 'recenter'. However, I'm not
> sure what the best way to do this would be. Is there some better
> function Eshell can call that would handle this case correctly?

Since pixel-scroll-precision-mode never configures a vscroll taller than
one screen line, resetting vscroll in these scenarios is generally the
safest and simplest solutions to problems such as the OP is facing.

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Ashton Wiersdorf
>  <ashton@wiersdorfmail.net>,  74430@debbugs.gnu.org
> Date: Fri, 22 Nov 2024 07:59:50 +0800
> 
> Jim Porter <jporterbugs@gmail.com> writes:
> 
> > I'm only dimly aware of how 'pixel-scroll-precision-mode' works, but I
> > seem to recall that it sets the window's vscroll to allow scrolling
> > past *part* of a line. On the Eshell side, I believe the relevant
> > function is 'eshell-postoutput-scroll-to-bottom', which calls
> > 'recenter' to scroll the window.
> >
> > I'm guessing these interact badly, and what we actually want to do is
> > to reset the vscroll when Eshell calls 'recenter'. However, I'm not
> > sure what the best way to do this would be. Is there some better
> > function Eshell can call that would handle this case correctly?
> 
> Since pixel-scroll-precision-mode never configures a vscroll taller than
> one screen line, resetting vscroll in these scenarios is generally the
> safest and simplest solutions to problems such as the OP is facing.

So you suggest that eshell-postoutput-scroll-to-bottom explicitly
resets the window's vscroll, and that should solve the OP's problem?

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Jim Porter]

On 11/18/2024 9:52 AM, Ashton Wiersdorf wrote:
> Then, when Emacs started, I resized the window so it wasn't a multiple
> of a full character's height.
[snip]
> When the command finished, the Eshell prompt was almost entirely
> obscured by the modeline.

I'm not able to reproduce this. I tried running a bunch of commands, 
including ones that output large amounts of text, but it all works as 
expected: once Eshell starts scrolling the buffer (by way of calls to 
'recenter'), the vscroll is reset to 0 and everything works as it should.

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

> Date: Sun, 24 Nov 2024 21:13:33 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 11/18/2024 9:52 AM, Ashton Wiersdorf wrote:
> > Then, when Emacs started, I resized the window so it wasn't a multiple
> > of a full character's height.
> [snip]
> > When the command finished, the Eshell prompt was almost entirely
> > obscured by the modeline.
> 
> I'm not able to reproduce this. I tried running a bunch of commands, 
> including ones that output large amounts of text, but it all works as 
> expected: once Eshell starts scrolling the buffer (by way of calls to 
> 'recenter'), the vscroll is reset to 0 and everything works as it should.

Ashton, could you please help Jim reproduce the problem?

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

Ping!

> Cc: jporterbugs@gmail.com, ashton@wiersdorfmail.net, 74430@debbugs.gnu.org
> Date: Fri, 22 Nov 2024 08:58:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  Ashton Wiersdorf
> >  <ashton@wiersdorfmail.net>,  74430@debbugs.gnu.org
> > Date: Fri, 22 Nov 2024 07:59:50 +0800
> > 
> > Jim Porter <jporterbugs@gmail.com> writes:
> > 
> > > I'm only dimly aware of how 'pixel-scroll-precision-mode' works, but I
> > > seem to recall that it sets the window's vscroll to allow scrolling
> > > past *part* of a line. On the Eshell side, I believe the relevant
> > > function is 'eshell-postoutput-scroll-to-bottom', which calls
> > > 'recenter' to scroll the window.
> > >
> > > I'm guessing these interact badly, and what we actually want to do is
> > > to reset the vscroll when Eshell calls 'recenter'. However, I'm not
> > > sure what the best way to do this would be. Is there some better
> > > function Eshell can call that would handle this case correctly?
> > 
> > Since pixel-scroll-precision-mode never configures a vscroll taller than
> > one screen line, resetting vscroll in these scenarios is generally the
> > safest and simplest solutions to problems such as the OP is facing.
> 
> So you suggest that eshell-postoutput-scroll-to-bottom explicitly
> resets the window's vscroll, and that should solve the OP's problem?
> 
> 
> 
> 

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

Ping!  Ashton, please respond.

> Cc: 74430@debbugs.gnu.org
> Date: Sat, 30 Nov 2024 12:07:20 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sun, 24 Nov 2024 21:13:33 -0800
> > From: Jim Porter <jporterbugs@gmail.com>
> > 
> > On 11/18/2024 9:52 AM, Ashton Wiersdorf wrote:
> > > Then, when Emacs started, I resized the window so it wasn't a multiple
> > > of a full character's height.
> > [snip]
> > > When the command finished, the Eshell prompt was almost entirely
> > > obscured by the modeline.
> > 
> > I'm not able to reproduce this. I tried running a bunch of commands, 
> > including ones that output large amounts of text, but it all works as 
> > expected: once Eshell starts scrolling the buffer (by way of calls to 
> > 'recenter'), the vscroll is reset to 0 and everything works as it should.
> 
> Ashton, could you please help Jim reproduce the problem?
> 
> 
> 
> 

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Eli Zaretskii]

Ping! Ping!  Po Lu, can you please answer the question?

> Cc: jporterbugs@gmail.com, ashton@wiersdorfmail.net, 74430@debbugs.gnu.org
> Date: Sat, 30 Nov 2024 12:07:51 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping!
> 
> > Cc: jporterbugs@gmail.com, ashton@wiersdorfmail.net, 74430@debbugs.gnu.org
> > Date: Fri, 22 Nov 2024 08:58:58 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Po Lu <luangruo@yahoo.com>
> > > Cc: Eli Zaretskii <eliz@gnu.org>,  Ashton Wiersdorf
> > >  <ashton@wiersdorfmail.net>,  74430@debbugs.gnu.org
> > > Date: Fri, 22 Nov 2024 07:59:50 +0800
> > > 
> > > Jim Porter <jporterbugs@gmail.com> writes:
> > > 
> > > > I'm only dimly aware of how 'pixel-scroll-precision-mode' works, but I
> > > > seem to recall that it sets the window's vscroll to allow scrolling
> > > > past *part* of a line. On the Eshell side, I believe the relevant
> > > > function is 'eshell-postoutput-scroll-to-bottom', which calls
> > > > 'recenter' to scroll the window.
> > > >
> > > > I'm guessing these interact badly, and what we actually want to do is
> > > > to reset the vscroll when Eshell calls 'recenter'. However, I'm not
> > > > sure what the best way to do this would be. Is there some better
> > > > function Eshell can call that would handle this case correctly?
> > > 
> > > Since pixel-scroll-precision-mode never configures a vscroll taller than
> > > one screen line, resetting vscroll in these scenarios is generally the
> > > safest and simplest solutions to problems such as the OP is facing.
> > 
> > So you suggest that eshell-postoutput-scroll-to-bottom explicitly
> > resets the window's vscroll, and that should solve the OP's problem?
> > 
> > 
> > 
> > 
> 
> 
> 
> 

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Ashton Wiersdorf]

Hey, sorry Eli. I haven't been able to get this to reproduce 
consistently—it happens most often when I run a (broken) test 
suite on an Elixir project I'm working on, and then only 
sometimes. I think running a complex Elixir application would be a 
suboptimal thing to run to try to reproduce the bug, no?

I might have a little time today to try reproducing it with 
simpler commands; I'll let you know then. Sorry I haven't been 
able to get a MWE yet.

-- 
Ashton Wiersdorf
https://lambdaland.org/

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Jim Porter]

On 12/14/2024 10:40 AM, Ashton Wiersdorf wrote:
> Hey, sorry Eli. I haven't been able to get this to reproduce 
> consistently—it happens most often when I run a (broken) test suite on 
> an Elixir project I'm working on, and then only sometimes. I think 
> running a complex Elixir application would be a suboptimal thing to run 
> to try to reproduce the bug, no?
> 
> I might have a little time today to try reproducing it with simpler 
> commands; I'll let you know then. Sorry I haven't been able to get a MWE 
> yet.

If you can't find a minimal example, a screenshot could also help, so 
long as you wouldn't be leaking any private information.

Also, are there any "unique" properties of the output that causes this 
bug? For example, does it use "\r" carriage returns to overwrite the 
last line, or does it use emojis, or anything like that? If there's 
something different from the norm, that could help narrow things down.

bug#74430: 30.0.92; pixel-scroll-precision-mode hiding Eshell prompt after some commands

[Ashton Wiersdorf]

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

> If you can't find a minimal example, a screenshot could also 
> help, so
> long as you wouldn't be leaking any private information.

Here's a screenshot of the bug in action:


[-- Attachment #2: Screenshot showing scroll bug in Emacs --]
[-- Type: image/png, Size: 282829 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1008 bytes --]


> Also, are there any "unique" properties of the output that 
> causes this
> bug? For example, does it use "\r" carriage returns to overwrite 
> the
> last line, or does it use emojis, or anything like that? If 
> there's
> something different from the norm, that could help narrow things 
> down.

I've seen this most often after running Elixir scripts—that might 
just be availability bias because that's what I'm doing for work 
right now! There *is* some colored text in the output. AFAIK 
Elixir doesn't send "\r" to do anything tricky with the last line. 
I think I've seen this happen with other commands.

I've noticed that the easiest way to rid myself of this behavior 
is to just it Ctrl-l when it arises. That resets something and it 
will work again for a while.

Note: I just upgraded to 30.0.93, and I'll keep my eyes peeled to 
see if it resurfaces.

Thanks for your help, attention, and patience. Happy holidays!

-- 
Ashton Wiersdorf
https://lambdaland.org/