From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Possible problem with Gnus Date: 13 May 2004 21:07:51 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040509230720.GB20485@fencepost> <87n04c5hz1.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084475500 24372 80.91.224.253 (13 May 2004 19:11:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 May 2004 19:11:40 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 13 21:11:30 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOLcA-00088t-00 for ; Thu, 13 May 2004 21:11:30 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOLc9-000636-00 for ; Thu, 13 May 2004 21:11:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOLbP-0005lc-NJ for emacs-devel@quimby.gnus.org; Thu, 13 May 2004 15:10:43 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOLZa-0004ZL-AQ for emacs-devel@gnu.org; Thu, 13 May 2004 15:08:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOLYm-000462-Ff for emacs-devel@gnu.org; Thu, 13 May 2004 15:08:31 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOLYl-00045g-RE for emacs-devel@gnu.org; Thu, 13 May 2004 15:08:00 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BOLYe-0002Dh-Qm; Thu, 13 May 2004 15:07:53 -0400 Original-To: Stefan Monnier In-Reply-To: <87n04c5hz1.fsf-monnier+emacs@gnu.org> Original-Lines: 97 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:23338 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23338 Stefan Monnier writes: > >From your experience it seems the best approach is to do something > >like what preview-latex does. Obviously. Equally obviously, I am biased. > >It can't easily use the same insert-image interface, but maybe > >preview-latex's code could be made generic. That would certainly be a good thing, all in all. And what I can basically offer in that line is to collect FSF copyright assignments: this process is going to start soon, anyway, since I intend to fold preview-latex into AUCTeX some time next year or so. Getting hold of the contributors to preview-latex will be much easier than with AUCTeX, anyway. preview-latex is a complex and specialized beast, however. It basically consists of four components: a) a LaTeX style that hooks itself into selected pieces and part of the core of LaTeX to suppress all ordinary page generation and instead generate one page of information for each `interesting' text passage. Shortcoming of generality here: would need to get adapted to plain TeX and ConTeXt for best utility. b) a process interface for running text passages through TeX or PDFTeX under control of AUCTeX, dumping formats to speed up matters, parse the `error messages' from AUCTeX in order to find out where images need to get placed and so on. Shortcoming of generality here: would need to get pretty much rewritten in order to work with Emacs' default TeX modes. c) user interface code that will replace images with text for editing and backwards, open and fold back images, copy stuff and similar. Not many shortcomings here: the stuff fits the preview-latex niche very nicely. Interfacing into the desktop package to save and restore images probably fits that niche as well. d) rendering pipelines that talk to GhostScript, analyze PostScript files to split them into resources and individual images, run material through dvips and GhostScript, or through pdf2dsc and GhostScript (in case PDFLaTeX was used), organize the daemon operation into proper order (on-screen material first, the rest afterwards), manage temporary files and stuff. The intelligence in d) would, after suitable cleanup, pruning and generalization, probably make a useful Emacs core addition. For example, it is perfectly conceivable to have the "calc" calculator (which has a TeX mode output) use a continuing TeX session (I know how to force TeX to flush the dvi file) connected with a named pipe for its dvi output to dvipng (which can also run continuously in a daemon mode) and have the resulting png files displayed in realtime in an Emacs calc window. The performance of those components can easily be tuned to be workable on a 100MHz Pentium I. There are quite more applications than just preview-latex itself: for example Wikipedia is written with HTML tags ... that get run through LaTeX. It would be convenient to have a "WYSIWYG" editing mode that would let one see the results before the fact. > >Anyway... just thinking out loud, Nothing wrong with that. Possibilities are endless. And, as I said, assignments won't be the problem. Getting people to do the work is the problem. So I am more or less focusing on getting the stuff better for its limited applicability right now. This gives results. It gives experiences. If I can't manage to afford the time to do anything else, it will at least give me the qualification to tell others when I believe that they are on the wrong track, and why. Of all the extension projects (supporting Emacs tex-mode in addition to AUCTeX, support ConTeXt and/or plain TeX, general image pipelines also for, say, gnuplot and so on), few have come anywhere except great planning. I am glad that preview-latex now works with PDFLaTeX as well, I am glad that dvipng came into being (it was something on my wishlist, and one of our developers scared me out of my wits by actually implementing it. Took almost a year until I had it integrated satisfactorily) and is integrated well now. I am glad that GhostScript interaction has been as streamlined and polished as possible (and yes, we use GhostScript as safely as possible: getting any Trojans through preview-latex will be rather difficult). It needs people with a genuine interest, and the necessary resources to expand its usefulness beyond its current scope. This is one of the reasons that I am planning to fold it into AUCTeX some time next year: to get it more exposure in those areas where people can already benefit from it. Nothing wrong with thinking loud... and if there are sufficient resources for more than just thinking, it will be easy for people to do so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum