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

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

[Texas Cyberthal]

#+begin_src elisp
(org-startup-truncated nil)
#+end_src

Line truncation is necessary for code but anathema for prose. Prose
lines need visual wrap as windows resize, so that texts can be
compared easily.

Advanced Org uses such as large tables require line truncation. Tables
are a code-like fixed-pitch feature.

Users will write a paragraph of prose longer than the screen well
before they discover a need for line truncation, such as long lines of
code or wide tables. Users who need line truncation are likely to know
about it, whereas users who need line truncation off are unlikely to
know what it's called.

Learning about line truncation is an unnecessary hurdle for beginners.
Therefore the default should be nil.

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

[Adam Porter]

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

> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src
>
> Line truncation is necessary for code but anathema for prose. Prose
> lines need visual wrap as windows resize, so that texts can be
> compared easily.
>
> Advanced Org uses such as large tables require line truncation. Tables
> are a code-like fixed-pitch feature.
>
> Users will write a paragraph of prose longer than the screen well
> before they discover a need for line truncation, such as long lines of
> code or wide tables. Users who need line truncation are likely to know
> about it, whereas users who need line truncation off are unlikely to
> know what it's called.
>
> Learning about line truncation is an unnecessary hurdle for beginners.
> Therefore the default should be nil.

visual-line-mode and toggle-truncate-lines are basic Emacs commands that
all users should learn early.  As well, many users prefer to use filled
paragraphs rather than visual wrapping.  And we shouldn't prioritize
prose above other uses. So this default should probably not be changed.

What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks.  I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill

As well, it might be good to discuss on emacs-devel whether a feature
could be developed to truncate/wrap lines selectively; maybe
font-locking could be used to apply text properties to disable wrapping
dynamically (assuming that a feature could be developed to wrap based on
a certain text property).  Then we could have the best of both worlds,
and solve an existing problem, viz. that tables and code gets wrapped
when visual-line-mode is enabled.

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

[Bastien]

Hi Texas,

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

> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src

I disagree.

The whole discussion about mixing prose and code in the same buffer is
interesting: ideas like mixing variable pitch fonts, truncating lines
for specific parts of the buffer, etc. are all worth experimenting,
but they are about *Emacs*, not just Org.

Your best luck is to discuss this on emacs-devel first.

Thanks,

-- 
 Bastien

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

[Texas Cyberthal]

> visual-line-mode and toggle-truncate-lines are basic Emacs commands that all users should learn early.

Visual lines, logical lines etc is a complicated mess that Spacemacs
avoids entirely. I recall fiddling with it and never being satisfied,
until adopting Spacemacs solved it. Now I know even less about it than
I did then, because there's no need to know. A brief investigation
shows Spacemacs sets (line-move-visual t) in prosey text modes, so
that C-n next-line operates on visual lines. However commands such as
C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
default that permits fluid navigation of paragraphs, which is all a
noob wants to do.

Similarly, I almost never use truncate-lines, to the point that I had
to websearch to recall what it was called within the last week.

Emacs is self-documenting; learning it requires bootstrapping. The
less noob-friendly the defaults, the lower the chances they
successfully boostrap.
Emacs noobs have enough to contend with. If learning the twenty ways
to wrap lines can be skipped, it should be. Prose should wrap at
window's edge; code should continue. That's the universal standard
now. Emacs was written before this standard, so it pretends there
isn't one.

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

[Samuel Wales]

On 2/4/20, Texas Cyberthal <texas.cyberthal@gmail.com> wrote:
> Prose should wrap at
> window's edge

many users need fully maximized emacs while still having legible
paragraph width.

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

[Texas Cyberthal]

> many users need fully maximized emacs while still having legible paragraph width.

Splitting windows vertically creates narrower columns. Unlike
truncation etc, window management actually is something all noobs must
learn.

Narrower columns can increase reading speed, to a point. But wide
columns aren't actively uncomfortable. It isn't important for noobs to
be fast; they're slow anyway. Reducing disorientation, frustration and
distraction is the priority.

Full width is bad for detailed reading, but it's great for skimming
the document overview. Half width is 80 chars on my primary display.
The default fill column is 70.

It's reasonable to expect users will set font size so that vertical
window split results in a comfortable paragraph width. It's
unreasonable to expect they will hit M-q constantly to refill
paragraphs.

