Re: A new online publishing tool for Texinfo documents.

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 (regarding Lynx and Links)

[Nic Ferrier]

I've just tested Links from:

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

and it has working Javascript support. So it might be possible to
suggest that people use that instead of Lynx.

It is GPLed.


Nic

Re: A new online publishing tool for Texinfo documents (regarding Lynx and Links)

[Alex Schroeder]

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

> and it has working Javascript support. So it might be possible to
> suggest that people use that instead of Lynx.

I also remember seeing a w3m (another text browser) with javascript
support (or at least a patch to add it).

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

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

XML and emacs (was Re: A new online publishing tool for Texinfo documents.)

[Nic Ferrier]

Juri Linkov <juri@jurta.org> writes:

> 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)))

Yes. Or STaX which is a new API available only for Java right now and
looks like it's a  bit easier to deal with than SAX.

libxml2 does have a SAX implementation so if I make it part of Emacs
then that would be available.

James Clark and I have already had a discussion about this on the
emacs-devel list. James is writing an XML parser in Emacs Lisp and
his view was that native Elisp is always going to be better than a
foreign library.

I take his point. But there are other reasons why I'd like libxml2
integrated into Emacs (because I use it everywhere else other than
Emacs) so I might do it anyway.



Nic

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.

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

[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/

Emacs and Javascript/XSLT (was Re: A new online publishing tool for Texinfo documents.)

[Nic Ferrier]

storm@cua.dk (Kim F. Storm) writes:

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

This is not about altering the emacs info reader. This is about
writing a new HTML publishing system for Texinfo.

The arguments about adding Javascript and XSLT functionality to Emacs
are about the functionality of Emacs/W3, _not_ about Emacs info mode.

Whether the new publishing system relies on Javascript/XSLT or not is
aside from the question of whether Javascript/XSLT functionality
should be added to Emacs/W3. Clearly, Emacs/W3 is never going to be a
competitive browser without those features.


IMHO it's really not defensible to suggest that Emacs shouldn't have
access to XSLT (the question is _how_).

I can understand reservations about adding Javascript to
emacs. Unfortunately, I can't see anyway of doing it other than
linking the Javascript engine into emacs and rms has said he won't
support that.


If the new publishing system uses Javascript then Emacs/W3 won't be
able to display the pages with all the functionality.

If people here feel that a client side code system supporting emacs
lisp would be useful then I think I could probably add that to W3 and
support the 2 sets of code used for the publishing tool (Elisp and
Javascript).

Tagging might also be possible but this would require patching W3 to
support this new info publishing system. That doesn't seem the right
way round to me.


Nic

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: Emacs and Javascript/XSLT (was Re: A new online publishing tool for Texinfo documents.)

[Stefan Monnier]

> Whether the new publishing system relies on Javascript/XSLT or not is
> aside from the question of whether Javascript/XSLT functionality
> should be added to Emacs/W3. Clearly, Emacs/W3 is never going to be a
> competitive browser without those features.

Emacs/W3 has been dying for the last several years, so its competitivity
currently depends on much more serious issues than "how does it deal with
Javascript and XSLT".  The first issue is "who is going to work on it".


        Stefan

Re: Emacs and Javascript/XSLT (was Re: A new online publishing tool for Texinfo documents.)

[Juri Linkov]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> storm@cua.dk (Kim F. Storm) writes:
>> 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.

In this my post I missed the word "better".  So more correctly this
sentence should look like this: "currently web browsers have no other
better extensibility mechanism than JavaScript", that means the most
general and browser- and platform-independent.  But Emacs has the
different and well-established extensibility by Emacs Lisp.

>> > 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.
>> [...]
>> But by all means, add whatever javascript and XML etc to make it
>> useful in a standard browser as well.
>
> This is not about altering the emacs info reader. This is about
> writing a new HTML publishing system for Texinfo.
>
> The arguments about adding Javascript and XSLT functionality to Emacs
> are about the functionality of Emacs/W3, _not_ about Emacs info mode.

This is not about HTML publishing system for Texinfo either.  Since
this discussion turned to be about making Emacs a full-blown web browser,
I want to mention that I heard an opinion about some "marriage" between
Emacs and Mozilla.  Although this is technically questionable idea,
this is what many people wish, because they are not satisfied with the
Emacs/W3.

> Whether the new publishing system relies on Javascript/XSLT or not is
> aside from the question of whether Javascript/XSLT functionality
> should be added to Emacs/W3. Clearly, Emacs/W3 is never going to be a
> competitive browser without those features.

Emacs/W3 has inherent limitation on the speed because HTML rendering
is implemented in Lisp.  Implementing parts of it in C with some hooks
to Lisp would improve its performance.  The similar solution is
provided already by the emacs-w3m, but it uses an external program for
rendering, and I can't tell how it would share JavaScript processing
with Emacs.

> IMHO it's really not defensible to suggest that Emacs shouldn't have
> access to XSLT (the question is _how_).

Emacs has much better structure transformation mechanisms than XSLT.

> I can understand reservations about adding Javascript to
> emacs. Unfortunately, I can't see anyway of doing it other than
> linking the Javascript engine into emacs and rms has said he won't
> support that.
>
> If the new publishing system uses Javascript then Emacs/W3 won't be
> able to display the pages with all the functionality.

I am not against the idea of developing Emacs into decent web browser,
but JavaScript and XML are issues that should be considered only after
solving other more important problems with using Emacs as a web browser
(e.g. faster rendering, better graphical display, full compliance to www
standards, etc.).

> If people here feel that a client side code system supporting emacs
> lisp would be useful then I think I could probably add that to W3 and
> support the 2 sets of code used for the publishing tool (Elisp and
> Javascript).
>
> Tagging might also be possible but this would require patching W3 to
> support this new info publishing system. That doesn't seem the right
> way round to me.

No need to patch W3.  This would implemented as a minor mode for
w3 buffers.

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

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/