Ihor Radchenko <yanta...@gmail.com> writes:
> Tom Gillespie <tgb...@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.