On Wed, Feb 5, 2020 at 7:26 AM Samuel Wales <samologist@gmail.com> wrote:
>
> On 2/4/20, Texas Cyberthal <texas.cyberthal@gmail.com> wrote:
> > Prose should wrap at
> > window's edge
>
> many users need fully maximized emacs while still having legible
> paragraph width.

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

[Samuel Wales]

i am feeling highly uncomfortable now.


On 2/4/20, Texas Cyberthal <texas.cyberthal@gmail.com> wrote:
>> many users need fully maximized emacs while still having legible paragraph
>> width.
>
> Splitting windows vertically creates narrower columns. Unlike
> truncation etc, window management actually is something all noobs must
> learn.
>
> Narrower columns can increase reading speed, to a point. But wide
> columns aren't actively uncomfortable. It isn't important for noobs to
> be fast; they're slow anyway. Reducing disorientation, frustration and
> distraction is the priority.
>
> Full width is bad for detailed reading, but it's great for skimming
> the document overview. Half width is 80 chars on my primary display.
> The default fill column is 70.
>
> It's reasonable to expect users will set font size so that vertical
> window split results in a comfortable paragraph width. It's
> unreasonable to expect they will hit M-q constantly to refill
> paragraphs.
>
> On Wed, Feb 5, 2020 at 7:26 AM Samuel Wales <samologist@gmail.com> wrote:
>>
>> On 2/4/20, Texas Cyberthal <texas.cyberthal@gmail.com> wrote:
>> > Prose should wrap at
>> > window's edge
>>
>> many users need fully maximized emacs while still having legible
>> paragraph width.
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

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

[Samuel Wales]

you do not know what every user needs.

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

[Samuel Wales]

should not have hit send on last email.  meant to disengage
completely.  will do so now.  last email was not an invitation to
converse.

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

[Adam Porter]

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

>> visual-line-mode and toggle-truncate-lines are basic Emacs commands
>> that all users should learn early.
>
> Visual lines, logical lines etc is a complicated mess that Spacemacs
> avoids entirely. I recall fiddling with it and never being satisfied,
> until adopting Spacemacs solved it. Now I know even less about it than
> I did then, because there's no need to know. A brief investigation
> shows Spacemacs sets (line-move-visual t) in prosey text modes, so
> that C-n next-line operates on visual lines. However commands such as
> C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
> default that permits fluid navigation of paragraphs, which is all a
> noob wants to do.
>
> Similarly, I almost never use truncate-lines, to the point that I had
> to websearch to recall what it was called within the last week.

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.

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

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.

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
<texas.cyberthal@gmail.com> 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.

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

[Fraga, Eric]

On Thursday,  6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> Visual line mode is annoying and unnecessary; Spacemacs users do not
> need it because its defaults offer adequate paragraph navigation.

I'm not sure I understand the conflation of visual-line-mode with
paragraph navigation.  Is it because you mean intra-paragraph navigation
as opposed to M-{ and M-} for navigating from paragraph to paragraph?

Maybe auto-fill-mode is what you want?

In any case, the solution may simply be some example org mode hooks
with, say, settings for writing prose and have these in the org mode
manual?

Fundamentally, emacs is challenging because it is both powerful and
completely customizable.  I remember a colleague complaining that Linux
was not friendly because you had too much choice.  Emacs takes that to
another level.  And that's why many of us live in it... 
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Texas Cyberthal]

auto-fill-mode definitely isn't what I want. Beyond that I don't
understand your question.

I doubt it's productive to reiterate my legibility critiques since
I've concluded they're more appropriate for Spacemacs.

> the solution may simply be some example org mode hooks with, say, settings for writing prose and have these in the org mode manual?

Sounds like a step in the right direction.

It sounds like vanilla Emacs' primary mission is to be the common
component between all configurations, and to be by the devs and for
the devs. Greybeard compatibility is big due to the proliferation of
heavily individualized configs. It can be user-friendly for dev noobs
but not normie noobs.

In that light, leaving Org's defaults no different than an IDE's makes sense.

That leaves Spacemacs being to vanilla Emacs as Ubuntu is to Debian.
Spacemacs is crowd-configured and vanilla Emacs isn't.

It doesn't make sense for vanilla Emacs to be more normie-noob
friendly than Spacemacs, so I feel most of my Org legibility
suggestions should be implemented on Spacemacs before vanilla, if at
all.

