unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
@ 2014-02-22  1:51 N. Jackson
  2014-02-22  8:21 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: N. Jackson @ 2014-02-22  1:51 UTC (permalink / raw)
  To: 16840

With an image taller than the window, scrolling behaviour is jerky and
asymmetrical in Eww.

Scrolling Downwards with <down>
===============================
When scrolling down the page (pressing <down> <down> <down> ...), when
the cursor reaches the line above the image, it stops going to the next
line. Instead, the image is smoothly scrolled up in to view. I am told
that this is the designed behaviour.

When the line with the cursor disappears off the top of the window, the
cursor jumps to the image. There is a slight jerk when this happens,
which might be worth eliminating.

At some point (and it's approximately when two lines are visible below
the image) the cursor jumps to the line below the image, and, most
unfortunately, the window scrolls so that that line is the top line in
the window. This results in a huge jerk, and it also means that the
image has disappeared before you can read a caption directly below it.

If the designed behaviour mentioned three paragraphs above this one is
correct, then it would seem better, when the image has scrolled up
sufficiently for the line below it to be visible, if the cursor then
jumped to that line, but stayed on it while additional <down> presses
continued to scroll the image smoothly upwards until the bottom of the
image had disappeared off the top of the window, and then the <down>
presses resumed doing next-line in the normal way.

Scrolling Upwards with <up>
===========================
Currently when scrolling upwards from below an image the behaviour is
completely different (and worse) from that observed when scrolling
downwards from above one. Surely the upward-going behaviour should be
symmetrical with the downward-going behaviour?

Additional Oddities
===================
Furthermore, while scrolling one key press at a time like this, there
are occasional "glitches" where the image jumps back to the position it
was in immediately before scrolling started.

Additionally (and I think this may only happen at the same time as the
"glitches" mentioned above), the cursor column changes from the first
column for no obvious reason, and then appears at the ends of lines of
text instead of at the beginning of them.

===

In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8)
 of 2014-02-19 on moondust
Repository revision: 116484 lekktu@gmail.com-20140219210406-y2s7lx244ojfl5on
Windowing system distributor `Fedora Project', version 11.0.11404000
System Description:	Fedora release 19 (Schrödinger’s Cat)

Configured using:
 `configure --prefix=/home/nlj/local/'

Important settings:
  value of $LC_MONETARY: en_DK.utf8
  value of $LC_NUMERIC: en_DK.utf8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_CA.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  image-minor-mode: t
  diff-auto-refine-mode: t
  recentf-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  display-time-mode: t
  display-battery-mode: t
  cua-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <down-mouse-1> <mouse-movement> 
<mouse-1> <down-mouse-3> <mouse-3> <down-mouse-4> <mouse-4> 
<double-down-mouse-4> <double-mouse-4> <down-mouse-7> 
<mouse-7> <double-down-mouse-7> <double-mouse-7> <triple-down-mouse-7> 
<triple-mouse-7> <triple-down-mouse-7> <triple-mouse-7> 
<triple-down-mouse-7> <triple-mouse-7> <triple-down-mouse-7> 
<triple-mouse-7> <triple-down-mouse-7> <triple-mouse-7> 
<triple-down-mouse-7> <triple-mouse-7> <triple-down-mouse-7> 
<triple-mouse-7> <triple-down-mouse-7> <triple-mouse-7> 
<triple-down-mouse-7> <triple-mouse-7> <triple-down-mouse-7> 
<triple-mouse-7> <down-mouse-6> <mouse-6> <double-down-mouse-6> 
<double-mouse-6> <triple-down-mouse-6> <triple-mouse-6> 
<triple-down-mouse-6> <triple-mouse-6> <triple-down-mouse-6> 
<triple-mouse-6> <triple-down-mouse-6> <triple-mouse-6> 
<triple-down-mouse-6> <triple-mouse-6> <triple-down-mouse-6> 
<triple-mouse-6> <triple-down-mouse-6> <triple-mouse-6> 
<triple-down-mouse-6> <triple-mouse-6> <triple-down-mouse-6> 
<triple-mouse-6> <triple-down-mouse-6> <triple-mouse-6> 
<down-mouse-5> <mouse-5> <down-mouse-6> <mouse-6> <double-down-mouse-6> 
<double-mouse-6> <triple-down-mouse-6> <triple-mouse-6> 
<down-mouse-4> <mouse-4> <double-down-mouse-4> <double-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <switch-frame> 
M-x r e p o r t - <tab> <return>

Recent messages:
Auto-saving...done
<mouse-7> is undefined
<double-mouse-7> is undefined
<triple-mouse-7> is undefined [10 times]
<mouse-6> is undefined
<double-mouse-6> is undefined
<triple-mouse-6> is undefined [10 times]
<mouse-6> is undefined
<double-mouse-6> is undefined
<triple-mouse-6> is undefined
byte-code: Beginning of buffer [2 times]

