From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Javascript/XSLT (was Re: A new online publishing tool for Texinfo documents.) Date: Tue, 25 Nov 2003 19:55:39 +0200 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87vfp8uyck.fsf@mail.jurta.org> References: <200311222118.hAMLI3v07843@f7.net> <87r800dr09.fsf@kanga.tapsellferrier.co.uk> <87znemp5a0.fsf@mail.jurta.org> <878ym6dtbh.fsf@kanga.tapsellferrier.co.uk> <87smkc7ulq.fsf@mail.jurta.org> <87u14sbup3.fsf_-_@kanga.tapsellferrier.co.uk> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069783354 17847 80.91.224.253 (25 Nov 2003 18:02:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Nov 2003 18:02:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Nov 25 19:02:31 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AOhWB-00029e-00 for ; Tue, 25 Nov 2003 19:02:31 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AOhWA-00042q-00 for ; Tue, 25 Nov 2003 19:02:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AOiR0-00084U-TJ for emacs-devel@quimby.gnus.org; Tue, 25 Nov 2003 14:01:14 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AOiQ7-00081K-9B for emacs-devel@gnu.org; Tue, 25 Nov 2003 14:00:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AOiPZ-0007pN-KJ for emacs-devel@gnu.org; Tue, 25 Nov 2003 14:00:16 -0500 Original-Received: from [64.246.52.22] (helo=ns5.tangramltd.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AOiPZ-0007p7-5i for emacs-devel@gnu.org; Tue, 25 Nov 2003 13:59:45 -0500 Original-Received: from 80-235-34-228-dsl.mus.estpak.ee ([80.235.34.228] helo=mail.jurta.org) by ns5.tangramltd.com with esmtp (Exim 4.20) id 1AOhS0-00034f-GX; Tue, 25 Nov 2003 19:58:12 +0200 Original-To: Nic Ferrier In-Reply-To: <87u14sbup3.fsf_-_@kanga.tapsellferrier.co.uk> (Nic Ferrier's message of "25 Nov 2003 10:37:12 +0000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns5.tangramltd.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jurta.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18112 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18112 Nic Ferrier writes: > storm@cua.dk (Kim F. Storm) writes: >> Juri Linkov 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/