emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org, Shankar Rao <shankar.rao@gmail.com>
Subject: Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Date: Wed, 24 Jun 2020 14:27:49 -0300	[thread overview]
Message-ID: <87a70sml0q.fsf@gmail.com> (raw)
In-Reply-To: <87lfkctqkl.fsf@nicolasgoaziou.fr>

Hi Nicolas,

On Wed, 24 Jun 2020 at 12:46, Nicolas Goaziou <mail@nicolasgoaziou.fr> 
wrote:

> Hello,
>
> Gustavo Barros <gusbrs.2016@gmail.com> writes:
>
>> You have a good point here.  When I made the suggestion I was naively
>> thinking the featured could be plugged/hooked somewhere in Org, when
>> fontification is done.  But that's not really true, as the feature
>> requires being run every time the point moves too.  So, as far as
>> I can tell, it seems using post-command-hook is unavoidable, and if
>> so, you are right in not wanting to add some load to it for everyone,
>> regardless of whether they want this feature or not.  You and Kyle
>> have me convinced here.
>
> Sorry for being late to the party, but, IMO, this doesn't sound like
> a right approach to the problem of invisible emphasis markers. A user
> choosing to hide emphasis markers should not need to—or even be given
> the opportunity to—display them in order to edit them efficiently.
>

I do agree with what you said, as you have stated it: It'd be good if 
the user of `org-hide-emphasis-markers' didn't need to display the 
invisible character to edit them efficiently.  And it is true that I 
argued in favor of this proposed patch giving the related editing 
inconveniences as a main point.  But the feature is the equivalent of 
`prettify-symbols-unprettify-at-point' for `org-hide-emphasis-markers' 
and it does have an appeal in itself, for the visual cue it offers, 
besides the editing improvement, which is a byproduct.  I like 
`org-hide-emphasis-markers', but if I was not "given the opportunity to 
display them" or if I could not edit them directly even if invisible, as 
a word processor does, I would probably not consider ever hiding them in 
the first place.

> I think we should upgrade `org-emphasize' command instead, so it 
> handles
> both marker visibility states in a DWIM, or in a word processor,
> fashion. Indeed, since emphasis markers of a given type cannot be 
> nested
> in Org, the WIM part is usually easy to guess, according to the 
> context,
> i.e., the syntax at point, and the region. I have some draft lying
> somewhere in that direction.
>
> WDYT?

I think that it would be great independently of the proposed patch. 
Indeed, that would be very useful including for users which set 
`org-hide-emphasis-markers' to nil.  On the other hand, even with a more 
capable dwim `org-empasize', I'm pretty sure many users will still add 
emphasis markers by directly typing them, even if occasionally, or they 
will delete them inadvertently if invisible, in which case, the proposed 
patch remains very useful for this reason too.

If I may, `TeX-font' in AUCTeX would be my dream `org-emphasize'.  Two 
things it does that `org-emphasize' doesn't (as far as I know of): i) 
when there is no region selected, and point is within a font macro, it 
operates on the imediate enclosing font macro, not requiring region 
selection, so that we can change the font macro by calling `TeX-font' 
with a prefix, or remove the font macro with "C-c C-f C-d"; ii) 
`LaTeX-font-list' is customizable, allowing for better key bindings; 
it's easier to type "b" than "*", "s" than "+" etc., anyway, it gives 
choice.

Again, just an user here, just offering a data point.  (And I was quoted 
;-).

Best,
Gustavo.


      parent reply	other threads:[~2020-06-24 17:28 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
2020-06-24 17:27               ` Gustavo Barros [this message]

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=87a70sml0q.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    --cc=shankar.rao@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).