Re: "Why is emacs so square?"

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have learned a lot more about Org mode from your message
than I was able ever to learn before.  Thank you.

  > This is not what a chapter about using a word processor should look
  > like.  It should begin with an introduction to word-processing with
  > Org, an overview of what's possible and what isn't; it should go on to
  > explaining how to start a document, how to write a heading and a
  > sub-heading, how to insert references, links, footnotes, and other
  > objects; it should then explain how to produce a TOC and an index, and
  > finally point me to another chapter that explains how to export my
  > document in a variety of formats.

That plan for a manual for the word-processing feature makes sense.

It appears that what people call "Org mode" is a collection of diverse
features, and what they have in common is use of a certain format of
the text.  Is that right?

I have to question the practice of treating these diverse features
conceptually as a single mode.  Although I still don't know what those
features are, if one of them is a word processor and the others are not,
they are too different to make sense conceptually that way.

It would make more sense to call them various different modes.  That
they all use a certain way of formatting the text may not be important
to mention.  If it is useful to have a name for that, I suggest the
name "Org format".  Each of these modes could say it uses "Org
format", or perhaps a variation of that.

  > > As a consequence, it probably makes little sense to separate such
  > > "facilities"---the term would need to be properly defined in the current
  > > context, tho---, because each of them implies full support for the whole
  > > Org syntax.

Maybe that is how things are now, but is there a reason why things
SHOULD be done this way?  Does each of these features need to support
"the whole Org syntax"?

It could be that the simple way of implementing them is by sharing code
that implements "the whole Org syntax".  If so, I won't argue against
sharing that code.  But it may not be useful to TALK about the fact
that each one implements "the whole Org syntax".  And it is possilble
that it is better to share only part of that code, not all.

In other words, if we don't let the concept of "Org mode" shape our thinking,
we might thing of these features differently.

  > I hope I explained at least what is my view of how Org should evolve
  > (in addition to the routine development that adds new features) -- it
  > should try to present a less monolith-like appearance towards new
  > users, and allow them to master just a part of its capabilities, the
  > part that they are interested in.

Hear, hear!

  > HTH and TIA

Hold Turnip Head and Turn It Around?  ;-}


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)