[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39927: 12.2; preview-latex gs treatment off by one
From: |
Ikumi Keita |
Subject: |
bug#39927: 12.2; preview-latex gs treatment off by one |
Date: |
Thu, 12 Mar 2020 15:50:27 +0900 |
Hi Itaï,
>>>>> address@hidden writes:
> Whenever generating previews, I get error messages for essentially all
> preview images, such as:
> « Cannot find image file ‘.../_region_.prv/.../pr1-1.png’ »
> Then, one preview image (first one in document order, last one to be treated,
> if I understood things correctly) fails to load, just get a big blank square.
> Move the cursor a bit, and it loads as well. Particularly annoying if you
> are just refreshing a single preview image and it fails to load.
I often (always?) have simiar experiences. It seems that the attached
patch works as a workaround. It is just a workaround, not a solution
because it does not suppress errors like
Cannot find image file ‘.../_region_.prv/.../pr1-1.png’
in *Messages* buffer at all.
Another workaround is to type C-l after you get blank rectangle.
> My diagnosis : in parsing the GS output, preview-gs-transact just
> assumes that some prompts from GS mean that an image has been treated.
> I **guess** the introduction of -dDELAYBIND could have added an extra
> such prompt, so now it assumes the image is ready before it actually
> is. emacs complains it cannot be found. Then when adding the next
> image to its overlay, emacs realises that the previous image is there
> now, and loads it, so in the end, it is only the last image to be
> loaded that is missing, but error messages are displayed for all.
I'm not sure whether -dDELAYBIND is relevant or not, but my guess is
similar with you. This off-by-one behavior reminds me of a topic in
https://lists.gnu.org/archive/html/bug-auctex/2019-10/msg00015.html :
> Secondly, the file name on your command line is
> "bbb.prv/tmp821SQO/pr1-2.png" but the one in the error is
> "bbb.prv/tmp821SQO/pr1-1.png". So, clearly not the same file.
It seems that there is a discrepancy between the sequence numbers which
preview-latex expects and ghostscript actually produces. I.e.,
when preview-latex expects that gs has produced pr1-1.png, gs acutually
produced nothing, when preview-latex expects that gs has produced
pr1-2.png, gs acutually produced pr1-1.png, and so on.
Unfortunately I don't understand the core of preview-latex, so I cannot
solve this problem completely.
Regards,
Ikumi Keita
workaround
Description: workaround