Vanilla documentation incompatibility due to distro drift isn't as bad
as I thought, thanks to Emacs being self-documenting. I think I can
construct a decent normie-noob adoption funnel in Spacemacs, based off
the tutorial, friendly defaults, and probably a tutorial layer. In
other words, create the equivalent of Ubuntu Mint.

Once someone starts living in Emacs, they'll eventually reach sage
status. It's just a matter of easing them in.

On Thu, Feb 6, 2020 at 3:16 PM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> On Thursday,  6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> > Visual line mode is annoying and unnecessary; Spacemacs users do not
> > need it because its defaults offer adequate paragraph navigation.
>
> I'm not sure I understand the conflation of visual-line-mode with
> paragraph navigation.  Is it because you mean intra-paragraph navigation
> as opposed to M-{ and M-} for navigating from paragraph to paragraph?
>
> Maybe auto-fill-mode is what you want?
>
> In any case, the solution may simply be some example org mode hooks
> with, say, settings for writing prose and have these in the org mode
> manual?
>
> Fundamentally, emacs is challenging because it is both powerful and
> completely customizable.  I remember a colleague complaining that Linux
> was not friendly because you had too much choice.  Emacs takes that to
> another level.  And that's why many of us live in it...
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Fraga, Eric]

On Thursday,  6 Feb 2020 at 17:46, Texas Cyberthal wrote:
> auto-fill-mode definitely isn't what I want. 

Why not?  Just curious.  Before I switched to visual-line-mode for all
org documents, I used auto-fill-mode for prose all the time.  Together
with fill-paragraph (M-q), this did the job very well.

> Beyond that I don't understand your question.

My question was: what do you mean by paragraph navigation?  And,
supplementary, what is missing in vanilla emacs in this respect?

And, yes, if I had a beard, it would be grey. ;-) But I would be more
than happy to see new users embrace Emacs & org mode.  They are missing
out on a fantastic system.  Unfortunately, people are blind to the "it's
all text" paradigm due to the frills of buttons, mice, and menus which
paradoxically get in the way of productivity.

The same issues arise in the LaTeX vs Word debate... and having to
produce technical documents (articles, books, proposals, presentations)
for a living, LaTeX is the only way to go.  But this is for another
day. :-)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Texas Cyberthal]

auto-fill-mode is unsuitable for prose work, and especially for rough
notes which rely on demi paragraphs. Demi-paragraphs are important for
conveying uncertainty. Polished publishable prose can usually be
written with proper syntax and paragraphs separated by blank lines,
but the requisite forethought and certainty are unavailable for raw
notes, which is exactly what a boostrapper needs to write.

When writing for publication in a markup that doesn't recognize single
line breaks as paragraphs, there is no disadvantage to using filled
paragraphs, since demi-paragraphs require ugly markup to survive
refilling. However, raw Org notes aren't written for publication.

The best solution for one's informal notes is truncation off and word
wrapping on. This respects demi-paragraphs, and permits dynamic visual
line length, depending on window width. When I'm composing a longer
document, I often prefer a column width of around 160 chars, or
fullscreen, to see the document overview. However, for close work I
prefer 80 chars, or for comparing two documents with a vertical window
split.

> My question was: what do you mean by paragraph navigation?

In this case, I meant intra-paragraph navigation.

> what is missing in vanilla emacs in this respect?

It's hard for a bootstrapping normie-noob to achieve a
paragraph-editing experience that isn't significantly worse than
Microsoft Word's. Which is basically the same as telling him to leave.

Last month I averaged a daily Org text intake+production of over 4.5k
words, so I have little tolerance for ergonomic friction. Failure to
support demi-paragraphs introduces UI friction right when the brain is
most overloaded, which is unacceptable for a productivity workspace.

On Thu, Feb 6, 2020 at 6:16 PM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> On Thursday,  6 Feb 2020 at 17:46, Texas Cyberthal wrote:
> > auto-fill-mode definitely isn't what I want.
>
> Why not?  Just curious.  Before I switched to visual-line-mode for all
> org documents, I used auto-fill-mode for prose all the time.  Together
> with fill-paragraph (M-q), this did the job very well.
>
> > Beyond that I don't understand your question.
>
> My question was: what do you mean by paragraph navigation?  And,
> supplementary, what is missing in vanilla emacs in this respect?
>
> And, yes, if I had a beard, it would be grey. ;-) But I would be more
> than happy to see new users embrace Emacs & org mode.  They are missing
> out on a fantastic system.  Unfortunately, people are blind to the "it's
> all text" paradigm due to the frills of buttons, mice, and menus which
> paradoxically get in the way of productivity.
>
> The same issues arise in the LaTeX vs Word debate... and having to
> produce technical documents (articles, books, proposals, presentations)
> for a living, LaTeX is the only way to go.  But this is for another
> day. :-)
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Fraga, Eric]

