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

[Juri Linkov]

Nic Ferrier <address@hidden> writes:
> address@hidden (Kim F. Storm) writes:
>> Juri Linkov <address@hidden> 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/