emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carlos Pita <carlosjosepita@gmail.com>
To: Carlos Pita <carlosjosepita@gmail.com>,
	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: Tue, 12 Feb 2019 20:23:34 -0300	[thread overview]
Message-ID: <CAELgYheMx7iStVjm=8S44=ihAMOa9jULz3czwUBBZqdONb+QNQ@mail.gmail.com> (raw)
In-Reply-To: <87va1otypx.fsf@nicolasgoaziou.fr>

> `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't
> use in Org.

Mmm ok :).

I proposed it because it is easy to remember if you think you're
modifying a base action by S and also because it's easier to keep C
pressed (versus simply S-l or M-l).

So lets play with minus as a modifier, I like that idea.

(A) Here is a variation of my proposal:

[C- -] [C-u] [C-u] C-c C-x C-l

The modifier [C- -] means force preview.
The modifier [C-u] means section scope.
The modifier [C-u][C-u] means document scope.

So - means force, C-u means section, C-u C-u means document.

One advantage of this approach is backwards compatibility.

(B) Here is a variation of your proposal. In it - means clear (I find
this a good mnemonic since "minus removes stuff"):

- C-c C-x C-l :: Toggle preview on the fragment at point, raise an
    error outside a fragment
- C-u C-c C-x C-l :: *Preview* for current section
- C-- C-u C-c C-x C-l :: *Clear preview* from the current section
- C-u C-u C-c C-x C-l :: *Preview* the whole document
- C-- C-u C-u C-c C-x C-l :: *Clear preview* for the whole document

So - means clear, C-u means section, C-u C-u means document.

> This doesn't solve the overlapping between `C-c C-x C-l' and `C-u C-x
> C-l' either.

I know I mentioned this overlapping but that was the result of a
confusion of mine: at first I mistakenly thought the C-u modifiers
were there to force preview clearing. But I don't think the
section-scope overlapping between C-u C-c C-x C-l and C-c C-x C-l when
used outside a fragment is a such bad thing. The C-u modifiers can be
thought as setting "strict scopes" of operation while the vanilla
operation tries to be smart. The problem with this smartness is not
the overlapping per se but that the meaning of "toggle" is ill defined
when you have a mixed set of un/previewed fragments. Therefore,
although I'm ok with the section-scope overlapping, I agree that it
could be convenient to ban the toggling behavior altogether except for
single fragments, for which it's well defined. But backwards
compatibility is a balancing consideration.

I'm fine with both (A) and (B) above. (A) is backwards compatible and
(B) removes the somewhat surprising toggle behavior when outside a
fragment (which motivated this report).

Best regards
--
Carlos

  reply	other threads:[~2019-02-12 23:23 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 [this message]
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
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='CAELgYheMx7iStVjm=8S44=ihAMOa9jULz3czwUBBZqdONb+QNQ@mail.gmail.com' \
    --to=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).