A new online publishing tool for Texinfo documents.

A new online publishing tool for Texinfo documents.

[Nic Ferrier]

Bob Chasell and I have been discussing a new way of making Texinfo
available online. I am planning to build what we have discussed over
December.

This message has been sent to all interested parties.

The aims of the new system are to make a web based info reader that
would be as good as the console based Info reader and that can be
used by people with slow Internet connections and free software web
browsers (Mozilla, Galeon, etc... as well as Emacs/W3, Lynx, etc...)


Our plan is to do this:

1 alter makeinfo --xml so that it splits the XML by Texinfo
  nodes. The --no-split switch will cause the existing output (or
  maybe add a new switch for the new XML output?)

2 write an XSLT stylesheet that transforms the chunked XML into
  specialized HTML;

  the specialized HTML will include Javascript to emulate Info
  navigation, index lookups, etc...

3 write a CGI script that will lookup a regular expression in the HTML
  files and return either a list of hits or the HTML file containing
  the Nth hit (N being an optional argument supplied to the CGI
  script)

4 write a shell script for linking all this together, and possibly to
  auto-magically install the produced files into an Apache webserver
  (other webservers to be supported as and when I have time).


The shell script(4) will be dependant on a tool called xsltproc which
comes with the GNOME libxsl library and is quite commonly available
on free software machines. xsltproc runs on all free operating
systems and also some non-free ones such as Windoze (but obviously we
don't care much about those  /8-)



I personally don't think this will deprecate the existing HTML output
from makeinfo because that has good support for ALL browsers.



There is one big problem with the current plan:

Emacs/W3 and Lynx do not support Javascript so we will have to find
another way of binding actions to keys within the HTML pages
downloaded to those browsers.

Does anyone have any bright ideas about that?


I am considering the potential of adding Mozilla's Javascript engine
to Emacs and Lynx which would solve this problem. The licence of
Mozilla's Javascript engine is compatible with the GPL. However, I
think this might be rather a big job, certainly bigger than the new
publishing system for online Texinfo.

 
On the subject of Lynx, has anyone tried this version of Links?

  http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/

It apparently has Javascript support and is GPLed.


Nic

Re: A new online publishing tool for Texinfo documents.

[Richard Stallman]

    The aims of the new system are to make a web based info reader that
    would be as good as the console based Info reader and that can be
    used by people with slow Internet connections and free software web
    browsers (Mozilla, Galeon, etc... as well as Emacs/W3, Lynx, etc...)

Is this intended as a replacement for Info format, or as another
format to be used alongside it?  It can't do any harm as an additional
format.

    I am considering the potential of adding Mozilla's Javascript engine
    to Emacs and Lynx which would solve this problem.

Although the license permits adding this to Emacs, I certainly
don't want to do it.

Re: A new online publishing tool for Texinfo documents.

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     The aims of the new system are to make a web based info reader that
>     would be as good as the console based Info reader and that can be
>     used by people with slow Internet connections and free software web
>     browsers (Mozilla, Galeon, etc... as well as Emacs/W3, Lynx, etc...)
> 
> Is this intended as a replacement for Info format, or as another
> format to be used alongside it?  It can't do any harm as an additional
> format.

It's an additional format to solve the specific problem of reading
documentation that you don't happen to have on your local machine.


 
>     I am considering the potential of adding Mozilla's Javascript engine
>     to Emacs and Lynx which would solve this problem.
> 
> Although the license permits adding this to Emacs, I certainly
> don't want to do it.

That's interesting.

If it isn't done then it's likely that the W3 browser will be less
and less useful as more and more javascript looks a likely trend.


Nic

Re: A new online publishing tool for Texinfo documents.

[Kevin Rodgers]

Nic Ferrier wrote:

> It's an additional format to solve the specific problem of reading
> documentation that you don't happen to have on your local machine.

Why can't ange-ftp, tramp, or http-get be used to retrieve remote Info
files for local browsing within Emacs?

-- 
Kevin Rodgers

Re: A new online publishing tool for Texinfo documents.

[Nic Ferrier]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Nic Ferrier wrote:
> 
> > It's an additional format to solve the specific problem of reading
> > documentation that you don't happen to have on your local machine.
> 
> Why can't ange-ftp, tramp, or http-get be used to retrieve remote Info
> files for local browsing within Emacs?

Because it would take a lot of work to alter the info reader to make
that happen.

And users would then be tied to emacs for doing it... The current
proposal offers at least as much flexibility as current Info
publishing systems:

- it will be available to browsers
- it will therefore be available to emacs
- it will also therefore be available on the console (links)


Nic

Re: A new online publishing tool for Texinfo documents.

[Kim F. Storm]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> Kevin Rodgers <ihs_4664@yahoo.com> writes:
> 
> > Nic Ferrier wrote:
> > 
> > > It's an additional format to solve the specific problem of reading
> > > documentation that you don't happen to have on your local machine.
> > 
> > Why can't ange-ftp, tramp, or http-get be used to retrieve remote Info
> > files for local browsing within Emacs?
> 
> Because it would take a lot of work to alter the info reader to make
> that happen.

I doubt that it will take more work than adding XSLT and javascript
support to and otherwise enhancing emacs/w3.

> 
> And users would then be tied to emacs for doing it... 

What's wrong about that?
This is emacs-devel which is supposed to deal with emacs development!

>                                                       The current
> proposal offers at least as much flexibility as current Info
> publishing systems:
> 
> - it will be available to browsers
> - it will therefore be available to emacs
> - it will also therefore be available on the console (links)

so:

- this discussion will continue outside emacs-devel, right?

Thank you.

++kfs

Re: A new online publishing tool for Texinfo documents.

[Robert J. Chassell]

Kevin Rodgers <ihs_4664@yahoo.com> asked

   Why can't ange-ftp, tramp, or http-get be used to retrieve remote
   Info files for local browsing within Emacs?

Because all the processing is done on the local machine, so for some
actions, like navigating via search the whole file must be downloaded.

Info can have a slow connection between the display and the rendering
engine, but presumes a fast connection between the rendering engine
and the source of the Info document.

On the other hand, a Web browser usually has a fast connection between
its display and the rendering engine -- it is very hard to use a mouse
with a slow connection, and commonly used Web browsers use mice -- but
in most cases, a Web browser has a slow connection between the
rendering engine and the source of the HTML: the bandwidth is that of
a telephone dial up line.  People with wider bandwidths make up a
small fraction of the over all Internet population.

The idea for this new tool, among other goals, is to cause the
computer holding the source of the HTML to do some of the work on the
document, such as search through multiple files that make up the
document.  This requires a CGI script.

The Info system could be enhanced to do the same -- at least, I think
so.  Can anyone think why, if some of the work were done by the the
device that provides the Info document, you could not run Info
remotely over a slow connection between its rendering engine and the
source of the Info document?

The point with this proposal is that currently, HTML fails as a
documentation source in its most common situation, which is with a
dial up.  The goal is to make an HTML expression of a Texinfo manual
do as well as Info did back in the 1980s, at least.  (Also, in
commonly used Web browsers, to do index searches, to do `next',
`prev', `up', and `last' movements with default keybindings rather
than depend on mice, and maybe to enhance W3 mode or other Emacs mode,
to be a good browser.)

A different goal is to enhance Info to enable people to read documents
remotely, when `remote' means `low bandwidth connection between
renderer and Info doc source' rather than `low bandwidth connection
between display and renderer'.  I doubt this second goal is as
important as the first.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: Re: A new online publishing tool for Texinfo documents.

[Eli Zaretskii]

> Date: Tue, 25 Nov 2003 19:21:27 -0500 (EST)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> 
> The Info system could be enhanced to do the same -- at least, I think
> so.  Can anyone think why, if some of the work were done by the the
> device that provides the Info document, you could not run Info
> remotely over a slow connection between its rendering engine and the
> source of the Info document?

I don't see any problem in principle, except that the rendering engine
of the Info reader will have to be redesigned to work on output from
some external program that delivers small portions of the displayed
text, instead of loading the entire file into memory and working from
there.

We will also have to design some protocol between the local and
remote parts, or teach Info to use some existing protocol, to pass
requests to the remote.

_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Kevin Rodgers]

Robert J. Chassell wrote:

[completely missing the point]


Nic said, "It's an additional format to solve the specific problem of reading
documentation that you don't happen to have on your local machine."

First of all, I question whether an additional format is required, since that
will demand that Emacs and other Info readers be modified to support the new
format.


Second, everyone seems to agree that Info's search and navigation facilities
are superior to HTML; so shouldn't we take advantage of that?

Third, Info files can be rendered very quickly (especially compared to HTML)
because they have already been pre-processed from the Texinfo source, but
the download time for Info is no worse than HTML because it's not much bigger
than the source.  So use a network transport that's likely to be supported
by a remote server like ftp or http, and be happy you've got access to remote
documentation at all.  Searching an entire document, whether it's in Info
format or HTML and whether it's a monolithic entity or split into pieces
still requires that the data be downloaded.  So download Info files as
needed, and cache them in the /tmp filesystem.

BTW, I just did `g (/@foo:/usr/local/info/gcc)Invoking GCC' and
was able to use the `i' and `s' commands just the way I expected.

What am I missing?  It seems to me different people are trying to solve
different problems within this single discussion thread.

-- 
Kevin Rodgers

Re: A new online publishing tool for Texinfo documents.

[Robert J. Chassell]

   Nic said, "It's an additional format to solve the specific problem
   of reading documentation that you don't happen to have on your
   local machine."

Kevin Rodgers <ihs_4664@yahoo.com> replied

   First of all, I question whether an additional format is required,
   since that will demand that Emacs and other Info readers be
   modified to support the new format.

But the proposed HTML format has nothing to do with Info!  It is a
different HTML format.  Its intent is to enable standards compliant
Web browsers to read documents on the Web (and if Web servers put in
the requisit CGI, to enable Web browsers to navigate via search).

   Second, everyone seems to agree that Info's search and navigation
   facilities are superior to HTML; so shouldn't we take advantage of
   that?

Right, that is why Info should not be changed (unless someone wants
to enhance it by enabling slow connections between an Info doc server
and the Info renderer; right now the connection must be fast).

   Third, Info files can be rendered very quickly (especially compared
   to HTML) because they have already been pre-processed from the
   Texinfo source, but the download time for Info is no worse than
   HTML because it's not much bigger than the source.

I do not understand you.  It takes me 17 minutes to download the Emacs
Lisp Reference Manual.  When I do the manual in Info format, I then
later read it in Info.  I do not wait 17 minutes and then start
reading.

The goal with the HTML/CGI proposal is that if I were to browse the
manual remotely in a Web browser, I would need to download only small
parts -- nodes most likely -- quickly, so I would not have to wait 17
minutes.

   Searching an entire document, whether it's in Info format or HTML
   and whether it's a monolithic entity or split into pieces still
   requires that the data be downloaded.

No, it does not.  That is the point of a CGI script.  You do *not*
have to download a whole document if the serving computer does the
work for you.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: A new online publishing tool for Texinfo documents.

[Kevin Rodgers]

Robert J. Chassell wrote:

>    Nic said, "It's an additional format to solve the specific problem
>    of reading documentation that you don't happen to have on your
>    local machine."
> 
> Kevin Rodgers <ihs_4664@yahoo.com> replied
> 
>    First of all, I question whether an additional format is required,
>    since that will demand that Emacs and other Info readers be
>    modified to support the new format.
> 
> But the proposed HTML format has nothing to do with Info!  It is a
> different HTML format.  Its intent is to enable standards compliant
> Web browsers to read documents on the Web (and if Web servers put in
> the requisit CGI, to enable Web browsers to navigate via search).


I just wanted to point out that there are divergent goals being discussed
in this single thread.


>    Second, everyone seems to agree that Info's search and navigation
>    facilities are superior to HTML; so shouldn't we take advantage of
>    that?
> 
> Right, that is why Info should not be changed (unless someone wants
> to enhance it by enabling slow connections between an Info doc server
> and the Info renderer; right now the connection must be fast).


I don't understand why that is, i.e. why the server <-> client connection
speed for HTML is not adequate for Info as well.


>    Third, Info files can be rendered very quickly (especially compared
>    to HTML) because they have already been pre-processed from the
>    Texinfo source, but the download time for Info is no worse than
>    HTML because it's not much bigger than the source.
> 
> I do not understand you.  It takes me 17 minutes to download the Emacs
> Lisp Reference Manual.  When I do the manual in Info format, I then
> later read it in Info.  I do not wait 17 minutes and then start
> reading.
> 
> The goal with the HTML/CGI proposal is that if I were to browse the
> manual remotely in a Web browser, I would need to download only small
> parts -- nodes most likely -- quickly, so I would not have to wait 17
> minutes.


Right; but I assumed that the remote Info manual is already split into
relatively small files, and I should have said that an Info _node_ can
be displayed quickly (at least as quickly as an HTML page).  And my
little experiment showed that you can already browse a remote Info
manual, only downloading the subfiles as necessary, using ange-ftp.


>    Searching an entire document, whether it's in Info format or HTML
>    and whether it's a monolithic entity or split into pieces still
>    requires that the data be downloaded.
> 
> No, it does not.  That is the point of a CGI script.  You do *not*
> have to download a whole document if the serving computer does the
> work for you.

Indeed, I was wrong: even a remote Info file accessed via ange-ftp can

be searched incrementally.


If the goal is to make remote documentation available in current Info
browsers, they just need to be changed to recognize remote file syntax
(like ange-ftp, tramp, or http-get.el provide for Emacs).  If the goal
is to make documentation available for web browsers, makeinfo --html
already does that.  Right?

-- 
Kevin Rodgers

Re: A new online publishing tool for Texinfo documents.

[Robert J. Chassell]

   I just wanted to point out that there are divergent goals being discussed
   in this single thread.

Yes, good point.

   > No, it does not.  That is the point of a CGI script.  You do *not*
   > have to download a whole document if the serving computer does the
   > work for you.

   Indeed, I was wrong: even a remote Info file accessed via ange-ftp
   can be searched incrementally.

Are you sure it does this efficiently -- that is to say, will I be
able to navigate through a complete `Emacs Lisp Reference Manual' in
less than 17 seconds, or will it take me 17 minutes before my
`Info-search' expression has got to the last node?

My understanding is that ange-ftp/tramp downloads the file or files to
the client machine and the search is done by the client.


   If the goal is to make documentation available for web browsers,
   makeinfo --html already does that.  Right?

No, `makeinfo --html' does a poor job; you cannot move around a
document well.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: A new online publishing tool for Texinfo documents.

[Kevin Rodgers]

Robert J. Chassell wrote:

>    Indeed, I was wrong: even a remote Info file accessed via ange-ftp
>    can be searched incrementally.
> 
> Are you sure it does this efficiently -- that is to say, will I be
> able to navigate through a complete `Emacs Lisp Reference Manual' in
> less than 17 seconds, or will it take me 17 minutes before my
> `Info-search' expression has got to the last node?


17 minutes to download 711 KB?  The uncompressed Info files in the
21-2.8 Emacs Lisp Reference Manual are 2,462,047 bytes; they gzip down
to 728,336 bytes.  So I think you could download, gunzip, and search
the whole thing in a reasonable amount of time.


> My understanding is that ange-ftp/tramp downloads the file or files to
> the client machine and the search is done by the client.


Correct.


>    If the goal is to make documentation available for web browsers,
>    makeinfo --html already does that.  Right?
> 
> No, `makeinfo --html' does a poor job; you cannot move around a
> document well.

Well, that's a different problem.  First make sure it's generating the

best possible HTML, then worry about extending the markup language.

-- 
Kevin Rodgers

Re: A new online publishing tool for Texinfo documents.

[Karl Berry]

Hi Nic, Bob, all,

    This message has been sent to all interested parties.

Well, not quite.  You missed everyone else interested in Texinfo :).
I've included texinfo-pretest@texinfo.org now.  (I also forwarded your
message there so the others will have the background.)

