From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21012: 25.0.50; eww: last char of a line sometimes not fully visible Date: Wed, 08 Jul 2015 23:03:17 +0300 Message-ID: <83d202v2m2.fsf@gnu.org> References: <87twteh65g.fsf@web.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1436385863 31121 80.91.229.3 (8 Jul 2015 20:04:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jul 2015 20:04:23 +0000 (UTC) Cc: 21012@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 08 22:04:12 2015 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 1ZCvZj-0006Lt-BW for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jul 2015 22:04:11 +0200 Original-Received: from localhost ([::1]:36708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCvZi-0002U4-Nt for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Jul 2015 16:04:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCvZe-0002Ty-T9 for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2015 16:04:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCvZa-0001ZY-QG for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2015 16:04:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCvZa-0001ZK-NU for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2015 16:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZCvZa-0000FO-5Z for bug-gnu-emacs@gnu.org; Wed, 08 Jul 2015 16:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Jul 2015 20:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21012 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21012-submit@debbugs.gnu.org id=B21012.1436385813914 (code B ref 21012); Wed, 08 Jul 2015 20:04:02 +0000 Original-Received: (at 21012) by debbugs.gnu.org; 8 Jul 2015 20:03:33 +0000 Original-Received: from localhost ([127.0.0.1]:44497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCvZ6-0000Ef-Np for submit@debbugs.gnu.org; Wed, 08 Jul 2015 16:03:33 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:37338) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCvZ4-0000ES-EP for 21012@debbugs.gnu.org; Wed, 08 Jul 2015 16:03:32 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NR600900Q88A600@mtaout29.012.net.il> for 21012@debbugs.gnu.org; Wed, 08 Jul 2015 23:02:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NR6002AVQCWQF80@mtaout29.012.net.il>; Wed, 08 Jul 2015 23:02:57 +0300 (IDT) In-reply-to: <87twteh65g.fsf@web.de> X-012-Sender: halo1@inter.net.il 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:104836 Archived-At: > From: Michael Heerdegen > Date: Wed, 08 Jul 2015 20:10:35 +0200 > > in eww, using shr-use-fonts -> t, for some lines, the last character is > only partially visible. Not a big deal, but distracting. Is the partially-visible character always the last character on that line, before the hard newline? If so, I think I know where's the flaw in the logic. See below. > --8<---------------cut here---------------start------------->8--- > (defun shr-insert-document (dom) > ... > (setq shr-content-cache nil) > (let ((start (point)) > (shr-start nil) > ... > (shr-internal-width (or (and shr-width..3..) > (if (not shr-use-fonts) > (- (window-width) 2) > (- (window-pixel-width) ; <---- here > (* (frame-fringe-width) 2)))))) > (shr-descend dom) > (shr-fill-lines start (point)) > (shr-remove-trailing-whitespace start (point)) > (when shr-warning..1..))) > --8<---------------cut here---------------end--------------->8--- > > AFAICT > > (- (window-pixel-width) (* (frame-fringe-width) 2)) > > is not the available width for text, it is a larger value including > scroll bars etc. Do you understand why the value of frame-fringe-width is multiplied by 2? > When I change it to > > (window-body-width nil t) > > this improves things. I think that using window-body-width is indeed better here. It will, for example, account for display margins. > --8<---------------cut here---------------start------------->8--- > (defun shr-vertical-motion (column) > (if (not shr-use-fonts) > (move-to-column column) > (unless (eolp) > (forward-char 1)) > (vertical-motion (cons (/ column (frame-char-width)) 0)) ; <-- here > (unless (eolp) > (forward-char 1)))) > --8<---------------cut here---------------end--------------->8--- > > This function is used, among other places, to decide where to break > lines in `shr-fill-line'. > > Probably (/ column (frame-char-width)) can be too large if you are > unlucky. Sorry, I don't follow. Can you elaborate on when this could happen? > For testing I tried with this version: > > --8<---------------cut here---------------start------------->8--- > (defun shr-vertical-motion (column) > (if (not shr-use-fonts) > (move-to-column column) > (unless (eolp) > (forward-char 1)) > (end-of-visual-line))) > --8<---------------cut here---------------end--------------->8--- > > This seems to fix this issue (together with the first change), I don't see how this could be right, unless you only tested it with text that is rendered using a single font. move-to-column goes to the Nth character starting from the left edge (forget tabs and double-width CJK characters for a moment), so it will not DTRT when a screen line displays characters of different size (as in with different-size fonts). The original code works in pixels (vertical-motion interprets the column number as the number of pixels equivalent to that number of frame's canonical characters), so it is not prone to this problem. I believe the problem is that the code determines whether the line should be wrapped based on this test: (shr-vertical-motion shr-internal-width) (when (looking-at " $") <<<<<<<<<<<<<<<<<<<<<<<<< (delete-region (point) (line-end-position))) IOW, it assumes that if the character at the goal pixel coordinate immediately precedes the newline, the line doesn't need to be wrapped. But that will fail if that last character is unusually wide.