Re: Simplified Org mode for newcomer Emacs veterans (was: Org mode and Emacs (was: Convert README.org to plain text README while installing package))

[Tim Cross <theophilusx@gmail.com>]

Ihor Radchenko <yantar92@gmail.com> writes:

> Tom Gillespie <tgbugs@gmail.com> writes:
>
>> With regard to the key-bindings straw man. I guess I'm a bit of an
>> outsider on this one, because I started writing org documents by just
>> typing them in and only over time learning some of the bindings. Maybe
>> having an org-markup-mode or something like that would be a way to
>> provide a sandbox for the +recalcitrants+ newcomers? It might also be
>> a nice way to a/b test them on whether the Emacs editing commands
>> really are as good as they think they are (said the evil-mode user).
>
> It can be either a simplified org-markup-mode or a series of minor-modes
> that enable different sets of bindings. Something like:
> org-structure-edit-mode, org-table-edit-mode, org-babel-edit-mode, etc
>
> However, the tricky question is: What should be the default?
>
> If we have org-markup-mode (disabled by default), how would the
> newcomers know to enable it?
>
> If we have the alternative set of minor modes and disable them by
> default, will the existing Org mode users accept the need to adjust the
> configuration?
>
> Can we address the above concerns without dissatisfying neither the
> existing Org users nor the newcomers?
>

I'm not convinced we actually need to do anything (yet). Most of the
'issues' raised by Eli were IMO theoretical rather than real. WE see
few, if any, issues or bug reports relating to most of the points he
raised. I'm also not convinced regarding some of the arguments regarding
casual or 'seldom' users. For me, many of the issues felt somewhat
contrived and actively looking for reasons why increased use of org in
Emacs was a "bad thing". 

This is not to say some of his points don't warrant some consideration.
However, they do seem largely general 'theoretical' and based on a
preconception of what an emacs mode is. In many ways, Org is not a
'normal' emacs mode. In some ways, it is a collection of modes with glue
to make them interoperate a little better. It is therefore possible,
many of the normal 'best practices', especially with respect to key
bindings, may not apply. 

I'm not fond of the 'magic' approach whereby special modes get activated
because some specific data is 'seen' in the buffer. For example, only
loading table editing mode because a table was seen or when the user
enters a line which looks like the start of a table. I much prefer a
system which allows me to enable the modes I want - similar I guess to
how we handle babel languages. However, that could just be me. It would
be good though that if we do support some form of 'dynamic' loading if
Emacs first asks i.e. "It looks like your editing a table. Shal I load
org-table-minor-mode?" sort of thing. 

So my approach would be to break things up into their own minor modes,
but by default, load them all. This will deal with the issue of not
impacting existing users. Typically, those who will care about not
loading additional unwanted bindings or features will also be the same
set of people who will be willing to customise their setup and they can
easily remove/turn off the modes they don't want. 

The one big area which does concern me slightly with introducing this
sort of modularity is with debugging and support. For example, to
reproduce the environment where an issue is encountered, we may need to
also know more about exactly which set of minor modes as been enabled
and possibly the order they are enabled. Even just basic testing will
become more complex as you may need to test with different minor mode
permutations. We may need to add some additional debugging and reporting
functionality to assist in this area. 

Likewise, how does org deal with an org file which includes some feature
the user has turned off. Consider a babel minor mode. Do we allow the
user to edit the babel blocks without loading that mode? Doe we warn
them the mode is not being loaded due to personal configuration? Do we
just disable all babel support if they don't load babel minor mode? 

One area which might be worth starting with would be to create an org
minor mode which only provides basic org navigation, folding and
font-locking support - no babel, no export, no agenda. reduced task
management key bindings. Essentially a minor mode which would render org
files in a 'clean' readable format, allow basic navigation and editing
and some basic/simple todo management. This would be the preferred mode
for seldom/casual users not interested in the full org experience.