Overall, I like the plan very much.  

As you may already know (perhaps it was the impetus for this?), there
was a long thread on emacs-devel recently about approaching this from
the other direction: extending Info format to carry more markup
information, so that Emacs could do a better job rendering it (the
original hope was to have a way to colorize certain parts of the Info files).

At that time, I stated (and still believe) that starting with the
makeinfo XML output would be much better and easier than turning Info
format into some kind of ersatz XML/HTML.  So I'm very happy to see this
proposal :).

Here are other comments.

    alter makeinfo --xml so that it splits the XML by Texinfo

I am no xml expert, but I'm not sure that is necessary or desirable,
since the only thing that will read the XML is other scripts.  It is the
specialized HTML that needs to be split.  And even then, split nodes are
just one possible outcome.  There are xref issues here, which Patrice
Dumas and I have hashed over at some length.  Anyway, all that is a
technical detail.

In any case, you should know that Alper Ersoy <dirt@gtk.org> (who's on
texinfo-pretest) has been doing great work with makeinfo in the last few
weeks, especially the XML, Docbook, and HTML output.  I'm sure he will
have some comments.

Alper has also worked a lot with the XML output for purposes of the GTK
documentation system.  Maybe some of that can be reused.

    I personally don't think this will deprecate the existing HTML output
    from makeinfo because that has good support for ALL browsers.