Load-path shadows:
/home/nlj/.emacs.d/elpa/org-20140217/ob-makefile hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-makefile
/home/nlj/.emacs.d/elpa/org-20140217/ob-io hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-io
/home/nlj/.emacs.d/elpa/org-20140217/org-pcomplete hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-pcomplete
/home/nlj/.emacs.d/elpa/org-20140217/ob-comint hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-comint
/home/nlj/.emacs.d/elpa/org-20140217/ob-awk hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-awk
/home/nlj/.emacs.d/elpa/org-20140217/ob-eval hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-eval
/home/nlj/.emacs.d/elpa/org-20140217/org-entities hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-entities
/home/nlj/.emacs.d/elpa/org-20140217/org-irc hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-irc
/home/nlj/.emacs.d/elpa/org-20140217/ob-exp hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-exp
/home/nlj/.emacs.d/elpa/org-20140217/ox-icalendar hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-icalendar
/home/nlj/.emacs.d/elpa/org-20140217/ob-lisp hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-lisp
/home/nlj/.emacs.d/elpa/org-20140217/org-colview hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-colview
/home/nlj/.emacs.d/elpa/org-20140217/ob-sql hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-sql
/home/nlj/.emacs.d/elpa/org-20140217/org-w3m hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-w3m
/home/nlj/.emacs.d/elpa/org-20140217/ob-java hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-java
/home/nlj/.emacs.d/elpa/org-20140217/org-crypt hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-crypt
/home/nlj/.emacs.d/elpa/org-20140217/ob-css hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-css
/home/nlj/.emacs.d/elpa/org-20140217/org-docview hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-docview
/home/nlj/.emacs.d/elpa/org-20140217/org-macro hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-macro
/home/nlj/.emacs.d/elpa/org-20140217/ob-picolisp hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-picolisp
/home/nlj/.emacs.d/elpa/org-20140217/ob-octave hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-octave
/home/nlj/.emacs.d/elpa/org-20140217/ob-dot hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-dot
/home/nlj/.emacs.d/elpa/org-20140217/org-mouse hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-mouse
/home/nlj/.emacs.d/elpa/org-20140217/org-feed hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-feed
/home/nlj/.emacs.d/elpa/org-20140217/ob-C hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-C
/home/nlj/.emacs.d/elpa/org-20140217/org-timer hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-timer
/home/nlj/.emacs.d/elpa/org-20140217/org-archive hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-archive
/home/nlj/.emacs.d/elpa/org-20140217/org hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org
/home/nlj/.emacs.d/elpa/org-20140217/org-capture hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-capture
/home/nlj/.emacs.d/elpa/org-20140217/ob-lilypond hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-lilypond
/home/nlj/.emacs.d/elpa/org-20140217/org-indent hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-indent
/home/nlj/.emacs.d/elpa/org-20140217/org-bbdb hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-bbdb
/home/nlj/.emacs.d/elpa/org-20140217/org-inlinetask hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-inlinetask
/home/nlj/.emacs.d/elpa/org-20140217/ob-maxima hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-maxima
/home/nlj/.emacs.d/elpa/org-20140217/ob-ocaml hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-ocaml
/home/nlj/.emacs.d/elpa/org-20140217/org-faces hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-faces
/home/nlj/.emacs.d/elpa/org-20140217/ob-ledger hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-ledger
/home/nlj/.emacs.d/elpa/org-20140217/ob-js hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-js
/home/nlj/.emacs.d/elpa/org-20140217/ob-scheme hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-scheme
/home/nlj/.emacs.d/elpa/org-20140217/ob-emacs-lisp hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-emacs-lisp
/home/nlj/.emacs.d/elpa/org-20140217/ob-sass hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-sass
/home/nlj/.emacs.d/elpa/org-20140217/ox-beamer hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-beamer
/home/nlj/.emacs.d/elpa/org-20140217/ob-gnuplot hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-gnuplot
/home/nlj/.emacs.d/elpa/org-20140217/org-element hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-element
/home/nlj/.emacs.d/elpa/org-20140217/ob-ref hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-ref
/home/nlj/.emacs.d/elpa/org-20140217/org-gnus hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-gnus
/home/nlj/.emacs.d/elpa/org-20140217/ox-man hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-man
/home/nlj/.emacs.d/elpa/org-20140217/org-rmail hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-rmail
/home/nlj/.emacs.d/elpa/org-20140217/ob hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob
/home/nlj/.emacs.d/elpa/org-20140217/org-bibtex hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-bibtex
/home/nlj/.emacs.d/elpa/org-20140217/ox-html hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-html
/home/nlj/.emacs.d/elpa/org-20140217/org-footnote hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-footnote
/home/nlj/.emacs.d/elpa/org-20140217/ob-ruby hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-ruby
/home/nlj/.emacs.d/elpa/org-20140217/ob-shen hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-shen
/home/nlj/.emacs.d/elpa/org-20140217/ox-latex hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-latex
/home/nlj/.emacs.d/elpa/org-20140217/ob-perl hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-perl
/home/nlj/.emacs.d/elpa/org-20140217/ob-calc hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-calc
/home/nlj/.emacs.d/elpa/org-20140217/ob-clojure hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-clojure
/home/nlj/.emacs.d/elpa/org-20140217/ob-latex hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-latex
/home/nlj/.emacs.d/elpa/org-20140217/org-macs hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-macs
/home/nlj/.emacs.d/elpa/org-20140217/ob-table hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-table
/home/nlj/.emacs.d/elpa/org-20140217/ox-odt hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-odt
/home/nlj/.emacs.d/elpa/org-20140217/org-datetree hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-datetree
/home/nlj/.emacs.d/elpa/org-20140217/ox-publish hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-publish
/home/nlj/.emacs.d/elpa/org-20140217/org-mhe hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-mhe
/home/nlj/.emacs.d/elpa/org-20140217/org-list hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-list
/home/nlj/.emacs.d/elpa/org-20140217/org-clock hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-clock
/home/nlj/.emacs.d/elpa/org-20140217/ob-sh hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-sh
/home/nlj/.emacs.d/elpa/org-20140217/ob-R hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-R
/home/nlj/.emacs.d/elpa/org-20140217/ob-core hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-core
/home/nlj/.emacs.d/elpa/org-20140217/org-id hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-id
/home/nlj/.emacs.d/elpa/org-20140217/org-mobile hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-mobile
/home/nlj/.emacs.d/elpa/org-20140217/ob-keys hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-keys
/home/nlj/.emacs.d/elpa/org-20140217/org-agenda hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-agenda
/home/nlj/.emacs.d/elpa/org-20140217/org-ctags hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-ctags
/home/nlj/.emacs.d/elpa/org-20140217/org-attach hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-attach
/home/nlj/.emacs.d/elpa/org-20140217/ob-screen hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-screen
/home/nlj/.emacs.d/elpa/org-20140217/ob-ditaa hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-ditaa
/home/nlj/.emacs.d/elpa/org-20140217/ob-plantuml hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-plantuml
/home/nlj/.emacs.d/elpa/org-20140217/org-habit hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-habit
/home/nlj/.emacs.d/elpa/org-20140217/ob-lob hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-lob
/home/nlj/.emacs.d/elpa/org-20140217/org-loaddefs hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-loaddefs
/home/nlj/.emacs.d/elpa/org-20140217/org-info hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-info
/home/nlj/.emacs.d/elpa/org-20140217/org-eshell hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-eshell
/home/nlj/.emacs.d/elpa/org-20140217/org-version hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-version
/home/nlj/.emacs.d/elpa/org-20140217/ob-haskell hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-haskell
/home/nlj/.emacs.d/elpa/org-20140217/ob-org hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-org
/home/nlj/.emacs.d/elpa/org-20140217/org-compat hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-compat
/home/nlj/.emacs.d/elpa/org-20140217/org-table hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-table
/home/nlj/.emacs.d/elpa/org-20140217/ob-python hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-python
/home/nlj/.emacs.d/elpa/org-20140217/org-src hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-src
/home/nlj/.emacs.d/elpa/org-20140217/org-plot hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-plot
/home/nlj/.emacs.d/elpa/org-20140217/ox-texinfo hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-texinfo
/home/nlj/.emacs.d/elpa/org-20140217/ob-sqlite hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-sqlite
/home/nlj/.emacs.d/elpa/org-20140217/ox hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox
/home/nlj/.emacs.d/elpa/org-20140217/ob-tangle hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-tangle
/home/nlj/.emacs.d/elpa/org-20140217/ob-matlab hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-matlab
/home/nlj/.emacs.d/elpa/org-20140217/ox-md hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-md
/home/nlj/.emacs.d/elpa/org-20140217/ox-org hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-org
/home/nlj/.emacs.d/elpa/org-20140217/ox-ascii hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ox-ascii
/home/nlj/.emacs.d/elpa/org-20140217/ob-mscgen hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-mscgen
/home/nlj/.emacs.d/elpa/org-20140217/ob-fortran hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-fortran
/home/nlj/.emacs.d/elpa/org-20140217/org-install hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-install
/home/nlj/.emacs.d/elpa/org-20140217/org-protocol hides /home/nlj/local/share/emacs/24.3.50/lisp/org/org-protocol
/home/nlj/.emacs.d/elpa/org-20140217/ob-asymptote hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-asymptote
/home/nlj/.emacs.d/elpa/org-20140217/ob-scala hides /home/nlj/local/share/emacs/24.3.50/lisp/org/ob-scala

