Ement scrolls image buffers upon insertion of new events

[9viz]

I apologise right away for this vague report. I tried to investigate to be more specific, only to be unsuccessful.

If you have ement connected and have a room buffer opened (but not viewed anywhere), and the current buffer is a pdf-tools buffer [*], upon insertion of new events in the ement room buffer, the pdf buffer is scrolled. This behaviour is not exhibited by "regular" buffers, as in buffers that only show text. I have been unsuccessful so far in coming up with a reproducer but it goes like this:

1. M-x ement-connect RET
2. Open a room.
3. Visit a pdf file.
4. Wait for an event to come up in the room, and watch the PDF file get scrolled. Sometimes, it takes an event or two to see the behaviour.

[*] I'm using pdf-tools in my description but I observe it in doc-view as well, or even an image-mode buffer with the image inserted such that it can be scrolled (i.e., "s b + +").

Edebug so far has not been very helpful... And nothing unusual shows up in lossage.

EDIT: In my tests, I had to scroll up in the image before (C-v). Ement scrolls down when there's an event. I haven't observed the inverse so far.

[alphapapa]

That seems very strange. Ement should not be affecting any buffers other than its own. I'd guess that this is either a problem in your Emacs configuration, or some kind of unusual bug in Emacs related to images. Please try to reproduce in a clean Emacs config (e.g. using with-emacs.sh), and if you can still reproduce it, be sure to report the versions of all relevant software. If possible, please also try to reproduce in the latest build of the Emacs 28 branch (FYI I use Guix to install it, like this: guix install --cores=4 emacs-native-comp --with-branch=emacs-native-comp=emacs-28).

[9viz]

I wish it was something to do with my config, but alas. I was able to reproduce in a clean config just after the Emacs 28 branch was cut but nevertheless, I will try to reproduce in Emacs 28. As for my sysinfo, here's what M-x report-emacs-bug has to say:

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
Repository revision: ca3858563c7ba8ee3caa82fbd2b7c386ea60c0d3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: NixOS 21.11 (Porcupine)

Configured using:
 'configure
 --prefix=/nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0
 --disable-build-details --with-modules --with-x-toolkit=lucid
 --with-xft --with-cairo --with-native-compilation'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $EMACSLOADPATH: 
  value of $EMACSNATIVELOADPATH: /nix/store/5gh4w50dhchhcyjm6ysh17h7y4i5vasf-emacs-packages-deps/share/emacs/native-lisp::
  value of $LC_MONETARY: ta_IN.UTF-8
  value of $LC_NUMERIC: ta_IN.UTF-8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

[9viz]

I used with-emacs.sh with init.el here to install ement and plz using straight.el. Reproducing this issue is straightforward,

1. ./with-emacs.sh -d ./ement-emacs (inside that dir I have the
   init.el linked above).

2. C-x C-f ~/path/to/image/file RET

   The image should be sufficiently large (I think?). I used this one http://0x0.st/oq-X.png.

3. s w + + so that you can scroll up.

4. C-v C-v so you can scroll down.

5. M-x ement-connect... and join a room.

6. Wait for someone to send a message.

AFAICT, if you send a message in a room, this does not reproduce. Someone else has to send a message. As for sysinfo, this is what M-x report-emacs-bug says: https://gist.github.com/vizs/7a601037d7c99498dd9f2aabda8812e3

[alphapapa]

As for my sysinfo, here's what M-x report-emacs-bug has to say: In GNU Emacs 29.0.50

So you originally encountered this problem when using Emacs from the version-29 (i.e. master) branch? If so, that is crucial information that you must not leave out of a bug report like this. You're running bleeding-edge, unreleased software that may contain new bugs that are unrelated to this package.

In your latest comment, you report the problem in Emacs 28, but neither Emacs 28 nor 29 are released yet. Please try to reproduce this bug with a released version of Emacs. You may have discovered a bug in Emacs 28+ that needs to be fixed in Emacs.

[alphapapa]

FWIW, I'm unable to reproduce this problem in Emacs 28.0.92. I opened an image in a buffer, zoomed in so it more than filled the window, scrolled down in that window, then opened a room buffer and buried it, then sent messages to that room from another account, and the image did not move.

[9viz]

Sorry for the late reply, I'm busy with my sem finals, I hope to get back to this bug report on May. But I vaguely remember not being able to reproduce this issue if I posted a message from an alt account in element... but if someone else sends a message, I can reproduce it reliably.

[alphapapa]

I don't understand how that could be possible. The software doesn't know that both accounts belong to you, so to it, your alt account is "someone else."

[alphapapa]

@Vizs IIRC I saw you mention this in #emacs:matrix.org the other day, that it doesn't only happen when using Ement. So is this confirmed to not be a bug in Ement now?

[9viz]

It was more like a random observation from time to time even without Ement connected. So I guess it was something more related to Emacs than Ement. But I haven't observed it for quite some time now, I would close the issue.

[9viz]

For future readers, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56008

[alphapapa]

Wow, that was quite an involved bug. Thanks to you, Lars, and Eli for working on the fix.