eww as a package?

eww as a package?

[Nic Ferrier]

I wish that something like eww was delivered as a separate package so
that those of us not on daily trunk could pull it and start playing with
it.

Any chance of that?


Nic

eww, shr, and mm-text-html-renderer

[Bill Wohler]

Nic Ferrier <nferrier@ferrier.me.uk> writes:

> I wish that something like eww was delivered as a separate package so
> that those of us not on daily trunk could pull it and start playing with
> it.
>
> Any chance of that?

On a related note, mm-text-html-renderer doesn't have eww. Why not?

What is the difference between shr and eww?

In an MH-Show buffer, which uses the value of mm-text-html-renderer to
render HTML, why are all of the images all down at the bottom of the
message when using shr? It would be preferable if they were inline.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: eww as a package?

[Rüdiger Sonderfeld]

On Sunday 27 July 2014 11:34:31 Nic Ferrier wrote:
> I wish that something like eww was delivered as a separate package so
> that those of us not on daily trunk could pull it and start playing with
> it.
> 
> Any chance of that?

The problem is that `eww' or rather `shr' relies on the C function `add-face-
text-property' which is only available in 24.4/trunk.  It is therefore not 
possible to package it for older versions.  Maybe it makes sense to provide an 
`eww' package once 24.4 is released.

Regards,
Rüdiger

Re: eww, shr, and mm-text-html-renderer

[Rüdiger Sonderfeld]

On Sunday 27 July 2014 16:34:33 Bill Wohler wrote:
> On a related note, mm-text-html-renderer doesn't have eww. Why not?
> 
> What is the difference between shr and eww?

`shr' is the HTML renderer used by `eww'.  Kinda like what Gecko is for 
Firefox or Webkit/Blink for some other browsers.  Maybe the docstring of `mm-
text-html-renderer' should be changed from "use the built-in Gnus HTML 
renderer" to "use eww's HTML renderer" or "use GNU Emacs' HTML renderer"?

Regards,
Rüdiger

Re: eww, shr, and mm-text-html-renderer

[Bill Wohler]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> wrote:

> On Sunday 27 July 2014 16:34:33 Bill Wohler wrote:
> > On a related note, mm-text-html-renderer doesn't have eww. Why not?
> > 
> > What is the difference between shr and eww?
> 
> `shr' is the HTML renderer used by `eww'.  Kinda like what Gecko is for 
> Firefox or Webkit/Blink for some other browsers.  Maybe the docstring of `mm-
> text-html-renderer' should be changed from "use the built-in Gnus HTML 
> renderer" to "use eww's HTML renderer" or "use GNU Emacs' HTML renderer"?

I like the idea of putting eww in the docstring, since I've heard of
eww, but not shr.

Vielen dank for your reply! The shr renderer does seem to give
slightly better results than w3m, but I was hoping for more inline
images.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: eww as a package?

[Wolfgang Jenkner]

On Mon, Jul 28 2014, Rüdiger Sonderfeld wrote:

> The problem is that `eww' or rather `shr' relies on the C function `add-face-
> text-property' which is only available in 24.4/trunk.  It is therefore not 
> possible to package it for older versions.

I think Lars wrote this only for performance reasons as primitive (see
the thread starting with [1]).

Otherwise, the visual effect is the same as with

(defun add-face-text-property (start end face &optional append object)
  (funcall (if append
	       #'font-lock-append-text-property
	     #'font-lock-prepend-text-property)
	   start end 'face face object))

The functions called here seem to exist since

1995-10-26  Simon Marshall  <simon@duality.gnu.ai.mit.edu>

	* font-lock.el: General reorganization.
        [...]
	(font-lock-fillin-text-property, font-lock-prepend-text-property,
	font-lock-append-text-property): New text property functions.

[1] http://permalink.gmane.org/gmane.emacs.devel/153114

Wolfgang

Re: eww as a package?

[Rüdiger Sonderfeld]

Hello,

On Tuesday 29 July 2014 13:48:49 Wolfgang Jenkner wrote:
> I think Lars wrote this only for performance reasons as primitive (see
> the thread starting with [1]).
> 
> Otherwise, the visual effect is the same as with
>
> [...]

Thanks for the explanation.  I think it's then just a matter of finding 
someone willing to maintain it as an external package.

Regards,
Rüdiger

Re: eww as a package?

[Nic Ferrier]

> Thanks for the explanation.  I think it's then just a matter of finding 
> someone willing to maintain it as an external package.

I might have a crack.


Nic

Re: eww as a package?

[Ted Zlatanov]

On Tue, 29 Jul 2014 16:30:25 +0100 Nic Ferrier <nferrier@ferrier.me.uk> wrote: 

>> Thanks for the explanation.  I think it's then just a matter of finding 
>> someone willing to maintain it as an external package.

NF> I might have a crack.

Shouldn't Lars, the author, have a say?

Ted

Re: eww as a package?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> Thanks for the explanation.  I think it's then just a matter of finding 
>>> someone willing to maintain it as an external package.
>
> NF> I might have a crack.
>
> Shouldn't Lars, the author, have a say?

Well...  I think eww is unlikely to work very well as an ELPA package
since it's written for the Emacs trunk in mind.  I doubt it would even
work on Emacs 24.4 due to using stuff like `when-let'.  Or did that make
it into Emacs 24.4?

Anyway, maintaining a package that's supposed to work over a large range
of Emacs versions is an quite different thing than just targeting one
single build.  If someone wants to try to maintain an eww "port", that's
fine by me, but I'm not going to change the "ooh! shiny!" implementation
style in shr or eww.

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

Re: eww, shr, and mm-text-html-renderer

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> On a related note, mm-text-html-renderer doesn't have eww. Why not?
>
> What is the difference between shr and eww?

shr is an HTML renderer.  eww is a web browser.  It's like the
difference between Gecko and Firefox.

eww doesn't make much sense as a `mm-text-html-renderer' value/

> In an MH-Show buffer, which uses the value of mm-text-html-renderer to
> render HTML, why are all of the images all down at the bottom of the
> message when using shr? It would be preferable if they were inline.

shr does render images inline, except in tables.  Emacs doesn't provide
the necessary control of the buffer to render stuff like


text text text text text text text
--------- text text text text text
| image | text text text text text
--------- text text text text text
text text text text text

which would be necessary for doing images inside tables without the
tables becoming illegible by the presence of the images.

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

Re: eww, shr, and mm-text-html-renderer

[Bill Wohler]

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

> Bill Wohler <wohler@newt.com> writes:
> 
> > On a related note, mm-text-html-renderer doesn't have eww. Why not?
> >
> > What is the difference between shr and eww?
> 
> shr is an HTML renderer.  eww is a web browser.  It's like the
> difference between Gecko and Firefox.

Gotcha.

> eww doesn't make much sense as a `mm-text-html-renderer' value/
> 
> > In an MH-Show buffer, which uses the value of mm-text-html-renderer to
> > render HTML, why are all of the images all down at the bottom of the
> > message when using shr? It would be preferable if they were inline.
> 
> shr does render images inline, except in tables.  Emacs doesn't provide
> the necessary control of the buffer to render stuff like
> 
> text text text text text text text
> --------- text text text text text
> | image | text text text text text
> --------- text text text text text
> text text text text text
> 
> which would be necessary for doing images inside tables without the
> tables becoming illegible by the presence of the images.

OK, then all of these emails must be tables then. Pity.

Thanks for the explanation.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD