Re: org-startup-truncated default should be nil [legibility 2/6]

[Texas Cyberthal]

> If I understand correctly, you're arguing that defaults should be changed 
> because you don't understand how Emacs works, and since you use Spacemacs, 
> you don't even care how it works.

You understand incorrectly. You incorrectly asserted that all users
must learn how visual line mode works. Visual line mode is annoying
and unnecessary; Spacemacs users do not need it because its defaults
offer adequate paragraph navigation.

Org's default should be (truncate-lines nil) with paragraph navigation
like Spacemacs, so that non-techie noobs can use it for text editing
out of the box. Requiring them to try to figure out sane defaults for
basic prose editing by trial and error drives too many away.

To review why Org is so frustrating to new users out of the box, I
turned on my vanilla Emacs and opened an Org file. I was unable to
toggle line truncation from M-x completion, so I enabled
visual-line-mode instead. This wrapped lines as desired, but left
paragraph navigation broken.

C-a/e org-end-of-line moves point to beginning/end of visual line, as
the mode name suggests. This is not very useful, because C-n/p
next-line also moves by visual lines, which in combination with M-f/b
forward-word allows one to reach any column on the visual line, not
just the beginning and end points. The visual beginning and ends of
lines have no logical significance and thus there is no reason to give
them the extra convenience of dedicated keybinds.

M-a/e org-backward-sentence only works if one remembers to
double-space after a period to denote the end of a sentence. Noobs are
unlikely to realize this, and will instead wrongly conclude that it
only detects paragraphs, since it does recognize a period followed by
a line break as a sentence. Spacemacs recognizes a single space after
the period as a sentence. Even if a user trains himself to always
double-space after the end of a sentence, much of the text he imports
into Org from other authors will not be formatted correctly.

Most importantly, there is no keybind for next-logical-line, which is
an important location in a paragraph. And there is no visual cue that
a line break is visual rather than logical. The next paragraph
navigation command level operates on paragraphs. C-down/up
org-forward-paragraph skips multiple adjacent lines as one paragraph,
treating line breaks in visual line mode the same as those in normal
fill mode, even though the former are deliberately inserted as
logically significant demi-paragraphs.

So if one types a stream of consciousness:

#+begin_quote
Hm maybe i should do x
or maybe y
I guess I'll think about it further
#+end_quote

These demi-paragraphs get obliterated by visual line mode, if the
lines are long.

And that's assuming the noob knows to enable visual-line-mode in the
first place!

Ok, I just figured out that M-x trunc completion failed because the
command is toggle-truncate-lines. That delivers a sane paragraph
editing experience, except for the sentence detection issue. So
toggle-truncate-lines needs an alias that starts with "truncat" so
that noobs can find it, if it's not going to be enabled in Org by
default.

truncate-lines nil still doesn't result in readable prose in vanilla.
The fixed pitch font with the continuation marks and the lack of word
wrapping and the narrow line spacing makes a total mess.

Meanwhile Spacemacs' Org paragraph navigation defaults are perfectly
sane and pleasant. C-a/e runs mwim-beginning-of-code-or-line. Lines
are wrapped and demi-paragraphs are preserved.

Why does Org inflict such a frustrating experience on non-techie noobs
when they attempt to draft their first raw notes into Org? How can
this possibly be optimal? If the plan is to prevent consumer adoption
of Org as a Personal Info Manager, it's working.

> May I suggest that you propose your changes on the Spacemacs repo.

In this case, I am suggesting Org adopt what Spacemacs already has.

Regarding the assertion that Emacs is doing just fine on noob
friendliness, this is false, as I demonstrated in my most recent post:
https://cyberthal-ghost.nfshost.com/emacs-needs-a-starter-zone-and-org-is-it/

The existence of B2C tech support for Linux but not Emacs demonstrates
that the former is sufficiently noob friendly and the latter isn't.

I don't particularly care whether noob intake is delegated to distros
or vanilla, but splitting the job between the two isn't working.