emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Tom Gillespie <tgbugs@gmail.com>, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Simplified Org mode for newcomer Emacs veterans (was: Org mode and Emacs (was: Convert README.org to plain text README while installing package))
Date: Sun, 19 Jun 2022 08:04:03 +1000	[thread overview]
Message-ID: <87wnddioai.fsf@gmail.com> (raw)
In-Reply-To: <87o7yq44vw.fsf@localhost>

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. 

  reply	other threads:[~2022-06-18 22:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YpuV9DKe9kzNt5np@ACM>
     [not found] ` <871qw31ois.fsf@yahoo.com>
     [not found]   ` <8735gj4ceo.fsf@gnu.org>
     [not found]     ` <87ee038ipt.fsf@gmx.de>
     [not found]       ` <87o7z61v59.fsf@gmail.com>
     [not found]         ` <Yp3l+rjJ0mAIcVZJ@ACM>
     [not found]           ` <87bkv527p5.fsf@gmail.com>
     [not found]             ` <835yld93w7.fsf@gnu.org>
     [not found]               ` <877d5t0yrn.fsf@gmail.com>
     [not found]                 ` <Yp92eI2pEuc/gQu4@ACM>
     [not found]                   ` <jwvtu8wbbjb.fsf-monnier+emacs@gnu.org>
     [not found]                     ` <87r140yuof.fsf@gmail.com>
     [not found]                       ` <E1nzQh5-0001OB-22@fencepost.gnu.org>
     [not found]                         ` <875yl9e7zm.fsf@gmail.com>
     [not found]                           ` <83czfh12kp.fsf@gnu.org>
     [not found]                             ` <87pmjhghu2.fsf@localhost>
     [not found]                               ` <835yl910gp.fsf@gnu.org>
     [not found]                                 ` <87wndndbhq.fsf@gmail.com>
     [not found]                                   ` <83bkuzznws.fsf@gnu.org>
     [not found]                                     ` <877d5mqmkh.fsf@localhost>
     [not found]                                       ` <E1o0sgC-0000jg-U3@fencepost.gnu.org>
2022-06-14  0:43                                         ` Org mode and Emacs (was: Convert README.org to plain text README while installing package) Ihor Radchenko
2022-06-15  5:58                                           ` Ihor Radchenko
2022-06-16 10:05                                             ` Tom Gillespie
2022-06-18 10:56                                               ` 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
2022-06-18 22:04                                                 ` Tim Cross [this message]
2022-06-19  8:49                                                   ` Ihor Radchenko
2022-06-17  6:42                                             ` Org syntax compatibility with texinfo syntax " Ihor Radchenko
     [not found]                                   ` <E1o0Bgv-0008SK-Gs@fencepost.gnu.org>
     [not found]                                     ` <874k0qbrhe.fsf@localhost>
     [not found]                                       ` <E1o0WEH-0004wk-Hw@fencepost.gnu.org>
     [not found]                                         ` <87v8t3wfgd.fsf@localhost>
     [not found]                                           ` <87zgifxt48.fsf@gmail.com>
2022-06-15  6:13                                             ` Cusom special block export, similar org org-link :export parameter (was: Org mode and Emacs) Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnddioai.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tgbugs@gmail.com \
    --cc=yantar92@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).