unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kevin Rodgers <ihs_4664@yahoo.com>
Subject: Re: A new online publishing tool for Texinfo   documents.
Date: Tue, 02 Dec 2003 11:54:21 -0700	[thread overview]
Message-ID: <3FCCDFDD.2030306@yahoo.com> (raw)
In-Reply-To: m1AP7KO-000UNgC@rattlesnake.com

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

  reply	other threads:[~2003-12-02 18:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-22 20:50 A new online publishing tool for Texinfo documents Nic Ferrier
2003-11-23 16:34 ` Richard Stallman
2003-11-23 16:56   ` Nic Ferrier
2003-11-25 18:36     ` Kevin Rodgers
2003-11-25 20:05       ` Nic Ferrier
2003-11-25 22:38         ` Kim F. Storm
2003-11-26  0:21       ` Robert J. Chassell
2003-11-26  6:25         ` Eli Zaretskii
2003-11-26 18:37         ` Kevin Rodgers
2003-11-26 21:36           ` Robert J. Chassell
2003-12-02 18:54             ` Kevin Rodgers [this message]
2003-12-02 21:56               ` Robert J. Chassell
2003-12-03  0:42                 ` Kevin Rodgers
  -- strict thread matches above, loose matches on Subject: below --
2003-11-22 21:18 Karl Berry
2003-11-22 21:37 ` Nic Ferrier
2003-11-24  7:57   ` Juri Linkov
2003-11-24  9:11     ` Nic Ferrier
2003-11-25  4:27       ` Richard Stallman
2003-11-25  7:52       ` Juri Linkov
2003-11-25 11:21         ` Kim F. Storm
2003-11-24 14:10     ` Karl Berry
2003-11-25 21:45       ` Juri Linkov
2003-11-24 16:22   ` Richard Stallman
2003-11-24 16:39     ` Nic Ferrier
     [not found] <200311222102.hAML20T05380@f7.net>
2003-11-23  9:16 ` Stepan Kasal
2003-11-23  9:28   ` Miles Bader
2003-11-23 12:33     ` Stepan Kasal
2003-11-23 21:19       ` Miles Bader
2003-11-24  8:57         ` Stepan Kasal
2003-11-25 13:58 Karl Berry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FCCDFDD.2030306@yahoo.com \
    --to=ihs_4664@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).