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

[Ihor Radchenko <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Not really. The remappings usually intend to re-implement the usual
>> expected Emacs behavior inside Org. It's just that it is not always
>> possible using the built-in functions. Hence, we implement a layer on
>> top.
>> 
>> There should not be anything to learn with regard to remapped commands
>> given that Org defaults are not changed.
>
> 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.

> And anyway, even if what you say is 110% true, how am I as a user to
> know that up front?  I'm used to read the documentation of every
> command I don't already know by heart, so when faced with such massive
> remapping, I have quite some reading to do before I can feel myself at
> ease.
>
> And please note that, unlike Alan, I _do_ use Org, just not very
> often, at least these days.  So what I'm sating doesn't come from the
> POV of an anti-Org user.  I _want_ Org to be easier and less demanding
> to use.

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.

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.

So, I'd say that your concern is not really justified. 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.

>> > The difference is that we had years or decades to get used to the
>> > Emacs defaults, and once Org is turned on in a buffer, one has a lot
>> > of new stuff to get used to.  Unless Org is used constantly, you will
>> > forget most of those changes till the next time, so this re-learning
>> > experience will be repeated every time.
>> 
>> Isn't it the same for any other major mode?
>
> 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. 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.

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

C-S-<up> is not a basic movement command. By default, it is activating
region. Without shift-select-mode, it is not bound to anything. Org does
provide support for shift-select-mode, but we never got overwhelming
requests to enable this support by default.

C-<up>/<down>, which is the actual basic movement command is not
overridden by Org.

AFAIK, the only shadowed command is M-<right>/<left> with its other
C-<right>/<left> binding being untouched. However, I am not even sure
what Org can do about this. Arrow bindings are one of the most core and
frequently used commands. Removing them will dissatisfy existing users.

Note that Emacs dedicates C-c + letter for user bindings. Anything else
is not guaranteed to be not shadowed by major/minor modes. If users
absolutely want they personal bindings to be preferred, there is always
override-global-map.

>> > It isn't a catastrophe, of course, but we should recognize this as an
>> > issue, especially if many of the bindings aren't needed.
>> 
>> I am not sure what you mean by aren't needed.
>
> Ask Tim Cross: the claim that most of the 230 bindings I counted
> aren't needed comes from him.

He was referring to reading Org files without editing.
You can argue the same for reading pretty much any other major-mode
files. Most bindings will not be needed.

>> There is no doubt that you do not need most of the bindings just to
>> navigate Org files or do basic editing. You do not need to learn those
>> other bindings either.
>
> 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? I'd
say that conventional approach is binding the relevant commands and
letting Emacs to do autoloading once those commands are called.

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

Best,
Ihor