all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
@ 2022-06-16  4:01 Visuwesh
  2022-06-16 12:04 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-06-16  4:01 UTC (permalink / raw)
  To: 56008

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

image-mode buffers are scrolled down without user intervention sometimes
when another buffer content is updated.  I can reliably reproduce this
using eww.  To demonstrate,

    1. emacs -Q
    2. Visit attached image file.
    3. s o ;; to make the window show only some part of the image
    4. M->
    5. C-x 3 ;; split the frame into two windows
    6. M-s M-w search for something here RET
    7. C-x o ;; switch to the image-mode buffer
    8. Observe image-mode buffer moving to the beginning of image when
       the eww buffer gets updated with the webpage content.

(7,8) You have to be quick enough to switch back to the image-mode
buffer as otherwise, this behaviour is not seen.

By (2), I mean to say that the image should be large enough such that
only a part of the image is shown in the window, unlike what is seen
when you visit the file initially.

This does not happen only with eww but in other scenarios as well.  But
I am unable to reproduce this behaviour in those scenarios as they are a
lot more involved.


[-- Attachment #2: test.png --]
[-- Type: image/png, Size: 167850 bytes --]

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



In GNU Emacs 29.0.50 (build 17, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2022-06-15 built on astatine
Repository revision: 112b6b8e37b5df268ced98c4354802275a4da417
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-modules --with-sound=alsa --with-x-toolkit=lucid
 --with-json --without-xaw3d --without-gconf --without-libsystemd
 --with-x --without-cairo'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XFT
XIM XINPUT2 XPM LUCID ZLIB

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

Major mode: Group

Minor modes in effect:
  shell-dirtrack-mode: t
  gnus-undo-mode: t
  eros-mode: t
  pdf-occur-global-minor-mode: t
  minibuffer-depth-indicate-mode: t
  repeat-mode: t
  display-time-mode: t
  display-battery-mode: t
  winner-mode: t
  delete-selection-mode: t
  straight-use-package-mode: t
  straight-package-neutering-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  undelete-frame-mode: t
  buffer-read-only: 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 dictionary dictionary-connection emacsbug rect org-datetree
org-capture doct shr-color lacarte icomplete vc-backup log-view
pcvs-util vc pulse color vc-git vc-dispatcher bug-reference dabbrev
sh-script smie executable help-fns radix-tree ecomplete qp flyspell
ispell org-pdftools pdf-annot facemenu org-noter goto-addr org-element
avl-tree generator ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs ob-shell shell ob-racket
async ob-async cdlatex texmathp ol-eww eww xdg url-queue mm-url ol-rmail
ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view ol-bibtex
ol-bbdb ol-w3m ol-doi org-link-doi org-tempo tempo org-id org-refile
ol-man org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp
ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat
org-macs org-loaddefs smerge-mode diff diff-mode mule-util flow-fill
mm-archive gnus-fun sort gnus-cite mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check gnus-async
gnus-bcklg gnus-ml network-stream nsm nndraft nnmh nnfolder nnmaildir
nnagent nnml nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig nntp
gnus-cache gnus-sum shr pixel-fill kinsoku url-file url-dired svg dom
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo parse-time iso8601 gnus-spec gnus-int
gnus-range message sendmail yank-media rmc puny rfc822 mml mml-sec epa
epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util mail-utils range mm-util mail-prsvr face-remap
misearch multi-isearch tabify man cursor-sensor server paredit edmacro
kmacro eros time-date checkdoc lisp-mnt flymake-proc flymake project
warnings thingatpt wordel-autoloads sokoban-autoloads ement-autoloads
ts-autoloads svg-lib-autoloads taxy-magit-section-autoloads
taxy-autoloads plz-autoloads nov-autoloads esxml-autoloads kv-autoloads
transmission-autoloads lua-mode-autoloads nix-mode-autoloads
magit-section-autoloads dash-autoloads racket-mode-autoloads
eros-autoloads flymake-shellcheck-autoloads writegood-mode-autoloads
siege-mode-autoloads paredit-autoloads puni-autoloads
expand-region-autoloads filladapt-autoloads compose quail
scroll-other-window org-pdftools-autoloads org-noter-autoloads
change-env-autoloads math-delimiters-autoloads doct-autoloads
ob-async-autoloads async-autoloads emacs-ob-racket-autoloads
valign-autoloads org-starless-autoloads cdlatex-autoloads
auctex-autoloads tex-site pdf-occur ibuf-ext ibuffer ibuffer-loaddefs
tablist advice tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
let-alist pdf-misc imenu pdf-tools package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source eieio eieio-core eieio-loaddefs json map url-vars compile
comint ansi-color cus-edit hl-todo edebug debug backtrace find-func
wid-edit pdf-view password-cache jka-compr pdf-cache pdf-info tq
pdf-util pdf-macs image-mode dired-x dired dired-loaddefs exif
pdf-tools-autoloads tablist-autoloads mb-depth repeat
visual-fill-autoloads olivetti-autoloads hl-todo-autoloads time
format-spec battery dbus filenotify xml disp-table lacarte-autoloads
shell-command-plus-autoloads winner derived delsel cus-load easy-mmode
avy ring avy-autoloads vc-backup-autoloads icalendar diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs rx filecache
flymake-grammarly-autoloads grammarly-autoloads websocket-autoloads
finder-inf request-autoloads s-autoloads chemtable-autoloads
molar-mass-autoloads saveplace-pdf-view saveplace bookmark
text-property-search pp saveplace-pdf-view-autoloads pcase
straight-autoloads info cl-seq cl-extra help-mode seq byte-opt straight
subr-x cl-macs gv cl-loaddefs cl-lib bytecomp byte-compile cconv
vz-nh-theme vz-options-theme iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd 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 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 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 669053 130341) (symbols ?0 36912 13) (strings 32 181064 19196) (string-bytes 1 5941597)
 (vectors 16
          100406) (vector-slots 8 2012397 208881) (floats 8 614 566) (intervals ?8 45133 1478) (buffers 992 37))

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16  4:01 bug#56008: 29.0.50; image-mode buffer scrolled down automatically Visuwesh
@ 2022-06-16 12:04 ` Lars Ingebrigtsen
  2022-06-16 12:19   ` Lars Ingebrigtsen
  2022-06-16 12:52   ` Eli Zaretskii
  0 siblings, 2 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-16 12:04 UTC (permalink / raw)
  To: Visuwesh; +Cc: 56008

Visuwesh <visuweshm@gmail.com> writes:

> image-mode buffers are scrolled down without user intervention sometimes
> when another buffer content is updated.  I can reliably reproduce this
> using eww.  To demonstrate,
>
>     1. emacs -Q
>     2. Visit attached image file.
>     3. s o ;; to make the window show only some part of the image
>     4. M->
>     5. C-x 3 ;; split the frame into two windows
>     6. M-s M-w search for something here RET
>     7. C-x o ;; switch to the image-mode buffer
>     8. Observe image-mode buffer moving to the beginning of image when
>        the eww buffer gets updated with the webpage content.

I can reproduce this -- what a strange error.

Hm...  anybody got any ideas how to debug this?  Something is apparently
resetting the window-start in the wrong window?  Or...  something else?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 12:04 ` Lars Ingebrigtsen
@ 2022-06-16 12:19   ` Lars Ingebrigtsen
  2022-06-16 13:19     ` Visuwesh
  2022-06-16 12:52   ` Eli Zaretskii
  1 sibling, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-16 12:19 UTC (permalink / raw)
  To: Visuwesh; +Cc: 56008

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  anybody got any ideas how to debug this?  Something is apparently
> resetting the window-start in the wrong window?  Or...  something else?

Hm!  If I say `M-:' afterwards, the window position in the Image buffer
window flips back to where it was supposed to be.  So this seems like
it's a redisplay bug and not a programming error somewhere (I was
wondering if some shr code was setting window-start in the wrong window
or something like that).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 12:04 ` Lars Ingebrigtsen
  2022-06-16 12:19   ` Lars Ingebrigtsen
