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: Fri, 17 Jun 2022 13:55:41 +0800
> 
> > So Org is _unlike_ TeX mode, in that the assumption that every
> > environment or markup are only used where their Org meaning is
> > intended -- that assumption is not necessarily true, while it is in
> > TeX.
> 
> I think we are mis-communicating.

Most probably, see below.

> >> Org tables are always preceded by ^[ \t]*|
> >
> > That's what I remembered, and that is exactly what bothers me in the
> > context of this discussion: seemingly innocent text sequences are
> > interpreted by Org in some very special way, and the user doesn't
> > always have good means to disable that interpretation when it is not
> > intended.
> 
> I do not think that Org will support major user changes in Org syntax
> any time soon or in future. At least, there is no intention to guarantee
> such support.
> 
> I am not sure why you consider using pre-defined markup constructs as
> "innocent". It is problematic in any kind of markup language, be it Org,
> markdown, texinfo, or anything else.

Neither of the other markup modes is being proposed for viewing and
editing documents that were not originally edited under those modes.
By contrast, there's a fraction of Emacs contributors and developers
who repeatedly suggest to use Org for documents that were not
originally written in Org.  A notable example (not the only one) is
recent discussions of turning on Org when visiting NEWS files.

If you think these ideas are problematic from the POV of Org
developers, please voice this opinion whenever such proposals are
brought up.  Those proposals, and in general the proposals to use Org
widely in unrelated contexts, is what I had in mind all the time in
this discussion.  Perhaps now you can better understand some of my
comments and responses.

For example, what is your opinion of using Org markup in email
messages?  There are a lot of examples of that, both here and on the
bug tracker.  People use Org markup and Org-style code blocks quite a
lot, and reading that is always jarring to me.  For some reason,
people assume that I read my email in Org mode or some derivative of
Org.

> I'd say that you should not use Org on files that do not use Org syntax.

See above: there are suggestions to do just that.  People are
proposing to use Org in many situations where Org was not originally
used, and therefore the "usual" Org assumptions don't hold.

> > If we want to promote Org to be used more widely and frequently, that
> > would inevitably mean it will be used by Emacs users who use Org only
> > infrequently, and those are the ones I'm thinking about.  We should
> > make it easier to use Org infrequently, by people who don't do
> > everything in Org.
> 
> I agree here. However, I am not sure how to achieve this. We can limit
> Org functionality to lower the entry barrier for infrequent Org users,
> yes. However, it will necessarily mean that most of frequent Org users
> have to adjust their Org mode configurations - not good.
> 
> Should we mark some of the Org commands disabled by default? Though it
> would make sense to mark the whole groups of commands. Is it possible?
> Is it also possible to disable commands only for users who never
> customized Org?

I don't know the answers.  But I'd appreciate if these consequences
and prerequisites of using Org in places where it wasn't used
originally could be voiced when such suggestions are brought up, and
by Org developers on top of that.  I quite frequently opposition to
such proposals is regarded as pure conservatism, so if there are valid
technical reasons and problems to solve before such proposals can be
considered practical, it would be good to have them part of those
discussions.

> This thread is raising so many issues of various levels of
> criticality, generality, and validity that it is very hard to stay on
> topic.

Agreed.  There should be a separate thread for each specific topic.