Built-in HTML renderer in Emacs?

Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

By the way, has there been any progress the past, er, decade in getting
an HTML renderererer included in Emacs?  I mean, emacs-w3m is fine for
me, but it's not included in the base distribution, so that doesn't
really help normal(ish) people much...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Leo]

On 2010-08-28 23:43 +0100, Lars Magne Ingebrigtsen wrote:
> By the way, has there been any progress the past, er, decade in
> getting an HTML renderererer included in Emacs? I mean, emacs-w3m is
> fine for me, but it's not included in the base distribution, so that
> doesn't really help normal(ish) people much...

It looks like proposals to include emacs-w3m have been made a few times.

Leo

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Leo <sdl.web@gmail.com> writes:

> It looks like proposals to include emacs-w3m have been made a few times.

What are the objections?  Missing paperwork?  The reliance on the w3m
program? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What are the objections?  Missing paperwork?  The reliance on the w3m
> program? 

I've poked around a bit, and emacs-w3m is apparently built around the
concept that you can call "w3m -halfdump" and get stuff like the
following out:

                                                                       <title_alt title="Gnus Newsreader Homepage"><pre_int><img_alt src="pictures/gnus.gif" hseq="1" title="">[gnus]  </img_alt></pre_int>

<b>Gnus Network User Services</b>

GNUS is the one-stop shopping center dedicated to all things Gnus, the Emacs
newsreader.

  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="1" href="about.html">About Gnus</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="2" href="history.html">A short Gnus history</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="3" href="resources.html">Resources</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="4" href="distribution.html">Distribution</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="5" href="manual.html">Manuals</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="6" href="contrib.html">Other packages</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="7" href="links.html">Related reading</a>
  <_SYMBOL TYPE=32>*</_SYMBOL> <a hseq="8" href="stuff/">Paraphernalia</a>

<nobr><_SYMBOL TYPE=26>-------------------------------------------------------------------------------</_SYMBOL>
</nobr>

Then is processes that and makes it all purdy and stuff.

Since emacs-w3m implements a complete browser based on this, emacs-w3m
is kinda big.

It seems to me that it should be a day's work to implement a simple html
viewer based on this.  I mean, one that doesn't do cookies or bookmarks
or anything -- just take a buffer with html, run it through this, and
make the URLs clickable (and point to browse-url) and display and cache
the images.

It won't be as good as emacs-w3m, but it would be included in the
default Emacs distribution.

I'm really tempted.  Like really.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 01:10:51 +0200, Lars wrote:

[...]

> It seems to me that it should be a day's work to implement a simple html
> viewer based on this.

[...]

> I'm really tempted.  Like really.  

Go, Lars, go!


  :-),

-- 
 "Didn't matter to me what I said. Still doesn't,             Adam Sjøgren
  really."                                               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> asjo@koldfront.dk (Adam Sjøgren):

> On Sun, 29 Aug 2010 01:10:51 +0200, Lars wrote:
> [...]

>> It seems to me that it should be a day's work to implement a simple html
>> viewer based on this.

> [...]

>> I'm really tempted.  Like really.  

> Go, Lars, go!

Well there is (was?) Bill Perry's w3-mode
	http://en.wikipedia.org/wiki/Emacs/W3

There is a resurrection of that browser here:
	http://www.gnu.org/software/w3/
but I don't know the current state.

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Well there is (was?) Bill Perry's w3-mode
> 	http://en.wikipedia.org/wiki/Emacs/W3

There's been quite a few Emacs-based web browsers over the years, which
is why nobody has written a minimal HTML viewer, because we were all
waiting for a real browser to be included in Emacs.

Which is why I didn't write gnus-html.el fifteen years ago, which I
should have.

I've now gotten minimal workability -- it displays the gwene groups I've
tested in somewhat correctly, and makes the links clickable and the
pictures...  er...  picturable.

Now to add some frills and stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Now to add some frills and stuff.

And I've tried the pre-fetching stuff, which works kinda OK, but not
totally.  I think if Emacs has done a MAKE-IMAGE on a file before, then
it's cached somewhere in memory?  So selecting an article that has all
the images on local disc isn't instantaneous, like it is the second time
you select it.

I think that can probably be fixed by just calling MAKE-IMAGE from the
async hook, but I think it's almost my bed time...  back in my days I
would have stayed up all night instead of waddling to bed at 5AM...  get
off my lawn, you young whippersnappers...  rassa frassa...

Anyway.  There are some artifacts here and there, and it probably
doesn't work under XEmacs since I haven't tested it under XEmacs, so let
me know what the bugs are.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Leo]

On 2010-08-29 00:02 +0100, Lars Magne Ingebrigtsen wrote:
>> It looks like proposals to include emacs-w3m have been made a few times.
>
> What are the objections? Missing paperwork? The reliance on the w3m
> program?

I can't remember so must be one of those trivial reasons.

But you have made the right decision to roll one for gnus; that is
great. I think it will take a while to get emacs-w3m in emacs.

Leo

Re: Built-in HTML renderer in Emacs?

[David Engster]

Leo writes:
> On 2010-08-29 00:02 +0100, Lars Magne Ingebrigtsen wrote:
>>> It looks like proposals to include emacs-w3m have been made a few times.
>>
>> What are the objections? Missing paperwork? The reliance on the w3m
>> program?
>
> I can't remember so must be one of those trivial reasons.

I think it was a problem of some developers getting approval of their
employers. The reliance on an external program is not a problem as long
as it's free software.

-David

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

I've been tweaking it a bit more, and added some error-checking here and
there, and it now seems quite stable.  The image prefetch makes it much
more pleasant to the tah bloogs from Gwene.

The main remaining issue is the eternal charset issue.  Hm.  Perhaps I
should take a peek at what emacs-w3m does here...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 04:45:18 +0200, Lars wrote:

> Anyway.  There are some artifacts here and there, and it probably
> doesn't work under XEmacs since I haven't tested it under XEmacs, so let
> me know what the bugs are.

First: I have to load gnus-html.el and mm-url.el manually to not have
XEmacs complain about gnus-article-html and mm-url-decode-entities not
being around.

