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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

There are some interim conclusions for now.
I agree that the approach Org takes on remapping may be improved.
I will keep in mind to reach to emacs-devel about possibility to extend
built-in Emacs functionality if it is required to get rid of the Org
remappings.

>> 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.
...
>> 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?

Let me be clear here. Org syntax is fixed as much as possible. One
cannot just tell Org to ignore tables in Org buffers. However, users can
alter behavior of specific Org commands if they wish to. Using available
customization and other usual Elisp tools.

One would not expect, say, tex-mode behave correctly if the user
arbitrarily changes buffer syntax table. Similarly, tables are the core
part of Org syntax.

>> 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 |
>>  ...
>> 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.

We do not assume that users always expect specific behavior. That's wy
org-special-ctrl-o is customization. It's default value has been agreed
upon and has not been questioned by many. The current behavior is what
most of Org users expect. The default open-line behavior is not.
Otherwise, nobody would bother implementing org-open-line.

>> > 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.

Sorry, but I do not understand what you mean here, except that you are
dissatisfied with the existing implementation. AFAIU, you objected the
number of Org bindings. That many of them are not needed. I think my
reply was targeting your objection. I did not recognize any kind of
reference to implementation specifics.

Best,
Ihor