And doesn't require any server-side support.

    Emacs/W3 and Lynx do not support Javascript so we will have to find
    another way of binding actions to keys within the HTML pages
    downloaded to those browsers.

Presumably it is possible to do anything in Emacs :).  
In any case, Emacs/W3 may not the best approach for Emacs support.  But
that's up to the emacs developers, of course.

As for lynx, I do not know; I haven't tried the version of links you
mention.

JavaScript is the only standard way to do browser-side programming that
I know of.  It may turn out that only a small subset of JavaScript is
actually needed for the job, that wouldn't be as painful to add to Emacs
and Lynx as the whole huge mess.

Thanks,
karl
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Nic Ferrier]

References: <200311222118.hAMLI3v07843@f7.net>
From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
Date: 22 Nov 2003 21:37:10 +0000
In-Reply-To: <200311222118.hAMLI3v07843@f7.net>
Message-ID: <87u14wdr09.fsf@kanga.tapsellferrier.co.uk>
Lines: 114
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
--text follows this line--
karl@freefriends.org (Karl Berry) writes:

> Well, not quite.  You missed everyone else interested in Texinfo :).
> I've included texinfo-pretest@texinfo.org now.  (I also forwarded your
> message there so the others will have the background.)

I've included them in this reply.

 
> As you may already know (perhaps it was the impetus for this?), there
> was a long thread on emacs-devel recently about approaching this from
> the other direction: extending Info format to carry more markup
> information, so that Emacs could do a better job rendering it (the
> original hope was to have a way to colorize certain parts of the Info files).
> 
> At that time, I stated (and still believe) that starting with the
> makeinfo XML output would be much better and easier than turning Info
> format into some kind of ersatz XML/HTML.  So I'm very happy to see this
> proposal :).

