From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nljlistbox2@gmail.com (N. Jackson) Newsgroups: gmane.emacs.bugs Subject: bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww Date: Sat, 22 Feb 2014 13:15:53 -0400 Message-ID: <87y513rrue.fsf_-_@moondust.localdomain> References: <874n3rj4ng.fsf@moondust.localdomain> <83eh2v4kx6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393089429 7706 80.91.229.3 (22 Feb 2014 17:17:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Feb 2014 17:17:09 +0000 (UTC) Cc: 16840@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 22 18:17:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WHGCT-0003Uu-0d for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Feb 2014 18:17:17 +0100 Original-Received: from localhost ([::1]:50340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGCS-0006CJ-GK for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Feb 2014 12:17:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGCK-0006Bz-D1 for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:17:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHGCE-0007HW-Ut for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:17:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGCE-0007HR-PD for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WHGCE-0002fr-CT for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: nljlistbox2@gmail.com (N. Jackson) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Feb 2014 17:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16840 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.139308938010215 (code B ref -1); Sat, 22 Feb 2014 17:17:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 22 Feb 2014 17:16:20 +0000 Original-Received: from localhost ([127.0.0.1]:35863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WHGBX-0002eg-QQ for submit@debbugs.gnu.org; Sat, 22 Feb 2014 12:16:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37972) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WHGBV-0002eT-8r for submit@debbugs.gnu.org; Sat, 22 Feb 2014 12:16:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHGBK-00078s-Fc for submit@debbugs.gnu.org; Sat, 22 Feb 2014 12:16:11 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:53409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGBK-00078o-C7 for submit@debbugs.gnu.org; Sat, 22 Feb 2014 12:16:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGBE-00069a-Rj for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:16:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHGB9-00077o-EM for bug-gnu-emacs@gnu.org; Sat, 22 Feb 2014 12:16:00 -0500 Original-Received: from mail-qa0-x229.google.com ([2607:f8b0:400d:c00::229]:38211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGB9-00077j-8k; Sat, 22 Feb 2014 12:15:55 -0500 Original-Received: by mail-qa0-f41.google.com with SMTP id w8so4819007qac.0 for ; Sat, 22 Feb 2014 09:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=YsDNwa/V73YhkYDrhzXhqzQgojHii8M1xsZ3BlTX9yw=; b=B5Q2d+5RsD5msgA6/hU2VQXh6NbT0l2X9eBp1TtGAyWtGWkfsTlUwK9pisygLOEyip 9o7+vdjZ20UmirI/gWo2MPPKCo287cigCvQSJnsAZ3v0dqa2FRgeUtsVL65kA7IMyWoS rfTPndlzjwLs7WSEoNWS0srWSwbw7acbIDc3ptq42Xoe1jq1m+peSi3Fgup10plJWpW8 pEtqtDPxEjW4qZln8qGQL5PJwwpKd57ufYlTPovK85PZkA+UFpknIupbjhsd6QgSR4dp M3Em9qG0kbFzAe+BqKRYQ8OTeCdU8Cs5+fNYUPbcMx87ywzJQsjIBpFyax9gPS0Z8WO3 RraA== X-Received: by 10.140.48.172 with SMTP id o41mr17615399qga.16.1393089354910; Sat, 22 Feb 2014 09:15:54 -0800 (PST) Original-Received: from moondust.localdomain.nodomain.none (T8630.WPA.Dal.Ca. [134.190.134.48]) by mx.google.com with ESMTPSA id z1sm32689942qaz.18.2014.02.22.09.15.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Feb 2014 09:15:54 -0800 (PST) In-Reply-To: <83eh2v4kx6.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 Feb 2014 10:21:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86028 Archived-At: 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 >> =============================== >> When scrolling down the page (pressing ...), 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 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 >> 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 >> =========================== >> 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.