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: Thu, 09 Jul 2015 18:34:03 +0300 Message-ID: <834mlduyz8.fsf@gnu.org> References: <87twteh65g.fsf@web.de> <83d202v2m2.fsf@gnu.org> <87wpya5rey.fsf@web.de> <83a8v6ukbe.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1436456125 8759 80.91.229.3 (9 Jul 2015 15:35:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jul 2015 15:35:25 +0000 (UTC) Cc: 21012@debbugs.gnu.org To: michael_heerdegen@web.de Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 09 17:35:13 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 1ZDDqy-0002Va-Iv for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jul 2015 17:35:12 +0200 Original-Received: from localhost ([::1]:40498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDDqx-0004x1-V7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jul 2015 11:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDDqt-0004ve-DA for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2015 11:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDDqo-0005pH-AP for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2015 11:35:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDDqo-0005oW-6P for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2015 11:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZDDqn-0004M1-LQ for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2015 11:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Jul 2015 15:35:01 +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.143645605616678 (code B ref 21012); Thu, 09 Jul 2015 15:35:01 +0000 Original-Received: (at 21012) by debbugs.gnu.org; 9 Jul 2015 15:34:16 +0000 Original-Received: from localhost ([127.0.0.1]:45330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZDDq3-0004Kv-Pz for submit@debbugs.gnu.org; Thu, 09 Jul 2015 11:34:16 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:39746) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZDDq1-0004Ke-9q for 21012@debbugs.gnu.org; Thu, 09 Jul 2015 11:34:14 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NR80040085YF200@mtaout25.012.net.il> for 21012@debbugs.gnu.org; Thu, 09 Jul 2015 18:30:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NR800KL78E3LJB0@mtaout25.012.net.il>; Thu, 09 Jul 2015 18:30:03 +0300 (IDT) In-reply-to: <83a8v6ukbe.fsf@gnu.org> 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:104855 Archived-At: > Date: Thu, 09 Jul 2015 05:38:29 +0300 > From: Eli Zaretskii > Cc: 21012@debbugs.gnu.org > > > I think you looked at the wrong `if' branch...? What I changed was to > > use `end-of-visual-line', which I hope is more accurate than > > > > (vertical-motion (cons (/ column (frame-char-width)) 0)) > > > > for finding the right point for breaking the line. > > Maybe, it sounds like I need to take a better look. I did that now. There are a few subtle issues with this, as described below. Please try the patch at the end of this message, and see if it gives good results. You didn't provide a reproducible test case for the screenshots you show, so I used Yamaoka-san's recipe; the patch below fixes all the issues I saw with that recipe. First, regarding your suggestion above to use end-of-visual-line: this is only TRT when shr-width is nil, i.e. shr is filling text to the full window width. But shr-vertical-motion should also support the case when shr-width is some specific number of columns or pixels, in which case end-of-visual-line will put us at the wrong position. Now to the issues I found. First, the value of shr-internal-width was computed incorrectly: it used window-width, which, as you discovered, is more than the text area width, and it subtracted 2 columns from that value, whereas it really needs to subtract only 1 (since column numbers are zero-based). The 2nd issue was in shr-find-fill-point, where it deals with CJK characters using the kinsoku feature: (a) it preferred to look for a breakable point forward even when shr-width is nil, which produces continuation lines; and (b) it mistakenly allowed to break the line before a character that is forbidden by kinsoku to be at BOL. Yet another subtlety is only visible when you disable one of the fringes (or both): the calculation of shr-internal-width should in that case subtract one more column, to be reserved for the continuation glyph. The patch below fixes that as well, albeit slightly crudely (we sometimes lose a column); suggestions for how to do that better are welcome. Here's a patch that attempts at fixing all but the last of these issues; if it gives good results, I will install it. If not, please show a test case that reproduces whatever problems are left. Thanks. diff --git a/lisp/net/shr.el b/lisp/net/shr.el index 0ce77b9..f440abf 100644 --- a/lisp/net/shr.el +++ b/lisp/net/shr.el @@ -222,10 +222,29 @@ (defun shr-insert-document (dom) (if (not shr-use-fonts) shr-width (* shr-width (frame-char-width)))) + ;; We need to adjust the available + ;; width for when the user disables + ;; the fringes, which will cause the + ;; display engine usurp one column for + ;; the continuation glyph. (if (not shr-use-fonts) - (- (window-width) 2) - (- (window-pixel-width) - (* (frame-fringe-width) 2)))))) + (- (window-body-width) 1 + (if (and (null shr-width) + (or (zerop + (fringe-columns 'right)) + (zerop + (fringe-columns 'left)))) + 0 + 1)) + (- (window-body-width nil t) + (frame-char-width) + (if (and (null shr-width) + (or (zerop + (fringe-columns 'right)) + (zerop + (fringe-columns 'left)))) + (* (frame-char-width) 2) + 0)))))) (shr-descend dom) (shr-fill-lines start (point)) (shr-remove-trailing-whitespace start (point)) @@ -439,8 +458,18 @@ (defun shr-fill-text (text) (with-temp-buffer (let ((shr-indentation 0) (shr-start nil) - (shr-internal-width (- (window-pixel-width) - (* (frame-fringe-width) 2)))) + (shr-internal-width (- (window-body-width nil t) + (frame-char-width) + ;; Adjust the window width for when + ;; the user disables the fringes, + ;; which causes the display engine + ;; usurp one coplumn for the + ;; continuation glyph. + (if (and (null shr-width) + (or (zerop (fringe-columns 'right)) + (zerop (fringe-columns 'left)))) + (* (frame-char-width) 2) + 0)))) (shr-insert text) (buffer-string))))) @@ -620,7 +649,9 @@ (defun shr-find-fill-point (start) ;; There's no breakable point, so we give it up. (let (found) (goto-char bp) - (unless shr-kinsoku-shorten + ;; Don't overflow the window edge, even if + ;; shr-kinsoku-shorten is nil. + (unless (or shr-kinsoku-shorten (null shr-width)) (while (setq found (re-search-forward "\\(\\c>\\)\\| \\|\\c<\\|\\c|" (line-end-position) 'move))) @@ -632,9 +663,12 @@ (defun shr-find-fill-point (start) ;; Don't put kinsoku-bol characters at the beginning of a line, ;; or kinsoku-eol characters at the end of a line. (cond - (shr-kinsoku-shorten + ;; Don't overflow the window edge, even if shr-kinsoku-shorten + ;; is nil. + ((or shr-kinsoku-shorten (null shr-width)) (while (and (not (memq (preceding-char) (list ?\C-@ ?\n ? ))) - (shr-char-kinsoku-eol-p (preceding-char))) + (or (shr-char-kinsoku-eol-p (preceding-char)) + (shr-char-kinsoku-bol-p (following-char)))) (backward-char 1)) (when (setq failed (<= (point) start)) ;; There's no breakable point that doesn't violate kinsoku,