[Bug-AUCTeX] Re: preview oddity when "merging" inline formulas...

[Evil Boris]

David Kastrup <address@hidden> writes:

> Evil Boris <address@hidden> 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