@ 2022-06-16 12:52   ` Eli Zaretskii
  1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 12:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 56008, visuweshm

> Cc: 56008@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 16 Jun 2022 14:04:54 +0200
> 
> >     1. emacs -Q
> >     2. Visit attached image file.
> >     3. s o ;; to make the window show only some part of the image
> >     4. M->
> >     5. C-x 3 ;; split the frame into two windows
> >     6. M-s M-w search for something here RET
> >     7. C-x o ;; switch to the image-mode buffer
> >     8. Observe image-mode buffer moving to the beginning of image when
> >        the eww buffer gets updated with the webpage content.
> 
> I can reproduce this -- what a strange error.

Indeed.

> Hm...  anybody got any ideas how to debug this?  Something is apparently
> resetting the window-start in the wrong window?  Or...  something else?

Something else, because window-start stays put at 1.  image-mode
implements "M->" by setting vscroll and hscroll, it doesn't change
window-start.  Moreover, if you type "M-x" after the recipe, the image
gets redisplayed as expected after "M->".  Which means that the
window's vscroll didn't change, either.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 12:19   ` Lars Ingebrigtsen
@ 2022-06-16 13:19     ` Visuwesh
  2022-06-16 13:57       ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-06-16 13:19 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 56008

[வியாழன் ஜூன் 16, 2022 14:19] Lars Ingebrigtsen wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Hm...  anybody got any ideas how to debug this?  Something is apparently
>> resetting the window-start in the wrong window?  Or...  something else?
>
> Hm!  If I say `M-:' afterwards, the window position in the Image buffer
> window flips back to where it was supposed to be.