I think that's true as well. I'm considering some work to make
libxml2 (which provides xsltproc) available as part of Emacs. This
would make using it very simple indeed.

 
> Here are other comments.
> 
>     alter makeinfo --xml so that it splits the XML by Texinfo
> 
> I am no xml expert, but I'm not sure that is necessary or desirable,
> since the only thing that will read the XML is other scripts.  It is the
> specialized HTML that needs to be split.  And even then, split nodes are
> just one possible outcome.  There are xref issues here, which Patrice
> Dumas and I have hashed over at some length.  Anyway, all that is a
> technical detail.

It's not necessary because you can easily chunk XML with
XSLT. However, I think it's desirable because it's what one might
expect...

But this could certainly warrant further discussion. I'm not going to
do it straight away, I'll be using XSLT to do my chunking initially.


 
>     I personally don't think this will deprecate the existing HTML output
>     from makeinfo because that has good support for ALL browsers.
> 
> And doesn't require any server-side support.

Note that this application will not require any specific server side
support excepting the regex search mechanism. Everything else will be
within the page.


>     Emacs/W3 and Lynx do not support Javascript so we will have to find
>     another way of binding actions to keys within the HTML pages
>     downloaded to those browsers.
> 
> Presumably it is possible to do anything in Emacs :).  
> In any case, Emacs/W3 may not the best approach for Emacs support.  But
> that's up to the emacs developers, of course.
> 
> As for lynx, I do not know; I haven't tried the version of links you
> mention.
> 
> JavaScript is the only standard way to do browser-side programming that
> I know of.  It may turn out that only a small subset of JavaScript is
> actually needed for the job, that wouldn't be as painful to add to Emacs
> and Lynx as the whole huge mess.

