bug#19462: shr: use wrap-prefix when possible, instead of filling the text

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Package:  emacs
Severity: wishlist
X-Debbugs-Cc: emacs-devel@gnu.org

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Lars Ingebrigtsen  Date: Mon, 29 Dec 2014 00:04:38 +0100

 >> (Yes, Emacs can display proportional fonts and fonts of different
 >> sizes, but until you can fold (etc) proportional text (and text with
 >> a mixture of font sizes) in a pretty manner, that's more of a toy
 >> than anything else.)

 > What's non-pretty with how we do this now?  What features are
 > missing?

	The only feature that I’m aware to be missing is the actual
	support for Emacs native text wrapping (as in: the word-wrap
	variable and wrap-prefix text property) in SHR.

	Please thus consider the patch MIMEd.

	* lisp/net/shr.el (shr-force-fill): New variable to disable this
	feature if needed.
	(shr-internal-width): Defer initialization until...
	(shr-insert-document): ... here; set to nil if neither
	shr-force-fill nor shr-width are non-nil.
	(shr-fold-text, shr-tag-table-1): Likewise.
	(shr-insert): Use insert-and-inherit; do not fill if
	shr-internal-width is nil.
	(shr-setup-wrap): New function.
	(shr-indent, shr-tag-blockquote, shr-tag-dd, shr-tag-li):
	Call shr-setup-wrap.
	(shr-tag-hr): Use a constant if shr-internal-width is nil.

	A test case is also MIMEd.  The buffer it produces shows the
	text being dynamically filled as the window width changes
	(as in: C-x 3, for instance.)

	The table rendering is not changed in any way.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[-- Attachment #2: Type: text/diff, Size: 5260 bytes --]

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 26bb292..e634a5a 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -128,13 +128,16 @@
 (defvar shr-inhibit-images nil
   "If non-nil, inhibit loading images.")
 
+(defvar shr-force-fill nil
+  "If non-nil, fill text even in the cases Emacs can wrap it by itself.")
+
 ;;; Internal variables.
 
 (defvar shr-folding-mode nil)
 (defvar shr-state nil)
 (defvar shr-start nil)
 (defvar shr-indentation 0)
-(defvar shr-internal-width (or shr-width (1- (window-width))))
+(defvar shr-internal-width nil)		; set in shr-insert-document
 (defvar shr-list-mode nil)
 (defvar shr-content-cache nil)
 (defvar shr-kinsoku-shorten nil)
@@ -206,7 +209,8 @@ defun shr-insert-document (dom)
 	(shr-base nil)
 	(shr-depth 0)
 	(shr-warning nil)
-	(shr-internal-width (or shr-width (1- (window-width)))))
+	(shr-internal-width
+	 (or shr-width (and shr-force-fill (1- (window-width))))))
     (shr-descend dom)
     (shr-remove-trailing-whitespace start (point))
     (when shr-warning
@@ -420,7 +424,8 @@ defun shr-fold-text (text)
       (let ((shr-indentation 0)
 	    (shr-state nil)
 	    (shr-start nil)
-	    (shr-internal-width (window-width)))
+	    (shr-internal-width (and shr-force-fill
+				     (1- (window-width)))))
 	(shr-insert text)
 	(buffer-string)))))
 