So, the only problem that you have, as far as I can tell, is that Emacs
doesn't distinguish paragraphs by a single newline character but
requires 2 instead?  For me, a blank line between paragraphs is very
useful to visually identify new paragraphs (or demi-paragraphs).

For writing and for intra-paragraph navigation, what is necessary beyond
visual-line-mode, next-line (C-n, <down>), forward-word (M-f), forward
sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite
direction?  (Okay, maybe a few others like begin/end of line, paging up
and down, etc.)  What does spacemacs provide that vanilla Emacs does
not?  (I've never used spacemacs so please excuse my ignorance.)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Texas Cyberthal]

No, I just didn't repeat everything.

A blank line is useful, yes. Use of demi-paragraphs implies use of
line breaks to signal stronger transitions. E.g., from my recent
workflow:

#+begin_quote
turning the mic off/on manually also causes a pop
so would need to pause recording first
simpler to just leave the mic on then
fair enough.
[2020-02-05 Wed 08:47]

seems I'm suffering from electet mic pop
which can be solved by adding a capacitor and resistor to the circuit?
[2020-02-05 Wed 08:52]

http://www.discovercircuits.com/H-Corner/popfree%20micophone%20switch.htm
pop-free microphone switch

could sample out the sound in audacity easily
#+end_quote

Single line breaks allow preservation of the chronological sequence of
thoughts, which is useful for e.g. debugging false assumptions.

The above was a simple example with short lines. But if they were long
and complex, vanilla Emac's defaults would make paragraph navigation
difficult.

> For writing and for intra-paragraph navigation, what is necessary beyond visual-line-mode, next-line (C-n, <down>), forward-word (M-f), forward sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite direction?

What vanilla Emacs Org default visual-line-mode is missing for
informal prose notes:
- recognize sentences with a single space after terminal punctuation
- word wrap
- more line spacing and a variable pitch font
- denote single line breaks with the absence of continuation marks, as
truncate lines nil does
- C-a/e begin/end of line should still operate on logical lines.

It's easier to achieve the last two points without visual line mode,
since line-move-visual is t by default. Toggling truncation off is
enough.

visual-line-mode's minor luxury of slightly easier navigation to
arbitrary visual line endpoints doesn't compensate for loss of the
critical ability to identify logical lines with single line breaks,
and the loss of keybinds for quick navigation to their endpoints.

On Thu, Feb 6, 2020 at 7:17 PM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> So, the only problem that you have, as far as I can tell, is that Emacs
> doesn't distinguish paragraphs by a single newline character but
> requires 2 instead?  For me, a blank line between paragraphs is very
> useful to visually identify new paragraphs (or demi-paragraphs).
>
> For writing and for intra-paragraph navigation, what is necessary beyond
> visual-line-mode, next-line (C-n, <down>), forward-word (M-f), forward
> sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite
> direction?  (Okay, maybe a few others like begin/end of line, paging up
> and down, etc.)  What does spacemacs provide that vanilla Emacs does
> not?  (I've never used spacemacs so please excuse my ignorance.)
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Fraga, Eric]

On Thursday,  6 Feb 2020 at 20:09, Texas Cyberthal wrote:
> A blank line is useful, yes. Use of demi-paragraphs implies use of
> line breaks to signal stronger transitions. E.g., from my recent
> workflow:

I get this.  My own approach is to simply use - at the start of the line
and then each of these demi-paragraphs becomes a list item which are
wrapped nicely (whether with visual or fill mode).

> What vanilla Emacs Org default visual-line-mode is missing for
> informal prose notes:
> - recognize sentences with a single space after terminal punctuation

Does for me.  Maybe I've customized something... that's the problem with
a .emacs file that has elements that date back 37 years... ;-)

> - word wrap

Not sure what you mean here.  Visual mode does this; so does fill
mode.  What I am failing to understand from you is your frequent
reference to truncation but then wanting wrapping?  I'm obviously
missing something.

> - more line spacing and a variable pitch font