I'm unsure about Lynx but for Emacs/W3 I'm sure we could add a hack
so that we could use Elisp as an in-page language. In other words
we'd deliver pages that have HTML like this:

<html>
<head>
<script language="Javascript">
function index_lookup(word)
{
  .
  .
  .
}
</script>
<script language="EmacsLisp">
(defun index-lookup (word)
  .
  .
  .)
</script>
</head>
<body keybinding="i index_lookup">
</body>


'keybinding' is an imagined attribute that binds a function name to a
key press. I've done this for brevity only.

Maybe we'd need to provide emacs-lisp versions of the event
attributes (the ones that links to scripts) so we'd have:

  <table onkeypress="if (key == 's') doSearch();"
         emacs_onkeypress='(if (equals key "s") (do-search))'>
    .
    .
    .


Whatever, as you say, because Emacs is so adaptable we can achieve
something. It's just "what thing" which is important.


Nic

Re: A new online publishing tool for Texinfo documents.

[Juri Linkov]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> karl@freefriends.org (Karl Berry) writes:
>> At that time, I stated (and still believe) that starting with the
>> makeinfo XML output would be much better and easier than turning Info
>> format into some kind of ersatz XML/HTML.  So I'm very happy to see this
>> proposal :).
>
> I think that's true as well. I'm considering some work to make
> libxml2 (which provides xsltproc) available as part of Emacs. This
> would make using it very simple indeed.

Making some XML library available as part of Emacs might be useful.
Current XML parsing implemented in Emacs Lisp is too slow on large
XML files.  But maybe building a DOM tree from makeinfo XML output
is not needed at all.  This might be needed for XML transformation,
e.g. for reordering the Info nodes.  But for simple text formatting
a simple sequential SAX-like processor should be enough.  It could
provide, for instance, the following hooks:

(defun xml-start-element (name atts))

(defun xml-characters (str)
  (insert str))

(defun xml-end-element (name from to)
  ;; this could be used to format the inserted text
  (cond ((equal name "para"))
         (fill-region-as-paragraph from to)))

>> Here are other comments.
>> 
>>     alter makeinfo --xml so that it splits the XML by Texinfo
>> 
>> I am no xml expert, but I'm not sure that is necessary or desirable,
>> since the only thing that will read the XML is other scripts.  It is the
>> specialized HTML that needs to be split.  And even then, split nodes are
>> just one possible outcome.  There are xref issues here, which Patrice
>> Dumas and I have hashed over at some length.  Anyway, all that is a
>> technical detail.
>
> It's not necessary because you can easily chunk XML with
> XSLT. However, I think it's desirable because it's what one might
> expect...
>
> But this could certainly warrant further discussion. I'm not going to
> do it straight away, I'll be using XSLT to do my chunking initially.

It's better not to split a XML file, because splitting it to many files
will complicate the processing of XML structure as a whole.

>> JavaScript is the only standard way to do browser-side programming that
>> I know of.  It may turn out that only a small subset of JavaScript is
>> actually needed for the job, that wouldn't be as painful to add to Emacs
>> and Lynx as the whole huge mess.
>
> Whatever, as you say, because Emacs is so adaptable we can achieve
> something. It's just "what thing" which is important.

JavaScript is mostly useful for web applications supposed to run in
mainstream browsers.  But for such browsers HTML files is already
good enough solution.  What is rather needed is to improve Emacs
Info browser.  Currently I see at least three ways to do it:

1. continue to hack existing info.el to overcome existing limitations
   of Info format;
2. extend existing Web browser implemented in Emacs for better support
   of Info HTML navigation;
3. try to use an additional XML format in Emacs;

-- 
http://www.jurta.org/emacs/

