emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Carlos Pita <carlosjosepita@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Date: Wed, 13 Feb 2019 17:24:12 +0100	[thread overview]
Message-ID: <87r2cbsllf.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <CAELgYhdm_iPE1dFHiJkPhbVxC6u6Cb9Gm+6D376deALLzevFyQ@mail.gmail.com> (Carlos Pita's message of "Wed, 13 Feb 2019 12:10:20 -0300")

Carlos Pita <carlosjosepita@gmail.com> writes:

>> C-c C-x C-l: as you defined it
>> C-u C-c C-x C-l: preview document scope.
>> C-- (or C-0) C-c C-x C-l: as you defined C-u C-c C-x C-l.
>> C-- (or C-0) C-u C-c C-x C-l: unpreview document scope.
>
> Btw, I don't think that "preview the entire document" is such a rare
> use case. Consider that you've taken some quick notes using embedded
> latex (I need to do that often because my notes are almost exclusively
> about mathematical stuff and unicode is far from enough). Now you open
> the notes and you can i. export to pdf and preview using
> docview/pdf-tools/external pdf reader or, alternatively, ii. preview
> all fragments. I agree it's more usual to go to some section of
> interest and then preview it, but nevertheless full preview has its
> place.

I don't want to remove the possibility to preview a full document.
However, I prefer not binding it instead of binding it to an awfully
long key sequence. For example, if the function responsible for
previewing the full document is called `org-latex-preview-all', I'm sure
I can fire `M-x org-latex-preview-all RET' at least as fast as `C-0 C-u
C-c C-x C-l'. And if I need it often enough, I could bind it to, e.g.,
`C-c v' and be done with it.

> This proposal makes more cumbersome to unpreview the entire document,
> which I do think is barely necessary. But the other use cases are just
> one modifier away from the base use case (toggle fragment). The
> downside is that C-0 is assigned to an arguably less frequent use case
> than C-u, because of the mnemonic argument. As I said, I dislike
> swapping them, but if you prefer it that way I'm fine with it; in that
> case what will result is your proposal plus two C-0 or something
> variations for full document.

Even if C-0 or C-- are good mnemonics, C-u is, in addition to being
easier to type, the universal argument. For any given binding `B', one
can reasonably expect to find the most usual alternative action bound to
`C-u B'. Here, clearing previewing is much more useful than previewing
the whole document. As a user, I would rather expect it under `C-u C-c
C-x C-l`.

On the implementation side, all previewing functions are just a wrapper
away from `org-format-latex'. For example:

    (defun org--latex-preview-region (beg end)
      "Preview LaTeX fragments between BEG and END."
      (let ((file (buffer-file-name (buffer-base-buffer))))
        (org-format-latex
         (concat org-preview-latex-image-directory "org-ltximg")
         beg end
         ;; Emacs cannot overlay images from remote hosts.  Create
         ;; it in `temporary-file-directory' instead.
         (if (or (not file) (file-remote-p file))
    	 temporary-file-directory
           default-directory)
         'overlays nil 'forbuffer org-preview-latex-default-process)))

    (defun org-latex-preview-all (&optional arg)
      "Preview all LaTeX fragments throughout the document.
    When optional argument ARG is non-nil, remove previews instead."
      (if arg (org-remove-latex-fragment-image-overlays)
        (org--latex-preview-region (point-min) (point-max))))

We can then re-use `org--latex-preview-region' for previewing a section,
or only the LaTeX fragment at point.

  reply	other threads:[~2019-02-13 16:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 22:30 Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)] Carlos Pita
2019-02-11 22:33 ` Carlos Pita
2019-02-11 22:51 ` Carlos Pita
2019-02-11 23:15   ` Carlos Pita
2019-02-12 21:45     ` Nicolas Goaziou
2019-02-12 22:00       ` Carlos Pita
2019-02-12 22:43         ` Nicolas Goaziou
2019-02-12 23:23           ` Carlos Pita
2019-02-13 14:25             ` Nicolas Goaziou
2019-02-13 14:53               ` Carlos Pita
2019-02-13 15:10                 ` Carlos Pita
2019-02-13 16:24                   ` Nicolas Goaziou [this message]
2019-02-13 16:43                     ` Carlos Pita
2019-02-13 19:38                       ` Carlos Pita
2019-02-14  0:23                         ` Nicolas Goaziou
2019-02-14  1:31                           ` Carlos Pita
2019-02-14 14:52                             ` Nicolas Goaziou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r2cbsllf.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=carlosjosepita@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).