This is "look and feel" and easily addressed, as others have noted, by a
theme.

> - denote single line breaks with the absence of continuation marks, as
> truncate lines nil does

What about turning on whitespace-mode?

> visual-line-mode's minor luxury of slightly easier navigation to
> arbitrary visual line endpoints doesn't compensate for loss of the
> critical ability to identify logical lines with single line breaks,
> and the loss of keybinds for quick navigation to their endpoints.

So turn off line-move-visual.

I guess what I am saying is what I said earlier: a simple org mode hook
with some settings would be all the customization you would need to
achieve your desired writing experience and could easily be an example
early in the org mode manual.

Does spacemacs initialise things they way you want them?  If so, go with
it but I guess there are other things about spacemacs that you do not
like?

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Texas Cyberthal]

> I get this.  My own approach is to simply use - at the start of the line and then each of these demi-paragraphs becomes a list item which are wrapped nicely (whether with visual or fill mode).

The cost of this approach is that one can't distinguish between
demi-paragraphs and actual bullet points. I used both in my prior
email. I'd prefer to use \\
instead. Unlike the - prefix, appending \\ doesn't require
anticipation that the line will be followed by another demi-paragraph.
However, it's ugly and distracting.

The problem is that the normie-noob bootstrapper is unlikely to know
either trick. He will probably wind up using visual-line-mode once he
Googles his frustration over the strange line truncation, and then he
won't be able to return to the start of demi-paragraphs with
org-beginning-of-line, even if he knew to prefix a "-".

> Does for me.  Maybe I've customized something... that's the problem with a .emacs file that has elements that date back 37 years... ;-)

Vanilla Emacs doesn't. Yes, I'd forgotten some of my earliest
Spacemacs Org customizations as well.

It's not that Spacemacs' defaults are vastly better, it's that
Spacemacs' UI is vastly more discoverable. The one issue that's hard
to fix, single-space sentence detection, is fixed by default.
Spacemacs guides the user to the other solutions. E.g., using
visual-line-mode introduces one to the superior
spacemacs/toggle-truncate-lines because it's on the lowercase version
of the same keybind. Which is in the UI toggles section, which also
offers related toggles and theme control, via whic-key.

The normie-noob bootstrapper will wonder whether he can even cope with
Emacs' notoriously challenging environment. Before investing lots of
time reading the manual of a program he's never used, it's rational
for him to hop in and see whether he can stand it. This means
installing vanilla Emacs and starting the tutorial. Maybe, if he's
particularly well informed, he manages to open an Org file to take
notes as he learns.

Then, while he's trying to learn these bizarre keybinds for mouse-less
editing, he struggles to find a way to display and edit a paragraph.
He finds he can't even document his learning efforts. He resorts to
switching between Word and Emacs. Word is easier to use. He gives up
and goes back to whatever GTD PIM is next on his list to try.

The problem with vanilla Emacs' defaults for prose paragraphs is that
there's too many things wrong for the normie-noob to unravel the
Gordian knot. Toggling truncation off doesn't look viable because the
continuation marks without word wrap with close line spacing are very
hard to read. So he uses visual-line-mode instead, which destroys
demi-paragraphs, which is hostile to experimental learning. Or maybe
he struggles with filled paragraphs instead, which are even clunkier.

> Visual mode does this; so does fill mode.

Vanilla Emacs with truncation off does not word wrap by default; it
wraps in the middle of words. You're right, visual-line-mode does wrap
words by default, as does filling. So this is another push away from
the truncation toggle, which is the actual correct solution.

> This is "look and feel" and easily addressed, as others have noted, by a theme.

It's standard for modern programs to ship with a default theme that
already makes it look good and usable.

Spacemacs comes with themes but none add variable pitch and line
spacing to Org, IIRC. Emacs' default custom themes don't either.

Themes seem to be mostly about color scheme. I doubt a theme is the
right answer, since specifying variable pitch and line spacing would
reduce its compatibility. If a theme is the answer, it's something
like Poet, which I haven't tested:

https://github.com/kunalb/poet

> What about turning on whitespace-mode?

That makes all the spaces visible, which isn't legible.

> So turn off line-move-visual.

I wasn't able to do so for visual-line-mode, but it worked for
truncation off. Unfortunately, this also disables visual movement for
C-n/p next-line, which renders paragraphs un-navigable again. There's
no need for logical C-n/p when one already has logical C-a/e and
C-up/down. So in the unlikely event the bootstrapper finds this, he
will get excited and congratulate himself on his cleverness, only to
realize he's made it even worse than before. This is the kind of
experience that leads to quitting.