Re: A new online publishing tool for Texinfo documents.

[Nic Ferrier]

Juri Linkov <juri@jurta.org> writes:

> >> JavaScript is the only standard way to do browser-side programming that
> >> I know of.  It may turn out that only a small subset of JavaScript is
> >> actually needed for the job, that wouldn't be as painful to add to Emacs
> >> and Lynx as the whole huge mess.
> >
> > Whatever, as you say, because Emacs is so adaptable we can achieve
> > something. It's just "what thing" which is important.
> 
> JavaScript is mostly useful for web applications supposed to run in
> mainstream browsers.  But for such browsers HTML files is already
> good enough solution.  What is rather needed is to improve Emacs
> Info browser.  

Just to be clear. Bob Chassell and I are proposing a new system for
making Texinfo documentation available over the web. It's not a
replacement for Emacs Info mode. But it is intended that users of
Emacs web browsers will be able to view the HTML produced by the new
system.


>Currently I see at least three ways to do it:
> 
> 1. continue to hack existing info.el to overcome existing limitations
>    of Info format;
> 2. extend existing Web browser implemented in Emacs for better support
>    of Info HTML navigation;
> 3. try to use an additional XML format in Emacs;

Personally, I see absolutely nothing wrong with current Emacs Info. I
use it an awfull lot (I use Texinfo for all my word processing tasks
and info mode for viewing all the documentation I have to write as
part of my work) as well as using Info from the console.

Right now, I almost never read HTML Info documents. I hope that the
new system Bob and I are talking about will change that a bit.


Nic

Re: A new online publishing tool for Texinfo documents.

[Richard Stallman]

    Just to be clear. Bob Chassell and I are proposing a new system for
    making Texinfo documentation available over the web. It's not a
    replacement for Emacs Info mode. But it is intended that users of
    Emacs web browsers will be able to view the HTML produced by the new
    system.

Ok, that seems like a useful thing to do, and can't hurt anything.

Re: A new online publishing tool for Texinfo documents.

[Juri Linkov]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>> >> JavaScript is the only standard way to do browser-side programming that
>> >> I know of.  It may turn out that only a small subset of JavaScript is
>> >> actually needed for the job, that wouldn't be as painful to add to Emacs
>> >> and Lynx as the whole huge mess.
>> >
>> > Whatever, as you say, because Emacs is so adaptable we can achieve
>> > something. It's just "what thing" which is important.
>> 
>> JavaScript is mostly useful for web applications supposed to run in
>> mainstream browsers.  But for such browsers HTML files is already
>> good enough solution.  What is rather needed is to improve Emacs
>> Info browser.  
>
> Just to be clear. Bob Chassell and I are proposing a new system for
> making Texinfo documentation available over the web. It's not a
> replacement for Emacs Info mode. But it is intended that users of
> Emacs web browsers will be able to view the HTML produced by the new
> system.

I still think that there is no need to add Javascript and XSLT engines
to Emacs.  The solution you propose will be useful for web browsers
because they have no other extensibility mechanisms.  But Emacs could
handle pages received from server by using local Emacs Lisp programs.
The received pages could contain some indication about their type so
that Emacs will decide what functions to call to handle them.  And
this is much safer than to embed Emacs Lisp code on the web pages.

> Personally, I see absolutely nothing wrong with current Emacs Info. I
> use it an awfull lot (I use Texinfo for all my word processing tasks
> and info mode for viewing all the documentation I have to write as
> part of my work) as well as using Info from the console.

I like the current Emacs Info too because it is fast and well suited
for viewing the reference manuals.  However, I want to fix some minor
problems recently reported in it.

> Right now, I almost never read HTML Info documents. I hope that the
> new system Bob and I are talking about will change that a bit.

I hope it will change that for the better ;-)

-- 
http://www.jurta.org/emacs/

Re: A new online publishing tool for Texinfo documents.

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> I still think that there is no need to add Javascript and XSLT engines
> to Emacs.  The solution you propose will be useful for web browsers
> because they have no other extensibility mechanisms.  But Emacs could
> handle pages received from server by using local Emacs Lisp programs.
> The received pages could contain some indication about their type so
> that Emacs will decide what functions to call to handle them.  And
> this is much safer than to embed Emacs Lisp code on the web pages.

I totally agree.

Just put something like

<!-- *Info-Node* next=XX prev=XX up=XX index=XX ... -->

into every page and let emacs info reader -- or stand-alone info
reader -- deal with that; should be damn trivial compared to XSLT or
javascript or whatever.

But by all means, add whatever javascript and XML etc to make it
useful in a standard browser as well.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: A new online publishing tool for Texinfo documents.

[Karl Berry]

    It's better not to split a XML file, because splitting it to many files
    will complicate the processing of XML structure as a whole.

I agree, and I see no gain to splitting the XML since it is an
intermediate format in this scenario.  But we're not writing the code,
so it's not up to us :).

    But for such browsers HTML files is already good enough solution.

