unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Where to put the documentation of shr.el?
@ 2010-10-19 23:49 Lars Magne Ingebrigtsen
  2010-10-20  8:39 ` Andreas Schwab
  2010-10-20 15:52 ` Stefan Monnier
  0 siblings, 2 replies; 6+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-19 23:49 UTC (permalink / raw)
  To: emacs-devel

shr.el (Simple HTML Renderer) is a standalone package for rendering
HTML, based on the libxml-parse-html-region parse tree.  It's not
dependent on anything else much, and isn't (in principle) a
Gnus-specific thing, so where should I stick the documentation?  There
isn't a lot to document -- just a handful of commands and one
entry-point, so doing a separate info file seems odd.

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




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Where to put the documentation of shr.el?
  2010-10-19 23:49 Where to put the documentation of shr.el? Lars Magne Ingebrigtsen
@ 2010-10-20  8:39 ` Andreas Schwab
  2010-10-20 11:50   ` Lars Magne Ingebrigtsen
  2010-10-20 15:52 ` Stefan Monnier
  1 sibling, 1 reply; 6+ messages in thread
From: Andreas Schwab @ 2010-10-20  8:39 UTC (permalink / raw)
  To: emacs-devel

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

> There isn't a lot to document -- just a handful of commands and one
> entry-point, so doing a separate info file seems odd.

There are already other small info files, the smallest one having only 6
nodes.

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."



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Where to put the documentation of shr.el?
  2010-10-20  8:39 ` Andreas Schwab
@ 2010-10-20 11:50   ` Lars Magne Ingebrigtsen
  2010-10-20 11:59     ` Andreas Schwab
  2010-10-20 12:34     ` Ted Zlatanov
  0 siblings, 2 replies; 6+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-20 11:50 UTC (permalink / raw)
  To: emacs-devel

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

> There are already other small info files, the smallest one having only 6
> nodes.

This would be one or two nodes.

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




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Where to put the documentation of shr.el?
  2010-10-20 11:50   ` Lars Magne Ingebrigtsen
@ 2010-10-20 11:59     ` Andreas Schwab
  2010-10-20 12:34     ` Ted Zlatanov
  1 sibling, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2010-10-20 11:59 UTC (permalink / raw)
  To: emacs-devel

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

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> There are already other small info files, the smallest one having only 6
>> nodes.
>
> This would be one or two nodes.

So what?  The smallest info file installed on my system has 2 nodes.

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."



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Where to put the documentation of shr.el?
  2010-10-20 11:50   ` Lars Magne Ingebrigtsen
  2010-10-20 11:59     ` Andreas Schwab
@ 2010-10-20 12:34     ` Ted Zlatanov
  1 sibling, 0 replies; 6+ messages in thread
From: Ted Zlatanov @ 2010-10-20 12:34 UTC (permalink / raw)
  To: emacs-devel

On Wed, 20 Oct 2010 13:50:23 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Andreas Schwab <schwab@linux-m68k.org> writes:
>> There are already other small info files, the smallest one having only 6
>> nodes.

LMI> This would be one or two nodes.

I think shr.el will grow much larger.  It has lots of potential
to render HTML and even interact with it IMHO, more than emacs-w3m or W3
ever had, because of the fast libxml parsing.  It needs lots of work to
parse and render HTML, especially broken pages and CSS styles, but IMHO
it's the right path for Emacs work with HTML.

The HTML editing modes, in particular, can benefit from shr.el.  So my
point is, it should definitely have a separate manual.

Ted




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Where to put the documentation of shr.el?
  2010-10-19 23:49 Where to put the documentation of shr.el? Lars Magne Ingebrigtsen
  2010-10-20  8:39 ` Andreas Schwab
@ 2010-10-20 15:52 ` Stefan Monnier
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2010-10-20 15:52 UTC (permalink / raw)
  To: emacs-devel

> shr.el (Simple HTML Renderer) is a standalone package for rendering
> HTML, based on the libxml-parse-html-region parse tree.  It's not
> dependent on anything else much, and isn't (in principle) a
> Gnus-specific thing, so where should I stick the documentation?  There
> isn't a lot to document -- just a handful of commands and one
> entry-point, so doing a separate info file seems odd.

You can start by adding it to the lispref manual and when/if it grows
enough, we can move it into its own manual.  If that's likely to happen,
you may want to immediately put it into its own texi file (but still
part of lispref).


        Stefan



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-10-20 15:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-19 23:49 Where to put the documentation of shr.el? Lars Magne Ingebrigtsen
2010-10-20  8:39 ` Andreas Schwab
2010-10-20 11:50   ` Lars Magne Ingebrigtsen
2010-10-20 11:59     ` Andreas Schwab
2010-10-20 12:34     ` Ted Zlatanov
2010-10-20 15:52 ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).