From: Shankar Rao <email@example.com> To: Shankar Rao <firstname.lastname@example.org>, Gustavo Barros <email@example.com>, firstname.lastname@example.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: <email@example.com> [-- 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 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' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region' \ /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
Code repositories for project(s) associated with this 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).