No, it isn't.  That is the whole point of the Bob/Nic proposal.  It does
not support search/index-search, which is a crucial feature.

    1. continue to hack existing info.el to overcome existing limitations
       of Info format;

I strongly, strongly believe that current Info format should continue to
be a text/console based format, essentially as it is now, trying to
describe only what can be done on character-based displays.  I.e., as we
battered to death earlier, we might add color support, which is about
the only thing (I can think of) that consoles can do that Info can't now.

As I said, I see no point in trying to make Info format into some ersatz
HTML or XML with "logical" markup, trying to somehow allow reformatting
paragraphs and all the other things HTML does.  That way lies madness.

For using the Info system with bitmapped displays, using HTML/XML, such
as Bob and Nic are proposing, seems to me to be a far superior approach.
HTML/XML will be much better at that than the Info format ever could be.
And we lose the simplicity and usefulness of current Info format if we
try to make it into XML.

    2. extend existing Web browser implemented in Emacs for better support
       of Info HTML navigation;

That is what Bob/Nic are proposing.

    3. try to use an additional XML format in Emacs;

Again, that is what Bob/Nic are proposing -- essentially.  I suppose one
could parse the XML output from Texinfo directly, but I don't think that
has any special benefits in this case.  (Although GTK does it.)  It
seems better to make it work with web browsers, since most everyone has
a browser installed already.
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Juri Linkov]

karl@freefriends.org (Karl Berry) writes:
>     But for such browsers HTML files is already good enough solution.
>
> No, it isn't.  That is the whole point of the Bob/Nic proposal.  It does
> not support search/index-search, which is a crucial feature.

The search in a whole document is already available for HTML files in
web browsers when HTML output is generated in one HTML file without
splitting.  However, loading one big HTML file in web browser
sometimes is undesirable.  In this case to search many HTML files some
CGI script on HTTP server will be needed if documentation is viewed
on the web by some web browser, or HTML search can be done by Emacs
if files are viewed locally.

>     1. continue to hack existing info.el to overcome existing limitations
>        of Info format;
>
> As I said, I see no point in trying to make Info format into some ersatz
> HTML or XML with "logical" markup, trying to somehow allow reformatting
> paragraphs and all the other things HTML does.  That way lies madness.

Yes, I agree that adding more markup to Info format is not an option.
What I meant here is the improvement of Info readers without changing
the current Info format.

> For using the Info system with bitmapped displays, using HTML/XML, such
> as Bob and Nic are proposing, seems to me to be a far superior approach.
> HTML/XML will be much better at that than the Info format ever could be.
> And we lose the simplicity and usefulness of current Info format if we
> try to make it into XML.
>
>     2. extend existing Web browser implemented in Emacs for better support
>        of Info HTML navigation;
>
> That is what Bob/Nic are proposing.

A new online publishing tool Bob and Nic are proposing will be useful
for normal web browsers.  However, implementing it with JavaScript
and XSLT will require too big effort to make it available for Emacs
web browsers.  Much easier is to write some Emacs Lisp code to handle
such HTML/XML files specially in Emacs web browsers.

>     3. try to use an additional XML format in Emacs;
>
> Again, that is what Bob/Nic are proposing -- essentially.  I suppose one
> could parse the XML output from Texinfo directly, but I don't think that
> has any special benefits in this case.  (Although GTK does it.)  It
> seems better to make it work with web browsers, since most everyone has
> a browser installed already.

Reading the XML output of Texinfo in Emacs might be a good alternative
to the current Info format, because it will allow to extend the XML
markup without affecting the Info viewer.

-- 
http://www.jurta.org/emacs/

Re: A new online publishing tool for Texinfo documents.

[Richard Stallman]

    I think that's true as well. I'm considering some work to make
    libxml2 (which provides xsltproc) available as part of Emacs. This
    would make using it very simple indeed.

As I see it, this is a major disadvantage of the plan.  I don't want
to make Emacs link with another library just for this.

    I'm unsure about Lynx but for Emacs/W3 I'm sure we could add a hack
    so that we could use Elisp as an in-page language.

Perhaps each instruction could be provided both in Javascript and in
Emacs Lisp; then each program to display the file could use whichever
one is easier.

Or if the Javascript that you need is very limited and stereotyped,
a simple Lisp program could recognize the standard Javascript programs
with regexps, and handle each case appropriately.

Re: A new online publishing tool for Texinfo documents.

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     I'm unsure about Lynx but for Emacs/W3 I'm sure we could add a hack
>     so that we could use Elisp as an in-page language.
> 
> Perhaps each instruction could be provided both in Javascript and in
> Emacs Lisp; then each program to display the file could use whichever
> one is easier.

Yes, that was what I was suggesting.

The trouble with doing that is that viruses become a real
possibility. We'd have to invent some security checking stuff to
ensure that elisp programs embedded in webpages only did what they
were allowed to do.

Of course, with elisp that's not as difficult as it is in other
languages because an elisp parser is not as difficult to write... but
it's still more work than linking in Javascript.

