GNU bug report logs -
#10973
shr rendering seems wrong
Previous Next
Reported by: Dave Abrahams <dave <at> boostpro.com>
Date: Fri, 9 Mar 2012 07:50:02 UTC
Severity: normal
Tags: fixed
Found in version 5.130004
Fixed in version 24.1
Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10973 in the body.
You can then email your comments to 10973 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Fri, 09 Mar 2012 07:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dave Abrahams <dave <at> boostpro.com>:
New bug report received and forwarded. Copy sent to
bugs <at> gnus.org.
(Fri, 09 Mar 2012 07:50:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
No matter how I set shr-width, it seems that most HTML messages render
way too narrowly. The enclosed example is 44 columns wide and I
requested full-window-width (shr-width is nil). I've also attached an
example of how the same message renders in Safari. Also, I don't seem to
see any images in shr renderings, though shr apparently does have some
kind of image support.
[browser.png (image/png, attachment)]
[shr.png (image/png, attachment)]
[Message part 4 (text/plain, inline)]
Ma Gnus v0.4
GNU Emacs 24.0.94.1 (x86_64-apple-darwin11.3.0, Carbon Version 1.6.0 AppKit 1138.32)
of 2012-03-03 on pluto.luannocracy.com
200 Leafnode NNTP Daemon, version 1.11.8 running at localhost.luannocracy.com (my fqdn: pluto.boostpro.com)
500 Unknown command
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Sat, 10 Mar 2012 00:41:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> No matter how I set shr-width, it seems that most HTML messages render
> way too narrowly. The enclosed example is 44 columns wide and I
> requested full-window-width (shr-width is nil). I've also attached an
> example of how the same message renders in Safari. Also, I don't seem to
> see any images in shr renderings, though shr apparently does have some
> kind of image support.
Could you forward the message in question, too? My guess is that there
are some <td>s in the HTML with width settings that confuses shr.el
somehow.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Sat, 10 Mar 2012 18:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 10973 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
on Fri Mar 09 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> No matter how I set shr-width, it seems that most HTML messages render
>> way too narrowly. The enclosed example is 44 columns wide and I
>> requested full-window-width (shr-width is nil). I've also attached an
>> example of how the same message renders in Safari. Also, I don't seem to
>> see any images in shr renderings, though shr apparently does have some
>> kind of image support.
>
> Could you forward the message in question, too? My guess is that there
> are some <td>s in the HTML with width settings that confuses shr.el
> somehow.
voilà:
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
===============================
Atlassian
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a7119d578caf8d34d562c765124911255a2888a3b06900c2dcfe3ae57685ea33c
===============================
Please give a warm welcome to HipChat, the newest member of the Atlassian family. Today we're pleased to announce we have acquired HipChat, an awesome group chat service that teams, and even entire companies, use to collaborate better in real-time. Atlassian teams - from product development to marketing and customer support - have been using HipChat for months. Simply put: we love it, and we think you will too.
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a62d13bbe54bc61a06dac8777941948c72cc63ed6f031f38eb3ba11bcc38545cd
HipChat is simple enough for the whole company to use, not just the techies. And it's loaded with goodies you'll love: persistent chat, file-sharing, instant display of media (images, YouTube videos, Tweets), social goodness like @mentions, integrations with loads of popular internet services, and much more. It rocks!
We want you to try HipChat with your team, so we've arranged a special offer for Bitbucket customers: get six months free service for as many users as you want. Offer expires on April 6, 2012.
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a7101e03a0ec6e3f0c26ee8d521807d3566fc1af751809061722143d402c4aeb4
Learn more about HipChat and redeem this special promotion, just for our customers, while it lasts.
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a62d13bbe54bc61a06dac8777941948c72cc63ed6f031f38eb3ba11bcc38545cd
Regards,
The Atlassians
Facebook:
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a13aea16356fb7e157ebe4c998ea874abf97744154e2d22f9bec792a48585adc1
Twitter:
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a20ab1778b4f379ffde96b7f55d6b1b46e595fbb5326ba48ddc0a26a63354d822
Blogs:
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a964253e78d93424212f565f2052834a841b482f3ab36973908ca82534a845276
Newsletter:
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266ab1a1353ab7df84a43b980a699f532f433157b523c677d3377df9a2d923a971a2
Contact Us:
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a8f07772dcff6b1022cfb95eb8040fe0e5c58fe6e3b69121737d5948930d483b8
It's us, not you.
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266a7125fdc2d0a1cbd854bd440b239558abe81cddb562c870a2e3b0d6ccc4f64bb0
Click here to unsubscribe from the Product Announcements List or manage your email subscriptions.
Copyright 2012 Atlassian Pty Ltd. All rights reserved. We are located at 173-185 Sussex Street, Sydney, NSW, 2000, Australia and here is our
http://click.mailer.atlassian.com/?qs=57dfb92a93c2266aba58fe2a3750af39558324ed9219ef4d01dc32802e25c1811a3fa8de8f38321b
Privacy Policy .
[Message part 4 (text/html, inline)]
[Message part 5 (text/plain, inline)]
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 16:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> voilà:
Eek. That had tables nested five levels deep...
But after slashing away at it for fifteen minutes, I've come up with the
following parse tree that displays the bug:
(table
((bgcolor . "#003366"))
(tr nil
(td nil
(table
((bgcolor . "#FFFFFF"))
(tr nil
(td nil)
(td nil "please give a warm welcome to bla bla bla"))))))
(save-excursion (goto-char (point-min)) (setq dom (read (current-buffer))) (pop-to-buffer "*html*") (erase-buffer) (shr-insert-document dom) (other-window 1))
That makes shr.el think that is has only 13 characters to render the
text in question.
Now to fix the bug...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 17:49:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
> Now to fix the bug...
I've located the problem, but fixing this totally without redoing how
all the table widths are computed looks to be kinda tricky. And at this
point in the Emacs 24 cycle, experimental coding probably isn't the
right thing to engage in.
I've found some bugs in the current computation, though, and I'll fix
those. But deeply nested tables probably won't be rendering as well as
they should in Emacs 24...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 18:02:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
> I've found some bugs in the current computation, though, and I'll fix
> those.
These are now committed to No Gnus. They don't actually help much in
your specific case, but they make some other tables render better.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 19:24:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> voilà:
>
> Eek. That had tables nested five levels deep...
That may be, but this sort of extremely narrow rendering is quite a common
experience for me on a variety of HTML emails I receive. I haven't
checked to see whether those mails are also full of tables.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 19:28:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> That may be, but this sort of extremely narrow rendering is quite a common
> experience for me on a variety of HTML emails I receive. I haven't
> checked to see whether those mails are also full of tables.
I'd be surprised if they weren't.
Anyway, I've now reimplemented how the table cell widths are computed
now (three times, actually), and the third time seems to cover all the
use cases I have, and renders your message readably. It's in No Gnus
now, so it'll appear in Emacs 24 later.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 19:33:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> That may be, but this sort of extremely narrow rendering is quite a common
>> experience for me on a variety of HTML emails I receive. I haven't
>> checked to see whether those mails are also full of tables.
>
> I'd be surprised if they weren't.
>
> Anyway, I've now reimplemented how the table cell widths are computed
> now (three times, actually), and the third time seems to cover all the
> use cases I have, and renders your message readably. It's in No Gnus
> now, so it'll appear in Emacs 24 later.
Thanks very much for your work on it!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 19:34:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> That may be, but this sort of extremely narrow rendering is quite a common
>> experience for me on a variety of HTML emails I receive. I haven't
>> checked to see whether those mails are also full of tables.
>
> I'd be surprised if they weren't.
>
> Anyway, I've now reimplemented how the table cell widths are computed
> now (three times, actually), and the third time seems to cover all the
> use cases I have, and renders your message readably. It's in No Gnus
> now, so it'll appear in Emacs 24 later.
Hmm, not be a perpetual complainer, but you might want to work on the
speed of rendering for that message in particular...
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 19:36:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> Hmm, not be a perpetual complainer, but you might want to work on the
> speed of rendering for that message in particular...
How long does it take for you, and what's your CPU?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 21:38:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Hmm, not be a perpetual complainer, but you might want to work on the
>> speed of rendering for that message in particular...
>
> How long does it take for you, and what's your CPU?
About 3.5 seconds,
Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz
3.5 seconds is tolerable, but it's a simple enough message that it seems
like there could be a scalability problem.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 22:04:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> About 3.5 seconds,
> Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz
Intel(R) Core(TM) i5-2390T CPU @ 2.70GHz, and it takes me about 0.3
seconds to render the message. So something is off.
Could you `M-x elp-instrument-package', view the article and then `M-x
elp-results'?
> 3.5 seconds is tolerable, but it's a simple enough message that it seems
> like there could be a scalability problem.
It's not a simple message, but a quite complicated message. :-)
You'll see the structure more clearly if you
(setq shr-table-vertical-line ?|
shr-table-horizontal-line ?-
shr-table-corner ?+)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Wed, 14 Mar 2012 23:11:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> About 3.5 seconds,
>> Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz
>
> Intel(R) Core(TM) i5-2390T CPU @ 2.70GHz, and it takes me about 0.3
> seconds to render the message. So something is off.
>
> Could you `M-x elp-instrument-package', view the article and then `M-x
> elp-results'?
--8<---------------cut here---------------start------------->8---
shr-descend 1096 36.677767000 0.0334651158
shr-generic 673 19.762296000 0.0293644814
shr-tag-table 110 16.675172000 0.1515924727
shr-tag-table-1 110 16.604425999 0.1509493272
shr-make-table 330 16.351984999 0.0495514696
shr-render-td 2007 16.342077000 0.0081425396
shr-insert-document 1 2.96734 2.96734
shr-tag-body 1 2.930845 2.930845
shr-colorize-region 602 0.2964739999 0.0004924817
shr-put-color 1986 0.2618129999 0.0001318293
shr-insert-table 110 0.2416919999 0.0021971999
shr-insert 633 0.1008650000 0.0001593443
shr-parse-style 735 0.0398039999 5.415...e-05
shr-put-color-1 7636 0.033944 4.445...e-06
shr-color-check 601 0.031523 5.245...e-05
shr-collect-overlays 669 0.0245419999 3.668...e-05
shr-color-visible 601 0.0227669999 3.788...e-05
shr-tag-a 188 0.0165250000 8.789...e-05
shr-transform-dom 159 0.0152960000 9.620...e-05
shr-find-fill-point 490 0.0099859999 2.037...e-05
shr-max-columns 220 0.0069680000 3.167...e-05
shr-overlays-in-region 4317 0.0063980000 1.482...e-06
shr-find-elements 121 0.0061439999 5.077...e-05
shr-insert-table-ruler 583 0.0051170000 8.777...e-06
shr-urlify 188 0.0048599999 2.585...e-05
shr-column-specs 110 0.0044919999 4.083...e-05
shr-expand-newlines 2 0.0030090000 0.0015045000
shr-color->hexadecimal 1202 0.0027279999 2.269...e-06
shr-remove-trailing-whitespace 1 0.002094 0.002094
shr-tag-img 200 0.0018579999 9.289...e-06
shr-count 1892 0.0015719999 8.308...e-07
shr-natural-width 2 0.0015049999 0.0007524999
shr-indent 3805 0.0012919999 3.395...e-07
shr-add-font 190 0.0011790000 6.205...e-06
shr-table-widths 110 0.0010829999 9.845...e-06
shr-color-set-minimum-interval 306 0.0006600000 2.156...e-06
shr-expand-url 388 0.0006260000 1.613...e-06
shr-tag-div 20 0.0004859999 2.429...e-05
shr-pro-rate-columns 110 0.0004370000 3.972...e-06
shr-ensure-paragraph 112 0.0002650000 2.366...e-06
shr-tag-title 1 0.000141 0.000141
shr-heading 1 0.000137 0.000137
shr-fontize-cont 1 9.8e-05 9.8e-05
shr-tag-br 10 8.800...e-05 8.8e-06
shr-previous-newline-padding-width 76 5.099...e-05 6.710...e-07
shr-tag-comment 117 4.599...e-05 3.931...e-07
shr-ensure-newline 40 4.200...e-05 1.050...e-06
shr-image-displayer 25 2.200...e-05 8.800...e-07
shr-tag-style 20 1.600...e-05 8.000...e-07
--8<---------------cut here---------------end--------------->8---
>
>> 3.5 seconds is tolerable, but it's a simple enough message that it seems
>> like there could be a scalability problem.
>
> It's not a simple message, but a quite complicated message. :-)
>
> You'll see the structure more clearly if you
>
> (setq shr-table-vertical-line ?|
> shr-table-horizontal-line ?-
> shr-table-corner ?+)
Meh. Should be fast for a computer :-) I only said "simple enough."
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 00:08:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> shr-render-td 2007 16.342077000 0.0081425396
Yikes. That's like an exponential number of calls based on the depth of
the table nesting... which, come to think of it, is what shr does.
> Meh. Should be fast for a computer :-) I only said "simple enough."
If you have a better algorithm for computing widths of table cells,
please go ahead. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 00:54:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> shr-render-td 2007 16.342077000 0.0081425396
>
> Yikes. That's like an exponential number of calls based on the depth of
> the table nesting... which, come to think of it, is what shr does.
>
>> Meh. Should be fast for a computer :-) I only said "simple enough."
>
> If you have a better algorithm for computing widths of table cells,
> please go ahead. :-)
My better algorithm for now might turn out to be "figure out how to get
my Gnus to use w3m like it used to. In fact, why not ask Lars?"
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 01:50:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> My better algorithm for now might turn out to be "figure out how to get
> my Gnus to use w3m like it used to. In fact, why not ask Lars?"
I'm pretty sure that's in the manual.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Added tag(s) fixed.
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 15 Mar 2012 01:56:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 24.1, send any further explanations to
10973 <at> debbugs.gnu.org and Dave Abrahams <dave <at> boostpro.com>
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 15 Mar 2012 01:56:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 02:18:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> My better algorithm for now might turn out to be "figure out how to get
>> my Gnus to use w3m like it used to. In fact, why not ask Lars?"
>
> I'm pretty sure that's in the manual.
I'm pretty sure what the manual says to do isn't working for me. It's
using shr despite my setting.
,----[ C-h v mm-text-html-renderer RET ]
| mm-text-html-renderer is a variable defined in `mm-decode.el'.
| Its value is w3m
| Original value was shr
|
| Documentation:
| Render of HTML contents.
| It is one of defined renderer types, or a rendering function.
| The defined renderer types are:
| `shr': use the built-in Gnus HTML renderer;
| `gnus-w3m': use Gnus renderer based on w3m;
| `w3m': use emacs-w3m;
| `w3m-standalone': use plain w3m;
| `links': use links;
| `lynx': use lynx;
| `w3': use Emacs/W3;
| `html2text': use html2text;
| nil : use external viewer (default web browser).
|
| You can customize this variable.
|
| This variable was introduced, or its default value was changed, in
| version 24.1 of Emacs.
|
| [back]
`----
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 02:21:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> I'm pretty sure what the manual says to do isn't working for me. It's
> using shr despite my setting.
>
> ,----[ C-h v mm-text-html-renderer RET ]
> | mm-text-html-renderer is a variable defined in `mm-decode.el'.
> | Its value is w3m
> | Original value was shr
It works for me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 02:28:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Dave Abrahams <dave-AT-boostpro.com> wrote:
> on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
>
>> Dave Abrahams <dave <at> boostpro.com> writes:
>>
>>> My better algorithm for now might turn out to be "figure out how to get
>>> my Gnus to use w3m like it used to. In fact, why not ask Lars?"
>>
>> I'm pretty sure that's in the manual.
>
> I'm pretty sure what the manual says to do isn't working for me. It's
> using shr despite my setting.
>
> ,----[ C-h v mm-text-html-renderer RET ]
> | mm-text-html-renderer is a variable defined in `mm-decode.el'.
> | Its value is w3m
> | Original value was shr
> |
> | Documentation:
> | Render of HTML contents.
> | It is one of defined renderer types, or a rendering function.
> | The defined renderer types are:
> | `shr': use the built-in Gnus HTML renderer;
> | `gnus-w3m': use Gnus renderer based on w3m;
> | `w3m': use emacs-w3m;
> | `w3m-standalone': use plain w3m;
> | `links': use links;
> | `lynx': use lynx;
> | `w3': use Emacs/W3;
> | `html2text': use html2text;
> | nil : use external viewer (default web browser).
> |
> | You can customize this variable.
> |
> | This variable was introduced, or its default value was changed, in
> | version 24.1 of Emacs.
> |
> | [back]
> `----
Oddly, when I un-customized mm-discouraged-alternatives, (it was
("text/html" "text/richtext")), w3m rendering came back.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 02:30:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 10973 <at> debbugs.gnu.org (full text, mbox):
Dave Abrahams <dave <at> boostpro.com> writes:
> Oddly, when I un-customized mm-discouraged-alternatives, (it was
> ("text/html" "text/richtext")), w3m rendering came back.
When I have that setting, text/html is discouraged whether I use shr or
w3m for rendering, so I seem to be unable to reproduce this.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bugs <at> gnus.org:
bug#10973; Package
gnus.
(Thu, 15 Mar 2012 03:26:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 10973 <at> debbugs.gnu.org (full text, mbox):
on Wed Mar 14 2012, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Oddly, when I un-customized mm-discouraged-alternatives, (it was
>> ("text/html" "text/richtext")), w3m rendering came back.
>
> When I have that setting, text/html is discouraged whether I use shr or
> w3m for rendering, so I seem to be unable to reproduce this.
If it helps, the complete rundown of my gnus-related settings is in
https://github.com/dabrahams/dwamacs/tree/166213aab7fede7e79d9b712d20cec3b536a3d25/settings
See, in particular, gnus-settings.el, mime-settings.el,
mail-settings.el, and message-settings.el
(customizations are at the bottom of each file).
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 12 Apr 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.