[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add mode for automatically unhiding emphasis markers in the

From: Shankar Rao
Subject: Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Date: Tue, 7 Jul 2020 17:57:19 +0200

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]