Re: Convert README.org to plain text README while installing package

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: theophilusx@gmail.com,  acm@muc.de,  emacs-devel@gnu.org
> Date: Sun, 12 Jun 2022 16:40:31 +0800
> 
> > For a serious discussion of this example, I'd need more detail about
> > the aspects you mentioned above (it is not trivial to deduce them from
> > looking at the top levels of org-forward-paragraph).  Specifically:
> >
> >   . how does paragraph definition depend on context in Org, and what
> >     are the possible definitions in the existing contexts?
> >   . why don't paragraph-start and paragraph-separate fit Org, and can
> >     we come up with a small number of additional variables that would
> >     augment these two so that the built-in forward-paragraph could be
> >     extended to cover Org?
> 
> I do not want to start a serious discussion on this just yet as I do not
> plant to work on this specific area in near future, however I would like
> to answer some of your questions in order to provide some insight for
> Emacs developers.

Thanks, but if we are not going to continue this discussion until we
come to some conclusions, I see no reason to keep talking about it.  I
do understand better the difficulties now (thanks!), but I'm not yet
convinced that the existing solution is the best one.

> > My main concern is that forward-paragraph is used when editing the
> > purely textual parts of an Org document, and when used there, casual
> > users of Org will expect it to behave as the command behaves in plain
> > text.  Any deviation from the behavior of the built-in command will
> > confuse such users when they edit the plain-text parts, and should
> > therefore be avoided.
> 
> There is no difference between forward-paragraph and
> org-forward-paragraph on purely texture parts. The difference is only on
> the Org-specific constructs, where forward-paragraph would behave
> unexpectedly.

How does Org make sure that the different behavior doesn't happen
without the user's intent?  Isn't it possible that Org perceives
something as a sign of an "Org-specific construct" when the user
didn't mean that?  When that happens, what can the user do to avoid
the unintended (from that user's POV) Org-specific behavior?

These situations are where user control is necessary, especially for
casual, non-seasoned users of Org.

> >> <remap> <open-line>                org-open-line
> >> <remap> <move-beginning-of-line> org-beginning-of-line
> >> <remap> <move-end-of-line> org-end-of-line
> >
> > Each of these (and other examples you provided) should require a
> > separate serious discussion.  Let's take open-line as an example.  It
> > is basically the built-in open-line, unless org-special-ctrl-o is
> > non-nil.  A trivial extension of the built-in command could have
> > prevented the need to remap.  (And why does the support for tables in
> > org-open-line need to be turned on outside of orgtbl-mode?)
> 
> You misunderstand orgtbl-mode. orgtbl-mode is optional minor-mode
> provided for users who want to edit tables "like in Org mode", but in
> _other_ major modes. Inside Org mode, tables are always supported.

What if the user doesn't intend to use Org tables?  How can such a
user turn off this automatic support, which interprets some patterns
of buffer text as an indication of a table, and turns on the special
behavior reserved for Org tables?

> Also, org-special-ctrl-o is non-nil by default. Using built-in open-line
> on Org tables can produce incorrect formatting. For example, calling
> open-line on the following table
> 
> | this | is        | table |
> | with | <point> 2 | lines |
> 
> will produce
> 
> | this | is | table |
> | with | 
>  2 | lines |
> 
> while org-open-line will produce
> 
> | this | is | table |
> |      |    |       |
> | with |  2 | lines |
> 
> The default behavior is not satisfactory and somewhat unexpected.

You assume that users always expect what Org does in that case.  This
is not a given, if we want to make Org more attractive for editing
text that is "less Org-specific", so to speak, like README files, NEWS
files, etc.

> > No, I'm saying that, sadly, we have no real control on what the
> > developers of unbundled packages decide to do.  Thus, what you see
> > there is the evidence of our lack of control more than anything else.
> 
> I do not get your point here. I was referring to the markdown-mode and
> Auctex to illustrate the _need_ to have numerous key bindings in order
> to edit complex Org documents. It is not just something introduced into
> Org out of the blue. Other people solved similar problems and did not
> come up with significantly less key bindings. If you say that usual
> 40-50 major mode bindings are sufficient, I am not convinced.

I'm not arguing with the need, I'm arguing with the particular
implementation that caters to that need.