It also only solves the problem for this application. More and more
websites are using Javascript in the page.

 
> Or if the Javascript that you need is very limited and stereotyped,
> a simple Lisp program could recognize the standard Javascript programs
> with regexps, and handle each case appropriately.

That's a good idea. We could tag the javascript with comments so that
they could be recognised easily.


Nic

Re: A new online publishing tool for Texinfo documents.

[Stepan Kasal]

Hello all,

[I hope I've got the cc list right.]

> On the subject of Lynx, has anyone tried this version of Links?
>   http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/
> It apparently has Javascript support and is GPLed.

I use it regularily as my text browser, it handles tables and frames
nicely.  I like it very much.

It's not only text browser, it's also a lightweight X web browser.
I know several people who have links as their primary X browser.

It's being actively developed.

There is also a derived project, ``elinks,'' which can be extended by
Lua and Guile.  The maintainer of elinks is also very responsive and
helped me to fix a problem in an hour.  (http://elinks.or.cz/)

But unless you find a reason to use elinks, start with the true links,
as you mentioned above.

The authors are Czech, feel free to ask me for help in case you needed it.

So, go on and make links a requirement for your web info solution with
text terminal clients.

I'd be glad to answer any questions...

Stepan
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Miles Bader]

On Sun, Nov 23, 2003 at 10:16:45AM +0100, Stepan Kasal wrote:
> But unless you find a reason to use elinks, start with the true links,
> as you mentioned above.

AFAIK, neither the version cited here, nor elinks, is the `true' links --
that apparently ceased development quite a while ago, and both the above are
forks of it.

[I say this because elinks also seems to have made many improvements, so it's
not clear whether one or the other is to be preferred; what debian packages
is elinks.]

-Miles
-- 
We have met the enemy, and he is us.  -- Pogo

Re: A new online publishing tool for Texinfo documents.

[Stepan Kasal]

Hi,

On Sun, Nov 23, 2003 at 04:28:44AM -0500, Miles Bader wrote:
> On Sun, Nov 23, 2003 at 10:16:45AM +0100, Stepan Kasal wrote:
> > But unless you find a reason to use elinks, start with the true links,
> > as you mentioned above.
>
> AFAIK, neither the version cited here, nor elinks, is the `true' links --
> that apparently ceased development quite a while ago, and both the above are
> forks of it.

I know the authors a bit, though I've never met them in person.
clock is the login name of Petr Kulhavy, one of the principle authors of links.

So I think the URL mentioned is ``the one true links.''

But it's not important which one will be used.
I beleive many improvements migrate both directions.

> [I say this because elinks also seems to have made many improvements, so it's
> not clear whether one or the other is to be preferred; what debian packages
> is elinks.]

And it seems to have some problems.  When I go to a complex page, eg. mailman
page of holded messages, then uparrow won't get me to the top, it goes in
a weird cycle.
Though the configuration language has improved, I had problems to find the
documentation for it.

Red Hat also packages elinks, I'm actually currently using elinks, not links.

Stepan

_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Miles Bader]

On Sun, Nov 23, 2003 at 01:33:09PM +0100, Stepan Kasal wrote:

> > AFAIK, neither the version cited here, nor elinks, is the `true' links --
> > that apparently ceased development quite a while ago, and both the above
> > are forks of it.
> 
> I know the authors a bit, though I've never met them in person.  clock is
> the login name of Petr Kulhavy, one of the principle authors of links.

As I recall, the original links was the work of a single person, [let's see,
google, google] Mikulas Patocka, who basically stopped working on it; it
looks like the various people with versions today all branched off at around
the same point.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Stepan Kasal]

Hello,

On Sun, Nov 23, 2003 at 04:19:51PM -0500, Miles Bader wrote:
> Mikulas Patocka, who basically stopped working on it;

they all for the founding group.  The
http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/development.html
page says

     * Send bugreport to the following four addresses:
	mikulas at twibright.com
	brain at twibright.com
	clock at twibright.com
	perm at twibright.com

Maybe mikulas (Mikulas Patocka) dooesn't work on it nowadays.
And maybe Mikulas was the original author, back in the days before
they conquered the world.

elinks, OTOH, is work of Petr Baudis <pasky@ucw.cz>

Stepan
_______________________________________________
Texinfo home page: http://www.gnu.org/software/texinfo/
texinfo-pretest@texinfo.org
http://ff0.org/mailman/listinfo/texinfo-pretest

Re: A new online publishing tool for Texinfo documents.

[Karl Berry]

    <!-- *Info-Node* next=XX prev=XX up=XX index=XX ... -->

Most of this info, at least, is already there, in every format.

    into every page and let emacs info reader -- or stand-alone info

?

Once again, I believe that the emacs/standalone info readers should not
be changed to try to read html or xml or anything-else-ml.  The whole
point of info format is to be preformatted and simple to handle.  If you
want logical markup, use something that was designed for it.  As Bob and
Nic are proposing.