When I have done that, the article buffer seems to be somewhat rendered
(the html is rendered, but no headers nor images are shown), and then I
get this error:

  Debugger entered--Lisp error: (void-function set-process-plist)
    (set-process-plist process (list (quote images) images (quote buffer) buffer))
    (let* ((url ...) (process ...)) (set-process-sentinel process (quote gnus-html-curl-sentinel)) (set-process-plist process (list ... images ... buffer)))
    gnus-html-schedule-image-fetching(#<buffer "*Article nntp+news.gwene.org:gwene.com.livejournal.jwz.atom*"> (("http://www.jwz.org/images/tumblr_l5u8ao1ewu1qct75oo1_500.jpg" #<marker at 774 in *Article nntp+news.gwene.org:gwene.com.livejournal.jwz.atom* 0xda06> #<marker at 786 in *Article nntp+news.gwene.org:gwene.com.livejournal.jwz.atom* 0xda07>)))
    (if images (gnus-html-schedule-image-fetching (current-buffer) (nreverse images)))
    (when images (gnus-html-schedule-image-fetching (current-buffer) (nreverse images)))
    (let (tag parameters string start end images) (mm-url-decode-entities) (goto-char (point-min)) (while (re-search-forward "<\\([^ />]+\\)\\([^>]*\\)>" nil t) (setq tag ... parameters ... start ...) (when ... ...) (delete-region start ...) (when ... ...) (setq end ...) (cond ... ... ...) (goto-char start)) (goto-char (point-min)) (while (re-search-forward "</pre_int>" nil t) (replace-match "" t t)) (when images (gnus-html-schedule-image-fetching ... ...)))
    gnus-html-wash-tags()
    (save-restriction (narrow-to-region (point) (point)) (save-excursion (set-buffer ...) (call-process-region ... ... "w3m" nil article-buffer nil "-halfdump" "-t" ... "-cols" ... "-o" "display_image=off" "-T" "text/html")) (gnus-html-wash-tags))
    (let ((article-buffer ...)) (save-restriction (narrow-to-region ... ...) (save-excursion ... ...) (gnus-html-wash-tags)))
    gnus-article-html((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
    mm-inline-text-html((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
    mm-display-inline((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
    mm-display-part((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil) t)
    byte-code("..." [type ignored handles beg display handle string-match nil mm-inline-override-p 4 "inline" mm-attachment-override-p mm-automatic-display-p mm-inlinable-p mm-inlined-p mm-automatic-external-display-p t split-string "/" "text" "message" insert-char ?\n 2 0 1 gnus-unbuttonized-mime-type-p gnus-insert-mime-button gnus-article-insert-newline -1 (set-buffer gnus-summary-buffer) ((error)) gnus-article-mode gnus-buffer-live-p mm-display-part mm-insert-inline mail-content-type-get charset "text/calendar" utf-8 mm-string-as-multibyte mm-get-part gnus-decoded buffer-string mm-decode-string gnus-treat-article "application/pgp-signature" gnus-safe-html-newsgroups part --dolist-temp--51136 ...] 6)
    gnus-mime-display-single((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
    gnus-mime-display-part((#<buffer " *mm*"> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
    gnus-display-mime()
    gnus-article-prepare-display()
    gnus-article-prepare(79 nil)
    gnus-summary-display-article(79)
    gnus-summary-next-page(nil)
    call-interactively(gnus-summary-next-page)
    (dispatch-event "[internal]")

That one I couldn't crack within my attention span of 5s.

XEmacs 21.5  (beta29) "garbanzo" db84c9d41437+ [Lucid] (x86_64-pc-linux, Mule) of Fri Aug 27 2010 on topper

  :-),

   Adam

-- 
 "Didn't matter to me what I said. Still doesn't,             Adam Sjøgren
  really."                                               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> When I have done that, the article buffer seems to be somewhat rendered
> (the html is rendered, but no headers nor images are shown), and then I
> get this error:
>
>   Debugger entered--Lisp error: (void-function set-process-plist)

I need to stash some data in the process object...  what's that function
called in XEmacs?

Oh, I should just start XEmacs and debug it myself...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 16:26:05 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> Debugger entered--Lisp error: (void-function set-process-plist)

> I need to stash some data in the process object...  what's that function
> called in XEmacs?

That was exactly where my 5s attention span ran out :-)

> Oh, I should just start XEmacs and debug it myself...

I tried the naïve googling of the function name and XEmacs, but didn't
find anything of help (to me).


  Best regards,

    Adam

-- 
 "The success of open source code is perhaps the only         Adam Sjøgren
  thing in the computer field that hasn't surprised me   asjo@koldfront.dk
  during the past several decades."

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Oh, I should just start XEmacs and debug it myself...

Gnus won't start at all for me under XEmacs, I'm afraid, so I think I'll
just give up on that and let somebody who's interested in figuring that
stuff out, er, figure that stuff out.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 16:34:35 +0200, Lars wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Oh, I should just start XEmacs and debug it myself...

> Gnus won't start at all for me under XEmacs

When I try GNU Emacs, I usually have a separate test user, so I don't
have to change the files in my usual setup.

A minimal .gnus like this in ~test/.gnus did the trick yesterday:

  (setq gnus-select-method '(nnnil ""))

  (setq gnus-secondary-select-methods
        '(
          (nntp "news.gwene.org"
                (nntp-address "news.gwene.org"))
          ))

  (setq mm-inline-text-html-with-images t)

  (setq mm-w3m-safe-url-regexp nil
        w3m-default-display-inline-images t)

when I was trying out the slowness.

> I'm afraid, so I think I'll just give up on that and let somebody
> who's interested in figuring that stuff out, er, figure that stuff
> out.

Darn - ok; I shall pester some XEmacs folks if no one jumps on this.


   :-),

    Adam

-- 
 "I went for the police                                       Adam Sjøgren
  But they were all over town                            asjo@koldfront.dk
  I went for the fireengines
  But they were all upside down"

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 16:43:03 +0200, Adam wrote:

> Darn - ok; I shall pester some XEmacs folks if no one jumps on this.

Aidan Kehoe replied:

 * http://article.gmane.org/gmane.emacs.xemacs.beta/33453

When I eval his lines, the next thing I run into is "put-image". But it
seems that compability there is already handled, as there is a
"gnus-put-image" function.

Next problem after that is that XEmacs doesn't have "find-image". That
is worked around elsewhere in Gnus by just checking for its existence.

So, I monkey patch thusly:

diff --git a/lisp/gnus-html.el b/lisp/gnus-html.el
index c8aec16..a40043e 100644
--- a/lisp/gnus-html.el
+++ b/lisp/gnus-html.el
@@ -167,10 +167,11 @@
 	     (not (and (eq (getf (cdr image) :type) 'gif)
 		       (= (car (image-size image t)) 30))))
 	(progn
-	  (put-image image point)
+	  (gnus-put-image image point)
 	  t)
-      (put-image (find-image '((:type xpm :file "lock-broken.xpm")))
-		 point)
+      (if (fboundp 'find-image)
+          (gnus-put-image (find-image '((:type xpm :file "lock-broken.xpm")))
+                          point))
       nil)))
 
 (defun gnus-html-prune-cache ()

Now I can open a gwene article XEmacs without any errors popping up, and
the HTML is rendered, but no images are shown. Maybe gnus-put-image
doesn't do what I think it does. Or something else.

Progress!

Slight!


  :-),

   Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> So, I monkey patch thusly:
>
> diff --git a/lisp/gnus-html.el b/lisp/gnus-html.el
> index c8aec16..a40043e 100644

I tried running the file through "git am" thusly:

[larsi@quimbies ~/pgnus/lisp]$ git am < /tmp/a
previous rebase directory /home/larsi/pgnus/.git/rebase-apply still exists but mbox given.

And then...  er...  is that an error, or...  the file didn't change,
anyway.  Now what?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

When I hover over a link in an article rendered by gnus-article-html,
the mini buffer shows "Follow the link" - it would be helpful if I could
see what the link actually is, I think?


  :-),

   Adam

-- 
 "KOMPRESSOR sound is hard and angry, good words used         Adam Sjøgren
  for song and electronic."                              asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> When I hover over a link in an article rendered by gnus-article-html,
> the mini buffer shows "Follow the link" - it would be helpful if I could
> see what the link actually is, I think?

Yup.  Fix in No Gnus v0.11 (i. e., CVS).

Hey!  I still had that as a keyboard shortcut, although it's kinda wrong
now... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 20:38:40 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> So, I monkey patch thusly:

>> diff --git a/lisp/gnus-html.el b/lisp/gnus-html.el
>> index c8aec16..a40043e 100644

> I tried running the file through "git am" thusly:

Ah, sorry, I didn't use "git format-patch" to create the patch, so I
guess stuff was missing.

Let me try to send it again.


  Best regards,

    Adam

-- 
 "KOMPRESSOR sound is hard and angry, good words used         Adam Sjøgren
  for song and electronic."                              asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

gwene.dk.ing.blogs.phloggen.rss:111 looks like it is displayed with
double encoded utf-8 with gnus-article-html, while w3m shows the Danish
characters as expected.

Also:

On Mon, 30 Aug 2010 14:17:40 +0200, Lars wrote:

> `gnus-put-image' should actually work, on second thought.

Can't wait!


  :-),

   Adam

-- 
 "The laws of perspective have been repealed!                 Adam Sjøgren
  Objects no longer diminish in size with distance!"     asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Can't wait!

Give it a whirl...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 18:51:28 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> Can't wait!

> Give it a whirl...

I still have to require mm-url and gnus-html manually.

I get no errors.

But I get no images either.

If I wait quite a while, I can see - with ngrep - a request go out, but
nothing is displayed i XEmacs.

Maybe the three forms that Aidan Kehoe wrote for set-process-plist etc. 
aren't quite enough?


  Best regards,

    Adam

-- 
 "The laws of perspective have been repealed!                 Adam Sjøgren
  Objects no longer diminish in size with distance!"     asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> I still have to require mm-url and gnus-html manually.

Odd.  The interface functions have the autoload cookies in from of them,
so the gnus-load.el file should be generated and have them?  

> If I wait quite a while, I can see - with ngrep - a request go out, but
> nothing is displayed i XEmacs.

The images should end up in ~/News/html-cache/...

> Maybe the three forms that Aidan Kehoe wrote for set-process-plist etc. 
> aren't quite enough?

Wasn't there a C-level patch needed, too?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 19:18:29 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> I still have to require mm-url and gnus-html manually.

> Odd.  The interface functions have the autoload cookies in from of them,
> so the gnus-load.el file should be generated and have them?  

  $ grep gnus-html lisp/gnus-load.el
  $ grep mm-url lisp/gnus-load.el
  $ 

>> If I wait quite a while, I can see - with ngrep - a request go out, but
>> nothing is displayed i XEmacs.

> The images should end up in ~/News/html-cache/...

Lemme try and see... Yes, files appear there. But no pictures are
displayed.

>> Maybe the three forms that Aidan Kehoe wrote for set-process-plist etc. 
>> aren't quite enough?

> Wasn't there a C-level patch needed, too?

Maybe I misread his reply. Ah, yes, I did. Ok, off to patch and try
again. Sorry.


  Best regards,

    Adam

-- 
 "Are you talking to us from yesterday?"                      Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 19:32:18 +0200, Adam wrote:

>> Wasn't there a C-level patch needed, too?

> Maybe I misread his reply. Ah, yes, I did. Ok, off to patch and try
> again. Sorry.

I have rebuilt with the patch, and no images. They are requested
(ngrep), they are stored (~/News/html-cache/*), but not displayed.

No errors either.


  :-/,

   Adam

-- 
 "Vegetarian progressive grindcore"                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> I have rebuilt with the patch, and no images. They are requested
> (ngrep), they are stored (~/News/html-cache/*), but not displayed.

Try evaling

  (gnus-put-html-image "~/News/html-cache/FOO" (point))

and see what happens.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 20:28:07 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> I have rebuilt with the patch, and no images. They are requested
>> (ngrep), they are stored (~/News/html-cache/*), but not displayed.

> Try evaling

>   (gnus-put-html-image "~/News/html-cache/FOO" (point))

> and see what happens.  

Evaling:

  (gnus-html-put-image "~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387" (point))

Returns nil.

  $ file ~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387
  /home/asjo/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387: JPEG image data, JFIF standard 1.01
  $ 

Hm.


  Best regards,

    Adam

-- 
 "Vegetarian progressive grindcore"                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 20:36:04 +0200, Adam wrote:

>   (gnus-html-put-image "~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387" (point))

> Returns nil.

edebug-defun on gnus-html-put-image reveals why: XEmacs doesn't have
create-image... so image is nil.


  Best regards,

    Adam

-- 
 "Vegetarian progressive grindcore"                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Hm.

Try edebugging it.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 20:39:51 +0200, Lars wrote:

> Try edebugging it.  :-)

Way ahead of you. Like, 33s.


  :-),

    Adam

-- 
 "Först kom ingenting                                         Adam Sjøgren
  Sen kom ingenting"                                     asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>
>> So, I monkey patch thusly:
>>
>> diff --git a/lisp/gnus-html.el b/lisp/gnus-html.el
>> index c8aec16..a40043e 100644
>
> I tried running the file through "git am" thusly:
>
> [larsi@quimbies ~/pgnus/lisp]$ git am < /tmp/a
> previous rebase directory /home/larsi/pgnus/.git/rebase-apply still exists but mbox given.
>
> And then...  er...  is that an error, or...  the file didn't change,
> anyway.  Now what?

You didn't complete a previous git am.  Either run git am --abort or
continue it with git am --continue.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Built-in HTML renderer in Emacs?

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> It seems to me that it should be a day's work to implement a simple html
> viewer based on this.  I mean, one that doesn't do cookies or bookmarks
> or anything -- just take a buffer with html, run it through this, and
> make the URLs clickable (and point to browse-url) and display and cache
> the images.

Like html2text?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> And then...  er...  is that an error, or...  the file didn't change,
>> anyway.  Now what?
>
> You didn't complete a previous git am.  Either run git am --abort or
> continue it with git am --continue.

Yeah, I got that to work..

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Like html2text?

No -- isn't html2text mainly concerned with removing tags and stuff?
w3m renders the text as a web browser would.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 20:39:33 +0200, Adam wrote:

> On Mon, 30 Aug 2010 20:36:04 +0200, Adam wrote:
>> (gnus-html-put-image "~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387" (point))

>> Returns nil.

> edebug-defun on gnus-html-put-image reveals why: XEmacs doesn't have
> create-image... so image is nil.

Ok; just pulled and tried again - now I get to gnus-create-image, which
is gnus-xmas-create-image, which seems to only handle pbm and xbm files,
so the PNG file in ~/News/html-cache/f0ba isn't handled.


  Best regards,

    Adam

-- 
 "Sunday morning when the rain begins to fall                 Adam Sjøgren
  I believe I have seen the end of it all"               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Ok; just pulled and tried again - now I get to gnus-create-image, which
> is gnus-xmas-create-image, which seems to only handle pbm and xbm files,
> so the PNG file in ~/News/html-cache/f0ba isn't handled.

Gah.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 22:11:10 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> Ok; just pulled and tried again - now I get to gnus-create-image, which
>> is gnus-xmas-create-image, which seems to only handle pbm and xbm files,
>> so the PNG file in ~/News/html-cache/f0ba isn't handled.

> Gah.

Well, if this isn't turning out to be a public crash-course in elisp, as
well as an endless source of me embarrasing myself...

I think I misread that function, as well - please don't take my word for
anything when it comes to what elisp does and doesn't.

(I am comparing to what w3m does, now, and it looks quite similar -
calls make-glyph).


  Best regards,

    Adam

-- 
 "Sunday morning when the rain begins to fall                 Adam Sjøgren
  I believe I have seen the end of it all"               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

Ok, so this is what I am edebugging my way into: gnus-xmas-create-image
tries to use the filename extension as the type.

So type becomes the entire filename
"~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387"; and this
code:

	      (make-glyph
	       (vector
		(or (intern type)
		    (mm-image-type-from-buffer))
		:data (buffer-string))))))

returns nil.

So, I tried changing the filename to end in '.jpg'. Well, that failed
spectacularly with nil.

I have no idea what 'intern'¹ does, but it doesn't seem to do any good
there?

Ok, so I changed the filename to end in '.jpeg', and - lo and behold -
now I got something other than nil in the mini-buffer:

  Wrong type argument: lisp, #<glyph (buffer) #<image-specificer
  global=((x) . [jpeg :data "ÿØÿà........etc.etc.

Close? elisp is hard, let's go shopping.


  Best regards,

    Adam

¹ 
,----
| `intern' is a built-in function
|   -- loaded from "/usr/src/xemacs/xemacs-snapshot-21.5/src/symbols.c"
| (intern STRING &optional OBARRAY)
| 
| Documentation:
| Return the canonical symbol whose name is STRING.
| If there is none, one is created by this function and returned.
| Optional second argument OBARRAY specifies the obarray to use;
| it defaults to the value of the variable `obarray'.
`----

-- 
 "Sunday morning when the rain begins to fall                 Adam Sjøgren
  I believe I have seen the end of it all"               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> So type becomes the entire filename
> "~/News/html-cache/2e3c3819257fbbdf9d03712c188dad90c3667387"; and this
> code:
>
> 	      (make-glyph
> 	       (vector
> 		(or (intern type)
> 		    (mm-image-type-from-buffer))
> 		:data (buffer-string))))))
>
> returns nil.

That's very bogus.  I've now checked in something that should possibly
fix this for dot-less image names.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 22:41:17 +0200, Lars wrote:

> That's very bogus.  I've now checked in something that should possibly
> fix this for dot-less image names.

It does; now I don't get nil, but the "Wrong type argument: lisp,
#<glyph (buffer) #<image-specificer global=((x) . [jpeg :data "ÿØÿà...."
message.


  Best regards,

    Adam

-- 
 "Sunday morning when the rain begins to fall                 Adam Sjøgren
  I believe I have seen the end of it all"               asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> It does; now I don't get nil, but the "Wrong type argument: lisp,
> #<glyph (buffer) #<image-specificer global=((x) . [jpeg :data "ÿØÿà...."
> message.

Oh, I know what that is.  Pushed out.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Like html2text?
>
> No -- isn't html2text mainly concerned with removing tags and stuff?
> w3m renders the text as a web browser would.

I'm using it for gwene groups where the articles are not really html
(like gwene.de.snookermania.forum, it contains just the raw forum posts
and a real html renderer messes up the formatting).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 22:52:42 +0200, Lars wrote:

> Oh, I know what that is.  Pushed out.

I saw an image - success!

Well, the buffer also had a sha1 and some other text after the image,
which wasn't supposed to be there:

  "M
   9Df78Eab33525D08D6E5Fb8D27136E95 F I File 1 18 Support the Pirate Bay"
                                                  ^
    - gwene.net.boingboing.ibag:56

But if I quit the group and read the same article, the image isn't
displayed again.

If I delete html-cache it is. It looks like it only works if the image
is fetched over the net...

Woohoo!


  Best regards,

     Adam

-- 
 "Noone stops you                                             Adam Sjøgren
  Like you stop yourself"                                asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> If I delete html-cache it is. It looks like it only works if the image
> is fetched over the net...

Hm.  I wonder whether it has something to do with the deletion of the
text afterwards.  Try removing the `delete-region' after
`gnus-html-put-image' in `gnus-html-wash-tags' and see whether that
works... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Mon, 30 Aug 2010 23:29:01 +0200, Lars wrote:

> Hm.  I wonder whether it has something to do with the deletion of the
> text afterwards.  Try removing the `delete-region' after
> `gnus-html-put-image' in `gnus-html-wash-tags' and see whether that
> works... 

Yeah, now the images appear! (But also the unwanted alt-texts).


  Signing off for tonight,

     Adam

-- 
 "I hate dancing. So, this, to me, is a living                Adam Sjøgren
  embodyment of hell."                                   asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

I've now changed the way Gnus determines what images to download.  I've
introduced the new `gnus-blocked-images' variable, that works as
expected.  It's now much easier to block all the tracking images/ad
stuff. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've now changed the way Gnus determines what images to download.  I've
> introduced the new `gnus-blocked-images' variable, that works as
> expected.  It's now much easier to block all the tracking images/ad
> stuff. 

I use the following topic parameters for the Gwene groups now, and it
makes things much more pleasant:

((gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com")
 (subscribe . "gwene"))

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> I've now changed the way Gnus determines what images to download.
> I've introduced the new `gnus-blocked-images' variable, that works as
> expected.  It's now much easier to block all the tracking images/ad
> stuff.

I think I would prefer it if all images were blocked by default (at
least when reading HTML from inside gnus), and that one could open for
those that are harmful.

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I think I would prefer it if all images were blocked by default (at
> least when reading HTML from inside gnus), and that one could open for
> those that are harmful.

The default regexp is ".", which means that all external images are
blocked.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

I've tried the code from Emacs21 now, and it seems to work OK, strangely
enough... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Mon, 30 Aug 2010 18:51:28 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> asjo@koldfront.dk (Adam Sjøgren) writes:
>> Can't wait!

LMI> Give it a whirl...

Is there a gnus-html-for-idiots guide?

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Is there a gnus-html-for-idiots guide?

# apt-get install w3m

The rest should happen automatically.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Tue, 31 Aug 2010 20:42:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Is there a gnus-html-for-idiots guide?

LMI> # apt-get install w3m

LMI> The rest should happen automatically.

I have:

(setq
 url-be-asynchronous t
 url-honor-refresh-requests nil
 mm-inline-text-html-renderer 'mm-inline-text-html-render-with-w3m
 mm-inline-text-html-with-images t
 w3m-display-inline-image t
 gnus-article-wash-function 'gnus-article-wash-html-with-w3m)

Is all of that obsolete?  Or is it still respected?

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> (setq
>  url-be-asynchronous t
>  url-honor-refresh-requests nil
>  mm-inline-text-html-renderer 'mm-inline-text-html-render-with-w3m
>  mm-inline-text-html-with-images t
>  w3m-display-inline-image t
>  gnus-article-wash-function 'gnus-article-wash-html-with-w3m)
>
> Is all of that obsolete?  Or is it still respected?

It's still respected, so you should probably just delete all those
settings to get the new behaviour.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Tue, 31 Aug 2010 21:01:47 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> (setq
>> url-be-asynchronous t
>> url-honor-refresh-requests nil
>> mm-inline-text-html-renderer 'mm-inline-text-html-render-with-w3m
>> mm-inline-text-html-with-images t
>> w3m-display-inline-image t
>> gnus-article-wash-function 'gnus-article-wash-html-with-w3m)
>> 
>> Is all of that obsolete?  Or is it still respected?

LMI> It's still respected, so you should probably just delete all those
LMI> settings to get the new behaviour.  

I think there should be an explicit choice in addition to the default,
so I can be sure what my renderer is.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think there should be an explicit choice in addition to the default,
> so I can be sure what my renderer is.

Oh, the choice is explicit:

(setq mm-text-html-renderer 'gnus-article-html)

Which is the default now if you have w3m installed.

All the other dozens of variables you listed may override that, I think,
for some things, but as a Gnus user without any previous customisations,
that should be the default value now if you have w3m installed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Tue, 31 Aug 2010 21:17:54 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think there should be an explicit choice in addition to the default,
>> so I can be sure what my renderer is.

LMI> Oh, the choice is explicit:

LMI> (setq mm-text-html-renderer 'gnus-article-html)

LMI> Which is the default now if you have w3m installed.

LMI> All the other dozens of variables you listed may override that, I think,
LMI> for some things, but as a Gnus user without any previous customisations,
LMI> that should be the default value now if you have w3m installed.

I now have just the following:

(setq
 url-be-asynchronous t
 url-honor-refresh-requests nil
 mm-inline-text-html-with-images t
 w3m-display-inline-image t)

and the gnus-article-html renderer is invoked as you described.  I see
no images, though.  gnus-blocked-images is set to block some domains as
you suggested, e.g. pheedo, but no images at all are fetched or
displayed.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> and the gnus-article-html renderer is invoked as you described.  I see
> no images, though.  gnus-blocked-images is set to block some domains as
> you suggested, e.g. pheedo, but no images at all are fetched or
> displayed.

Hm.  Are you sure that the gnus-article-html is actually invoked?  Try
edebugging the function to make sure...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 16:27:12 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> and the gnus-article-html renderer is invoked as you described.  I see
>> no images, though.  gnus-blocked-images is set to block some domains as
>> you suggested, e.g. pheedo, but no images at all are fetched or
>> displayed.

LMI> Hm.  Are you sure that the gnus-article-html is actually invoked?  Try
LMI> edebugging the function to make sure...

Yes.  Here are the top two levels of the backtrace:

Debugger entered: nil
  gnus-article-html((#<buffer  *mm*> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))
  mm-inline-text-html((#<buffer  *mm*> ("text/html" (charset . "utf8")) 8bit nil nil nil nil nil))

I see images in the w3m buffer when I follow a link in the article.  The
message (from gwene) has just one text/html part and I checked that the
images are valid and should not be blocked.

I added logging into gnus-html.el to help with this issue and generally
to track image fetching activiy (including blocked images, although I
think there's code duplication between gnus-html-wash-tags and
gnus-html-prefetch-images for checking blocked images and I only log the
latter).

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I added logging into gnus-html.el to help with this issue and generally
> to track image fetching activiy (including blocked images, although I
> think there's code duplication between gnus-html-wash-tags and
> gnus-html-prefetch-images for checking blocked images and I only log the
> latter).

They're run from different contexts, so they both have to check for
blocked images.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 17:32:20 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I added logging into gnus-html.el to help with this issue and generally
>> to track image fetching activiy (including blocked images, although I
>> think there's code duplication between gnus-html-wash-tags and
>> gnus-html-prefetch-images for checking blocked images and I only log the
>> latter).

LMI> They're run from different contexts, so they both have to check for
LMI> blocked images.

I understand, but they both do:

	    (or (null blocked-images)
                (not (string-match blocked-images url)))

which could live in a gnus-html-image-url-blocked-p function, where the
log message could also be inserted.  Sorry for the crossed commits, btw.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I understand, but they both do:
>
> 	    (or (null blocked-images)
>                 (not (string-match blocked-images url)))
>
> which could live in a gnus-html-image-url-blocked-p function, where the
> log message could also be inserted.

Sure.

> Sorry for the crossed commits, btw.

Isn't that what we have an SCM for?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 17:56:42 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I understand, but they both do:
>> 
>> (or (null blocked-images)
>> (not (string-match blocked-images url)))
>> 
>> which could live in a gnus-html-image-url-blocked-p function, where the
>> log message could also be inserted.

LMI> Sure.

OK, done.  It produced the lovely (unless A (unless B ...)) logic
pattern but otherwise seems OK.

So now I see that gnus-blocked-images is causing the problem because it
was set to ".".  But I did (setq gnus-blocked-images nil) globally.  I'm
not sure what's going on, looks like buffer-local variables but I can't
debug it right now.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So now I see that gnus-blocked-images is causing the problem because it
> was set to ".".  But I did (setq gnus-blocked-images nil) globally.  I'm
> not sure what's going on, looks like buffer-local variables but I can't
> debug it right now.

Try setting it as a topic/group parameter instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 18:43:01 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> So now I see that gnus-blocked-images is causing the problem because it
>> was set to ".".  But I did (setq gnus-blocked-images nil) globally.  I'm
>> not sure what's going on, looks like buffer-local variables but I can't
>> debug it right now.

LMI> Try setting it as a topic/group parameter instead.

I did.  To be 100% certain I did not only the topic but also the group
specifically:

((gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com"))

and still gnus-blocked-images is "." when it's logged by
gnus-html-image-url-blocked-p.

I checked in the summary buffer:

---
gnus-blocked-images is a variable defined in `gnus-html.el'.
Its value is 
"pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com"
Local in buffer *Summary nntp+news.gwene.org:gwene.awkward.family.photos*; global value is "."
---

So I think gnus-html-image-url-blocked-p needs to get the buffer-local
value, perhaps with a let capture.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> So I think gnus-html-image-url-blocked-p needs to get the buffer-local
> value, perhaps with a let capture.

It does now.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

And I have to say that reading picture-filled blogs is much more
pleasant now (if you have an imagemagick-enabled Emacs 24), since all
huge pictures get rescaled down to something sensible.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 19:10:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> So I think gnus-html-image-url-blocked-p needs to get the buffer-local
>> value, perhaps with a let capture.

LMI> It does now.  :-)

Inspect gnus-blocked-images in gnus-html-wash-tags before it gets passed
to gnus-html-image-url-blocked-p.  It's the global value (".") for me
instead of the right one.  Do you need to use buffer-local-value?

Also, in gnus-html-prefetch-images you do

      (with-current-buffer summary
	(setq blocked-images gnus-blocked-images))

but why?  I don't see a mention of blocked-images anywhere else in the source.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Inspect gnus-blocked-images in gnus-html-wash-tags before it gets passed
> to gnus-html-image-url-blocked-p.  It's the global value (".") for me
> instead of the right one.  Do you need to use buffer-local-value?

It should be copied over from the summary buffer to the article buffer,
and that function runs in the article buffer.

> Also, in gnus-html-prefetch-images you do
>
>       (with-current-buffer summary
> 	(setq blocked-images gnus-blocked-images))
>
> but why?  I don't see a mention of blocked-images anywhere else in the source.

Hm?  blocked-images is a lexical variable that's checked later in a
buffer where gnus-blocked-images isn't local...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 19:27:27 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Inspect gnus-blocked-images in gnus-html-wash-tags before it gets passed
>> to gnus-html-image-url-blocked-p.  It's the global value (".") for me
>> instead of the right one.  Do you need to use buffer-local-value?

LMI> It should be copied over from the summary buffer to the article buffer,
LMI> and that function runs in the article buffer.

I don't know then.  I'm still getting the blockage:

Image URL http://....jpg is blocked by gnus-blocked-images regex .

And I can verify the parameters are not ".":

(gnus-topic-parameters "nntprss")
-> ((gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com") (subscribe . "gwene"))

so I must be doing something wrong if it works for you.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> And I can verify the parameters are not ".":
>
> (gnus-topic-parameters "nntprss")
> -> ((gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com") (subscribe . "gwene"))
>
> so I must be doing something wrong if it works for you.

Add.  You're not setting that variable from any other hooks or... stuff? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 19:51:59 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> And I can verify the parameters are not ".":
>> 
>> (gnus-topic-parameters "nntprss")
-> ((gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com") (subscribe . "gwene"))
>> 
>> so I must be doing something wrong if it works for you.

LMI> Add.  You're not setting that variable from any other hooks or... stuff? 

No.  There are two places where it emerges: gnus-html-prefetch-images
and gnus-html-wash-tags.  I verified that in gnus-html-wash-tags both
gnus-blocked-images and 

(buffer-local-value 'gnus-blocked-images (current-buffer)) 

are "." so there's no way the topic parameter is getting used.

The parameter is installed buffer-local to the summary buffer, right?
In the article buffer it's the global value but it's the topic parameter
value in the summary buffer.  So maybe gnus-html-wash-tags needs to
switch to the summary buffer.  

I would also make gnus-blocked-images nil by default.  "." is a pain.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The parameter is installed buffer-local to the summary buffer, right?
> In the article buffer it's the global value but it's the topic parameter
> value in the summary buffer.  So maybe gnus-html-wash-tags needs to
> switch to the summary buffer.  

All summary-local variables are also copied over to the article buffer.
Or perhaps they don't if `gnus-single-article-buffer' is t?  What your
setting there?

> I would also make gnus-blocked-images nil by default.  "." is a pain.

No, that would mean that spammers could track you when you read their
email.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 20:38:03 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The parameter is installed buffer-local to the summary buffer, right?
>> In the article buffer it's the global value but it's the topic parameter
>> value in the summary buffer.  So maybe gnus-html-wash-tags needs to
>> switch to the summary buffer.  

LMI> All summary-local variables are also copied over to the article buffer.
LMI> Or perhaps they don't if `gnus-single-article-buffer' is t?  What your
LMI> setting there?

I haven't customized it.  It defaults to t and can only be nil if, when
gnus-summary-setup-buffer is called, (gnus-group-quit-config group) is
true.  I have no idea what that function checks.

In any case your latest changes fixes the problem for me.

>> I would also make gnus-blocked-images nil by default.  "." is a pain.

LMI> No, that would mean that spammers could track you when you read their
LMI> email.  

Katsumi Yamaoka and I had a similar discussion about safe URLs.  I think
fighting spammers by filtering all images is a losing battle and
everyone will just set that to nil, but maybe the filter can at least
take the image size into account.  1x1 images are suspicious but a
800x600 image is probably safe.  Basically the pixel count should be
over 8 and each dimension should be over 2.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Katsumi Yamaoka and I had a similar discussion about safe URLs.  I think
> fighting spammers by filtering all images is a losing battle and
> everyone will just set that to nil, but maybe the filter can at least
> take the image size into account.

I don't think spammers are the main problem -- it's a question of loss
of privacy.  There are people selling tools that lets you know whether
somebody has read the email you sent them just by exploiting the
sloppiness of mail readers in this area.  I don't think that's a good
idea to have enable by default.

> 1x1 images are suspicious but a 800x600 image is probably safe.
> Basically the pixel count should be over 8 and each dimension should
> be over 2.

You don't know the size of the image before you download it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 21:57:26 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Katsumi Yamaoka and I had a similar discussion about safe URLs.  I think
>> fighting spammers by filtering all images is a losing battle and
>> everyone will just set that to nil, but maybe the filter can at least
>> take the image size into account.

LMI> I don't think spammers are the main problem -- it's a question of loss
LMI> of privacy.  There are people selling tools that lets you know whether
LMI> somebody has read the email you sent them just by exploiting the
LMI> sloppiness of mail readers in this area.  I don't think that's a good
LMI> idea to have enable by default.

OK, s/spammers/evildoers and other miscreants/.  I believe 99% of the
users will set this to nil or give up.  We should at least try to give
this some nuance; a regex is not the best solution.

So, looking at http://w2.eff.org/Privacy/Marketing/web_bug.html and
http://en.wikipedia.org/wiki/Web_bug...

Gnus doesn't let w3m use cookies so session tracking won't work.  We're
only worried about images.  We should maybe look at w3m-filter-rules and
structure gnus-blocked-images after it.

Also image URLs that have GET parameters could be filtered out
explicitly as a separate rule.  That's very likely to be a web bug.

>> 1x1 images are suspicious but a 800x600 image is probably safe.
>> Basically the pixel count should be over 8 and each dimension should
>> be over 2.

LMI> You don't know the size of the image before you download it.

It's pretty common to set the width and height explicitly to 1 for web
bug images in the HTML.  That's what I was thinking of; sorry for being
unclear.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, s/spammers/evildoers and other miscreants/.  I believe 99% of the
> users will set this to nil or give up.  We should at least try to give
> this some nuance; a regex is not the best solution.

Well, we could have a more fine-grained solution.  Like "I want to have
privacy", "do a best effort for privacy, but let me loot at purdy
pictures", and "whatever".

> Gnus doesn't let w3m use cookies so session tracking won't work.  We're
> only worried about images.  We should maybe look at w3m-filter-rules and
> structure gnus-blocked-images after it.

Well.  I'm not sure this is very helpful, really:

(defcustom w3m-filter-rules
  `(("\\`http://www\\.geocities\\.co\\.jp/"
     w3m-filter-delete-regions
     "<DIV ALIGN=CENTER>\n<!--*/GeoGuide/*-->" "<!--*/GeoGuide/*-->\n</DIV>")
    ("\\`http://[a-z]+\\.hp\\.infoseek\\.co\\.jp/"
     w3m-filter-delete-regions
     "<!-- start AD -->" "<!-- end AD -->")
    ("\\`http://linux\\.ascii24\\.com/linux/"
     w3m-filter-delete-regions
     "<!-- DAC CHANNEL AD START -->" "<!-- DAC CHANNEL AD END -->")
    ("\\`http://\\(www\\|images\\|news\\|maps\\|groups\\)\\.google\\."
     w3m-filter-google)
    ("\\`https?://\\(?:www\\.\\)?amazon\\.\
\\(?:com\\|co\\.\\(?:jp\\|uk\\)\\|fr\\|de\\)/"
     w3m-filter-amazon)
    ("\\`https?://mixi\\.jp" w3m-filter-mixi)
    ("\\`http://eow\\.alc\\.co\\.jp/[^/]+/UTF-8" w3m-filter-alc)
    ("\\`http://www\\.asahi\\.com/" w3m-filter-asahi-shimbun)
    ("\\`http://imepita\\.jp/[0-9]+/[0-9]+" w3m-filter-imepita)
    ("\\`http://allatanys\\.jp/" w3m-filter-allatanys)
    ("\\`http://.*\\.wikipedia\\.org/" w3m-filter-wikipedia)
    ("" w3m-filter-iframe))

> Also image URLs that have GET parameters could be filtered out
> explicitly as a separate rule.  That's very likely to be a web bug.

There are plenty of images out there that have get parameters.

>>> 1x1 images are suspicious but a 800x600 image is probably safe.
>>> Basically the pixel count should be over 8 and each dimension should
>>> be over 2.
>
> LMI> You don't know the size of the image before you download it.
>
> It's pretty common to set the width and height explicitly to 1 for web
> bug images in the HTML.  That's what I was thinking of; sorry for being
> unclear.

Ah, right.  Yes, that makes sense.  Please make it so.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ah, right.  Yes, that makes sense.  Please make it so.  :-)

But I had a peek at that myself, and the output from w3m -halfdump
doesn't include the image sizes.  How annoying.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But I had a peek at that myself, and the output from w3m -halfdump
> doesn't include the image sizes.  How annoying.

I found a switch to w3m that made it output the sizes, so I've
implemented this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 22:26:35 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> OK, s/spammers/evildoers and other miscreants/.  I believe 99% of the
>> users will set this to nil or give up.  We should at least try to give
>> this some nuance; a regex is not the best solution.

LMI> Well, we could have a more fine-grained solution.  Like "I want to have
LMI> privacy", "do a best effort for privacy, but let me loot at purdy
LMI> pictures", and "whatever".

That would be swell (with "custom" as the fourth option).  And it should
have the granularity to specify some combination of symbolic
parameterized rules in an alist, e.g. 
((no-get-params) (min-dimensions 2) (min-area 8)) in addition
to multiple URL regexes.  WDYT?

Finally, there should be a way to get an image in the article buffer
even if it was blocked by going to it and hitting `i' or whatever.

>> Also image URLs that have GET parameters could be filtered out
>> explicitly as a separate rule.  That's very likely to be a web bug.

LMI> There are plenty of images out there that have get parameters.

Yes.  As a rule it would make sense but I agree it's not for everyone.

>>>> 1x1 images are suspicious but a 800x600 image is probably safe.
>>>> Basically the pixel count should be over 8 and each dimension should
>>>> be over 2.
>> 
LMI> You don't know the size of the image before you download it.
>> 
>> It's pretty common to set the width and height explicitly to 1 for web
>> bug images in the HTML.  That's what I was thinking of; sorry for being
>> unclear.

LMI> Ah, right.  Yes, that makes sense.  Please make it so.  :-)

Let's figure out the above rule structure and then I'll write it.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> That would be swell (with "custom" as the fourth option).  And it should
> have the granularity to specify some combination of symbolic
> parameterized rules in an alist, e.g. 
> ((no-get-params) (min-dimensions 2) (min-area 8)) in addition
> to multiple URL regexes.  WDYT?

Yes, that sounds good.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Is there a gnus-html-for-idiots guide?

> # apt-get install w3m

> The rest should happen automatically.

So the new gnus-html still needs w3m?  I thought the idea was to have a
pure elisp HTML renderer?

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> So the new gnus-html still needs w3m?  I thought the idea was to have a
> pure elisp HTML renderer?

Oh, no.  That's be way too slow.

The idea was to be able to view HTML messages in Emacs without
installing third-party Emacs Lisp packages, basically.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Ah, right.  Yes, that makes sense.  Please make it so.  :-)

> But I had a peek at that myself, and the output from w3m -halfdump
> doesn't include the image sizes.  How annoying.

Even if it did, the size might be a lie, in this case.

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> So the new gnus-html still needs w3m?  I thought the idea was to have a
>> pure elisp HTML renderer?

> Oh, no.  That's be way too slow.

> The idea was to be able to view HTML messages in Emacs without
> installing third-party Emacs Lisp packages, basically.

The existing w3m elisp package was not distributed with emacs or gnus,
is that it?

Have you borrowed any code from that?  Or is this new one written from
scratch? 

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> The existing w3m elisp package was not distributed with emacs or gnus,
> is that it?

Yes.

> Have you borrowed any code from that?  Or is this new one written from
> scratch? 

From scratch. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Even if it did, the size might be a lie, in this case.

Yes.  If I were running a mail bugging service, I'd include the images
in an invisible <div style="visibility: none;"> (or whatever the style
is) and say width=20, but serve out a 1-pixel image, anyway.

But then again, I'm evil.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Frank Schmitt]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 01 Sep 2010 21:57:26 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 
>
> LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> Katsumi Yamaoka and I had a similar discussion about safe URLs.  I think
>>> fighting spammers by filtering all images is a losing battle and
>>> everyone will just set that to nil, but maybe the filter can at least
>>> take the image size into account.
>
> LMI> I don't think spammers are the main problem -- it's a question of loss
> LMI> of privacy.  There are people selling tools that lets you know whether
> LMI> somebody has read the email you sent them just by exploiting the
> LMI> sloppiness of mail readers in this area.  I don't think that's a good
> LMI> idea to have enable by default.
>
> OK, s/spammers/evildoers and other miscreants/.  I believe 99% of the
> users will set this to nil or give up.  We should at least try to give
> this some nuance; a regex is not the best solution.

I think the most common solution in other MUAs is to have a button which
allows to load the images in the current mail. We could have

[load images], [ ] load always for this group, [ ] never load for this group

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> Even if it did, the size might be a lie, in this case.

> Yes.  If I were running a mail bugging service, I'd include the images
> in an invisible <div style="visibility: none;"> (or whatever the style
> is) and say width=20, but serve out a 1-pixel image, anyway.

> But then again, I'm evil.

BTW, what's the deal about 1-pixel images?  The request size?  The
visibility when displayed?

Re: Built-in HTML renderer in Emacs?

[Daniel Pittman]

Steinar Bang <sb@dod.no> writes:
>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>
>> Steinar Bang <sb@dod.no> writes:
>>> Even if it did, the size might be a lie, in this case.
>
>> Yes.  If I were running a mail bugging service, I'd include the images
>> in an invisible <div style="visibility: none;"> (or whatever the style
>> is) and say width=20, but serve out a 1-pixel image, anyway.
>
>> But then again, I'm evil.
>
> BTW, what's the deal about 1-pixel images?  The request size?  The
> visibility when displayed?

If I email you a message with a one pixel transparent image and the URL...

   http://rimspace.net/steinar-bang-read-this.gif

...I can tell if you did, in fact, read my mail by checking the Apache logs.
Substitute in less obvious naming and a database and you can see where this
might leak information you don't especially want like "did you open the
email".
        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> BTW, what's the deal about 1-pixel images?  The request size?  The
> visibility when displayed?

Yeah, the idea is that people won't notice that they've been bugged.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Steinar Bang]

>>>>> Daniel Pittman <daniel@rimspace.net>:

> If I email you a message with a one pixel transparent image and the URL...

>    http://rimspace.net/steinar-bang-read-this.gif

> ...I can tell if you did, in fact, read my mail by checking the Apache
> logs.  Substitute in less obvious naming and a database and you can
> see where this might leak information you don't especially want like
> "did you open the email".

I understand that bit.

What I wasn't sure of was why they went for 1x1 pixel images?  The
network overhead of an HTTP request is so that whether the payload is
near to zero bytes, or a handful of kilobytes, the extra load from
fetching the image shouldn't be noticable in the HTTP traffic resulting
from loading a typical HTML page, and fetching everything it refers to.

And if looking for 1x1 pixel images made them easy to recognize I would
have thought that would be something to avoid...?

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 01 Sep 2010 22:55:47 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That would be swell (with "custom" as the fourth option).  And it should
>> have the granularity to specify some combination of symbolic
>> parameterized rules in an alist, e.g. 
>> ((no-get-params) (min-dimensions 2) (min-area 8)) in addition
>> to multiple URL regexes.  WDYT?

LMI> Yes, that sounds good.

I'll do that when I get a chance.  btw, gnus-html.el really needs a
function I can bind to hide/show all the images (in emacs-w3m that's
available so I'm used to it).

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> btw, gnus-html.el really needs a function I can bind to hide/show all
> the images (in emacs-w3m that's available so I'm used to it).

I've added the right magic to have the images go away when you hit
`W D D'.  For displaying the images -- perhaps just re-selecting the
message with `gnus-blocked-images' bound to nil will suffice?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've added the right magic to have the images go away when you hit
> `W D D'.  For displaying the images -- perhaps just re-selecting the
> message with `gnus-blocked-images' bound to nil will suffice?

Nah, that'd suck.

`W D W' now just fetches and inserts all the images (asynchronously)
without rerendering the article.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Fri, 03 Sep 2010 20:47:30 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> I've added the right magic to have the images go away when you hit
>> `W D D'.  For displaying the images -- perhaps just re-selecting the
>> message with `gnus-blocked-images' bound to nil will suffice?

LMI> Nah, that'd suck.

LMI> `W D W' now just fetches and inserts all the images (asynchronously)
LMI> without rerendering the article.

If the image is too big it gets scaled down, which is Really Awesome.
But there's no way to view the image URL (except in *Messages*) to open
it if the rescaling makes it illegible.  Did I miss this command?

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> But there's no way to view the image URL (except in *Messages*) to open
> it if the rescaling makes it illegible.  Did I miss this command?

Nope.  Haven't made that yet.  I think the best way is to just make all
images into links, so that hitting RET on them issues a `browse-url'
call. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Julien Danjou]

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

On Tue, Sep 07 2010, Lars Magne Ingebrigtsen wrote:

> Nope.  Haven't made that yet.  I think the best way is to just make all
> images into links, so that hitting RET on them issues a `browse-url'
> call. 

But the image can already point to another link, can't it?
That would would not work correctly in that case.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 08 Sep 2010 10:34:23 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Tue, Sep 07 2010, Lars Magne Ingebrigtsen wrote:
>> Nope.  Haven't made that yet.  I think the best way is to just make all
>> images into links, so that hitting RET on them issues a `browse-url'
>> call. 

JD> But the image can already point to another link, can't it?
JD> That would would not work correctly in that case.

`e' could work (it opens the external handler for MIME, so it kind of
makes sense).  `v' has mnemonic value.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> JD> But the image can already point to another link, can't it?
> JD> That would would not work correctly in that case.
>
> `e' could work (it opens the external handler for MIME, so it kind of
> makes sense).  `v' has mnemonic value.

Perhaps `i' for "open image", and `a' for "show alt text", and `RET' for
"follow link (if any)"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 08 Sep 2010 16:13:59 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
JD> But the image can already point to another link, can't it?
JD> That would would not work correctly in that case.
>> 
>> `e' could work (it opens the external handler for MIME, so it kind of
>> makes sense).  `v' has mnemonic value.

LMI> Perhaps `i' for "open image", and `a' for "show alt text", and `RET' for
LMI> "follow link (if any)"?

Works for me, as long as `?' lists them.

Speaking of following links, the face for links should probably be
emphasized a little more, but I don't know how to do it right.  Colors
won't work in all environments; underlining monospaced text looks awful;
boxing the content makes the text look uneven.

Maybe an arrow symbol before the link [-> LINK] (with a Unicode
character used instead when possible) would work.

Ted

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Speaking of following links, the face for links should probably be
> emphasized a little more, but I don't know how to do it right.  Colors
> won't work in all environments; underlining monospaced text looks awful;
> boxing the content makes the text look uneven.

How about changing the background colour?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps `i' for "open image", and `a' for "show alt text", and `RET' for
> "follow link (if any)"?

I thought one could stack keymaps for different things on top of each
other, so I could have one overlay map for <a> and then a different for
<img>, and if there was an <a> around an <img>, then the local maps
would be "blended".  But that's not happening, unfortunately.  Darn.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Ted Zlatanov]

On Wed, 08 Sep 2010 17:59:18 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Speaking of following links, the face for links should probably be
>> emphasized a little more, but I don't know how to do it right.  Colors
>> won't work in all environments; underlining monospaced text looks awful;
>> boxing the content makes the text look uneven.

LMI> How about changing the background colour?

That would be OK.  I don't know what a good default would be, though.

Ted

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Sun, 29 Aug 2010 20:51:35 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> When I hover over a link in an article rendered by gnus-article-html,
>> the mini buffer shows "Follow the link" - it would be helpful if I could
>> see what the link actually is, I think?

> Yup.  Fix in No Gnus v0.11 (i. e., CVS).

Has anyone gotten this to work in XEmacs (21.5)?

I don't see the shortcut with C-h b at all...

u runs `gnus-summary-tick-article-forward' for me :-/


  Best regards,

     Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Wed, 08 Sep 2010 22:22:21 +0200, Adam wrote:

> On Sun, 29 Aug 2010 20:51:35 +0200, Lars wrote:
>> asjo@koldfront.dk (Adam Sjøgren) writes:

>>> When I hover over a link in an article rendered by gnus-article-html,
>>> the mini buffer shows "Follow the link" - it would be helpful if I could
>>> see what the link actually is, I think?

I am an idiot - *slaps forehead*.

The thing I can't get to work is the "Copy link location" functionality.

The link is displayed nicely in the mini-buffer when I hover with the
mouse, but I can't for the life of me make Gnus copy the link to the
clipboard (for pasting in, say, Firefox).


  Best regards,

     Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Built-in HTML renderer in Emacs?

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> The link is displayed nicely in the mini-buffer when I hover with the
> mouse, but I can't for the life of me make Gnus copy the link to the
> clipboard (for pasting in, say, Firefox).

I guess the local-map overlay thing isn't working in XEmacs, either?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Built-in HTML renderer in Emacs?

[Adam Sjøgren]

On Wed, 08 Sep 2010 23:01:01 +0200, Lars wrote:

> I guess the local-map overlay thing isn't working in XEmacs, either?

It looks like XEmacs wants 'keymap instead of 'local-map, but I can't
make that work either.

,----[ C-h f gnus-overlay-put RET ]
| `gnus-overlay-put' is an alias for `set-extent-property', a built-in function
|   -- loaded from "gnus-ems"
| (gnus-overlay-put EXTENT PROPERTY VALUE)
| 
| Documentation:
| Change a property of an extent.
| PROPERTY may be any symbol; the value stored may be accessed with
|  the `extent-property' function.
| 
| The following symbols have predefined meanings:
| 
[...]
|  keymap             This keymap is consulted for mouse clicks on this
|                     extent, or keypresses made while point is within the
|                     extent.
[...]


  Best regards,

    Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk