emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: org-adapt-indentation default should be nil [legibility 3/6]
Date: Wed, 05 Feb 2020 10:12:02 -0600	[thread overview]
Message-ID: <87eev9ggj1.fsf@alphapapa.net> (raw)
In-Reply-To: CAMUm493DWFFYG2ZEuAcEnFWG0ozLYcK4q67ZwcQT3B9hFG0HkA@mail.gmail.com

Texas Cyberthal <texas.cyberthal@gmail.com> writes:

>> the default settings do not put blank lines between headings and
>> their entry text,
>
> I don't know what this means. Plain Emacs behaves the same way
> Spacemacs does in this regard. Insertion of a blank line after a
> heading is voluntary but standrd.

I don't know what you mean, either, but you keep mentioning Spacemacs,
which isn't very relevant.

>> without any indentation, headings and entry text on varying levels
>> tends to blend together, making for very poor readability.
>
> If the goal is to read the body text of headings, then deeply
> indenting it is contrary to the goal. If the goal is to see the depth
> of headings, then the bodies should be folded. If folded mode doesn't
> convey sufficient information, the solution is to rewrite the heading
> titles to better summarize the body text.

It is not for you to decide what others should do.  Your preferences are
not mine.  It sounds like you should develop your own "Texas Cyberthal
Emacs starter kit" that has all the settings you think are best.

>> No one is "good at" Emacs and Org when they first come to it.
>
> UI difficulty is exponential, not linear.

Come on, we all know that the Emacs learning curve is a spiral.

> The more initially difficult the Emacs UI is acknowledged to be, the
> more important it is to reduce that difficulty with noob-friendly
> defaults, so that they can eventually reach the point of elitist
> unconcern for noobs.

The issue here is not whether Emacs can generally be improved, but
whether your specific proposals are good ideas.

It's unfriendly of you--and incorrect--to imply that we are elitists
without concern for new users.  Much effort is put into improving
documentation, answering questions, writing explanatory articles, giving
demonstrations, etc.  Some of us even publish code to help others
improve their configs, e.g. https://github.com/alphapapa/alpha-org.  I
suggest that you give those avenues a try, rather than insisting that
your preferences are best for others.

> The problem with aiming software at noobs is ruining the expert
> experience.

That is one problem with software that overemphasizes the experience of
new users.  Another, perhaps more serious, problem is that it inhibits
the development of such expertise.  I feel like some of ESR's writings
are relevant here.

> Changing defaults doesn't ruin expert experience because experts have
> configuration management.

A VCS does not obviate the need to compensate for changes in default
behavior.

> Noob friendly defaults increases the likelihood there is a long term
> for them.  Emacs' biggest barrier to adoption is acclimatization.

You're not quite wrong, but you're missing the point about long-term
users.  What makes software attractive in the long-term is not what
makes it appeal to new users.  Emacs is not called "the editor of a
lifetime" for nothing--nor is notepad.exe called that, even though it is
very easy for new users to use.  Emacs is attractive in the long-term
because of its power, flexibility, and potential for mastery.  There is
a balance to be struck between appealing to new users and empowering the
development of expertise; to an extent, the two goals do conflict.

> I just read a GTD thread in which they all agreed Org was too hard to
> be worth learning, including the guy advocating it:
>
> https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2
>
> To be clear, this is the biggest GTD forum, which Org is the best
> implementation of, and it seems most of them are using digital GTD
> tools.

So what?  Emacs and Org do not need to adapt themselves to users who do
not like them.  They are successful because of what they are.

You seem very concerned about new users, thinking that, unless we make
Emacs/Org very easy for new users to understand, there will be no new
users.  This is obviously not the case.  Emacs is one of the oldest
pieces of software still widely used.  It and Org are gaining new users
every day; the community is more vibrant than ever.  Probably more
people use Emacs and Org today than ever before.

Consider an analogy: Years ago, Mozilla Firefox was the fastest, most
powerful, most popular browser that wasn't imposed on its users.  It was
the obvious victor in the "browser wars," having led the way in
unseating IE and freeing the Web from Microsoft's hegemony.  Then Google
Chrome arose as a challenger, with certain inherent advantages due to
Google's position.  Mozilla then chose to stop leading and start
following.  Every new Firefox release became more like Chrome, with
Mozilla thinking that it could win back users.  But why would a user who
was happy with Chrome want to switch to a poor imitation of it?  Mozilla
thought it could succeed by abandoning what had made it successful--it
thought Firefox would be more popular if it stopped being Firefox.  The
result was continued decline in Firefox's market share and, eventually,
Mozilla's recent layoffs.

Time and again, concerned people say that Emacs needs to be made simpler
for new users.  In a way, these people are right.  In a way, they are
missing the point.  Emacs is successful because it is Emacs.

  reply	other threads:[~2020-02-05 16:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 22:00 org-adapt-indentation default should be nil [legibility 3/6] Texas Cyberthal
2020-02-05 16:12 ` Adam Porter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-02-04  4:09 Texas Cyberthal
2020-02-04  7:21 ` Adam Porter
2020-02-10  7:05   ` Bastien
2020-02-10 20:33     ` Samuel Wales
2020-02-10 21:52       ` Bastien
2020-02-10 22:01         ` Samuel Wales

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=87eev9ggj1.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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