unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Possible problem with Gnus
Date: 13 May 2004 21:07:51 +0200	[thread overview]
Message-ID: <x5y8nww3g8.fsf@lola.goethe.zz> (raw)
In-Reply-To: <87n04c5hz1.fsf-monnier+emacs@gnu.org>

Stefan Monnier <monnier@iro.umontreal.ca> 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 <math>...</math> 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

  reply	other threads:[~2004-05-13 19:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-09 23:07 Gnus for next release Miles Bader
2004-05-09 23:19 ` John Wiegley
2004-05-09 23:29 ` Stefan Monnier
2004-05-09 23:54   ` Miles Bader
2004-05-10  7:34     ` Frank Schmitt
2004-05-10  8:31 ` David Kastrup
2004-05-10 10:04   ` Reiner Steib
2004-05-11 12:22     ` Possible problem with Gnus Richard Stallman
2004-05-11 12:40       ` David Kastrup
2004-05-12 19:40         ` Richard Stallman
2004-05-11 13:48       ` Stefan Monnier
2004-05-11 16:07       ` Reiner Steib
2004-05-11 16:31         ` Paul Jarc
2004-05-12  9:59           ` Reiner Steib
2004-05-12 14:15             ` Paul Jarc
2004-05-12 15:48               ` Jesper Harder
2004-05-12 16:39               ` Reiner Steib
2004-05-12 15:36             ` Jesper Harder
2004-05-11 17:51         ` Stefan Monnier
2004-05-12  9:59           ` Reiner Steib
2004-05-12 10:34             ` David Kastrup
2004-05-13 15:45               ` Richard Stallman
2004-05-13 17:25                 ` David Kastrup
2004-05-13 17:59                   ` Stefan Monnier
2004-05-13 19:07                     ` David Kastrup [this message]
2004-05-14 21:01                   ` Richard Stallman
2004-05-14 21:18                     ` David Kastrup
2004-05-15 18:33                       ` Richard Stallman
2004-05-23  3:46                         ` Andy Tai
2004-05-23  3:48                         ` Andy Tai
2004-05-10 17:54 ` Gnus for next release Richard Stallman
2004-05-10 18:23   ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x5y8nww3g8.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).