From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id yET1Km+cBF+hLAAA0tVLHw (envelope-from ) for ; Tue, 07 Jul 2020 16:01:51 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id qAThJm+cBF+qRgAAB5/wlQ (envelope-from ) for ; Tue, 07 Jul 2020 16:01:51 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BCFF0940D58 for ; Tue, 7 Jul 2020 16:01:50 +0000 (UTC) Received: from localhost ([::1]:52444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsq2X-0000qs-3K for larch@yhetil.org; Tue, 07 Jul 2020 12:01:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jspyS-0006JF-4j for emacs-orgmode@gnu.org; Tue, 07 Jul 2020 11:57:36 -0400 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]:34642) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jspyP-0004Xb-5J for emacs-orgmode@gnu.org; Tue, 07 Jul 2020 11:57:35 -0400 Received: by mail-vk1-xa2f.google.com with SMTP id m21so8228554vkp.1 for ; Tue, 07 Jul 2020 08:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1P8xMLlbtoVWiKYrx1f61J7hQ3odl1fX9Q0P49SqRbk=; b=s6fUPt91Xi+S4jUy0WSNrih1t5pSbMpGFpg8u+2x3ryQYETs/SUzrbVpAlTQ9H3RI1 MhaOfLdxA1mW9J4TGlcJC8kg/++raYofOuZAHgiwZvp81ZeLDij6FPgautioOXGFjeDs VGR03HZQCxM9LHsUGwaTw8jBZ01zt3dO6eiqgCMmH+qZ7WvKvQxuorYQvUVsVzIKS0IJ AwBexsRNDbhB8NRRdDRlh3gloJ10UCwmxfdWQEPu8eU7njQipN8RnRiwRCINdrtfrBE2 NiDL0eXBzDuhyQi0SxkHgLm/JkzYIt7PqYoneXtLJHG63fdXOduS+S86gCaSCcnC3Oce R54g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1P8xMLlbtoVWiKYrx1f61J7hQ3odl1fX9Q0P49SqRbk=; b=CtfCnncpFM66ZKuGt7d7SKK+g++wfrDJhqPpG8nAqV4n+ENCPXMtUr2oeajKyvvObO vkZpALVsEH9P+JAhZtqtvX9RvbTGsepNZxY2AisFq5cfyOVZn1pAvTleZYqKb0feaOUM wZ1Grdr2bkuWq9/6tER6R4UT8C0pjgGKpwdfvkjj1+c5SA4sbDn6kf7yUA8ZqpOJahm4 B7NEuIgmScjStA0ly6hHhcyWTyOhm+p4ug9SXiTF52MCCDKYdYhQqmK1AwnhqMzYrDLi boqPxaB+hWy4/4BgIf+VxEGP06sGU2WgbfSUkK0uFXUSOLDuN4UL2W21eggLzUt49+jM R4HQ== X-Gm-Message-State: AOAM5322L/E6gfOnP7UjFPxz8Q38uDKqFmXgLXTPvdHeRVvT3H6k1Gi0 11Nu+7+ipyuItyzkoMcS/MGEsVmrcMg5OBw/rZw= X-Google-Smtp-Source: ABdhPJxtRFFY1KDoo3E4z/3yfglHQ0SMqyB1jO3pyoDR4e5/khHdO69WMPXDY+r4rRSC6ZE5w4amFyuXYf/9jCuq6G0= X-Received: by 2002:a1f:930f:: with SMTP id v15mr37618407vkd.63.1594137451110; Tue, 07 Jul 2020 08:57:31 -0700 (PDT) MIME-Version: 1.0 References: <877dvzwtdy.fsf@kyleam.com> <87d05rcpgh.fsf@gmail.com> <871rm6wson.fsf@kyleam.com> <87mu4svaj9.fsf@gmail.com> <87lfkctqkl.fsf@nicolasgoaziou.fr> <877dvus2mx.fsf@nicolasgoaziou.fr> <87r1tq44ms.fsf@nicolasgoaziou.fr> In-Reply-To: <87r1tq44ms.fsf@nicolasgoaziou.fr> From: Shankar Rao Date: Tue, 7 Jul 2020 17:57:19 +0200 Message-ID: Subject: Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region To: Shankar Rao , Gustavo Barros , emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000007f29af05a9dc0ccf" Received-SPF: pass client-ip=2607:f8b0:4864:20::a2f; envelope-from=shankar.rao@gmail.com; helo=mail-vk1-xa2f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=s6fUPt91; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.71 X-TUID: Jn5NushagHG5 --0000000000007f29af05a9dc0ccf Content-Type: text/plain; charset="UTF-8" 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 --0000000000007f29af05a9dc0ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your hard work on this. It's defini= tely easier to compare two concrete blocks of code rather than abstract ide= as.

> I agree with you that my solution is somewhat intrusive. Ideally, I wo= uld
> have preferred that my solution could leverage advice functions or som= e 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-mod= e', only
> occurs if `org-auto-emphasis-mode' is active

The problem is not your implementation, really. It's just that I don= 9;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.

T= hat's a fair point. As I said, I modified `org-do-emphasis-faces' i= n 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-emph= asis-mode' an extension that leaves org.el unmodified?
= =C2=A0
> So in your system, in order to interact with emphasis markers, the use= r
> would have to learn two different commands? That doesn't seem to b= e 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 e= legant that you appropriated the M-o binding (which by default runs the `fa= cemenu-set-*' commands) in orgmode, and that the modifier keys (*,/,_,~= ,=3D,+) 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.<= br>
=C2=A0
> 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 undern= eath
> is implemented with just text, one can also directly access and manipu= late
> this text. The ability to switch between these two modalities is extre= mely
> 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 agr= ee 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 pos= t (https://www.reddi= t.com/r/orgmode/comments/grh423/is_it_possible_to_make_orghideemphasismarke= rs_and/). Coincidentally, I bound this function to M-o as well.
=C2=A0
Here it is.

The main command is `org-emphasis'. It emphasizes the minimal possible<= br> area around point, or region. If there's already an emphasis object of<= br> 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

=C2=A0 =C2=A0 =C2=A0 `M-o *'=C2=A0 =C2=A0 or=C2=A0 =C2=A0 `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= 9;. Since the two commands are so similar, I would recommend refining this = and having it be a replacement for `org-emphasize'. Here are my comment= s.

- I like that, in the absence of a region, `org-emphasis' emphasizes t= he area around the point. This improves upon `org-emphasize', which ins= erts 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 exp= and 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-r= ight or C-left) and then apply emphasis using M-o.
- I find it unwieldy that to unemphasize, you must use both the pre= fix 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 shou= ldn't be relegated to this space. In word processors like MS Word, unem= phasizing 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 do= esn'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 rep= eated invocation for toggling the emphasis
- I also agree with Gustavo that there should be a single command to r= emove 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 th= e point.

I'm glad that I've been able to contribute to this discussion, a= nd I hope we can reach some consensus for improving emphasis editing in Org= !

Shan= kar

--0000000000007f29af05a9dc0ccf--