* bug#19587: shr: produces an extra newline before a block element in <li />
@ 2015-01-13 18:50 Ivan Shmakov
2015-12-25 17:33 ` Lars Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Ivan Shmakov @ 2015-01-13 18:50 UTC (permalink / raw)
To: 19587
Package: emacs
Severity: minor
As of ec7605b4b137 (2015-01-10 16:54:24 +0000), shr produces an
extra newline before a “block” element which is the first child
to a <li /> element. Consider, e. g.:
(with-temp-buffer
(let ((r
(shr-tag-ul
'(ul nil
(li nil (div nil "One item."))
(li nil (div nil "Another item."))))))
(cons r (buffer-string))))
(nil . "\
•
One item.
•
Another item.\n\n")
There, I’d rather expect no newline between the bullet and the
div elements’ contents, like:
(nil . "\
• One item.
• Another item.\n\n")
Somewhat surprisingly, this produces a still less consistent
result when the p elements are used:
(with-temp-buffer
(let ((r
(shr-tag-ul
'(ul nil
(li nil (p nil "One item."))
(li nil (p nil "Another item."))
(li nil
(p nil "One more item.")
(p nil "And one more paragraph to the same item."))))))
(cons r (buffer-string))))
(nil . "\
*
One item.
* Another item.
* One more item.
And one more paragraph to the same item.\n\n")
I’d rather expect it to be formatted as follows:
(nil . "\
* One item.
* Another item.
* One more item.
And one more paragraph to the same item.\n\n")
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#19587: shr: produces an extra newline before a block element in <li /> 2015-01-13 18:50 bug#19587: shr: produces an extra newline before a block element in <li /> Ivan Shmakov @ 2015-12-25 17:33 ` Lars Ingebrigtsen 2015-12-26 9:12 ` Ivan Shmakov 0 siblings, 1 reply; 5+ messages in thread From: Lars Ingebrigtsen @ 2015-12-25 17:33 UTC (permalink / raw) To: Ivan Shmakov; +Cc: 19587 Ivan Shmakov <ivan@siamics.net> writes: > Package: emacs > Severity: minor > > As of ec7605b4b137 (2015-01-10 16:54:24 +0000), shr produces an > extra newline before a “block” element which is the first child > to a <li /> element. Consider, e. g.: > > (with-temp-buffer > (let ((r > (shr-tag-ul > '(ul nil > (li nil (div nil "One item.")) > (li nil (div nil "Another item.")))))) > (cons r (buffer-string)))) Do you have HTML that demonstrates this problem? The forms no longer work since the DOM changed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19587: shr: produces an extra newline before a block element in <li /> 2015-12-25 17:33 ` Lars Ingebrigtsen @ 2015-12-26 9:12 ` Ivan Shmakov 2015-12-26 19:17 ` Ivan Shmakov 0 siblings, 1 reply; 5+ messages in thread From: Ivan Shmakov @ 2015-12-26 9:12 UTC (permalink / raw) To: 19587 [-- Attachment #1: Type: text/plain, Size: 830 bytes --] >>>>> Lars Ingebrigtsen <larsi@gnus.org> writes: >>>>> Ivan Shmakov <ivan@siamics.net> writes: >> As of ec7605b4b137 (2015-01-10 16:54:24 +0000), shr produces an >> extra newline before a “block” element which is the first child to a >> <li /> element. Consider, e. g.: >> (with-temp-buffer >> (let ((r >> (shr-tag-ul >> '(ul nil >> (li nil (div nil "One item.")) >> (li nil (div nil "Another item.")))))) >> (cons r (buffer-string)))) > Do you have HTML that demonstrates this problem? I can no longer reproduce the bug as of 1dcf9a5d. An example HTML document is MIMEd just in case. > The forms no longer work since the DOM changed. ? -- FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A [-- Attachment #2: Type: text/html, Size: 182 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19587: shr: produces an extra newline before a block element in <li /> 2015-12-26 9:12 ` Ivan Shmakov @ 2015-12-26 19:17 ` Ivan Shmakov 2016-02-29 7:07 ` Lars Ingebrigtsen 0 siblings, 1 reply; 5+ messages in thread From: Ivan Shmakov @ 2015-12-26 19:17 UTC (permalink / raw) To: 19587 [-- Attachment #1: Type: text/plain, Size: 934 bytes --] >>>>> Ivan Shmakov <ivan@siamics.net> writes: >>>>> Lars Ingebrigtsen <larsi@gnus.org> writes: >>>>> Ivan Shmakov <ivan@siamics.net> writes: >>> As of ec7605b4b137 (2015-01-10 16:54:24 +0000), shr produces an >>> extra newline before a “block” element which is the first child to >>> a <li /> element. Consider, e. g.: >>> (with-temp-buffer >>> (let ((r >>> (shr-tag-ul >>> '(ul nil >>> (li nil (div nil "One item.")) >>> (li nil (div nil "Another item.")))))) >>> (cons r (buffer-string)))) >> Do you have HTML that demonstrates this problem? > I can no longer reproduce the bug as of 1dcf9a5d. An example > HTML document is MIMEd just in case. Correction: I still can reproduce this by using a <div /> element; consider the document MIMEd. -- FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A [-- Attachment #2: Type: text/html, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19587: shr: produces an extra newline before a block element in <li /> 2015-12-26 19:17 ` Ivan Shmakov @ 2016-02-29 7:07 ` Lars Ingebrigtsen 0 siblings, 0 replies; 5+ messages in thread From: Lars Ingebrigtsen @ 2016-02-29 7:07 UTC (permalink / raw) To: Ivan Shmakov; +Cc: 19587 Ivan Shmakov <ivan@siamics.net> writes: > Correction: I still can reproduce this by using a <div /> > element; consider the document MIMEd. This should now be fixed in emacs-25. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-29 7:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-13 18:50 bug#19587: shr: produces an extra newline before a block element in <li /> Ivan Shmakov 2015-12-25 17:33 ` Lars Ingebrigtsen 2015-12-26 9:12 ` Ivan Shmakov 2015-12-26 19:17 ` Ivan Shmakov 2016-02-29 7:07 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).