Andre Poenitz <[EMAIL PROTECTED]> writes: > On Sun, May 12, 2002 at 04:59:09PM +0200, David Kastrup wrote: > > [...] In contrast, I believe LyX to have the necessary infrastructure for > > that kind of functionality. > > At least partially... I believe so, too. > > > [...] 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. > > Actually I have been playing with this idea after I've seen your > preview-LaTeX package in action. I am fairly sure that can be done > at least for mathed by using a mechanism similar to what we already > do there for macro editing [Macro with arguments change their > appearance to allow editing parameters when the cursor is "in" the > macro. Probably not the best piece of user-interaction, but it > "works"].
That's the point. preview-latex has an auto-reveal-mode where it automatically opens stuff you enter (the default is to cater previews just as one single big character). This can be turned on and off and made dependent on some condition. The setting I use personally is to auto-open stuff if you are moving into it with cursor-left-right, but to keep it as a single character-like entity for other movements. This is wildly inconsistent (word-left-right will not trigger it). It also makes the display jump spontaneously when you are moving into and out of those areas. But it "works", as in "becomes convenient". Your macro editing sounds just like that. > Additionally I'd probably allow "plain LaTeX" editing, too, to > accomodate people who'd like to use the "hard way" (or want to use > "unusual" stuff). > > So in the end we'd have four cases: > > (a) cursor outside an inset, inset rendered by LyX (as we do now) > (b) cursor outside an inset, inset rendered by LaTeX (your proposal) > (c) cursor inside an inset, inset rendered by LyX (as we do now) > (d) cursor inside an inset, inset rendered as plain LaTeX source. > > (a) and (c) is what we have right now, Actually, (d) is "Evil Red Text" IIRC, and so the code for it should mostly exist already. > (b) and (d) is what preview-LaTeX does right now. It is not automatic. You can toggle between (b) and (d) regardless of the cursor position (although auto-reveal automates that). Editing changes permanently to state (d), you have to manually request regeneration (easy) for this to generate a new (b) (adjacent changed areas are merged into a single LaTeX/DviPS/GhostScript run). At the current point of time, preview-latex is defensive in resource usage; you need an explicit request to let it start the background machinations. Part of the reason is that there are associated fixed costs with starting up LaTeX, DviPS and GhostScript, and one would want to group requests as much as possible. LaTeX startup time can be considerably reduced by dumping formats (the CVS version of preview-latex uses Carlisle's mylatex.ltx for that purpose). The ultimate goal would be to keep one pipe running. DviPS cannot really be made to fit into that scheme, one would probably want to ultimately replace it with a DVI to bitmap rendering daemon. GhostScript could probably be kept running efficiently across multiple DviPS runs if you did clever resource management (do not download already present fonts and other stuff etc). But that's all future stuff to think about. > Toggling between ( (a) and (b) ) and ( (c) and (d) ) could be done > by some hotkey, so "the whole is more than sum of the parts"... Yes. That's exactly the work principle behind this: preview-latex itself does appallingly little except delegating work. > > 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. > > I'd basically need a _fast_ way to get some rendered bitmap out of a > string like $a^2+b^2$. That's it. The "obvious" solution would be to > create some temp.tex, run LaTeX on it, convert the dvi. I don't know > how 'fast' this is, though. If you start with a pregenerated format, surprisingly so. But you want to have this work asynchronously: editing should not block actively while the rendered bitmaps trundle in. What made me start this project at all was Emacs-21' ability to directly place EPS files into its buffer. Within one week, I had code ready that would place display formulas in the buffer. Even before the first regular release, this approach had to be scrapped, and still is (the historic code is still in and you can enable it, but it probably has suffered bit rot by now). The problem was that Emacs rendered on-demand. Scroll to a page with 20 previews on them, and Emacs started 20 GhostScript processes and would block until most of them were finished placing their bitmaps right into the window. You could not really scroll once you had activated the package. That's not acceptable. So preview-latex calls up GhostScript itself, rendering the on-display previews with priority into PNGs, and finishes the other previews afterwards. Emacs still reads in those PNGs just on-demand, but this does not slow it down anything like before. And the stuff runs in background (well, pseudo-background. Emacs does not really multi-thread, but it has an event loop where it can react to output arriving from separate processes). This is quite important for its acceptance: does LyX offer some sort of multithreading or asynchronicity or the like? Even just a possibility to call some code when it happens to idle or look for input? > I suppose preview-latex can help here already, but I am not sure how > far it helps... You could use the PostScript startup (colour, resolution, bitmap sizes) and PostScript source positioning code (in order to change the order of processing so that one can generate the more urgent images first) it contains, and the LaTeX styles, and take a look at what gets written to the files during format generation and elsewhere in its LaTeX startup, but apart from that, most of the code is in Emacs Lisp, and would serve for little more than as an example. > > 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. > > You know, there is always some difference between "incorporatin > GPLed software" and "incorporating GPLed software with active help > of its author"... Actually, the license issue is probably pretty moot anyway since copyright covers the actual expressions of the idea, and those are currently mostly in ELisp. So I do not know how much of an actual help I will prove. But I have found that doing things right for my project requires good judgment which of the glue parts one does best with external programs, which one should code in PostScript, which in TeX, which in Lisp (in this case), and what existing tools and packages offer assistance. There are few people around with the necessary expertise in all of those areas. I am the only in the preview-latex team that can manage most of the core areas involved. The areas others work on involve Emacs, XEmacs, documentation, installation. I'll be glad to offer opinions and assistance where required on those matters. > Actually I did not expect /you/ to show up on this list with such an > offer of assistance. You are certainly welcome here ;-) I am just being selfish. I have decided I want to try my luck at making a living with TeX-based stuff. That means arrangements with the real world. Whatever I can do to make people buy into TeX/LaTeX, I'll do. This will mean that I will have to cater for operating systems and environments I would not prefer for personal work. When I am forced to use and offer them, I better make sure that I do all that is reasonable to ensure this will be as painless as it gets for me and prospective customers. And don't you believe I am not perfectly capable of stealing any good code that you may develop in the course of implementing some preview-LyX functionality. Just tying together the work of others is one of the main strengths of preview-latex. Since it is at its core still a single-person effort, not much more is possible. So what better way to fill in missing links than persuade others to do the work for their own purposes? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
