[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A new online publishing tool for Texinfo documents.

From: Nic Ferrier
Subject: Re: A new online publishing tool for Texinfo documents.
Date: 22 Nov 2003 21:37:10 +0000

References: <address@hidden>
From: Nic Ferrier <address@hidden>
Date: 22 Nov 2003 21:37:10 +0000
In-Reply-To: <address@hidden>
Message-ID: <address@hidden>
Lines: 114
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
--text follows this line--
address@hidden (Karl Berry) writes:

> Well, not quite.  You missed everyone else interested in Texinfo :).
> I've included address@hidden 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

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:

<script language="Javascript">
function index_lookup(word)
<script language="EmacsLisp">
(defun index-lookup (word)
<body keybinding="i index_lookup">

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]