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

[Texas Cyberthal]

Emacs is the tool that allows a non-technical user to bootstrap to
control over his IT environment. Within that, Org is the tool that
allows him to bootstrap to control of Emacs. So Org's defaults should
allow someone with no experience to learn the basic text manipulation
commands in the help-with-tutorial and then log his efforts to learn
Emacs.

Eventually he will need to turn on truncation in Org to display inline
codelike elements properly, but until then he'll need his prose
paragraphs wrapped for him.

Correction:

I started an unmodified Spacemacs to check my memory of its Org
defaults. I was correct about Org recognizing single-space sentences
by default. I was wrong about Org using variable pitch with word
wrapping and without truncation by default. I'll certainly propose
that be changed there.

On the bright side, truncation is easily M-x discoverable with Helm,
and visual line mode is placed in an inferior position to truncation
in the keybinds: SPC-t-l for spacemacs/toggle-truncate-lines and
SPC-t-L for spacemacs/toggle-visual-line-navigation.

Now I'm wondering whether any distro ships an Org whose defaults
permit noobs to write prose paragraphs.

On Thu, Feb 6, 2020 at 10:33 AM Texas Cyberthal
<address@hidden> wrote:
>
> > 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.