From: Michael Heerdegen <michael_heerdegen@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 21012@debbugs.gnu.org
Subject: bug#21012: 25.0.50; eww: last char of a line sometimes not fully visible
Date: Sat, 11 Jul 2015 14:02:42 +0200 [thread overview]
Message-ID: <87380usxzx.fsf@web.de> (raw)
In-Reply-To: <834mlbbyi0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Jul 2015 22:31:35 +0300")
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> It should be possible, in principle, to write something similar to
> posn-at-point that would not depend on the text being visible, or
> rewrite posn-at-point to free it from this limitation, but we don't
> have such a function at this time. Maybe we should.
Of course would that be useful, not only for this issue. But I guess it
would be a lot of work.
I try now what you suggested, subtracting one more column width when
calculating `shr-internal-width'. I.e., I subtract one more
`frame-char-width' now. Looks good so far. I'll use it for some time
and tell you what I think.
So, here is what I'm testing, based on your first patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: shr-02.patch --]
[-- Type: text/x-diff, Size: 4012 bytes --]
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -222,10 +222,29 @@ DOM should be a parse tree as generated by
(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)
+ (* 2 (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 @@ size, and full-buffer size."
(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)
+ (* 2 (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 @@ size, and full-buffer size."
;; 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 @@ size, and full-buffer size."
;; 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,
[-- Attachment #3: Type: text/plain, Size: 20 bytes --]
Thanks,
Michael.
next prev parent reply other threads:[~2015-07-11 12:02 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 18:10 bug#21012: 25.0.50; eww: last char of a line sometimes not fully visible Michael Heerdegen
2015-07-08 20:03 ` Eli Zaretskii
2015-07-08 20:24 ` Michael Heerdegen
2015-07-09 2:38 ` Eli Zaretskii
2015-07-09 11:01 ` Michael Heerdegen
2015-07-09 14:43 ` Eli Zaretskii
2015-07-09 19:42 ` Michael Heerdegen
2015-07-09 15:34 ` Eli Zaretskii
2015-07-09 20:06 ` Michael Heerdegen
2015-07-10 6:03 ` Eli Zaretskii
2015-07-10 12:55 ` Michael Heerdegen
2015-07-10 13:06 ` Eli Zaretskii
2015-07-10 14:16 ` Michael Heerdegen
2015-07-10 14:43 ` Eli Zaretskii
2015-07-10 18:04 ` Michael Heerdegen
2015-07-10 18:45 ` Eli Zaretskii
2015-07-10 19:19 ` Michael Heerdegen
2015-07-10 19:31 ` Eli Zaretskii
2015-07-11 12:02 ` Michael Heerdegen [this message]
2015-07-11 13:45 ` Eli Zaretskii
2015-07-20 16:33 ` Michael Heerdegen
2015-07-20 16:34 ` Eli Zaretskii
2015-07-21 18:49 ` Michael Heerdegen
2015-09-25 4:00 ` Katsumi Yamaoka
2015-09-25 14:45 ` Michael Heerdegen
2015-09-28 21:30 ` Michael Heerdegen
2015-09-29 5:37 ` Eli Zaretskii
2015-10-03 8:08 ` Michael Heerdegen
2015-10-03 9:42 ` Eli Zaretskii
2015-10-03 12:41 ` Michael Heerdegen
2015-10-04 6:31 ` Michael Heerdegen
2015-10-04 7:09 ` Eli Zaretskii
2015-10-04 7:11 ` Michael Heerdegen
2015-10-04 7:39 ` Michael Heerdegen
2015-10-04 8:49 ` Eli Zaretskii
2015-10-04 10:18 ` Michael Heerdegen
2015-07-08 20:31 ` Michael Heerdegen
2015-10-07 6:34 ` bug#21012: Close Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87380usxzx.fsf@web.de \
--to=michael_heerdegen@web.de \
--cc=21012@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.