Oh, I knew that but that totally slipped my mind.  Sorry about that.

>  So this seems like it's a redisplay bug and not a programming error
> somewhere (I was wondering if some shr code was setting window-start
> in the wrong window or something like that).

Yes, it is not specific to shr/eww.  That's what I alluded to by saying,

    This does not happen only with eww but in other scenarios as well.  But
    I am unable to reproduce this behaviour in those scenarios as they are a
    lot more involved.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 13:19     ` Visuwesh
@ 2022-06-16 13:57       ` Eli Zaretskii
  2022-06-16 14:05         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 13:57 UTC (permalink / raw)
  To: Visuwesh; +Cc: larsi, 56008

> Cc: 56008@debbugs.gnu.org
> From: Visuwesh <visuweshm@gmail.com>
> Date: Thu, 16 Jun 2022 18:49:49 +0530
> 
> >  So this seems like it's a redisplay bug and not a programming error
> > somewhere (I was wondering if some shr code was setting window-start
> > in the wrong window or something like that).
> 
> Yes, it is not specific to shr/eww.  That's what I alluded to by saying,
> 
>     This does not happen only with eww but in other scenarios as well.  But
>     I am unable to reproduce this behaviour in those scenarios as they are a
>     lot more involved.

No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
something which directly causes this.  Stay tuned.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 13:57       ` Eli Zaretskii
@ 2022-06-16 14:05         ` Lars Ingebrigtsen
  2022-06-16 14:14           ` Visuwesh
  2022-06-16 15:48           ` Eli Zaretskii
  0 siblings, 2 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-16 14:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 56008, Visuwesh

Eli Zaretskii <eliz@gnu.org> writes:

> No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
> something which directly causes this.  Stay tuned.

I wondered whether it had something to do with shr-string-pixel-width
and friends (which does play games with windows), but stubbing those out
still led to the same problems, apparently.

