Sorry for barging in on this list like that, but I would like to share a few thoughts I had recently. Please stay on for a few paragraphs before blowing your top, I hope the relevance of this will then be clear.
Several of you probably are already aware of the preview-latex project where I am head developer. I delivered a talk about it at the recent EuroBachoTeX conference in Poland and witnessed an impressive amount of interest as compared to other Emacs-based tools for editing. I also had received several reports about vi users switching to Emacs because of it, and on the conference people asked me whether there would be any chance of seeing this in vi or its clones. The answer to that was no, simply because it is not conceivable that vi development will want to cater for an extension mechanism like that, or for graphical elements in buffers. In contrast, I believe LyX to have the necessary infrastructure for that kind of functionality. Instead of people abandoning their favorite editor because of some particular "killer feature", it would make more sense if their editor gained that functionality. preview-latex is little more than a bunch of streamlined glue interconnecting existing pieces of software (LaTeX, DviPS, GhostScript) and tying them with a convenient interface into an existing editing environment (Emacs/AUC TeX). Emacs has offered itself because it has the necessary power, because I know it well, because it provides a conveniently interactive test bed for applications like that. This does not mean that this approach would be infeasible for other editors. In fact, integrating this approach into LyX (which is a lot more aware of the underlying LaTeX structures) would seem to make a lot of sense. One of the current qualms of LyX developers is "ERT" (evil red text), LaTeX for which Lyx does not (yet) provide a graphical representation. If LyX offered the option to let LaTeX itself try to come up with a good rendition, this could make LyX buffers a lot more readable. While the amount of ground that LyX developers have already covered, is certainly impressive, things like PStricks graphics or MusiXTeX codes, or chess diagrams or similar don't seem to warrant the kind of work that would be necessary to make them natively known to LyX. Providing an option for having a graphical rendition for them in the source buffers might extend LyX' potential user base quite a bit. Even in those areas where LyX _does_ know its things (like in math formulas), some people might not be adverse to having an option to let LyX replace its own rendition of them by a true LaTeX one as long as one is not actively editing the formula. preview-latex uses LaTeX for determining and extracting the pieces of interest for previewing. This is done with the help of the preview.sty package that is part of preview-latex, but also separately available on CTAN. While most of the _determination_ of the previewable parts would probably already be done by LyX itself, the actual extraction (with the help of the preview environment provided by the style) could still be accomplished using that package. I would be glad to be of assistance if particular options or general advice would be necessary in order to generate a version suitable for working with LyX. The preview style already provides all of the necessary ingredients in order to turn out a single DVI file which, when processed by GhostScript, produces a set of graphic files with tight TeX bounding boxes (which has turned out to be one of the more challenging little details taking up quite more time than anticipated, since both vertical and horizontal material needs to be catered for, and any surrounding spacing should be removed). That alone will already provide a good and reasonably efficient path for an efficient _initial_ rendition of the previews for an entire document. But already there it would prove beneficial to incorporate a few of the details that have emerged desirable in the course of preview-latex development: parsing the PostScript file for its DSC comments, and using that information for generating those previews first that are currently displayed makes up for a lot of preview-latex's interactive response: the GhostScript pass is actually the slowest component of its operation, but the one which has about the least impact on interactive work since it first does the visible portions of its work. Of course, since preview-latex is GPLed software, you would be free to incorporate and read all of it that you want into LyX, anyhow. But also, of course, the source code sometimes is the result of some lessons learned, and the lessons itself are no longer visible. And also the set of those both willing to dig through bunches of Emacs Lisp, yet preferring to work on LyX rather than with Emacs, could probably be small. Implementing a way of making it easy for LyX users to let LaTeX itself cater for source buffer renditions of more obscure constructs would take a lot of pressure off LyX developers: they coould concentrate on making convenient _editing_ environments for LaTeX constructs (like the math editor), and relax some of the work that mostly focuses around making just native _display_ of features for which there are no particular advantageous editing modes or features surpassing the usual ERT editing to be expected. You might rightfully say that LyX already provides a fast interface to get page previews for the final document (by calling the existing previewer). But having those as pieces in a document makes quite an impressive change in look-and-feel, as well as saving the screen real estate necessary for a page-oriented preview. It has been my experience that a lot of people regard things like WhizzyTeX (an intricate package also under Emacs that provides very fast automatic refreshes during editing of a preview window while editing by a combination of a suitable DVI previewer, periodic format dumping and similar) or ActiveTeX (which uses a daemon approach for similar goals) with technical curiosity, but get intrigued much more by the in-source approach of previews that the preview-latex package provides. I think it likely you should find a similar interest for source buffer oriented display of previews among LyX users. For those of you that want to take a cursory look at what this may all be about, and that would like to get some more of an impression for considering whether incorporating similar functionality into LyX could be a worthwhile endeavor, the home page of it is available at <URL:http://preview-latex.sourceforge.net>. It gives a few screen shots and points to the project page. The preview style used for extracting the images is available separately at CTAN:macros/latex/contrib/supported/preview. Again, I apologize for the intrusion on this list, but hope that it might incite a few of you to look into a particular way of improving LyX in an area I personally would estimate to be well worth the work to be invested. I am not currently subscribed to the LyX developer's list, so it would be a courtesy if you included me in the recipient list of replies to this mail. Thank you, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
