From: Shankar Rao <shankar.rao@gmail.com>
To: Shankar Rao <shankar.rao@gmail.com>,
Gustavo Barros <gusbrs.2016@gmail.com>,
emacs-orgmode@gnu.org
Subject: Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Date: Tue, 7 Jul 2020 17:57:19 +0200 [thread overview]
Message-ID: <CAGEgU=gqyjHKG56+ETxPLVfU7w_T8kvKzRf55WHWm2g_hPY8Dg@mail.gmail.com> (raw)
In-Reply-To: <87r1tq44ms.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 5898 bytes --]
Thank you for your hard work on this. It's definitely easier to compare two
concrete blocks of code rather than abstract ideas.
> I agree with you that my solution is somewhat intrusive. Ideally, I would
> > have preferred that my solution could leverage advice functions or some
> Org
> > hook, so that I wouldn't have to modify org.el, but it doesn't seem like
> > there is a straightforward way to do that. The modification of
> > `post-command-hook', similar to one used for `prettify-symbols-mode',
> only
> > occurs if `org-auto-emphasis-mode' is active
>
> The problem is not your implementation, really. It's just that I don't
> think it should be the _built-in_ way to solve emphasis management. IOW,
> we shouldn't need to activate a minor mode to make that management
> tolerable in the first place.
>
> However, I agree that it makes senses as an extension, in the same vein
> as `org-fragtog` for LaTeX fragments.
>
That's a fair point. As I said, I modified `org-do-emphasis-faces' in
org.el only because I couldn't find a less intrusive way of achieving the
functionality I was looking for. Is there a way to make
`org-auto-emphasis-mode' an extension that leaves org.el unmodified?
> > So in your system, in order to interact with emphasis markers, the user
> > would have to learn two different commands? That doesn't seem to be in
> line
> > with the dwim philosophy used in modern emacs packages.
>
> Two different commands? Bah! The change I suggest introduces 7 new
> commands and 12 new bindings! :)
>
> Yet, I claim it is still (somewhat) intuitive.
>
I agree that your change is reasonably intuitive. I find it quite elegant
that you appropriated the M-o binding (which by default runs the
`facemenu-set-*' commands) in orgmode, and that the modifier keys
(*,/,_,~,=,+) map to text emphasis markers. But while I find your change
easy to understand, I find it a bit unwieldy to use. I discuss this further
below.
> > In my opinion, one of the strengths of Org is that the interface is
> > multimodal. One can (in principle) edit documents in much the same way as
> > word processors and rich text editors. However since everything
> underneath
> > is implemented with just text, one can also directly access and
> manipulate
> > this text. The ability to switch between these two modalities is
> extremely
> > powerful and is what sets Org apart from other document editing
> > systems.
>
> You can always toggle `visible-mode' for that.
>
> But, really, I think an option like `org-hide-emphasis-markers' is
> a one-off toggle. Having to, in a way, switch regularly between two
> values is sub-optimal.
>
I completely agree that toggling on and off *all* emphasis markers is
suboptimal. In fact, before I developed this `org-auto-emphasis-mode', my
previous solution was to toggle the emphasis marker at point. Please refer
to this reddit post (
https://www.reddit.com/r/orgmode/comments/grh423/is_it_possible_to_make_orghideemphasismarkers_and/).
Coincidentally, I bound this function to M-o as well.
> Here it is.
>
> The main command is `org-emphasis'. It emphasizes the minimal possible
> area around point, or region. If there's already an emphasis object of
> the desired type around point or region, it extends it forward instead.
> With a prefix argument, it removes the emphasis.
>
> Interactively, the command asks for the type of emphasis to use, but
> I suggest to use dedicated commands instead. Thus, I added a key-binding
> for each of the six emphasis types. For example, for bold, use
>
> `M-o *' or `M-o M-*'
>
> There are equivalent commands for underline (`M-o _` or `M-o M-_'), and
> so on.
>
I tested out your commands and I find your `org-emphasis' to indeed be an
improvement over `org-emphasize'. Since the two commands are so similar, I
would recommend refining this and having it be a replacement for
`org-emphasize'. Here are my comments.
- I like that, in the absence of a region, `org-emphasis' emphasizes the
area around the point. This improves upon `org-emphasize', which inserts a
pair of emphasis markers at point.
- I find the behavior of repeated invocations to expand the area of
emphasis to be useful, but strange. I don't know of any other commands that
expand the area of some property with repeated invocations (except for
`expand-region', which is designed to do that explicitly). To me, it would
be both more straightforward to expand or contract the region (e.g., using
C-right or C-left) and then apply emphasis using M-o.
- I find it unwieldy that to unemphasize, you must use both the prefix
command and remember which marker you chose (e.g. to unbold you must do C-u
M-o *). Prefix commands are usually reserved for special modifications of
commands, and I think unemphasizing is sufficiently common that it
shouldn't be relegated to this space. In word processors like MS Word,
unemphasizing is implemented by repeatedly invoking the keyboard command
(e.g, C-b on plain text bolds it and C-b on bolded text unbolds it). Since
Org doesn't properly render nested emphasis markers, I believe that it
would be more intuitive if unemphasizing was implemented via repeated
invocation (i.e., M-o * on already bolded text) toggle tht emphasis.
- I like Gustavo's idea of using a transient keymap to implement expansion.
In fact, if you implemented it that way, you could use the transient keymap
for expanding the area of emphasis and reserve repeated invocation for
toggling the emphasis
- I also agree with Gustavo that there should be a single command to remove
all emphasis at point/region. Similar to how `org-emphasize' does it, I
suggest that you could use M-o SPC for this.
- I believe that these adding/removing emphasis should not move the point.
I'm glad that I've been able to contribute to this discussion, and I hope
we can reach some consensus for improving emphasis editing in Org!
Shankar
[-- Attachment #2: Type: text/html, Size: 7500 bytes --]
next prev parent reply other threads:[~2020-07-07 16:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 14:14 [PATCH] Add mode for automatically unhiding emphasis markers in the current region Shankar Rao
2020-06-01 15:33 ` Shankar Rao
2020-06-22 5:40 ` Kyle Meyer
2020-06-22 11:25 ` Gustavo Barros
2020-06-23 0:07 ` Kyle Meyer
2020-06-24 12:53 ` Shankar Rao
2020-06-24 13:49 ` Gustavo Barros
2020-06-24 15:46 ` Nicolas Goaziou
2020-06-24 16:34 ` Shankar Rao
2020-06-26 7:32 ` Nicolas Goaziou
2020-07-03 15:19 ` Shankar Rao
2020-07-05 10:50 ` Nicolas Goaziou
2020-07-05 20:49 ` Gustavo Barros
2020-07-06 14:01 ` Gustavo Barros
2020-07-07 15:57 ` Shankar Rao [this message]
2020-06-24 17:27 ` Gustavo Barros
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='CAGEgU=gqyjHKG56+ETxPLVfU7w_T8kvKzRf55WHWm2g_hPY8Dg@mail.gmail.com' \
--to=shankar.rao@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=gusbrs.2016@gmail.com \
/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).