> a simple org mode hook with some settings would be all the customization you would need to achieve your desired writing experience and could easily be an example early in the org mode manual.

I don't think that's early enough in the bootstrapper's info
consumption pipeline. He's going to try to learn the basic keybinds
and UI of Emacs before diving into the Org manual. Otherwise how will
he even apply customizations? But it's definitely a step in the right
direction.

On Thu, Feb 6, 2020 at 8:40 PM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> On Thursday,  6 Feb 2020 at 20:09, Texas Cyberthal wrote:
> > A blank line is useful, yes. Use of demi-paragraphs implies use of
> > line breaks to signal stronger transitions. E.g., from my recent
> > workflow:
>
> I get this.  My own approach is to simply use - at the start of the line
> and then each of these demi-paragraphs becomes a list item which are
> wrapped nicely (whether with visual or fill mode).
>
> > What vanilla Emacs Org default visual-line-mode is missing for
> > informal prose notes:
> > - recognize sentences with a single space after terminal punctuation
>
> Does for me.  Maybe I've customized something... that's the problem with
> a .emacs file that has elements that date back 37 years... ;-)
>
> > - word wrap
>
> Not sure what you mean here.  Visual mode does this; so does fill
> mode.  What I am failing to understand from you is your frequent
> reference to truncation but then wanting wrapping?  I'm obviously
> missing something.
>
> > - more line spacing and a variable pitch font
>
> This is "look and feel" and easily addressed, as others have noted, by a
> theme.
>
> > - denote single line breaks with the absence of continuation marks, as
> > truncate lines nil does
>
> What about turning on whitespace-mode?
>
> > visual-line-mode's minor luxury of slightly easier navigation to
> > arbitrary visual line endpoints doesn't compensate for loss of the
> > critical ability to identify logical lines with single line breaks,
> > and the loss of keybinds for quick navigation to their endpoints.
>
> So turn off line-move-visual.
>
> I guess what I am saying is what I said earlier: a simple org mode hook
> with some settings would be all the customization you would need to
> achieve your desired writing experience and could easily be an example
> early in the org mode manual.
>
> Does spacemacs initialise things they way you want them?  If so, go with
> it but I guess there are other things about spacemacs that you do not
> like?
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Fraga, Eric]

Okay, I get it: Emacs (especially vanilla) just doesn't meet your
requirements.  So be it!  Horse for courses, as they say here in the
UK.  All I can say is that I find most, if not all, other tools so
frustrating.  I can never get them to work the way I want.  With Emacs,
I can.  Yes, this means that I have to work at customizing and this is
not easy for a beginner.  But I can.

One minor point, in case anybody else reading this thread might find
this useful:

>> What about turning on whitespace-mode?
>
> That makes all the spaces visible, which isn't legible.

As with all things Emacs, this is completely customizable.  You can have
whitespace mode show/highlight the bits you want and not the others.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Texas Cyberthal]

No, that isn't what I'm saying. I'm quite happy with Emacs, especially
Spacemacs. However, I had a much harder adoption experience than
necessary, and I find that the barriers to entry are preventing
normie-noobs from choosing Org as a PIM. So I intend to fix that.

On Fri, Feb 7, 2020 at 5:38 AM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> Okay, I get it: Emacs (especially vanilla) just doesn't meet your
> requirements.  So be it!  Horse for courses, as they say here in the
> UK.  All I can say is that I find most, if not all, other tools so
> frustrating.  I can never get them to work the way I want.  With Emacs,
> I can.  Yes, this means that I have to work at customizing and this is
> not easy for a beginner.  But I can.
>
> One minor point, in case anybody else reading this thread might find
> this useful:
>
> >> What about turning on whitespace-mode?
> >
> > That makes all the spaces visible, which isn't legible.
>
> As with all things Emacs, this is completely customizable.  You can have
> whitespace mode show/highlight the bits you want and not the others.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48

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

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

Greetings,

On Thu, Feb 6, 2020 at 5:33 PM Texas Cyberthal <texas.cyberthal@gmail.com>
wrote:

