From: Texas Cyberthal <texas.cyberthal@gmail.com>
To: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: org-startup-truncated default should be nil [legibility 2/6]
Date: Thu, 6 Feb 2020 10:33:45 +0800 [thread overview]
Message-ID: <CAMUm491U2gepegkQu+e6Y9xP++EMHjhT=JRTw9RNvJu7=69Geg@mail.gmail.com> (raw)
> 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.
next reply other threads:[~2020-02-06 2:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 2:33 Texas Cyberthal [this message]
2020-02-06 6:55 ` org-startup-truncated default should be nil [legibility 2/6] Texas Cyberthal
2020-02-06 7:15 ` Fraga, Eric
2020-02-06 9:46 ` Texas Cyberthal
2020-02-06 10:16 ` Fraga, Eric
2020-02-06 10:51 ` Texas Cyberthal
2020-02-06 11:17 ` Fraga, Eric
2020-02-06 12:09 ` Texas Cyberthal
2020-02-06 12:40 ` Fraga, Eric
2020-02-06 21:21 ` Texas Cyberthal
2020-02-06 21:38 ` Fraga, Eric
2020-02-06 23:33 ` Texas Cyberthal
2020-02-07 0:37 ` Corwin Brust
2020-02-07 1:06 ` Texas Cyberthal
2020-02-07 4:27 ` Texas Cyberthal
-- strict thread matches above, loose matches on Subject: below --
2020-02-04 21:36 Texas Cyberthal
2020-02-04 23:26 ` Samuel Wales
2020-02-05 2:43 ` Texas Cyberthal
2020-02-05 3:49 ` Samuel Wales
2020-02-05 4:02 ` Samuel Wales
2020-02-05 4:09 ` Samuel Wales
2020-02-05 15:30 ` Adam Porter
2020-02-04 4:08 Texas Cyberthal
2020-02-04 7:05 ` Adam Porter
2020-02-10 7:00 ` Bastien
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='CAMUm491U2gepegkQu+e6Y9xP++EMHjhT=JRTw9RNvJu7=69Geg@mail.gmail.com' \
--to=texas.cyberthal@gmail.com \
--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).