David Kastrup <[EMAIL PROTECTED]> writes: > Evil Boris <[EMAIL PROTECTED]> writes: > >> Aha! I had not realized (having not looked at the code, ever) that >> a preview is attached to the entire math mode string (a portion of >> the buffer, more precisely) and is kept around even if the string is >> modified. Would it be too difficult to simply catch modifications >> of the string and nuke the preview? I would find this a more >> logical behavior, as a user. > > It has the disadvantage that one of the most common ways of working > with previews is doing small edits and regenerating the preview.
I do not follow your reasoning, but I have been acting jet-lagged the last several days [and had other excuses before that ;-]. I just suggest leaving all (math) previews alone, unless and until the point enters it and some modifications are made. At this point I suggest the preview bitmap gets nuked. Perhaps a "men at work" or "computers at work" or "I would show you a preview if you only asked" icon should be displayed at the resulting math thing, so that it is clear it has been edited and the preview is not available. Of course, one can just treat it as it currently treats math material entered since the last preview was executed---ignores its existence until explicitly asked. >> I just was pointing out that in my opinion a natural behavior from a >> users point of view would be for the icon to disappear once one >> (C-d)s over the characters surrounding the place where it appears to >> be located in the buffer. > > I am not sure that crafting a consistent behavior on that premise > would be easy. I find it hard to understand how ANYTHING can behave sanely dynamically tracking arbitrary text modifications. However, most of the time font-lock seems to be able to track math formulas ok. So one could imagine (especially if one had no clue of the current architecture of preview) having font-lock install special text properties that might include all the desired behavior. Of course, I just looked a the things a bit closer and realized that overlays are used rather than text properties... > Well, if you decide against previews: the newer AUCTeX versions > support source specials quite well, and those make for a more > convenient coupling of previewer and editor. I have been using source specials and it works fine most of the time. Occasionally I need to use PDFLaTeX and I have not looked at what the options are there (I did see references to them). By the way (and off topic for this thread): How come the usual (non-source-special) way of invoking, say, XDvi, does not require a confirmation (C-c C-c RET is sufficient) but working with source specials turned on you need to confirm the command line? Is there an easy way to circumvent it? It bothers me slightly, as a user. > Still, I like the previews much better. They look better and are more attractive, especially to show off to someone who has never seen in-line previews :-) . I personally find them a bit odd, as I seem to have a lot less trouble reading the plain text in Emacs than the generated previews. I am referring to visual size, anti-aliased blur etc. Generated previews are just too thin and spidery to **read** (as opposed to just admire, not having to read complicated LaTeX syntax). I also dislike mouse and menus of any sort (have menubar, toolbar, scroll bar, and balloons [eh... forgot the right term again] usually turned off). So various mouse menues attached to formula previews are not spectacularly useful for me personally. --Boris _______________________________________________ bug-auctex mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-auctex