> No, that isn't what I'm saying. I'm quite happy with Emacs, especially
> Spacemacs. However, I had a much harder adoption experience than
> necessary, and I find that the barriers to entry are preventing
> normie-noobs from choosing Org as a PIM. So I intend to fix that.
>

I'm not sure this is on-topic, but... what about creating a separate
tutorial just org-mode?

The possibilities seem endless but, for example, this could
 * provide instruction for different primary use cases (for me:
note-taking, prose, agenda, habit, babel, and literature)
 * mention especially important customizations for the given usage
 * offer "express setup" buttons to instantly apply settings from a sample
configuration.

Finally, this could be added into the Emacs splash-screen alongside the
general tutorial.

I like the idea of promoting org-mode to people using Emacs for the first
time and I like the idea of sensible defaults, especially that reduce
frustrations for users new to the GNU tool-chain That said, org-mode is
lots of things to lots of people, even notwithstanding the reticence to
break things for people who've had them working the way the like for
decades.   I think this is fundamentally an education problem.   But even
if that's wrong, I think we should look closely at education as a solution.

-- 
*Corwin*
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
*corwin.brust (skype)corwin@bru.st <corwin@bru.st>*

[-- Attachment #2: Type: text/html, Size: 2836 bytes --]

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

[Texas Cyberthal]

That's a great idea. And if the Org tutorial included an easy option
to enable "PIM" mode for normie-noobs, so that Emacs starts behaving
like a PIM instead of an IDE, that would be even better. Someone who's
never coded before doesn't need IDE defaults.

On Fri, Feb 7, 2020 at 8:37 AM Corwin Brust <corwin@bru.st> wrote:
>
> Greetings,
>
> On Thu, Feb 6, 2020 at 5:33 PM Texas Cyberthal <texas.cyberthal@gmail.com> wrote:
>>
>> No, that isn't what I'm saying. I'm quite happy with Emacs, especially
>> Spacemacs. However, I had a much harder adoption experience than
>> necessary, and I find that the barriers to entry are preventing
>> normie-noobs from choosing Org as a PIM. So I intend to fix that.
>
>
> I'm not sure this is on-topic, but... what about creating a separate tutorial just org-mode?
>
> The possibilities seem endless but, for example, this could
>  * provide instruction for different primary use cases (for me: note-taking, prose, agenda, habit, babel, and literature)
>  * mention especially important customizations for the given usage
>  * offer "express setup" buttons to instantly apply settings from a sample configuration.
>
> Finally, this could be added into the Emacs splash-screen alongside the general tutorial.
>
> I like the idea of promoting org-mode to people using Emacs for the first time and I like the idea of sensible defaults, especially that reduce frustrations for users new to the GNU tool-chain That said, org-mode is lots of things to lots of people, even notwithstanding the reticence to break things for people who've had them working the way the like for decades.   I think this is fundamentally an education problem.   But even if that's wrong, I think we should look closely at education as a solution.
>
> --
> Corwin
> 612-217-1742
> 612-298-0615 (fax)
> 612-695-4276 (mobile)
> corwin.brust (skype)
> corwin@bru.st

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

[Texas Cyberthal]

Emacs has a giant normie-noob shaped hole in its intake funnel. The
warnings against using Emacs on Windows on the download page are good,
but not enough. Noobs need a positive recommendation of platform, and
a practical one, not ideological. It should say something like:

"If you've never coded, then Emacs can be very difficult if approached
wrong. Avoid Windows (unless you have someone to do your tech
support). Use MacOS (or a user-friendly Linux such as Ubuntu Mint).
Install Emacs with homebrew (on MacOS). Then install Spacemacs. Visit
their chat channel if you need help. Run the tutorial. Learn Org mode.
Become more productive!"

AFAIK Spacemacs is the only major consumer-oriented distro; the rest
are aimed at devs.

Dev-noobs will stick with Emacs cuz they need it for various techie
workflows and competing tools are similarly arcane. But normie-noobs
will bounce if they don't find a quick path to PIM.

Endorsing MacOS violates the free software ethos. But realistically,
normie-noobs shouldn't try Linux until they've learned Emacs. Emacs
allows them to control the Linux environment. Until then, Apple can
hold their hands. Getting them hooked on Emacs pretty much guarantees
they'll try Linux anyway. It's drug dealer marketing: the first hit is
always free.

How does that metaphor apply, if Emacs is already free software?
Because the cost of free software is the learning curve. Be as
ruthless about extracting that price as Microsoft is about extracting
theirs.