[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Convert README.org to plain text README while installing package
Date: Sun, 12 Jun 2022 12:59:47 +0300

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: theophilusx@gmail.com,  acm@muc.de,  emacs-devel@gnu.org
> Date: Sun, 12 Jun 2022 17:46:04 +0800
> > 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.

Thanks, I think this will indeed help in the future.

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

The syntax of TeX is dictated by an external tool.  By contrast, the
syntax of Org is determined by Org itself.

Is an Org table always preceded by some directive that makes it
impossible to interpret innocent text as a table?  If so, perhaps the
problems that were bothering me don't actually exist.

But if Org interprets some text patterns as meaning that there's a
table here, that could be contrary to user expectations.

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

Relying on a user option for something that can need frequent
adjustment is not the best UX.  defcustom is only a good solution when
it expresses a more-or-less constant user preference that change only
very rarely.  If I may need to change the value before invoking a
command, that's inconvenient.

> It's default value has been agreed upon and has not been questioned
> by many.

Maybe because most Org users are frequent Org users and always know
what they want well enough?  As mentioned, I have other kind of users
in mind.

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

Adding keybindings is a solution to a problem.  I'm saying that
alternatives to that solution were not seriously explored fro those
unbundled packages.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]