(shr-string-pixel-width should be replaced with string-pixel-width (sort
of), though.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 14:05         ` Lars Ingebrigtsen
@ 2022-06-16 14:14           ` Visuwesh
  2022-06-16 15:49             ` Eli Zaretskii
  2022-06-16 15:48           ` Eli Zaretskii
  1 sibling, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-06-16 14:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, 56008

[வியாழன் ஜூன் 16, 2022 16:05] Lars Ingebrigtsen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
>> something which directly causes this.  Stay tuned.
>

FWIW, I first saw this when using ement.el which inserts text in buffers
whenever it receives a matrix message.  The bug report I filed in ement.el bug
reporter can be found here: https://github.com/alphapapa/ement.el/issues/58.  
Maybe it is of some value, but I could never get to the root of the
problem.  And I heard another user seeing something similar as well,

    just me or sometimes pdf-view-mode from pdf-tools will automatically
    reset buffer position to initial position (like it just scrolls up the
    buffer). The scenario in which it happens is when I have a frame with
    two windows vertically splited, window 1 is for org-mode, and window 2
    is for pdf-view-mode, and current focus is on window 1.

    seems to be triggered after `Creating LaTeX preview... done.` by
    org-latex-preview and org-fragtog, and when saving the file.

> I wondered whether it had something to do with shr-string-pixel-width
> and friends (which does play games with windows), but stubbing those out
> still led to the same problems, apparently.
>
> (shr-string-pixel-width should be replaced with string-pixel-width (sort
> of), though.)

When I tried to dig around in ement.el's source code, I thought it was
`save-window-excursion' but that turned out not to be the case AFAIU.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 14:05         ` Lars Ingebrigtsen
  2022-06-16 14:14           ` Visuwesh
@ 2022-06-16 15:48           ` Eli Zaretskii
  2022-06-16 16:58             ` Eli Zaretskii
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 15:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 56008, visuweshm

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Visuwesh <visuweshm@gmail.com>,  56008@debbugs.gnu.org
> Date: Thu, 16 Jun 2022 16:05:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
> > something which directly causes this.  Stay tuned.
> 
> I wondered whether it had something to do with shr-string-pixel-width
> and friends (which does play games with windows), but stubbing those out
> still led to the same problems, apparently.
> 
> (shr-string-pixel-width should be replaced with string-pixel-width (sort
> of), though.)

It's shr-pixel-column, which calls set-window-buffer.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 14:14           ` Visuwesh
@ 2022-06-16 15:49             ` Eli Zaretskii
  2022-06-16 16:55               ` Visuwesh
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 15:49 UTC (permalink / raw)
  To: Visuwesh; +Cc: larsi, 56008

> From: Visuwesh <visuweshm@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  56008@debbugs.gnu.org
> Date: Thu, 16 Jun 2022 19:44:13 +0530
> 
> When I tried to dig around in ement.el's source code, I thought it was
> `save-window-excursion' but that turned out not to be the case AFAIU.

What do you mean by "it was `save-window-excursion'"? what is "it" in
this case?  And how did you see that this is not the case?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 15:49             ` Eli Zaretskii
@ 2022-06-16 16:55               ` Visuwesh
  2022-06-16 17:11                 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-06-16 16:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 56008

[வியாழன் ஜூன் 16, 2022 18:49] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  56008@debbugs.gnu.org
>> Date: Thu, 16 Jun 2022 19:44:13 +0530
>> 
>> When I tried to dig around in ement.el's source code, I thought it was
>> `save-window-excursion' but that turned out not to be the case AFAIU.
>
> What do you mean by "it was `save-window-excursion'"? what is "it" in
> this case?

I thought the source of the random, unwarranted scrolling could be
`save-window-excursion' since it did come with the following warning,

    BEWARE: Most uses of this macro introduce bugs.
    E.g. it should not be used to try and prevent some code from opening
    a new window, since that window may sometimes appear in another frame,
    in which case ‘save-window-excursion’ cannot help.

>  And how did you see that this is not the case?

Sorry, but it is close to a year since I looked at the source code.  All
I remember is being annoyed by the bug despite removing the
`save-window-excursion' bit willy-nilly.

[ This was all in ement.el's source code if I wasn't clear, BTW.  ]





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 15:48           ` Eli Zaretskii
@ 2022-06-16 16:58             ` Eli Zaretskii
  2022-06-16 17:20               ` Visuwesh
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 16:58 UTC (permalink / raw)
  To: larsi; +Cc: 56008, visuweshm

> Cc: 56008@debbugs.gnu.org, visuweshm@gmail.com
> Date: Thu, 16 Jun 2022 18:48:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Visuwesh <visuweshm@gmail.com>,  56008@debbugs.gnu.org
> > Date: Thu, 16 Jun 2022 16:05:20 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
> > > something which directly causes this.  Stay tuned.
> > 
> > I wondered whether it had something to do with shr-string-pixel-width
> > and friends (which does play games with windows), but stubbing those out
> > still led to the same problems, apparently.
> > 
> > (shr-string-pixel-width should be replaced with string-pixel-width (sort
> > of), though.)
> 
> It's shr-pixel-column, which calls set-window-buffer.

And in addition, shr-insert-document was resetting the hscroll of the
window it just happened to use for its rendering job.

This bug should be fixed now on the master branch.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 16:55               ` Visuwesh
@ 2022-06-16 17:11                 ` Eli Zaretskii
  2022-06-16 17:23                   ` Visuwesh
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 17:11 UTC (permalink / raw)
  To: Visuwesh; +Cc: larsi, 56008

> From: Visuwesh <visuweshm@gmail.com>
> Cc: larsi@gnus.org,  56008@debbugs.gnu.org
> Date: Thu, 16 Jun 2022 22:25:05 +0530
> 
> [வியாழன் ஜூன் 16, 2022 18:49] Eli Zaretskii wrote:
> 
> > What do you mean by "it was `save-window-excursion'"? what is "it" in
> > this case?
> 
> I thought the source of the random, unwarranted scrolling could be
> `save-window-excursion' since it did come with the following warning,
> 
>     BEWARE: Most uses of this macro introduce bugs.
>     E.g. it should not be used to try and prevent some code from opening
>     a new window, since that window may sometimes appear in another frame,
>     in which case ‘save-window-excursion’ cannot help.

We don't create new windows in this case, so that warning is not
relevant.

But save-window-excursion is indeed part of the puzzle, see below.

> >  And how did you see that this is not the case?
> 
> Sorry, but it is close to a year since I looked at the source code.  All
> I remember is being annoyed by the bug despite removing the
> `save-window-excursion' bit willy-nilly.
> 
> [ This was all in ement.el's source code if I wasn't clear, BTW.  ]

I don't know what ement.el does and whether this is related, but
here's what was happening in this case:

  . we invoke eww to fetch some URL
  . before it finishes to fetch the URL, we switch to another window
  . eww finishes fetching the URL and calls shr.el to render it
  . shr.el uses the selected window for rendering, and as part of
    that, it calls set-window-buffer to temporarily make the buffer in
    which it renders be the buffer of the selected window
  . set-window-buffer resets the window's hscroll and vscroll values
  . shr.el calls set-window-buffer inside save-window-excursion, but
    save-window-excursion didn't preserve the value of vscroll, and in
    addition shr.el called set-window-hscroll in one place that wasn't
    inside save-window-excursion
  . so both vscroll and hscroll of the window showing the image ended
    up with zero hscroll and vscroll
  . since image-mode overrides the usual definition of M-> with a
    command that works by setting the window's hscroll and vscroll,
    resetting these two makes the (mistaken) impression that the
    window was scrolled
  . the reason M-x and M-: appeared to "fix" the problem is that
    image-mode defines a window-configuration-change-hook that forces
    the display back to what it was -- this looked to us as if the
    problem was caused by some redisplay bug, something that took me
    some time to realize its being completely wrong





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 16:58             ` Eli Zaretskii
@ 2022-06-16 17:20               ` Visuwesh
  2022-06-16 17:26                 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Visuwesh @ 2022-06-16 17:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 56008

[வியாழன் ஜூன் 16, 2022 19:58] Eli Zaretskii wrote:

>> Cc: 56008@debbugs.gnu.org, visuweshm@gmail.com
>> Date: Thu, 16 Jun 2022 18:48:26 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > From: Lars Ingebrigtsen <larsi@gnus.org>
>> > Cc: Visuwesh <visuweshm@gmail.com>,  56008@debbugs.gnu.org
>> > Date: Thu, 16 Jun 2022 16:05:20 +0200
>> > 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> > 
>> > > No, this _is_ specific to eww and shr.  Well, in a way: shr.el does
>> > > something which directly causes this.  Stay tuned.
>> > 
>> > I wondered whether it had something to do with shr-string-pixel-width
>> > and friends (which does play games with windows), but stubbing those out
>> > still led to the same problems, apparently.
>> > 
>> > (shr-string-pixel-width should be replaced with string-pixel-width (sort
>> > of), though.)
>> 
>> It's shr-pixel-column, which calls set-window-buffer.
>
> And in addition, shr-insert-document was resetting the hscroll of the
> window it just happened to use for its rendering job.
>
> This bug should be fixed now on the master branch.

Can confirm that it is fixed, thanks for the quick fix!





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 17:11                 ` Eli Zaretskii
@ 2022-06-16 17:23                   ` Visuwesh
  0 siblings, 0 replies; 16+ messages in thread
From: Visuwesh @ 2022-06-16 17:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 56008

[வியாழன் ஜூன் 16, 2022 20:11] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: larsi@gnus.org,  56008@debbugs.gnu.org
>> Date: Thu, 16 Jun 2022 22:25:05 +0530
>> 
>> [வியாழன் ஜூன் 16, 2022 18:49] Eli Zaretskii wrote:
>> 
>> > What do you mean by "it was `save-window-excursion'"? what is "it" in
>> > this case?
>> 
>> I thought the source of the random, unwarranted scrolling could be
>> `save-window-excursion' since it did come with the following warning,
>> 
>>     BEWARE: Most uses of this macro introduce bugs.
>>     E.g. it should not be used to try and prevent some code from opening
>>     a new window, since that window may sometimes appear in another frame,
>>     in which case ‘save-window-excursion’ cannot help.
>
> We don't create new windows in this case, so that warning is not
> relevant.
>
> But save-window-excursion is indeed part of the puzzle, see below.
>
>> >  And how did you see that this is not the case?
>> 
>> Sorry, but it is close to a year since I looked at the source code.  All
>> I remember is being annoyed by the bug despite removing the
>> `save-window-excursion' bit willy-nilly.
>> 
>> [ This was all in ement.el's source code if I wasn't clear, BTW.  ]
>
> I don't know what ement.el does and whether this is related, but
> here's what was happening in this case:
>
>   . we invoke eww to fetch some URL
>   . before it finishes to fetch the URL, we switch to another window
>   . eww finishes fetching the URL and calls shr.el to render it
>   . shr.el uses the selected window for rendering, and as part of
>     that, it calls set-window-buffer to temporarily make the buffer in
>     which it renders be the buffer of the selected window
>   . set-window-buffer resets the window's hscroll and vscroll values
>   . shr.el calls set-window-buffer inside save-window-excursion, but
>     save-window-excursion didn't preserve the value of vscroll, and in
>     addition shr.el called set-window-hscroll in one place that wasn't
>     inside save-window-excursion
>   . so both vscroll and hscroll of the window showing the image ended
>     up with zero hscroll and vscroll
>   . since image-mode overrides the usual definition of M-> with a
>     command that works by setting the window's hscroll and vscroll,
>     resetting these two makes the (mistaken) impression that the
>     window was scrolled
>   . the reason M-x and M-: appeared to "fix" the problem is that
>     image-mode defines a window-configuration-change-hook that forces
>     the display back to what it was -- this looked to us as if the
>     problem was caused by some redisplay bug, something that took me
>     some time to realize its being completely wrong

Thanks for the explanation, Eli!  If I still the remember the ement.el
code, I think your commit _should_ fix the problem.  But if it doesn't,
at least now I have a better idea of where to look.  Thanks, again.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#56008: 29.0.50; image-mode buffer scrolled down automatically
  2022-06-16 17:20               ` Visuwesh
@ 2022-06-16 17:26                 ` Eli Zaretskii
  0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-06-16 17:26 UTC (permalink / raw)
  To: Visuwesh; +Cc: larsi, 56008-done

> From: Visuwesh <visuweshm@gmail.com>
> Cc: larsi@gnus.org,  56008@debbugs.gnu.org
> Date: Thu, 16 Jun 2022 22:50:12 +0530
> 
> > This bug should be fixed now on the master branch.
> 
> Can confirm that it is fixed, thanks for the quick fix!

Thanks for testing; closing.





^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2022-06-16 17:26 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-16  4:01 bug#56008: 29.0.50; image-mode buffer scrolled down automatically Visuwesh
2022-06-16 12:04 ` Lars Ingebrigtsen
2022-06-16 12:19   ` Lars Ingebrigtsen
2022-06-16 13:19     ` Visuwesh
2022-06-16 13:57       ` Eli Zaretskii
2022-06-16 14:05         ` Lars Ingebrigtsen
2022-06-16 14:14           ` Visuwesh
2022-06-16 15:49             ` Eli Zaretskii
2022-06-16 16:55               ` Visuwesh
2022-06-16 17:11                 ` Eli Zaretskii
2022-06-16 17:23                   ` Visuwesh
2022-06-16 15:48           ` Eli Zaretskii
2022-06-16 16:58             ` Eli Zaretskii
2022-06-16 17:20               ` Visuwesh
2022-06-16 17:26                 ` Eli Zaretskii
2022-06-16 12:52   ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.