> Comments on org-latex-preview.el (part 3).
>
>> (defun org-latex-preview (&optional mode)
>> ...
>> MODE can also be a org-element LaTeX environment or fragment, which
>> will be treated as \"point\"."
>
> Unless I miss something, it does not look like MODE=element is ever used
> anywhere in the code.
It's not used in the code, but is implemented in this function and
provided for elisp scripting purposes. Should it be removed?
>> (defun org-latex-preview--auto-aware-toggle (datum)
>
> I think these "auto" is a leftover from the previous naming of the
> mode. It would make sense to rename symbols according to new naming.
Renamed
org-latex-preview--auto-aware-toggle -> org-latex-preview--mode-aware-toggle
Also changed some comment references from "auto-mode" to
"org-latex-preview-mode".
>> (defun org-latex-preview--preview-region (processing-type &optional beg end)
>> "Produce image overlays of LaTeX math fragments between BEG and END.
>>
>> The LaTeX fragments are processed using PROCESSING-TYPE, a key of
>> `org-latex-preview-process-alist'.
>>
>> If `point' is currently on an LaTeX overlay, then no overlays
>> will be generated. Since in practice `org-latex-preview-clear-overlays'
>> should have been called immediately prior to this function, this
>> situation should not occur in practice and mainly acts as
>> protection against placing doubled up overlays."
>
> What do you mean that "this situation should not occur"?
> What about
>
> ('buffer
> (org-latex-preview--preview-region
> org-latex-preview-process-default (point-min) (point-max)))
>
> C-u C-u M-x org-latex-preview??
Huh, I think this is some mix of old and new logic that's slipped our
notice. Currently, C-u C-u M-x org-latex-preview does nothing if the
cursor is inside a LaTeX preview overlay.
I don't remember why this is the case. We don't get double LaTeX
preview overlays over a fragment because we handle this case in
--ensure-overlay.
I've changed it so that org-latex-preview--preview-region always
produces previews for fragments between BEG and END.
If there was some reason for imposing this limitation I guess we'll find
out in the future.
>> (when (memq processing-type '(dvipng dvisvgm imagemagick))
>> (overlay-recenter (or end (point-max))))
>
> This should be a FIXME. overlay-recenter does nothing since Emacs 29.
Added.
>> (end (- (org-element-property :end element)
>> (or (org-element-property :post-blank element) 0)
>> (if (eq (char-before (org-element-property :end element))
>> ?\n)
>> 1 0)))
>
> As I mentioned in another email, this is not the correct way to find
> position before blank in the case of fragments.
What is the correct way?
>> ;;;###autoload
>> (defun org-latex-preview-place (processing-type entries &optional
>> numbering-offsets latex-preamble)
>
> Does it have to be autoloaded?
Yes. This is the API entry point for Emacs-wide LaTeX previews (in any
major-mode). Anywhere in Emacs, you can run
(org-latex-preview-place 'dvisvgm ((beg1 end1) (beg2 end2) ...))
and place LaTeX previews over those regions, assuming beg1 to end1 is a
LaTeX fragment. No other requires or know-how will be necessary if this
is autoloaded.
Note that auto/live previews are not supported in other major-modes
because of our dependence on org-element. But basic previews (static
images over text) should just work. (Technically the LaTeX preamble
should be provided too as the fourth argument to this function for
Org-independent previews, but it should work without this argument as well)
You can try it now in your mail client:
Select this fragment: \( 2\pi + 3 \)
and eval-expression:
(org-latex-preview-place 'dvisvgm `((,(region-beginning) ,(region-end))))
In the future I want to add an API for full LaTeX preview support for
any major-mode, including live previews.
>> "Creat a hash table from numbered equations to their initial index.
> *Create
Fixed.
>> (defvar org-latex-preview--numbering-count-buffer nil)
> Docstring.
Added.
>> (with-current-buffer (org-element-property :buffer element)
>> (save-excursion
>> (goto-char (org-element-property :begin element))
>
> (org-with-point-at element ...) will do almost the same.
I'm not familiar with (org-with-point-at element) and hesitant to change
this now. Is it okay to leave it in its current form? You can make the
change before merging. I can also give you push access to my working
repo.
>> (goto-char (org-element-property :begin element))
>> (when (looking-at "\\\\begin{\\([^}]+\\)}")
>> (setq environment-name (match-string 1)))
>
> What if there are affiliated keywords?
Changed to
(goto-char (or (org-element-property :post-affiliated element)
(org-element-property :begin element)))
>> (insert-buffer-substring-no-properties
>> (org-element-property :buffer element)
>> (org-element-property :begin element) (org-element-property :end
>> element))
>> (goto-char (point-min))
>> (org-skip-whitespace)
>> ;; Remove the "outer" environment, so we can then
>> ;; easily delete all inner environments.
>> (delete-region (point-min) (+ (point) 8 (length environment-name))) ;
>> 8 = (length "\\begin{}")
>
> same question
Made a similar change.
>> ((org-element--cache-active-p)
>> (org-element-cache-map
>
> org-element-cache-map on main works even when cache is not active (by
> temporarily enabling it).
I take it to mean the org-element-map of this cond can be discarded.
I've made a tentative change, could you take a look at whether it makes
sense?
>> (cl-defun org-latex-preview-cache-images
>
> checkdoc warnings.
I don't see any checkdoc warnings for this function. (Maybe I fixed
it in an earlier commit?)
>> (elements
>> (org-element-map parse-tree
>> '(latex-fragment latex-environment)
>> #'identity export-info))
>> (entries-and-numbering
>> (org-latex-preview--construct-entries
>> elements t parse-tree))
>
> This implies that current buffer is the origin of the PARSE-TREE. Is it
> always the case?
org-latex-preview-cache-images is meant to be used by exporters for
generating LaTeX preview images. In that context, I think this is the case?
If you think a more robust alternative is required, please let me know
what change to make.
>> (cl-defun org-latex-preview--create-image-async
>> (processing-type fragments-info &key latex-processor latex-preamble
>> appearance-options place-preview-p)
>> "Preview PREVIEW-STRINGS asynchronously with method PROCESSING-TYPE.
>
> What is PREVIEW-STRINGS?
Should be FRAGMENTS-INFO, fixed.
>> It is worth noting the FRAGMENTS-INFO plists will be modified
>> during processing to hold more information on the fragments.
>
> +It is worth noting the+ (it is redundant)
Fixed.
>> When provided, LATEX-PREAMBLE overrides the default LaTeX preamble.
>
>> (processing-info
>> (nconc (list :latex-processor latex-processor
>> :latex-header latex-preamble)
>> (alist-get processing-type org-latex-preview-process-alist)))
>
> Maybe I am missing something, if latex-preamble=nil, will it simply
> shadow :latex-header from the process-alist? Then it implies that
> :latex-header in process-alist is ignored.
I modified it to
(processing-info
(nconc (list :latex-processor latex-processor)
(and latex-preamble (list :latex-header latex-preamble))
(alist-get processing-type org-latex-preview-process-alist)))
Should org-latex-preview-process-alist have a :latex-header field? I'm
not sure what its purpose is.
>> ((eq cache-location 'live)
>> org-latex-preview-live--cache-dir)
>
> I think I got confused by this in the past.
> 'live looks like something users can set for org-latex-preview-cache,
> but it is actually internal. Maybe use some more telling symbol name for this.
Explained in previous email.
>> (and (eq exit-code 1)
>> (with-current-buffer
>> (save-excursion
>> (goto-char (point-min))
>> (search-forward ": No such file or directory"
>> nil t))))
>
> with-current-buffer seems to be not intentional here.
Should be (with-current-buffer <process-buffer> ...)
Fixed.
>> (if (pcase (plist-get extended-info :processor)
>> ('dvisvgm (eq exit-code 252)) ; Input file does not exist.
>> ('dvipng ; Same check, just a bit more involved.
>> (and (eq exit-code 1)
>> (with-current-buffer
>> (save-excursion
>> (goto-char (point-min))
>> (search-forward ": No such file or directory"
>> nil t))))))
>> (propertize org-latex-preview--latex-log 'face 'warning)
>> (propertize org-latex-preview--image-log 'face 'warning))
>
> More generally, why do you need to guess the buffer here and do not use
> _buf instead?
I am now using _buf as the process buffer to search in for the dvipng
branch. But the problem that this is trying to solve is different: when
the image-extract-async task fails, we don't know if it failed because
dvipng failed to convert the dvi file to images, or because the dvi file
itself was not generated. If the dvi file itself was not generated, the user
should look in org-latex-preview--latex-log, else in
org-latex-preview--image-log. This is what the if statement above is
determining.
>> (defun org-latex-preview--create-tex-file (processing-info fragments
>> appearance-options)
>> "Create a LaTeX file based on PROCESSING-INFO and FRAGMENTS.
>
> APPEARANCE-OPTIONS undocumented in the docstring.
Fixed in an earlier commit.
Karthik
