From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id yIBYBDs+Al/kLgAA0tVLHw (envelope-from ) for ; Sun, 05 Jul 2020 20:55:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id EA0uADs+Al9OHwAAbx9fmQ (envelope-from ) for ; Sun, 05 Jul 2020 20:55:23 +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 57EAB9403C6 for ; Sun, 5 Jul 2020 20:55:22 +0000 (UTC) Received: from localhost ([::1]:33154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsBfT-0000I3-M9 for larch@yhetil.org; Sun, 05 Jul 2020 16:55:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51020) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsBaD-0001PB-J1 for emacs-orgmode@gnu.org; Sun, 05 Jul 2020 16:49:53 -0400 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]:37149) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jsBaB-00010I-G3 for emacs-orgmode@gnu.org; Sun, 05 Jul 2020 16:49:53 -0400 Received: by mail-qk1-x744.google.com with SMTP id k18so33125116qke.4 for ; Sun, 05 Jul 2020 13:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:references:user-agent:from:to:cc:subject:in-reply-to :message-id:date:mime-version:content-transfer-encoding; bh=gu20kMR84V8gMMc7J3ol0RvXNaL1GplXhqg1YWMPM1s=; b=m+nS0AeB7dBBjmOpkiw6VG25jGEuPo1cU/zhcLN2XHNscxTucRXcr+uO+XW3m+o4ym bGRsBJtYbNtiohidbcjN3P93xqYh8+/NSMtgh8lAZ/BYkGwkyL+Mzc01AXJ1Og1iwQt4 4ufoIOVPnUPtj+q9q0MI07JNoNBehCEeznIW4jTn+ySrhBvZUSll8nLz5kpec243YMvS dk5c4x0fPNWG844jyhKXaZ2gtb7qUHNhBLTRgG8vziSufjrNNu39AVdy9cdPD5ZGbINw m26eTAjQFe5mZ931IDQXrciiRFh3xIccQSsiRgf82/DS/lso5XSpah+t9KpiaC5yaM0w pZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version:content-transfer-encoding; bh=gu20kMR84V8gMMc7J3ol0RvXNaL1GplXhqg1YWMPM1s=; b=l4B+qbKttVtFZH47+26mIQCHCWRTUQ6If+lZw7uKzY3bODedj1zju7RO5P68uzqzAW 1rCFbM+0nVSGNIMsalIQ94PCqqzP3dS2tF3d4PoSP94jTHmjf9meKMyJHaKE5og3OHeE tQZ0uN8F8YA1puD8gHDFh/U0vzSj7iAWGG0XEs+0rOWV5z6ECpsQdGGOPDxY8jte2YvI C3YCpFmWVJtpdtN2ctP0j8d4AU7q7Ugg2a8JzgNio0xYbpoLLzNyS3eG7FJn+sP7+I00 kssuYDLJ9dPWjrmVhtxAQywfRlxqNqTQslSwqoZTO/EynBYiJIxF7SOj3Z5NK5hciUG5 0F1A== X-Gm-Message-State: AOAM532ROtSrD2rbwASivpIJXIshvLPtUTlMDCyQFer12RuBm3C++hTY B23ra7++BLieT7JVzIbFGt9wDdTEA5U= X-Google-Smtp-Source: ABdhPJwrx4b8NCdpxThQRWaNvzoejpbjJodlnQpVPs38OtWzQaShq1ySpdX0C3inv8WoBKOPxAZAEA== X-Received: by 2002:a37:ec7:: with SMTP id 190mr43249726qko.49.1593982189480; Sun, 05 Jul 2020 13:49:49 -0700 (PDT) Received: from gusbrs-laptop ([193.37.252.170]) by smtp.gmail.com with ESMTPSA id k194sm16430389qke.100.2020.07.05.13.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jul 2020 13:49:48 -0700 (PDT) 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> User-agent: mu4e 1.4.10; emacs 27.0.91 From: Gustavo Barros To: Nicolas Goaziou Subject: Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region In-reply-to: <87r1tq44ms.fsf@nicolasgoaziou.fr> Message-ID: <87o8ot4rh3.fsf@gmail.com> Date: Sun, 05 Jul 2020 17:49:44 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::744; envelope-from=gusbrs.2016@gmail.com; helo=mail-qk1-x744.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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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: , Cc: emacs-orgmode@gnu.org, Shankar Rao Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=m+nS0AeB; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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.09 X-TUID: enqb/2Y1d0vB Hi Nicolas, Hi All, On Sun, 05 Jul 2020 at 07:50, Nicolas Goaziou =20 wrote: > 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=20 > 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=20 > vein > as `org-fragtog` for LaTeX fragments. [...] > 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 don't think I have anything to add to the previous discussion on this=20 matter, and I know you took it into consideration. Also, I'm well aware=20 that sometimes a user interested in a feature lacks a more general=20 perspective a maintainer has. So I take your position here stems from=20 one such general design choices, and I understand and respect it. > 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=20 > 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=20 > 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-_'),=20 > and > so on. > > Note there, even though I polished it, there are probably some=20 > glitches > left, but it works well enough to give an idea. Tests are missing,=20 > too. > > Please evaluate the following code to try it. This is really, really nice. Certainly a major improvement in the way=20 `org-emphasize' works. I specially like you've chosen to make it act on=20 the element around point, that you added the possibility of increasing=20 this scope with repetition, and that you made the functions commands we=20 can bind. If I may, I'd like to add comments and report tests, for your=20 consideration, in the spirit of trying to help you polish the approach. One low hanging fruit, which you probably have already considered, is to=20 use a transient keymap to ease the repetition of the emphasis commands.=20 So that we could type `M-o * * * *' to emphasize four words, instead of=20 `M-o * M-o * M-o * M-o *'. Even better if in this keymap we could call=20 a command, bound e.g. to `-', to go back one step in case we have gone=20 too far in the repetition. This is interesting in itself, but specially=20 so given a number of the markers are shift-keys, which means the first=20 and the second part of the bindings use different modifiers, making the=20 repetition quite "athletic" (I suppose we could use "M-O", but still). A second thing is regarding the removal of the markers. I think there=20 is space to simplify this further and make it even more convenient. As=20 things are, we have six different bindings to remove an emphasis marker=20 around point. Of course, when adding emphasis, we have to specify which=20 one we want, but when removing it, the markers are already there and we=20 know what is the emphasis around point, and can go with a single=20 command, e.g. `org-remove-emphasis', and a single binding, e.g. `M-o=20 r/M-r', without the cognitive load of having to identify visually which=20 is the marker, to call the correct command to remove it. The only case=20 not covered by this would be if we have nested emphasis of different=20 types and want to remove the outer one. I'd say this is rare enough to=20 leave uncovered in exchange for the simplification of 6 to 1 commands=20 for emphasis removal. True, this seventh command could just be added,=20 and leave the current six as they are, but I do have a suggestion for=20 another use of the prefix, which see. (Perhaps an argument similar to=20 the one being made here for removal could be made for extending=20 emphasis, but I'm not sure if with the same relevance). Still regarding emphasis removal, I see two things one might want when=20 "removing" emphasis: one is to remove the whole emphasis around point,=20 the other is to remove part of an existing emphasized region, doing the=20 analogous of what your six emphasis commands do, but removing emphasis=20 one word at a time. If this distinction is deemed useful and worth=20 implementing, how about `org-remove-emphasis' with no prefix doing the=20 first, and with prefix doing the second? A third thing I think is worth considering is the direction of=20 extension, given that `org-emphasize' also works by extending an=20 existing emphasized region. Two things here: should one be able to=20 control the direction the expansion occurs? what should be the=20 preferred (or only) expansion direction? I'd say the first one would be=20 really nice, and I'd suggest using the prefix to the six emphasis=20 commands to achieve it ("prefix changes the default direction"). As to=20 the second, I'd go for preferring a backwards expansion, rather than a=20 forwards one. My reasoning here is that one would be adding emphasis=20 either while skimming/navigating through an existing document, in which=20 case one has more freedom in point placement, or when one is typing, in=20 which case moving point implies that we must get back to where we were=20 before continuing typing. So for this "while typing" situation a=20 backward expansion would be much more useful, while for the case of=20 "adding emphasis to existing text" the direction would be less=20 important. I take that's the reason `flyspell' has=20 `flyspell-auto-correct-previous-word' while it does not have a "next"=20 equivalent, and why `flyspell-correct' (the package) defaults to=20 correcting the previous misspelling. A fourth issue is point placement after the emphasis is added.=20 `org-emphasis' takes a stance here and places point within the emphasis.=20 I do agree with this option, but it is still true that sometimes, one=20 might want or need otherwise. This, of course, gets more interesting=20 when `org-hide-emphasis-markers' is t. And I actually think this issue=20 is still more general. One thing is to "add emphasis markers to=20 existing text", another is "adding text around existing emphasis=20 markers". The first one is superbly dealt with by this implementation=20 of `org-emphasize', the second one, as far as I can see, not equally so. Finally, as I took it for a spin, I might as well report some cases=20 which called my attention. I know you said this isn't ready yet, but I=20 hope it is still useful. In the examples, '|' represents point, and '=C2= =B7'=20 space. 1) When point is at the right-edge of a word, the emphasis command will=20 either emphasize the following word, if there is one before eol, or=20 error with "Nothing to emphasize in the region" even though there is no=20 active region. If there is only whitespace between point and eol the=20 emphasis command will issue the same error and move point to eol.=20 Illustrations: Starting from: #+begin_src org foo|=C2=B7bar #+end_src `M-o *' results in: #+begin_src org foo=C2=B7*|bar* #+end_src (note point has moved) Starting from: #+begin_src org foo=C2=B7bar| #+end_src `M-o *' errors with "Nothing to emphasize in the region". Starting from: #+begin_src org foo=C2=B7bar|=C2=B7=C2=B7=C2=B7 #+end_src `M-o *' errors with "Nothing to emphasize in the region" and moves point=20 to: #+begin_src org foo=C2=B7bar=C2=B7=C2=B7=C2=B7| #+end_src I suggest it would make sense, when at a word right boundary, to=20 emphasize the immediately preceding word rather than the next one.=20 Though this is probably somewhat a matter of preference, I'd argue it is=20 more intuitive. On the other hand, the last case, where the command=20 issues an error, does not apply emphasis and moves point, is clearly=20 unexpected behavior (it should at least not move point). 2) When point is within whitespace, with no "word" at point, it still=20 emphasizes the next word, if there is one. Illustration: Starting from: #+begin_src org foo=C2=B7|=C2=B7bar #+end_src `M-o *' results in: #+begin_src org foo=C2=B7=C2=B7*|bar* #+end_src (note point has moved) I would expect to get instead: #+begin_src org foo=C2=B7*|*=C2=B7bar #+end_src Starting from an empty line (or a "whitespace only" line): #+begin_src org | #+end_src We get error "Cannot emphasize contents here". But why not? #+begin_src org *|* #+end_src And be able to insert some content "to be bold". Indeed, if the right boundary logic above is used, and this within=20 whitespace one is also used, then point never needs to move when=20 applying emphasis "around point", which seems sensible to me. (I=20 haven't given proper thought on what to do with point/region when region=20 is active though.) Also, as far as I can tell, it would also never fall=20 back to "Nothing to emphasize in the region", which indeed is somewhat=20 strange when no region is active. The general idea is, if no "minimal=20 area around region or point" can be identified, place the markers around=20 point, instead of returning error. That said, I reiterate I really consider this revamping of=20 `org-emphasize' a major improvement, and a very welcome one. And I=20 thank you very much for that. My comments here are just offered for=20 your consideration and use as you see fit, in the hope they might be=20 useful. And I'm looking forward to see this reach distribution. Best, Gustavo.