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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> 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 a similar wording to my previous reply to Eli (I think it was to
Eli). The answer was that the emacs-devel discussion _was the bug
report_. Eli sometimes uses Org, but finds many things too much for him.
Other complaints are from Org non-users who are not interested to give
bug reports because they stopped short at the first try of using Org.

Not to say that I agree with all the complaints, but they should be
discussed here at least.

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

Surely, Org is a collection of at least org-agenda-mode and org-mode :)
The irony is that 'best practices' are not implemented by Emacs itself
(look at the number of default Emacs bindings!).
In any case, we should still try to extract something useful out of the
received feedback.

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

I also dislike that idea. I proposed it as a part of brainstorming,
hoping other ideas to be proposed by Eli. Alas...

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

I tend to agree:
1. We modularize some of the key bindings and overriding defaults (like
   org-special-ctrl-o in org-open-line) into minor modes. They will be
   enabled by default.

2. We create an org-clean-mode (aka clean-mode in Emacs master) that
   disables/toggles those minor modes.

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

I think I was not very clear in my previous message. There is no way we
disable parts of Org syntax. That will require refactoring of
org-element and many other functions. Not acceptable.

What we can disable/change is some of the default bindings + certain
customizations. The minor modes I propose will simply bind/unbind groups
of Org bindings and toggle certain custom variables between
Org-preferred and Emacs-default-ish.

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

I do not think that we should really disable babel support hard. I do
not see any problem leaving M-x org-babel-... working all the time.
We can just disable key bindings and change certain settings. This will
not be any different compared to dealing with tailored user configs. No
extra effort will be required on our side in this regard.

Best,
Ihor