@@ -454,12 +459,14 @@ defun shr-insert (text)
     (setq shr-state nil))
   (cond
    ((eq shr-folding-mode 'none)
-    (insert text))
+    (insert-and-inherit text))
    (t
+    ;; We generally use insert-and-inherit below so to inherit the
+    ;; wrap-prefix property, if any.  See shr-setup-wrap.
     (when (and (string-match "\\`[ \t\n ]" text)
 	       (not (bolp))
 	       (not (eq (char-after (1- (point))) ? )))
-      (insert " "))
+      (insert-and-inherit " "))
     (dolist (elem (split-string text "[ \f\t\n\r\v ]+" t))
       (when (and (bolp)
 		 (> shr-indentation 0))
@@ -482,17 +489,18 @@ defun shr-insert (text)
       ;; starts.
       (unless shr-start
 	(setq shr-start (point)))
-      (insert elem)
+      (insert-and-inherit elem)
       (setq shr-state nil)
       (let (found)
-	(while (and (> (current-column) shr-internal-width)
+	(while (and shr-internal-width	; Use Emacs native wrapping if nil.
+		    (> (current-column) shr-internal-width)
 		    (> shr-internal-width 0)
 		    (progn
 		      (setq found (shr-find-fill-point))
 		      (not (eolp))))
 	  (when (eq (preceding-char) ? )
 	    (delete-char -1))
-	  (insert "\n")
+	  (insert-and-inherit "\n")
 	  (unless found
 	    ;; No space is needed at the beginning of a line.
 	    (when (eq (following-char) ? )
@@ -500,11 +508,12 @@ defun shr-insert (text)
 	  (when (> shr-indentation 0)
 	    (shr-indent))
 	  (end-of-line))
-	(if (<= (current-column) shr-internal-width)
-	    (insert " ")
+	(if (or (not shr-internal-width)
+		(<= (current-column) shr-internal-width))
+	    (insert-and-inherit " ")
 	  ;; In case we couldn't get a valid break point (because of a
 	  ;; word that's longer than `shr-internal-width'), just break anyway.
-	  (insert "\n")
+	  (insert-and-inherit "\n")
 	  (when (> shr-indentation 0)
 	    (shr-indent)))))
     (unless (string-match "[ \t\r\n ]\\'" text)
@@ -663,7 +672,17 @@
 
 (defun shr-indent ()
   (when (> shr-indentation 0)
-    (insert (make-string shr-indentation ? ))))
+    (insert (make-string shr-indentation ? ))
+    (shr-setup-wrap)))
+
+(defun shr-setup-wrap ()
+  (when (> shr-indentation 0)
+    ;; The wrap-prefix property is sticky; abuse that here.  We use
+    ;; this after at least shr-indent (or within it), so we may safely
+    ;; assume that there is at least one character before the point.
+    (put-text-property (+ -1 (point)) (point)
+		       'wrap-prefix
+		       `(space :align-to ,shr-indentation))))
 
 (defun shr-fontize-dom (dom &rest types)
   (let (shr-start)
@@ -1309,6 +1334,7 @@ defun shr-tag-blockquote (dom)
   (shr-ensure-paragraph)
   (shr-indent)
   (let ((shr-indentation (+ shr-indentation 4)))
+    (shr-setup-wrap)
     (shr-generic dom))
   (shr-ensure-paragraph))
 
@@ -1325,6 +1351,7 @@
 (defun shr-tag-dd (dom)
   (shr-ensure-newline)
   (let ((shr-indentation (+ shr-indentation 4)))
+    (shr-setup-wrap)
     (shr-generic dom)))
 
 (defun shr-tag-ul (dom)
@@ -1350,6 +1377,7 @@ defun shr-tag-li (dom)
 	    shr-bullet))
 	 (shr-indentation (+ shr-indentation (length bullet))))
     (insert bullet)
+    (shr-setup-wrap)
     (shr-generic dom)))
 
 (defun shr-tag-br (dom)
@@ -1386,7 +1414,8 @@
 
 (defun shr-tag-hr (_dom)
   (shr-ensure-newline)
-  (insert (make-string shr-internal-width shr-hr-line) "\n"))
+  (insert (make-string (or shr-internal-width 31) ; FIXME: magic
+		       shr-hr-line) "\n"))
 
 (defun shr-tag-title (dom)
   (shr-heading dom 'bold 'underline))
@@ -1414,6 +1443,7 @@
 (defun shr-tag-table-1 (dom)
   (setq dom (or (dom-child-by-tag dom 'tbody) dom))
   (let* ((shr-inhibit-images t)
+	 (shr-internal-width (or shr-internal-width (1- (window-width))))
 	 (shr-table-depth (1+ shr-table-depth))
 	 (shr-kinsoku-shorten t)
 	 ;; Find all suggested widths.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/emacs-lisp, Size: 961 bytes --]

(with-current-buffer (generate-new-buffer "*shr*")
  (setq-local shr-width nil)
  (setq-local word-wrap t)
  (setq-local truncate-partial-width-windows nil)
  (shr-insert-document
   '(base
     ((href . "https://example.com/"))
     (html
      nil
      (head nil (title nil "Lorem ipsum"))
      (body
       nil
       (hr nil)
       (ol nil
	   (li ((lang . "la"))
	       "Lorem ipsum dolor sit amet, consectetur adipisicing"
	       " elit, sed do eiusmod tempor incididunt ut labore et"
	       " dolore magna aliqua.  Ut enim ad minim veniam, quis"
	       " nostrud exercitation ullamco laboris nisi ut"
	       " aliquip ex ea commodo consequat.  Duis aute irure"
	       " dolor in reprehenderit in voluptate velit esse"
	       " cillum dolore eu fugiat nulla pariatur.  Excepteur"
	       " sint occaecat cupidatat non proident, sunt in culpa"
	       " qui officia deserunt mollit anim id est laborum."))))))
  (pop-to-buffer (current-buffer)))

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

	As it seems, the initial version of the patch didn’t play well
	with other essential shr.el features (as in: hyperlinks.)

	Please thus consider the revised patch MIMEd.

	* lisp/net/shr.el (shr-force-fill): New variable to disable this
	feature if needed.
	(shr-internal-width): Defer initialization until...
	(shr-insert-document): ... here; set to nil if neither
	shr-force-fill nor shr-width are non-nil.
	(shr-fold-text, shr-tag-table-1): Likewise.
	(shr-insert): Do not fill if shr-internal-width is nil.
	(shr-setup-wrap-1, shr-setup-wrap): New function.
	(shr-tag-blockquote, shr-tag-dd, shr-tag-li):
	Call shr-setup-wrap.
	(shr-tag-hr): Use a constant if shr-internal-width is nil.

	The other so far unresolved issue with this approach is that the
	tables and <pre /> elements may actually require truncate-lines.
	Unfortunately, I know of no way to allow for word-wrapped and
	truncated lines to exist in the same buffer; I guess we may need
	either a truncate-lines or word-wrap property (or both) to
	override the buffer-local variables in this case.

	Similarly to wrap-prefix, we may also use line-prefix in place
	of shr-indent.  But that may not be a good idea if quoting
	text/html messages in text/plain replies, for instance.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 4441 bytes --]

--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -128,13 +128,16 @@
 (defvar shr-inhibit-images nil
   "If non-nil, inhibit loading images.")
 
+(defvar shr-force-fill nil
+  "If non-nil, fill text even in the cases Emacs can wrap it by itself.")
+
 ;;; Internal variables.
 
 (defvar shr-folding-mode nil)
 (defvar shr-state nil)
 (defvar shr-start nil)
 (defvar shr-indentation 0)
-(defvar shr-internal-width (or shr-width (1- (window-width))))
+(defvar shr-internal-width nil)		; set in shr-insert-document
 (defvar shr-list-mode nil)
 (defvar shr-content-cache nil)
 (defvar shr-kinsoku-shorten nil)
@@ -206,7 +209,8 @@ defun shr-insert-document (dom)
 	(shr-base nil)
 	(shr-depth 0)
 	(shr-warning nil)
-	(shr-internal-width (or shr-width (1- (window-width)))))
+	(shr-internal-width
+	 (or shr-width (and shr-force-fill (1- (window-width))))))
     (shr-descend dom)
     (shr-remove-trailing-whitespace start (point))
     (when shr-warning
@@ -420,7 +424,8 @@ defun shr-fold-text (text)
       (let ((shr-indentation 0)
 	    (shr-state nil)
 	    (shr-start nil)
-	    (shr-internal-width (window-width)))
+	    (shr-internal-width (and shr-force-fill
+				     (1- (window-width)))))
 	(shr-insert text)
 	(buffer-string)))))
 
@@ -485,7 +490,8 @@ defun shr-insert (text)
       (insert elem)
       (setq shr-state nil)
       (let (found)
-	(while (and (> (current-column) shr-internal-width)
+	(while (and shr-internal-width	; Use Emacs native wrapping if nil.
+		    (> (current-column) shr-internal-width)
 		    (> shr-internal-width 0)
 		    (progn
 		      (setq found (shr-find-fill-point))
@@ -500,7 +506,8 @@ defun shr-insert (text)
 	  (when (> shr-indentation 0)
 	    (shr-indent))
 	  (end-of-line))
-	(if (<= (current-column) shr-internal-width)
+	(if (or (not shr-internal-width)
+		(<= (current-column) shr-internal-width))
 	    (insert " ")
 	  ;; In case we couldn't get a valid break point (because of a
 	  ;; word that's longer than `shr-internal-width'), just break anyway.
@@ -665,6 +672,23 @@
   (when (> shr-indentation 0)
     (insert (make-string shr-indentation ? ))))
 
+(defun shr-setup-wrap-1 (from to pval)
+  (put-text-property from to 'wrap-prefix pval))
+
+(defun shr-setup-wrap (from to)
+  (let ((prev from)
+	(pos  (next-property-change from nil to))
+	(pval (and (> shr-indentation 0)
+		   `(space :align-to ,shr-indentation))))
+    (while (and pos (> pos prev))
+      (unless (get-text-property prev 'wrap-prefix)
+	(shr-setup-wrap-1 prev pos pval))
+      (setq prev pos
+	    pos  (next-property-change pos nil to)))
+    (unless (or (<= to prev)
+		(get-text-property prev 'wrap-prefix))
+	(shr-setup-wrap-1 prev to pval))))
+
 (defun shr-fontize-dom (dom &rest types)
   (let (shr-start)
     (shr-generic dom)
@@ -1308,8 +1338,10 @@
 (defun shr-tag-blockquote (dom)
   (shr-ensure-paragraph)
   (shr-indent)
-  (let ((shr-indentation (+ shr-indentation 4)))
-    (shr-generic dom))
+  (let ((from (point))
+	(shr-indentation (+ shr-indentation 4)))
+    (shr-generic dom)
+    (shr-setup-wrap from (point)))
   (shr-ensure-paragraph))
 
 (defun shr-tag-dl (dom)
@@ -1324,8 +1356,10 @@
 
 (defun shr-tag-dd (dom)
   (shr-ensure-newline)
-  (let ((shr-indentation (+ shr-indentation 4)))
-    (shr-generic dom)))
+  (let ((from (point))
+	(shr-indentation (+ shr-indentation 4)))
+    (shr-generic dom)
+    (shr-setup-wrap from (point))))
 
 (defun shr-tag-ul (dom)
   (shr-ensure-paragraph)
@@ -1348,9 +1382,11 @@ defun shr-tag-li (dom)
 		  (format "%d " shr-list-mode)
 		(setq shr-list-mode (1+ shr-list-mode)))
 	    shr-bullet))
+	 (from (point))
 	 (shr-indentation (+ shr-indentation (length bullet))))
     (insert bullet)
-    (shr-generic dom)))
+    (shr-generic dom)
+    (shr-setup-wrap from (point))))
 
 (defun shr-tag-br (dom)
   (when (and (not (bobp))
@@ -1386,7 +1422,8 @@
 
 (defun shr-tag-hr (_dom)
   (shr-ensure-newline)
-  (insert (make-string shr-internal-width shr-hr-line) "\n"))
+  (insert (make-string (or shr-internal-width 31) ; FIXME: magic
+		       shr-hr-line) "\n"))
 
 (defun shr-tag-title (dom)
   (shr-heading dom 'bold 'underline))
@@ -1414,6 +1451,7 @@
 (defun shr-tag-table-1 (dom)
   (setq dom (or (dom-child-by-tag dom 'tbody) dom))
   (let* ((shr-inhibit-images t)
+	 (shr-internal-width (or shr-internal-width (1- (window-width))))
 	 (shr-table-depth (1+ shr-table-depth))
 	 (shr-kinsoku-shorten t)
 	 ;; Find all suggested widths.

bug#19661: wrapping before window-width (new wrap-column text property?)

[Ivan Shmakov]

Package:  emacs
Severity: wishlist

	[As suggested in news:jwviogtdei4.fsf-monnier+emacs@gnu.org,
	news:87387w8r2j.fsf@violet.siamics.net, etc.; parts of the
	second message are reiterated below.]

	Please provide support for window-width-independent wrapping in
	the Emacs display engine; possibly by the means of a new
	wrap-column text property (and still perhaps complemented by a
	eponymous buffer-local variable), treated similarly to the likes
	of wrap-prefix.

	This feature could be used to display format=flowed (RFC 3676)
	MIME parts, as well as enriched-mode documents, documents using
	MediaWiki markup, SHR-rendered HTML documents, and pretty much
	any other kind of text which allows for /both/ wrappable and
	preformatted parts at the same time.

	It is already possible to influence the wrap width somewhat by
	setting the margin width variables (right-margin-width,
	left-margin-width) appropriately (see bug#4172, for instance.)
	The suggested wrap-column text property should probably have no
	effect on the window marginal areas, however.

	I admit that I know very little of the current Emacs display
	implementation.  However, it seems to me that wrap-column makes
	us one property closer to native multicolumn display (which’d
	warrant a separate wishlist bug report, though.)

	Consider, e. g.:

This is an example sentence with wrap-column set to 23.

This is yet another example sentence with line-prefix and wrap-prefix
both set to (space :align-to 25), – or something like that.

	From there, we may display it as follows:

This is an example
sentence with
wrap-column set to 23.

                         This is yet another example sentence with line-prefix
                         and wrap-prefix both set to (space :align-to 25), –
                         or something like that.

	Yet, provided that some other property is switched on, the Emacs
	display engine may decide to show it like this instead:

This is an example       This is yet another example sentence with line-prefix
sentence with            and wrap-prefix both set to (space :align-to 25), –
wrap-column set to 23.   or something like that.

	As already imagined in the preceding discussion, forward- and
	backward-char commands would then still follow the logical order
	of text in the buffer (that is: the “23” sentence, then the “25”
	one), while left-char, etc. would follow the visual order
	(assuming visual-order-cursor-movement.)

-- 
FSF associate member #7257  np. Mi memoras — Kajto      … 3013 B6A0 230E 334A

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 13:17:08 +0000
> 
> 	Please provide support for window-width-independent wrapping in
> 	the Emacs display engine; possibly by the means of a new
> 	wrap-column text property (and still perhaps complemented by a
> 	eponymous buffer-local variable), treated similarly to the likes
> 	of wrap-prefix.
> 
> 	This feature could be used to display format=flowed (RFC 3676)
> 	MIME parts, as well as enriched-mode documents, documents using
> 	MediaWiki markup, SHR-rendered HTML documents, and pretty much
> 	any other kind of text which allows for /both/ wrappable and
> 	preformatted parts at the same time.

format=flowed etc. is already supported by word-wrap, isn't it?

> 	I admit that I know very little of the current Emacs display
> 	implementation.

How about biting the bullet and trying to do this yourself?  I can
provide guidance and advice, if needed.

> 	Yet, provided that some other property is switched on, the Emacs
> 	display engine may decide to show it like this instead:
> 
> This is an example       This is yet another example sentence with line-prefix
> sentence with            and wrap-prefix both set to (space :align-to 25), –
> wrap-column set to 23.   or something like that.

This is a much harder nut to crack, and having wrap-column doesn't
help with that.

The fundamental problem here is that the Emacs display engine is based
on an "iterator" object that basically walks a buffer and generates
"glyph" objects that are then given to the display back-end for actual
display.  The iterator object has only a very myopic view of the text
it walks through.  Before Emacs 24, that view was one-character long
-- we only looked at the next character in the logical order.  With
Emacs 24's bidirectional display, the field of view became slightly
wider, but it is still limited to a single physical line, and most of
the display doesn't even know about that, the single exception being
bidi.c.

Now, the current display engine's workhorse is display_line, which
produces glyph objects for a single screen line.  What it does is call
a function to find the next "display element" (character, image,
composition, etc.) to display, produces glyphs for it, and goes to the
next display element in the visual order.

With your suggestion, once the width of the laid out glyphs reaches
some pixel value, the next display element will need to come from a
different part of the buffer.  But how to know where in the buffer is
that?  You cannot know that until you are done with layout of the
entire visible portion of the left-side pane, the one that in the
above example ends with "set to 23."

So either we need a deep surgery of display_line, so that it acquires
the ability to produce layout of each screen line in several parts, or
we write some tricky code that would perform all the necessary
calculations to find the buffer position of "This yet another example"
when we are done producing "This is an example" and want to continue
with the same screen line.

The former alternative means significant changes all over the display
engine, the latter means redisplay will be slower (not sure by how
much).  So both are highly non-trivial.

> 	As already imagined in the preceding discussion, forward- and
> 	backward-char commands would then still follow the logical order
> 	of text in the buffer (that is: the “23” sentence, then the “25”
> 	one), while left-char, etc. would follow the visual order
> 	(assuming visual-order-cursor-movement.)

That's the least of our trouble: the function that finds the place to
put the cursor (set_cursor_from_row) already thoroughly analyzes the
window display, and in Emacs 24 was rewritten to make it independent
of many assumptions that were broken by bidirectional display.

Perhaps you think that Emacs moves cursor visually, in which case it
would have had problems when the logical flow of text is broken like
that.  But that's not what Emacs does to move cursor: it moves point,
updates the display, and then figures out where in the new display to
put the cursor.

bug#19661: wrapping before window-width (new wrap-column text property?)

[martin rudalics]

 >> This is an example       This is yet another example sentence with line-prefix
 >> sentence with            and wrap-prefix both set to (space :align-to 25), –
 >> wrap-column set to 23.   or something like that.
 >
 > This is a much harder nut to crack, and having wrap-column doesn't
 > help with that.

This could be done with two side-by-side windows, `follow-mode' (Anders
Lindgren would certainly help with that) and some non-trivial changes in
window layout.  You'd probably want a zero width window to display a
common vertical scroll bar, a zero height window to display a horizontal
scroll bar and two zero height windows to display common mode and header
lines.  And obviously some meta mode that turns on multicolumn display
for parts of the text and manages the window layout appropriately.

In any case you can easily try a prototype with a number of side-by-side
windows turning off all decorations but the scroll bar of the rightmost
one and enabling `follow-mode'.  And you could insert (barely visible)
window dividers and use the mouse to change the widths of the columns.

martin

bug#19661: wrapping before window-width (new wrap-column text property?)

[Ivan Shmakov]

>>>>> martin rudalics <rudalics@gmx.at> writes:

 >>> This is an example       This is yet another example sentence with
 >>> sentence with            line-prefix and wrap-prefix both set to
 >>> wrap-column set to 23.   (space :align-to 25), – or something like that.

 >> This is a much harder nut to crack, and having wrap-column doesn't
 >> help with that.

 > This could be done with two side-by-side windows, `follow-mode'
 > (Anders Lindgren would certainly help with that) and some non-trivial
 > changes in window layout.

	Yes, I was thinking about something like that.  However, the
	ultimate goal is for Emacs to set foot on that wordprocessing
	land, so to say; and there, such window layouts may easily
	become unmanageable.

[…]

 > In any case you can easily try a prototype with a number of
 > side-by-side windows turning off all decorations but the scroll bar
 > of the rightmost one and enabling `follow-mode'.  And you could
 > insert (barely visible) window dividers and use the mouse to change
 > the widths of the columns.

	I doubt I really could experiment much with scrollbars with the
	tty-only Emacs builds I use exclusively for over a year now.

-- 
FSF associate member #7257  np. Innocent Exile — Iron Maiden … B6A0 230E 334A

bug#19661: wrapping before window-width (new wrap-column text property?)

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

 >> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 13:17:08 +0000

 >> Please provide support for window-width-independent wrapping in the
 >> Emacs display engine; possibly by the means of a new wrap-column
 >> text property (and still perhaps complemented by a eponymous
 >> buffer-local variable), treated similarly to the likes of
 >> wrap-prefix.

	… Or that could rather be wrap-width, given that Emacs supports
	pixelwise resize now (not to mention variable-width fonts, etc…)

 >> This feature could be used to display format=flowed (RFC 3676) MIME
 >> parts, as well as enriched-mode documents, documents using MediaWiki
 >> markup, SHR-rendered HTML documents, and pretty much any other kind
 >> of text which allows for /both/ wrappable and preformatted parts at
 >> the same time.

 > format=flowed etc. is already supported by word-wrap, isn't it?

	Not in its entirety; consider, e. g. (section 4.1 of RFC 3676):

   If the line ends in a space, the line is flowed.  Otherwise it is
   fixed.  The exception to this rule is a signature separator line,
   described in Section 4.3.  Such lines end in a space but are neither
   flowed nor fixed.

	I know of no way to make the Emacs display engine wrap one line
	but not the other in the very same buffer.

 >> I admit that I know very little of the current Emacs display
 >> implementation.

 > How about biting the bullet and trying to do this yourself?  I can
 > provide guidance and advice, if needed.

	I guess I can, but most probably /not/ in the next few months.

	(The biggest problem for me would be the change of the tools and
	the workflow.  Say, nothing like eval-defun is going to be
	available while working on the C code.  Also, I’m not really
	keen when it comes to non-tty Emacs frames, – never felt those
	as of being of much value for my tasks.)

[…]

 > The fundamental problem here is that the Emacs display engine is
 > based on an "iterator" object that basically walks a buffer and
 > generates "glyph" objects that are then given to the display back-end
 > for actual display.  The iterator object has only a very myopic view
 > of the text it walks through.  Before Emacs 24, that view was
 > one-character long -- we only looked at the next character in the
 > logical order.  With Emacs 24's bidirectional display, the field of
 > view became slightly wider, but it is still limited to a single
 > physical line, and most of the display doesn't even know about that,
 > the single exception being bidi.c.

	“Physical” as in “display” or “buffer”?

 > With your suggestion, once the width of the laid out glyphs reaches
 > some pixel value, the next display element will need to come from a
 > different part of the buffer.  But how to know where in the buffer is
 > that?  You cannot know that until you are done with layout of the
 > entire visible portion of the left-side pane, the one that in the
 > above example ends with "set to 23."

 > So either we need a deep surgery of display_line, so that it acquires
 > the ability to produce layout of each screen line in several parts,
 > or we write some tricky code that would perform all the necessary
 > calculations to find the buffer position of "This yet another
 > example" when we are done producing "This is an example" and want to
 > continue with the same screen line.

	Basically, yes, I thought about the display engine keeping track
	of the latest “wasted” rectangular chunk of screen space, and
	allowing for it to be occupied by the text coming later in the
	“buffer” order.  (Or perhaps up to two such chunks: one to the
	right and one to the left of the text being drawn.)

	IIUC, display_line would potentially have to be called several
	times to draw a single display line.

	And all this behavior only triggered when the text being drawn
	has some specific property; once the property value changes, —
	the state is reset.

 > The former alternative means significant changes all over the display
 > engine, the latter means redisplay will be slower (not sure by how
 > much).  So both are highly non-trivial.

	ACK; thanks for the detailed explanation.

 >> As already imagined in the preceding discussion, forward- and
 >> backward-char commands would then still follow the logical order of
 >> text in the buffer (that is: the “23” sentence, then the “25” one),
 >> while left-char, etc. would follow the visual order (assuming
 >> visual-order-cursor-movement.)

 > That's the least of our trouble: the function that finds the place to
 > put the cursor (set_cursor_from_row) already thoroughly analyzes the
 > window display, and in Emacs 24 was rewritten to make it independent
 > of many assumptions that were broken by bidirectional display.

 > Perhaps you think that Emacs moves cursor visually, in which case it
 > would have had problems when the logical flow of text is broken like
 > that.  But that's not what Emacs does to move cursor: it moves point,
 > updates the display, and then figures out where in the new display to
 > put the cursor.

	That was a pure UI consideration.  (And not even one I’ve
	personally thought of.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> Date: Fri, 23 Jan 2015 17:55:53 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19661@debbugs.gnu.org
> 
>  >> This is an example       This is yet another example sentence with line-prefix
>  >> sentence with            and wrap-prefix both set to (space :align-to 25), –
>  >> wrap-column set to 23.   or something like that.
>  >
>  > This is a much harder nut to crack, and having wrap-column doesn't
>  > help with that.
> 
> This could be done with two side-by-side windows, `follow-mode' (Anders
> Lindgren would certainly help with that) and some non-trivial changes in
> window layout.

That'd be a kludge-around.  I thought we were talking about teaching
Emacs new layout tricks, not overloading existing ones with features
they weren't designed to support.  We all know the subtle problems in
follow-mode, right?

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 19:45:31 +0000
> 
>  > format=flowed etc. is already supported by word-wrap, isn't it?
> 
> 	Not in its entirety; consider, e. g. (section 4.1 of RFC 3676):
> 
>    If the line ends in a space, the line is flowed.  Otherwise it is
>    fixed.  The exception to this rule is a signature separator line,
>    described in Section 4.3.  Such lines end in a space but are neither
>    flowed nor fixed.
> 
> 	I know of no way to make the Emacs display engine wrap one line
> 	but not the other in the very same buffer.

But then the feature you suggest will have the same problem, since it
will be build on the same infrastructure as word-wrap.

>  >> I admit that I know very little of the current Emacs display
>  >> implementation.
> 
>  > How about biting the bullet and trying to do this yourself?  I can
>  > provide guidance and advice, if needed.
> 
> 	I guess I can, but most probably /not/ in the next few months.

There's no rush.

> 
> 	(The biggest problem for me would be the change of the tools and
> 	the workflow.  Say, nothing like eval-defun is going to be
> 	available while working on the C code.  Also, I’m not really
> 	keen when it comes to non-tty Emacs frames, – never felt those
> 	as of being of much value for my tasks.)

Something to learn, I guess.

>  > The fundamental problem here is that the Emacs display engine is
>  > based on an "iterator" object that basically walks a buffer and
>  > generates "glyph" objects that are then given to the display back-end
>  > for actual display.  The iterator object has only a very myopic view
>  > of the text it walks through.  Before Emacs 24, that view was
>  > one-character long -- we only looked at the next character in the
>  > logical order.  With Emacs 24's bidirectional display, the field of
>  > view became slightly wider, but it is still limited to a single
>  > physical line, and most of the display doesn't even know about that,
>  > the single exception being bidi.c.
> 
> 	“Physical” as in “display” or “buffer”?

In the buffer, i.e. up to the next newline.

>  > So either we need a deep surgery of display_line, so that it acquires
>  > the ability to produce layout of each screen line in several parts,
>  > or we write some tricky code that would perform all the necessary
>  > calculations to find the buffer position of "This yet another
>  > example" when we are done producing "This is an example" and want to
>  > continue with the same screen line.
> 
> 	Basically, yes, I thought about the display engine keeping track
> 	of the latest “wasted” rectangular chunk of screen space, and
> 	allowing for it to be occupied by the text coming later in the
> 	“buffer” order.  (Or perhaps up to two such chunks: one to the
> 	right and one to the left of the text being drawn.)

That's the whole problem: the current display engine doesn't manage
any rectangular space.  It proceeds one line at a time.

> 	IIUC, display_line would potentially have to be called several
> 	times to draw a single display line.

Several calls is not the problem.  The problem is how to know with
which buffer position to call it.

> 	And all this behavior only triggered when the text being drawn
> 	has some specific property; once the property value changes, —
> 	the state is reset.

Redisplay will take care of that, so again, this isn't the problem.

bug#19661: wrapping before window-width (new wrap-column text property?)

[martin rudalics]

 > 	Yes, I was thinking about something like that.  However, the
 > 	ultimate goal is for Emacs to set foot on that wordprocessing
 > 	land, so to say; and there, such window layouts may easily
 > 	become unmanageable.

And you think the display engine can manage such layouts?

 > 	I doubt I really could experiment much with scrollbars with the
 > 	tty-only Emacs builds I use exclusively for over a year now.

So you are in the lucky position where you can omit scrollbars from such
experiments.

martin

bug#19661: wrapping before window-width (new wrap-column text property?)

[martin rudalics]

 > That'd be a kludge-around.  I thought we were talking about teaching
 > Emacs new layout tricks, not overloading existing ones with features
 > they weren't designed to support.

Layouts should be handled at the Elisp level.  Where exactly and how is
a matter of taste.  Currently, windows can provide a tiled layout only.
For example, having (multicolumn) text flow around an image is tedious.
So this would be just an incentive to provide different window layouts
(or layers).

 > We all know the subtle problems in
 > follow-mode, right?

Which we would have to solve anyway.  I wouldn't reinvent the wheel.

martin

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> Date: Sat, 24 Jan 2015 10:08:33 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19661@debbugs.gnu.org
> 
>  > That'd be a kludge-around.  I thought we were talking about teaching
>  > Emacs new layout tricks, not overloading existing ones with features
>  > they weren't designed to support.
> 
> Layouts should be handled at the Elisp level.

This is impossible with the current Emacs design, and you know it.
The design is that Lisp programs _specify_ the layout, by setting up
text properties, overlays, and local variables.  The actual _handling_
of the layout is done by the display engine, which is not exposed to
Lisp.

So if a particular kind of layout is not supported by the display
engine, you cannot specify it in Lisp.

> For example, having (multicolumn) text flow around an image is tedious.
> So this would be just an incentive to provide different window layouts
> (or layers).

I agree, but I don't think this can or should be done in Lisp.  Over
the years, I've seen many features that attempted to produce fancy
display traits not supported by the engine, and they all look kludgey
to me.  They also break very easily.

>  > We all know the subtle problems in follow-mode, right?
> 
> Which we would have to solve anyway.

The solutions are on the C level, not in Lisp.

> I wouldn't reinvent the wheel.

The wheel should be round, then it's a wheel.

bug#19661: wrapping before window-width (new wrap-column text property?)

[martin rudalics]

 >> Layouts should be handled at the Elisp level.
 >
 > This is impossible with the current Emacs design, and you know it.
 > The design is that Lisp programs _specify_ the layout, by setting up
 > text properties, overlays, and local variables.  The actual _handling_
 > of the layout is done by the display engine, which is not exposed to
 > Lisp.
 >
 > So if a particular kind of layout is not supported by the display
 > engine, you cannot specify it in Lisp.

The windows code does provide the display engine with a clipping
rectangle and two buffer positions where to start displaying text in
that rectangle and where to display the cursor (the latter may be
overridden by the display engine).  Together, these determine the basic
layout of buffer portions on screen and can be used by Lisp programs.

 > I agree, but I don't think this can or should be done in Lisp.  Over
 > the years, I've seen many features that attempted to produce fancy
 > display traits not supported by the engine, and they all look kludgey
 > to me.  They also break very easily.

With multiple columns we have to provide an API.  For example, to decide
whether the first character of a buffer's line is also the the first
character of a line in the rectangle displaying that line.  Otherwise,
we cannot provide the navigation facilities Ivan asked for.  If each
column is displayed in a separate rectangle, the first character of a
line is always the first character of the rectangle displaying that line
and you can handle this distinction, and thus provide the API, on the
Lisp level.

 > The wheel should be round, then it's a wheel.

And it should spin freely.

martin

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> Date: Sun, 25 Jan 2015 11:38:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19661@debbugs.gnu.org
> 
>  >> Layouts should be handled at the Elisp level.
>  >
>  > This is impossible with the current Emacs design, and you know it.
>  > The design is that Lisp programs _specify_ the layout, by setting up
>  > text properties, overlays, and local variables.  The actual _handling_
>  > of the layout is done by the display engine, which is not exposed to
>  > Lisp.
>  >
>  > So if a particular kind of layout is not supported by the display
>  > engine, you cannot specify it in Lisp.
> 
> The windows code does provide the display engine with a clipping
> rectangle and two buffer positions where to start displaying text in
> that rectangle and where to display the cursor (the latter may be
> overridden by the display engine).  Together, these determine the basic
> layout of buffer portions on screen and can be used by Lisp programs.

Sorry for being dense, this being just the first weekday for me, but
what "windows code" does that, please?

In any case, telling the display engine where to start the display is
a far cry from telling it how to lay out the screen from that point
onwards.

>  > I agree, but I don't think this can or should be done in Lisp.  Over
>  > the years, I've seen many features that attempted to produce fancy
>  > display traits not supported by the engine, and they all look kludgey
>  > to me.  They also break very easily.
> 
> With multiple columns we have to provide an API.  For example, to decide
> whether the first character of a buffer's line is also the the first
> character of a line in the rectangle displaying that line.  Otherwise,
> we cannot provide the navigation facilities Ivan asked for.  If each
> column is displayed in a separate rectangle, the first character of a
> line is always the first character of the rectangle displaying that line
> and you can handle this distinction, and thus provide the API, on the
> Lisp level.

Providing an API is not equivalent to implementing it.  In order for
us to be able to provide such an API, the display engine should
implement the support such an API will need.  And that's the hard part
of the job -- how to perform this layout.  Once we figure that out,
providing an API for controlling it will be easy.

bug#19661: wrapping before window-width (new wrap-column text property?)

[martin rudalics]

 > Sorry for being dense, this being just the first weekday for me, but
 > what "windows code" does that, please?

The one that calculates the text size of windows.  Or did you read
"Windows code"?

 > In any case, telling the display engine where to start the display is
 > a far cry from telling it how to lay out the screen from that point
 > onwards.

My point was to _not_ change the code of the display engine.

 > Providing an API is not equivalent to implementing it.  In order for
 > us to be able to provide such an API, the display engine should
 > implement the support such an API will need.  And that's the hard part
 > of the job -- how to perform this layout.  Once we figure that out,
 > providing an API for controlling it will be easy.

It essentially would have to subdivide a window into rectangles.  And I
would do that on the window(s) level to avoid the hard part of the job.

martin

bug#19661: wrapping before window-width (new wrap-column text property?)

[Eli Zaretskii]

> Date: Sun, 25 Jan 2015 18:46:34 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19661@debbugs.gnu.org
> 
>  > Sorry for being dense, this being just the first weekday for me, but
>  > what "windows code" does that, please?
> 
> The one that calculates the text size of windows.

OK, but I fail to see how this, or anything similar, can provide the
features being discussed.

>  > In any case, telling the display engine where to start the display is
>  > a far cry from telling it how to lay out the screen from that point
>  > onwards.
> 
> My point was to _not_ change the code of the display engine.

Why not?

>  > Providing an API is not equivalent to implementing it.  In order for
>  > us to be able to provide such an API, the display engine should
>  > implement the support such an API will need.  And that's the hard part
>  > of the job -- how to perform this layout.  Once we figure that out,
>  > providing an API for controlling it will be easy.
> 
> It essentially would have to subdivide a window into rectangles.  And I
> would do that on the window(s) level to avoid the hard part of the job.

Well, like I said, I consider such (ab)using of windows a kludge.

bug#19661: wrapping before window-width (new wrap-column text property?)

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 19:45:31 +0000

[…]

 >> I know of no way to make the Emacs display engine wrap one line but
 >> not the other in the very same buffer.

 > But then the feature you suggest will have the same problem, since it
 > will be build on the same infrastructure as word-wrap.

	When I set wrap-width for a specific line to a value greater
	than that line’s own width, I expect the line to no longer be
	wrapped.

	Also, as Stefan suggests, there can be a distinct “infinity”
	value for the property in question, to inhibit wrapping
	unconditionally for the line(s) covered.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

>  >> (Yes, Emacs can display proportional fonts and fonts of different
>  >> sizes, but until you can fold (etc) proportional text (and text with
>  >> a mixture of font sizes) in a pretty manner, that's more of a toy
>  >> than anything else.)
>
>  > What's non-pretty with how we do this now?  What features are
>  > missing?
>
> 	The only feature that I’m aware to be missing is the actual
> 	support for Emacs native text wrapping (as in: the word-wrap
> 	variable and wrap-prefix text property) in SHR.
>
> 	Please thus consider the patch MIMEd.

I think this was superseded by the shr proportional font rewrite, so I'm
closing the bug.

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

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> I do not know how to do this, but it sounds like a convenient
> solution! How does one tell shr to apply a particular font to its
> target (all that I know of is `shr-target-id', which seems to insert a
> '*')?

Look at `shr-tag-h1', for instance, and create whatever similar version
of that you want by overriding with `shr-external-rendering-functions'.

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

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Ivan Shmakov]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

[…]

 >> The only feature that I’m aware to be missing is the actual support
 >> for Emacs native text wrapping (as in: the word-wrap variable and
 >> wrap-prefix text property) in SHR.

 >> Please thus consider the patch MIMEd.

 > I think this was superseded by the shr proportional font rewrite, so
 > I'm closing the bug.

	I’ve stopped using the SHR version that comes with Emacs this
	May, so I don’t think I care much about that any longer.

	I have several items in my wishlist regarding rendering HTML in
	Emacs buffers, but I guess they will warrant writing the code
	anew, presumably to be released under a different name, so that
	it can be installed alongside SHR.

	(Not that I currently have much spare time to dedicate to that.)

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On 12/25/2015 11:51 PM, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
> 
>> I do not know how to do this, but it sounds like a convenient
>> solution! How does one tell shr to apply a particular font to its
>> target (all that I know of is `shr-target-id', which seems to insert a
>> '*')?
> 
> Look at `shr-tag-h1', for instance, and create whatever similar version
> of that you want by overriding with `shr-external-rendering-functions'.

That sounds like a great idea, actually. And I guess I can get the id of the current element to check it against the target id using (equal (dom-attr dom 'id) TARGET-ID).

I'll try that!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On 12/26/2015 05:53 PM, Clément Pit--Claudel wrote:
> On 12/25/2015 11:51 PM, Lars Ingebrigtsen wrote:
>> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>>
>>> I do not know how to do this, but it sounds like a convenient
>>> solution! How does one tell shr to apply a particular font to its
>>> target (all that I know of is `shr-target-id', which seems to insert a
>>> '*')?
>>
>> Look at `shr-tag-h1', for instance, and create whatever similar version
>> of that you want by overriding with `shr-external-rendering-functions'.
> 
> That sounds like a great idea, actually. And I guess I can get the id of the current element to check it against the target id using (equal (dom-attr dom 'id) TARGET-ID).
> 
> I'll try that!

I just tried this (capturing the id that I was interested in in a closure instead of putting it in shr-target-id), but shr-descend only works with globally defined functions; is there a reason for that? It's due to the following bit: 

	(if (fboundp function)
	    (funcall function dom)
	  (shr-generic dom))

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On 12/27/2015 04:36 AM, Clément Pit--Claudel wrote:
> On 12/26/2015 05:53 PM, Clément Pit--Claudel wrote:
>> On 12/25/2015 11:51 PM, Lars Ingebrigtsen wrote:
>>> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>>>
>>>> I do not know how to do this, but it sounds like a convenient
>>>> solution! How does one tell shr to apply a particular font to its
>>>> target (all that I know of is `shr-target-id', which seems to insert a
>>>> '*')?
>>>
>>> Look at `shr-tag-h1', for instance, and create whatever similar version
>>> of that you want by overriding with `shr-external-rendering-functions'.
>>
>> That sounds like a great idea, actually. And I guess I can get the id of the current element to check it against the target id using (equal (dom-attr dom 'id) TARGET-ID).
>>
>> I'll try that!

I looked into this more, but I don't think it will work. I want to highlight the context of the element that contains the target id, so if lines are not broken up then highlighting the full line works well. If they are, on the other hand, then I can't tell how much surrounding text to highlight.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> I just tried this (capturing the id that I was interested in in a
> closure instead of putting it in shr-target-id), but shr-descend only
> works with globally defined functions; is there a reason for that?
> It's due to the following bit:
>
> 	(if (fboundp function)
> 	    (funcall function dom)
> 	  (shr-generic dom))

I've now fixed this in the Emacs trunk.

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

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> I looked into this more, but I don't think it will work. I want to
> highlight the context of the element that contains the target id, so
> if lines are not broken up then highlighting the full line works
> well. If they are, on the other hand, then I can't tell how much
> surrounding text to highlight.

I'm not sure what you mean by "context".  But you can look "down" into
the DOM and see if your id is in an element there.  Or you can transform
the HTML, or transform the DOM, to wrap the elements you want to
highlight.

For instance, you can loop over all elements that have ids that match
with `dom-by-id', and you can alter the DOM to insert, say, h1 elements
around those that you want to have highlit.

Etc.

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

bug#19462: shr: use wrap-prefix when possible, instead of filling the text

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On 12/27/2015 07:22 AM, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
> 
>> I looked into this more, but I don't think it will work. I want to
>> highlight the context of the element that contains the target id, so
>> if lines are not broken up then highlighting the full line works
>> well. If they are, on the other hand, then I can't tell how much
>> surrounding text to highlight.
> 
> I'm not sure what you mean by "context".  But you can look "down" into
> the DOM and see if your id is in an element there.  Or you can transform
> the HTML, or transform the DOM, to wrap the elements you want to
> highlight.
> 
> For instance, you can loop over all elements that have ids that match
> with `dom-by-id', and you can alter the DOM to insert, say, h1 elements
> around those that you want to have highlit.

Thanks for the suggestions. It's not always obvious what element I want to highlight, though, beyond "everything that ends up on the same line. It may be that the thing I want to draw the attention of the user to is in a paragraph; in that case, I highlight the full paragrahp. Or it may be in a title; in that case, I highlight the full title. Or it may be part of a list; in that case I only highlight the item that contains it.

When the text that shr inserts isn't wrapped, I just need to highlight the line that contains that text after rendering is complete. When it is wrapped, however, it becomes unclear what exactly to highlight.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]