Features:
(shadow emacsbug shr-color color ibuf-ext ibuffer eieio-opt speedbar
sb-image ezimage dframe help-mode url-queue eww shr browse-url bookmark
pp mailalias smtpmail bbdb-message sendmail nnir tabify org-capture
org-element org-rmail org-mhe org-irc org-info org-gnus org-docview
doc-view image-mode dired org-bibtex bibtex org-bbdb org-w3m gnus-uu
yenc diff-mode jka-compr sort smiley gnus-cite flow-fill mm-archive
gnus-bcklg gnus-async gnus-kill qp mail-extr gnus-ml disp-table nndraft
nnmh url-http url-gw url-cache url-auth url-handlers nnrss xml mm-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse url-vars utf-7 nnimap utf7 gnutls nnfolder
parse-time bbdb-gnus bbdb-mua bbdb-com crm epa-file epa derived epg
netrc network-stream auth-source eieio eieio-core starttls tls
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 epg-config mm-view mml-smime smime password-cache dig
mailcap nntp gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail
mail-source gnus-start gnus-spec gnus-int gnus-range message rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems
nnheader gnus-util mail-utils mm-util mail-prsvr org byte-opt bytecomp
byte-compile cconv advice help-fns org-macro org-footnote org-pcomplete
pcomplete org-list org-faces org-entities noutline outline easy-mmode
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs bbdb bbdb-site timezone bbdb-loaddefs csv-mode-autoloads
info package edmacro kmacro recentf tree-widget wid-edit cl-loaddefs
cl-lib easymenu saveplace wheatgrass-theme delsel paren time battery
cua-base cus-start cus-load time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2014-02-22  1:51 bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww N. Jackson
@ 2014-02-22  8:21 ` Eli Zaretskii
  2014-02-22 17:15   ` N. Jackson
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-02-22  8:21 UTC (permalink / raw)
  To: N. Jackson; +Cc: 16840

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Fri, 21 Feb 2014 21:51:47 -0400
> 
> With an image taller than the window, scrolling behaviour is jerky and
> asymmetrical in Eww.

Please provide a URL to such an image, since the exact behavior
depends on the relative sizes of the image and the default font.

Also, does the behavior you describe happen in "emacs -Q", or do you
need some non-default customizations to see what you describe?

> Scrolling Downwards with <down>
> ===============================
> When scrolling down the page (pressing <down> <down> <down> ...), when
> the cursor reaches the line above the image, it stops going to the next
> line. Instead, the image is smoothly scrolled up in to view. I am told
> that this is the designed behaviour.

Yes, that's the design.

> When the line with the cursor disappears off the top of the window, the
> cursor jumps to the image. There is a slight jerk when this happens,
> which might be worth eliminating.

The jerk should bring the top of the image to the top of the window.
If that is what happens, then that's the intended behavior.

> At some point (and it's approximately when two lines are visible below
> the image) the cursor jumps to the line below the image, and, most
> unfortunately, the window scrolls so that that line is the top line in
> the window. This results in a huge jerk, and it also means that the
> image has disappeared before you can read a caption directly below it.

Wasn't the caption visible before the jump?

In any case, it's impossible to reason about the described behavior
without knowing the image size and size of the font used to display
text around it.

> If the designed behaviour mentioned three paragraphs above this one is
> correct, then it would seem better, when the image has scrolled up
> sufficiently for the line below it to be visible, if the cursor then
> jumped to that line, but stayed on it while additional <down> presses
> continued to scroll the image smoothly upwards until the bottom of the
> image had disappeared off the top of the window, and then the <down>
> presses resumed doing next-line in the normal way.

This is next to impossible with the current design of scrolling in
Emacs.  The goal of pixel-level scrolling in Emacs 24 is to allow the
user a chance to see every part of the image at least once.  If that
goal is reached, the rest are deeper limitations of the current
design, and will require significant changes, not just in the area of
scrolling tall images.

> Scrolling Upwards with <up>
> ===========================
> Currently when scrolling upwards from below an image the behaviour is
> completely different (and worse) from that observed when scrolling
> downwards from above one. Surely the upward-going behaviour should be
> symmetrical with the downward-going behaviour?

No, it should not (and cannot) be symmetrical, for boring technical
reasons.  Again, if the user doesn't have a chance of seeing each part
of the image at least once, please describe the details.

> Furthermore, while scrolling one key press at a time like this, there
> are occasional "glitches" where the image jumps back to the position it
> was in immediately before scrolling started.

I don't see it with images I tried.  It would be best if you could
provide a reproducible recipe, with a specific image, starting from
"emacs -Q", that shows these glitches.

> Additionally (and I think this may only happen at the same time as the
> "glitches" mentioned above), the cursor column changes from the first
> column for no obvious reason, and then appears at the ends of lines of
> text instead of at the beginning of them.

Likewise.

Thanks.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2014-02-22  8:21 ` Eli Zaretskii
@ 2014-02-22 17:15   ` N. Jackson
  2014-02-22 18:05     ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: N. Jackson @ 2014-02-22 17:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 16840

At 04:21 -0400 on Saturday 2014-02-22, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Fri, 21 Feb 2014 21:51:47 -0400
>> 
>> With an image taller than the window, scrolling behaviour is jerky and
>> asymmetrical in Eww.
>
> Please provide a URL to such an image, since the exact behavior
> depends on the relative sizes of the image and the default font.

I saw the same general behaviour with all of the few pages I
visited. The one I did my detailed examination on was
http://www.gnu.org/distros/screenshot.html.

> Also, does the behavior you describe happen in "emacs -Q", or do you
> need some non-default customizations to see what you describe?

Yes, with "emacs -Q".

For example this recipe (where the maximize before loading the page is
just to get the image big enough to be taller than the frame (as Eww
(sensibly, I think) resizes images to fit in the frame when it loads a
page). On my machine this makes the image slightly less than twice the
height of the display.

    emacs -Q
    M-x toggle-frame-maximized RET
    M-x eww RET http://www.gnu.org/distros/screenshot.html RET
    M-x toggle-frame-maximized RET

>> Scrolling Downwards with <down>
>> ===============================
>> When scrolling down the page (pressing <down> <down> <down> ...), when
>> the cursor reaches the line above the image, it stops going to the next
>> line. Instead, the image is smoothly scrolled up in to view. I am told
>> that this is the designed behaviour.
>
> Yes, that's the design.
>
>> When the line with the cursor disappears off the top of the window, the
>> cursor jumps to the image. There is a slight jerk when this happens,
>> which might be worth eliminating.
>
> The jerk should bring the top of the image to the top of the window.
> If that is what happens, then that's the intended behavior.

Yes. That's what happens.

If it's the current intended behaviour, then that is what it is. I
raised this bug report to point out that the behaviour I observe is
sub-optimal from a user-experience point of view, Emacs could be better
in this regard. Consider it then, perhaps, as a wishlist item for Emacs
25 or 26!

I myself am a bit ambivalent about this suddenly having images in
Emacs. I'm not sure that I like them, and I'm certain that I don't need
them. However to be able to view web pages within Emacs seems useful,
and in checking out this functionality in Emacs 24.3.50 I noticed the
perceived deficiencies reported, so I reported them, because I believe
that it's hard to improve something when one isn't aware of what might
be wrong with it.

>> At some point (and it's approximately when two lines are visible below
>> the image) the cursor jumps to the line below the image, and, most
>> unfortunately, the window scrolls so that that line is the top line in
>> the window. This results in a huge jerk, and it also means that the
>> image has disappeared before you can read a caption directly below it.
>
> Wasn't the caption visible before the jump?

The first line of it, but if there were a two-line gap instead of a
one-line gap between the image and its caption, it wouldn't be visible.

But if the intended behaviour is that the window should scroll to bring
the line below the image to the top of the window when a line or two
below the image becomes visible, then it is impossible in general with
an imgage taller than the frame to see text below the image that
pertains to it while the image is still in view (unless that text
happens to be only one or two lines long).

> In any case, it's impossible to reason about the described behavior
> without knowing the image size and size of the font used to display
> text around it.

    M-x describe-font RET

    name (opened by): -xos4-Terminus-normal-normal-normal-*-12-*-*-*-c-60-iso10646-1
           full name: Terminus:pixelsize=12:foundry=xos4:weight=normal:slant=normal:width=normal:spacing=110:scalable=false
                size: 12
              height: 12
     baseline-offset:  0
    relative-compose:  0

>> If the designed behaviour mentioned three paragraphs above this one is
>> correct, then it would seem better, when the image has scrolled up
>> sufficiently for the line below it to be visible, if the cursor then
>> jumped to that line, but stayed on it while additional <down> presses
>> continued to scroll the image smoothly upwards until the bottom of the
>> image had disappeared off the top of the window, and then the <down>
>> presses resumed doing next-line in the normal way.
>
> This is next to impossible with the current design of scrolling in
> Emacs.

Fair enough. From ignorance one may stipulate impossible
requirements. Yet it's not impossible that in such naive requirements
lies a germ of a better future Emacs.

> The goal of pixel-level scrolling in Emacs 24 is to allow the
> user a chance to see every part of the image at least once.

I believe human perception requires more than that.

I don't know about pixel-level scrolling. Naively (again) I feel that
even charcter-wise line-by-line scrolling would be far smoother that the
current observed behaviour if "behind" the image there were inserted as
many empty lines of text as needed to span the height of the image.

> If that goal is reached, the rest are deeper limitations of the
> current design, and will require significant changes, not just in the
> area of scrolling tall images.

Fair enough. I was ignorant of the fact that the failings of the current
behaviour were intentional, due to contraints of the existing infrastructure.

>> Scrolling Upwards with <up>
>> ===========================
>> Currently when scrolling upwards from below an image the behaviour is
>> completely different (and worse) from that observed when scrolling
>> downwards from above one. Surely the upward-going behaviour should be
>> symmetrical with the downward-going behaviour?
>
> No, it should not (and cannot) be symmetrical, for boring technical
> reasons.

From the point-of-view of an ideal interface, yes it should, in my
opinion, be symmetrical. But the ideal can never be realised or it is no
longer ideal, and in this case, obviously there are very practical
reasons as well.

> Again, if the user doesn't have a chance of seeing each part
> of the image at least once, please describe the details.

It works in the way you describe aside from the "glitches" (below)
and those allow the user to see the same part of the image more than once!

>> Furthermore, while scrolling one key press at a time like this, there
>> are occasional "glitches" where the image jumps back to the position it
>> was in immediately before scrolling started.
>
> I don't see it with images I tried.  It would be best if you could
> provide a reproducible recipe, with a specific image, starting from
> "emacs -Q", that shows these glitches.

If it is reproducible on demand, I don't see the pattern. That's what I
meant by the "occasional" in my description.

However, using the recipe provided earlier in this message, I saw it
happen thrice while scrolling up and down the page maybe seven or eight
times, so it is not uncommon on my set up.

I only see it happenning going down the page. (I had previously seen a
very similar "glitch" going up the page, but I realise now that that was
with an image in a Gnus message not an image in Eww -- I don't know if
there is any commonality in the code involved.)

>> Additionally (and I think this may only happen at the same time as the
>> "glitches" mentioned above), the cursor column changes from the first
>> column for no obvious reason, and then appears at the ends of lines of
>> text instead of at the beginning of them.
>
> Likewise.

After the "glitch" occurs at the beginning of scrolling an image, when
the cursor emerges in the text below the image it is at the ends of the
lines instead of in the first column. This seems to happen consistently
after the "glitch" occurs.

> Thanks.

Thank you.

N.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2014-02-22 17:15   ` N. Jackson
@ 2014-02-22 18:05     ` Eli Zaretskii
  2015-12-25  7:43       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2014-02-22 18:05 UTC (permalink / raw)
  To: N. Jackson; +Cc: 16840

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc:  bug-gnu-emacs@gnu.org
> Date: Sat, 22 Feb 2014 13:15:53 -0400
> 
> >> At some point (and it's approximately when two lines are visible below
> >> the image) the cursor jumps to the line below the image, and, most
> >> unfortunately, the window scrolls so that that line is the top line in
> >> the window. This results in a huge jerk, and it also means that the
> >> image has disappeared before you can read a caption directly below it.
> >
> > Wasn't the caption visible before the jump?
> 
> The first line of it, but if there were a two-line gap instead of a
> one-line gap between the image and its caption, it wouldn't be visible.

But a two-line gap would mean one more empty line, so I think the
caption would still be visible.

> >> Furthermore, while scrolling one key press at a time like this, there
> >> are occasional "glitches" where the image jumps back to the position it
> >> was in immediately before scrolling started.
> >
> > I don't see it with images I tried.  It would be best if you could
> > provide a reproducible recipe, with a specific image, starting from
> > "emacs -Q", that shows these glitches.
> 
> If it is reproducible on demand, I don't see the pattern. That's what I
> meant by the "occasional" in my description.

I think I found the way of reproducing this, and I will look into
that.

> After the "glitch" occurs at the beginning of scrolling an image, when
> the cursor emerges in the text below the image it is at the ends of the
> lines instead of in the first column. This seems to happen consistently
> after the "glitch" occurs.

Yes, I see this also.

Thanks.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2014-02-22 18:05     ` Eli Zaretskii
@ 2015-12-25  7:43       ` Lars Ingebrigtsen
  2015-12-25  8:01         ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-25  7:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: N. Jackson, 16840

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Furthermore, while scrolling one key press at a time like this, there
>> >> are occasional "glitches" where the image jumps back to the position it
>> >> was in immediately before scrolling started.
>> >
>> > I don't see it with images I tried.  It would be best if you could
>> > provide a reproducible recipe, with a specific image, starting from
>> > "emacs -Q", that shows these glitches.
>> 
>> If it is reproducible on demand, I don't see the pattern. That's what I
>> meant by the "occasional" in my description.
>
> I think I found the way of reproducing this, and I will look into
> that.

Did you get any further with this, by any chance?  Cursor movement and
scrolling is still somewhat unpredictable.  With visual line mode, my
expectation is that hitting the down key will take me to the next
visible line, and that doesn't always happen, especially with large-ish
images.

But it's much better now than when this bug report was created a couple
years ago...

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25  7:43       ` Lars Ingebrigtsen
@ 2015-12-25  8:01         ` Eli Zaretskii
  2015-12-25 16:54           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2015-12-25  8:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com (N. Jackson),  16840@debbugs.gnu.org
> Date: Fri, 25 Dec 2015 08:43:37 +0100
> 
> > I think I found the way of reproducing this, and I will look into
> > that.
> 
> Did you get any further with this, by any chance?

I have vague recollection that I did, but I have no proof.  Sorry.

Can you show a URL and describe the gestures to reproduce the problem?





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25  8:01         ` Eli Zaretskii
@ 2015-12-25 16:54           ` Lars Ingebrigtsen
  2015-12-25 17:04             ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-25 16:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: nljlistbox2@gmail.com (N. Jackson),  16840@debbugs.gnu.org
>> Date: Fri, 25 Dec 2015 08:43:37 +0100
>> 
>> > I think I found the way of reproducing this, and I will look into
>> > that.
>> 
>> Did you get any further with this, by any chance?
>
> I have vague recollection that I did, but I have no proof.  Sorry.
>
> Can you show a URL and describe the gestures to reproduce the problem?

I don't have any handy, and they are probably dependent on the screen
size, the font size and the window sizes.  But these glitches usually
show up after a while if you use eww on web sites that have many images,
like newspaper web sites.

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 16:54           ` Lars Ingebrigtsen
@ 2015-12-25 17:04             ` Eli Zaretskii
  2015-12-25 17:28               ` Lars Ingebrigtsen
  2015-12-25 19:01               ` N. Jackson
  0 siblings, 2 replies; 23+ messages in thread
From: Eli Zaretskii @ 2015-12-25 17:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16840@debbugs.gnu.org,  nljlistbox2@gmail.com
> Date: Fri, 25 Dec 2015 17:54:26 +0100
> 
> > Can you show a URL and describe the gestures to reproduce the problem?
> 
> I don't have any handy, and they are probably dependent on the screen
> size, the font size and the window sizes.  But these glitches usually
> show up after a while if you use eww on web sites that have many images,
> like newspaper web sites.

How about if you tell me the next time you see one of those?





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 17:04             ` Eli Zaretskii
@ 2015-12-25 17:28               ` Lars Ingebrigtsen
  2015-12-25 19:56                 ` Eli Zaretskii
  2015-12-25 19:01               ` N. Jackson
  1 sibling, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-25 17:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> How about if you tell me the next time you see one of those?

I just went to http://salon.com and held <down> down.  Sometimes it takes
me to the next line, and sometimes it scrolls semi-displayed images...

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 17:04             ` Eli Zaretskii
  2015-12-25 17:28               ` Lars Ingebrigtsen
@ 2015-12-25 19:01               ` N. Jackson
  2015-12-25 19:58                 ` Eli Zaretskii
  1 sibling, 1 reply; 23+ messages in thread
From: N. Jackson @ 2015-12-25 19:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 16840

Hi Eli,

At 13:04 -0400 on Friday 2015-12-25, Eli Zaretskii wrote:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: 16840@debbugs.gnu.org,  nljlistbox2@gmail.com
>> Date: Fri, 25 Dec 2015 17:54:26 +0100
>> 
>> > Can you show a URL and describe the gestures to reproduce the
>> > problem?
>> 
>> I don't have any handy, and they are probably dependent on the
>> screen size, the font size and the window sizes. But these glitches
>> usually show up after a while if you use eww on web sites that have
>> many images, like newspaper web sites.
>
> How about if you tell me the next time you see one of those?

Testing this afternoon, here's a recipe that shows the problem for me
(on Emacs 24):

1. emacs -Q [1]

2. M-x eww

3. Enter http://www.fsf.org/campaigns/ at the prompt [2]

4. M-x split-window-below (this is to make the images taller than the
window)

5. Scroll down the page with C-n, down to the heading "Secure Boot vs
Restricted Boot" (about 51 lines)

6. C-n to the blank line above the image

7. C-n eight times (this scrolls the image at one would expect, one
"line" at a time)

8. C-n again
   
[1] Emacs 24.5. Default font is coming up as
-xos4-Terminus-normal-normal-normal-*-12-*-*-*-c-60-iso10646-1.

[2] Accessed 2015-12-25 18:13 UTC.

The `C-n's in Step 7 scroll the image as one would expect. At the
second last of those `C-n's, the heading "Secure Boot vs Restricted
Boot" scrolls off the top of the window. At the next `C-n' the blank
line below the image is at the top of the window.

At the next `C-n' (Step 8) which I understand is supposed to move
point to the line below the image [Although it would be awesome if it
could continue scrolling the image one "line" at a time.], the
scrolling "glitches" and point moves _up_ again to the blank line
above the image.

I will install Emacs 25 now and report back whether I still see the
same behaviour on this system.

Regards,
Neil.






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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 17:28               ` Lars Ingebrigtsen
@ 2015-12-25 19:56                 ` Eli Zaretskii
  0 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2015-12-25 19:56 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16840@debbugs.gnu.org,  nljlistbox2@gmail.com
> Date: Fri, 25 Dec 2015 18:28:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How about if you tell me the next time you see one of those?
> 
> I just went to http://salon.com and held <down> down.  Sometimes it takes
> me to the next line, and sometimes it scrolls semi-displayed images...

Thanks.  I see nothing wrong in the behavior there, it does what it
was supposed to do, given the arrangement of the images and the window
size.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 19:01               ` N. Jackson
@ 2015-12-25 19:58                 ` Eli Zaretskii
  2019-09-26 16:58                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2015-12-25 19:58 UTC (permalink / raw)
  To: N. Jackson; +Cc: larsi, 16840

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  16840@debbugs.gnu.org
> Date: Fri, 25 Dec 2015 15:01:21 -0400
> 
> The `C-n's in Step 7 scroll the image as one would expect. At the
> second last of those `C-n's, the heading "Secure Boot vs Restricted
> Boot" scrolls off the top of the window. At the next `C-n' the blank
> line below the image is at the top of the window.
> 
> At the next `C-n' (Step 8) which I understand is supposed to move
> point to the line below the image [Although it would be awesome if it
> could continue scrolling the image one "line" at a time.], the
> scrolling "glitches" and point moves _up_ again to the blank line
> above the image.

That's an entirely different problem: Emacs doesn't find a good place
to start the window, so it recenters the window.  I will look into it
when I have time.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2015-12-25 19:58                 ` Eli Zaretskii
@ 2019-09-26 16:58                   ` Lars Ingebrigtsen
  2019-09-26 17:11                     ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-26 16:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: N. Jackson, 16840

Eli Zaretskii <eliz@gnu.org> writes:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  16840@debbugs.gnu.org
>> Date: Fri, 25 Dec 2015 15:01:21 -0400
>> 
>> The `C-n's in Step 7 scroll the image as one would expect. At the
>> second last of those `C-n's, the heading "Secure Boot vs Restricted
>> Boot" scrolls off the top of the window. At the next `C-n' the blank
>> line below the image is at the top of the window.
>> 
>> At the next `C-n' (Step 8) which I understand is supposed to move
>> point to the line below the image [Although it would be awesome if it
>> could continue scrolling the image one "line" at a time.], the
>> scrolling "glitches" and point moves _up_ again to the blank line
>> above the image.
>
> That's an entirely different problem: Emacs doesn't find a good place
> to start the window, so it recenters the window.  I will look into it
> when I have time.

If you need an easier example to test image scrolling with, here's a
sexp.  :-)

I just find large-image scrolling in Emacs to be kinda
... unpredictable?  But it does work.  But perhaps it would be nicer if
it was somehow less surprising.

(progn
  (switch-to-buffer "*image*")
  (erase-buffer)
  (set-frame-height (window-frame (selected-window)) 1000 nil t)
  (let* ((width 300)
	 (height 800)
	 (svg (svg-create width height)))
    (svg-gradient svg "background" 'linear '((0 . "#b0b0b0") (100 . "#808080")))
    (svg-rectangle svg 0 0 width height :gradient "background"
                   :stroke-width 2 :stroke-color "black")
    (dotimes (i 30)
      (insert (format "%d\n" i)))
    (svg-insert-image svg)
    (insert "\n")
    (dotimes (i 30)
      (insert (format "%d\n" i)))
    (goto-char (point-min))))

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 16:58                   ` Lars Ingebrigtsen
@ 2019-09-26 17:11                     ` Eli Zaretskii
  2019-09-26 17:19                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2019-09-26 17:11 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com (N. Jackson),  16840@debbugs.gnu.org
> Date: Thu, 26 Sep 2019 18:58:02 +0200
> 
> If you need an easier example to test image scrolling with, here's a
> sexp.  :-)

I don't need another example, I need someone who'd be willing to look
into these problems and fix them.  It isn't right for Emacs to depend
on a single curmudgeon for fixing all the display glitches: what if
I'm run over by a bus or something?

> (progn
>   (switch-to-buffer "*image*")
>   (erase-buffer)
>   (set-frame-height (window-frame (selected-window)) 1000 nil t)
>   (let* ((width 300)
> 	 (height 800)
> 	 (svg (svg-create width height)))
>     (svg-gradient svg "background" 'linear '((0 . "#b0b0b0") (100 . "#808080")))
>     (svg-rectangle svg 0 0 width height :gradient "background"
>                    :stroke-width 2 :stroke-color "black")
>     (dotimes (i 30)
>       (insert (format "%d\n" i)))
>     (svg-insert-image svg)
>     (insert "\n")
>     (dotimes (i 30)
>       (insert (format "%d\n" i)))
>     (goto-char (point-min))))

I get an empty window showing nothing.  What did I miss?  And how is
this related to the issue at hand, may I ask?





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 17:11                     ` Eli Zaretskii
@ 2019-09-26 17:19                       ` Lars Ingebrigtsen
  2019-09-26 17:55                         ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-26 17:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> I don't need another example, I need someone who'd be willing to look
> into these problems and fix them.  It isn't right for Emacs to depend
> on a single curmudgeon for fixing all the display glitches: what if
> I'm run over by a bus or something?

We need more curmudgeons!

Oops.  Did I just volunteer myself?

> I get an empty window showing nothing.  What did I miss?  And how is
> this related to the issue at hand, may I ask?

Hm, you were supposed to get a window with some text, and then an image
higher than the frame, and then some more text, which demonstrates one
of the issues discussed in this bug report...

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 17:19                       ` Lars Ingebrigtsen
@ 2019-09-26 17:55                         ` Eli Zaretskii
  2019-09-26 18:03                           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2019-09-26 17:55 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  16840@debbugs.gnu.org
> Date: Thu, 26 Sep 2019 19:19:31 +0200
> 
> > I get an empty window showing nothing.  What did I miss?  And how is
> > this related to the issue at hand, may I ask?
> 
> Hm, you were supposed to get a window with some text, and then an image
> higher than the frame, and then some more text, which demonstrates one
> of the issues discussed in this bug report...

Ah, I see: it lacked (load "svg").

But after that, I see no issues with scrolling, none at all.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 17:55                         ` Eli Zaretskii
@ 2019-09-26 18:03                           ` Lars Ingebrigtsen
  2019-09-26 18:32                             ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-26 18:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> But after that, I see no issues with scrolling, none at all.

I get (when hitting `down' from the start of the buffer) that I advance
line by line until I hit the image, and then I suddenly get a big jump,
and about half the window displays the top of the image.

Then hitting `down' some more, it advances line by line.

Then when we get to the end of the image, I get "0 1" at the bottom of
the frame, and then I hit `down' once more, and then nothing of the
image is displayed.

Going back up, things are a bit less surprising.

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 18:03                           ` Lars Ingebrigtsen
@ 2019-09-26 18:32                             ` Eli Zaretskii
  2019-09-26 18:34                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2019-09-26 18:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  16840@debbugs.gnu.org
> Date: Thu, 26 Sep 2019 20:03:21 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But after that, I see no issues with scrolling, none at all.
> 
> I get (when hitting `down' from the start of the buffer) that I advance
> line by line until I hit the image, and then I suddenly get a big jump,
> and about half the window displays the top of the image.
> 
> Then hitting `down' some more, it advances line by line.
> 
> Then when we get to the end of the image, I get "0 1" at the bottom of
> the frame, and then I hit `down' once more, and then nothing of the
> image is displayed.

This is all as expected, so there's no bug here.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 18:32                             ` Eli Zaretskii
@ 2019-09-26 18:34                               ` Lars Ingebrigtsen
  2019-09-26 18:50                                 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-26 18:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> This is all as expected, so there's no bug here.

Well, you may expect it, but this bug report is about how apparently a
lot of other people find it surprising.

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 18:34                               ` Lars Ingebrigtsen
@ 2019-09-26 18:50                                 ` Eli Zaretskii
  2019-09-27 14:12                                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2019-09-26 18:50 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  16840@debbugs.gnu.org
> Date: Thu, 26 Sep 2019 20:34:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is all as expected, so there's no bug here.
> 
> Well, you may expect it, but this bug report is about how apparently a
> lot of other people find it surprising.

I don't understand why.

Your code generates an image whose height is smaller than the window
height, and in that case Emacs scrolls the entire image off the window
in one go, because all of the image was already visible once.  If I
decrease the frame height so that the image becomes taller than the
window, the image is scrolled partially until you had a chance to see
all of it, then the rest is scrolled away in one large step.  This is
exactly how the code in simple.el is designed and implemented, so I
see no bug here.

Once again, the principle is to make sure the user sees all of the
image before the image is scrolled off the viewport.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-26 18:50                                 ` Eli Zaretskii
@ 2019-09-27 14:12                                   ` Lars Ingebrigtsen
  2019-09-27 14:29                                     ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 14:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> Your code generates an image whose height is smaller than the window
> height, and in that case Emacs scrolls the entire image off the window
> in one go, because all of the image was already visible once.

Oh, the

  (set-frame-height (window-frame (selected-window)) 1000 nil t)

bit didn't work?  That was supposed to ensure that the window was
shorter than the image...

> If I decrease the frame height so that the image becomes taller than
> the window, the image is scrolled partially until you had a chance to
> see all of it, then the rest is scrolled away in one large step.  This
> is exactly how the code in simple.el is designed and implemented, so I
> see no bug here.

It might be how it's designed, but it's (as you can see from this bug
report) behaviour that people find surprising.

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





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-27 14:12                                   ` Lars Ingebrigtsen
@ 2019-09-27 14:29                                     ` Eli Zaretskii
  2019-09-27 14:35                                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2019-09-27 14:29 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: nljlistbox2, 16840

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  16840@debbugs.gnu.org
> Date: Fri, 27 Sep 2019 16:12:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Your code generates an image whose height is smaller than the window
> > height, and in that case Emacs scrolls the entire image off the window
> > in one go, because all of the image was already visible once.
> 
> Oh, the
> 
>   (set-frame-height (window-frame (selected-window)) 1000 nil t)
> 
> bit didn't work?  That was supposed to ensure that the window was
> shorter than the image...

Evidently, it didn't.

> > If I decrease the frame height so that the image becomes taller than
> > the window, the image is scrolled partially until you had a chance to
> > see all of it, then the rest is scrolled away in one large step.  This
> > is exactly how the code in simple.el is designed and implemented, so I
> > see no bug here.
> 
> It might be how it's designed, but it's (as you can see from this bug
> report) behaviour that people find surprising.

Maybe they don't understand why this was designed like that?  I
explained the idea, and it makes sense if you consider the use case of
text displayed with very large font.

If that is still not good enough, you and they are welcome to get the
hands dirty in the relevant parts of simple.el.  I don't plan on doing
that any time soon, having stepped through that code and hacked it too
much for one lifetime.





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

* bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww
  2019-09-27 14:29                                     ` Eli Zaretskii
@ 2019-09-27 14:35                                       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 23+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-27 14:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: nljlistbox2, 16840

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe they don't understand why this was designed like that?  I
> explained the idea, and it makes sense if you consider the use case of
> text displayed with very large font.

Oh, that explains a lot.  Yes, that behaviour makes sense for huge
fonts.  But not so much for images, where you'd expect them to enter and
leave in similar fashion.

And I do think that the huge-image case is more common than the
huge-font case, so perhaps it makes more sense to cater to the former
than the latter.

> If that is still not good enough, you and they are welcome to get the
> hands dirty in the relevant parts of simple.el.  I don't plan on doing
> that any time soon, having stepped through that code and hacked it too
> much for one lifetime.

I can imagine.  :-)  I'll try to familiarise myself with the code and
see what I come up with...

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





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

end of thread, other threads:[~2019-09-27 14:35 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-22  1:51 bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww N. Jackson
2014-02-22  8:21 ` Eli Zaretskii
2014-02-22 17:15   ` N. Jackson
2014-02-22 18:05     ` Eli Zaretskii
2015-12-25  7:43       ` Lars Ingebrigtsen
2015-12-25  8:01         ` Eli Zaretskii
2015-12-25 16:54           ` Lars Ingebrigtsen
2015-12-25 17:04             ` Eli Zaretskii
2015-12-25 17:28               ` Lars Ingebrigtsen
2015-12-25 19:56                 ` Eli Zaretskii
2015-12-25 19:01               ` N. Jackson
2015-12-25 19:58                 ` Eli Zaretskii
2019-09-26 16:58                   ` Lars Ingebrigtsen
2019-09-26 17:11                     ` Eli Zaretskii
2019-09-26 17:19                       ` Lars Ingebrigtsen
2019-09-26 17:55                         ` Eli Zaretskii
2019-09-26 18:03                           ` Lars Ingebrigtsen
2019-09-26 18:32                             ` Eli Zaretskii
2019-09-26 18:34                               ` Lars Ingebrigtsen
2019-09-26 18:50                                 ` Eli Zaretskii
2019-09-27 14:12                                   ` Lars Ingebrigtsen
2019-09-27 14:29                                     ` Eli Zaretskii
2019-09-27 14:35                                       ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).