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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: theophilusx@gmail.com,  acm@muc.de,  emacs-devel@gnu.org
> Date: Thu, 09 Jun 2022 17:15:05 +0800
> 
> > Are you sure this is always true?  There are several dozens of
> > remapped commands; did you audit all of them?
> 
> I have audited a couple of them and relied on a good faith to other Org
> devs + absence of bug reports relevant to the raised concern.
> Rather then re-checking the remapped functions, I'd rather just fix any
> concrete bug reports about misbehavior, if such reports arise.

Didn't this discussion raise such "bug reports"?  Why not consider
what several people here said as such a bug report?  The difference is
that these reports come from people who use Org rarely, so the
concerns are different.  But if the Org developers want to have Org
adopted more widely, I think they should listen to these concerns, not
reject them.

> While I understand the possible fear of unexpected or unnatural
> behavior of the remapped command, I'd like to point out that command
> behavior can span over quite a significant range even without remapping.
> Just the fact that some major mode does not use remapping, does not mean
> that you are guaranteed to get the normal command behavior.

Most major modes don't remap global and frequently-used commands.
Those that do are problematic, and should be fixed rather than be used
as examples of what's "kosher".

> Some major modes rely on post-command-hook instead of remapping, which
> not only modifies the original command behavior in unspecified ways, but
> is also not directly visible from the mode bindings. Or consider changes
> in filter-buffer-substring-function and how it can modify killing text.

And that is in your opinion a Good Thing?  I don't think it is, and
therefore don't consider such problematic behavior a good example for
development.

> So, I'd say that your concern is not really justified.

??? Just because "others do that"?

> There is generally no reliable way to tell if an arbitrary major
> mode modifies standard command behavior just by looking at its key
> bindings. You have to rely on faith and report bugs if you stumble
> upon them.

I don't see how this solves the concerns.  We should still try to
minimize such problematic behaviors as much as possible.

> > No, not IME.  Show me another general-purpose editing mode that
> > defines so many key bindings.  The only modes that get close are those
> > where text is read-only, so normal editing is impossible anyway.
> 
> I am not sure what you mean by general-purpose.

Modes for editing mostly human-readable text.

> Auctex binds a decent number of key-bindings. VHDL mode binds even
> more (I just looked into one of the largest mode built-in prog
> modes). markdown-mode binds over 100 keys not counting prefix maps.

Two of these aren't part of Emacs, and VHDL is an example of
programming language, where text is not really for human consumption.

> >   And even those leave alone basic movement commands, like C-S-<up>
> > which Alan mentioned.
> 
> C-S-<up> is not a basic movement command.

Of course, it is: it moves by paragraphs.

> By default, it is activating
> region. Without shift-select-mode, it is not bound to anything.

But shift-select-mode is on by default.

> > Then why bind them by default? why not wait until I actually need that
> > functionality?  If that's hard or impossible to detect automatically,
> > let the user say so.  For example, I could envision a minor mode that
> > enables Org-Babel and binds the corresponding commands to keys.
> 
> Org-babel bindings are needed as soon as you create a source block
> inside the Org file. Are you proposing to track changes in buffer and
> autoload babel as soon as a source block appears inside the buffer?

That's one way.  Another one is to have a minor mode that users could
turn on when they need it (or turn it on by default in their init
files if they need it a lot).

> Would it help if we hide the babel-related stuff under dedicated prefix
> map?

Probably.