Convert some files from outline-mode to org-mode

Convert some files from outline-mode to org-mode

[Stefan Kangas]

In Bug#40813, I suggest the following:

    * CONTRIBUTE:
    * etc/CALC-NEWS:
    * etc/DEBUG:
    * etc/MACHINES:
    * etc/PROBLEMS:
    * etc/TODO: Use org-mode instead of outline-mode.

The reason is that I believe our users are more familiar with org-mode
than outline-mode, and that I simply think the interface is better.
It's the forward-looking, "modern" choice, if you like.

This was not met with undivided enthusiasm, and the suggestion was to
bring the discussion here.

Here's my attempt to summarize the counter-arguments:

(1) Outline-mode is in fact more well-known than org-mode.
(2) Org-mode increases memory consumption (by 1-3 MB).
(3) We could improve outline-mode by adding something like org-cycle (TAB).
(4) There's a slight delay when opening an org file for the first time
in a session.

I would say that (1) is hard to prove or disprove, and I have only
anecdotal evidence here.  Regarding (2), this is true but I disagree
that it's significant enough to worry about in this day and age.  It's
hard to argue against (3) but it needs an interested party to do it.
Finally, I don't know if anything can be done about (4).

So please make it known how you feel about this proposal.

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[Clément Pit-Claudel]

On 26/04/2020 11.43, Stefan Kangas wrote:
> In Bug#40813, I suggest the following:
> 
>     * CONTRIBUTE:
>     * etc/CALC-NEWS:
>     * etc/DEBUG:
>     * etc/MACHINES:
>     * etc/PROBLEMS:
>     * etc/TODO: Use org-mode instead of outline-mode.
> 
> So please make it known how you feel about this proposal.

This sounds like a great idea to me.  Yes please :)

I get very confused every time I open one of these files.  It looks sufficiently similar to org to switch my org-mode reflexes on, and besides I've never see the plain outline-mode used anywhere else.  Also, syntax highlighting is confusing (it's not clear what is a title and isn't, e.g. in etc/TODO some of the bullets are full titles and others are wrapped, causing weird highlighting inconsistencies).

Re: Convert some files from outline-mode to org-mode

[Stefan Monnier]

>>     * etc/TODO: Use org-mode instead of outline-mode.
>> So please make it known how you feel about this proposal.
> This sounds like a great idea to me.  Yes please :)
> I get very confused every time I open one of these files.  It looks
> sufficiently similar to org to switch my org-mode reflexes on, and besides
> I've never see the plain outline-mode used anywhere else.

I'm a sufficiently naive user of those systems that I must say I have no
idea what concrete difference it would make on those files.  From where
I stand the only visible difference for me would be that it might delay
the display of the buffer by a few seconds while Org-mode loads (tho
there's a chance, this cost would be recovered later when I open one of
my Org files in the same session).

So could someone summarize what are those "org-mode reflexes" that need
switching, as well as any other impact (including hypothetical future
benefits which will only materialize after we make further changes to
those files to take advantage of some Org features)?


        Stefan

Re: Convert some files from outline-mode to org-mode

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So could someone summarize what are those "org-mode reflexes" that need
> switching, as well as any other impact (including hypothetical future
> benefits which will only materialize after we make further changes to
> those files to take advantage of some Org features)?

What does "org-mode reflexes" mean here?

For me, the main motivation is better navigation.

As for future improvements, I'm not sure.  I'm not necessarily even
suggesting any.  But here's one idea: We have seen people make
mistakes with "+++" and "---" in NEWS before.  So how about using
org-mode tags, such that this:

+++
** New command 'undo-redo'.

Instead is written like:

** New command 'undo-redo'.                                      :documented:

That would be a whole lot clearer and easier on the eyes.  It's only
one line of text to set file specific tags, and once that's done it's
one command (C-c C-q) to use them.  Or indeed, one can just type
":documented:" manually after the headline if one doesn't want to use
the command or don't know it.

(One nice thing here is that when it's time for review, one could then
filter the file to look only for headlines tagged ":undocumented:" (or
whatever we would use) using org-sparse-tree.)

But I understand the point that there are just a small number of such
improvements that could be made.  In fact, I think we should be
careful not to make these files too "heavy" to use (as is Alan's
concern).

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[Stefan Monnier]

>> So could someone summarize what are those "org-mode reflexes" that need
>> switching, as well as any other impact (including hypothetical future
>> benefits which will only materialize after we make further changes to
>> those files to take advantage of some Org features)?
> What does "org-mode reflexes" mean here?

That's what I'm asking.  Clément used that term:

    I get very confused every time I open one of these files.  It looks
    sufficiently similar to org to switch my org-mode reflexes on, ...

> For me, the main motivation is better navigation.

I don't know what "better navigation" means concretely.

> But I understand the point that there are just a small number of such
> improvements that could be made.

That is not my point at all.  I don't know if those possible
improvements are few or not (nor how important they can be).
Which is why I'm asking.


        Stefan

Re: Convert some files from outline-mode to org-mode

[Clément Pit-Claudel]

On 26/04/2020 16.54, Stefan Monnier wrote:
>>> So could someone summarize what are those "org-mode reflexes" that need
>>> switching, as well as any other impact (including hypothetical future
>>> benefits which will only materialize after we make further changes to
>>> those files to take advantage of some Org features)?
>> What does "org-mode reflexes" mean here?
> 
> That's what I'm asking.  Clément used that term:
> 
>     I get very confused every time I open one of these files.  It looks
>     sufficiently similar to org to switch my org-mode reflexes on, ...

Expecting tab and S-tab to work, expecting lines starting with `*` to be titles, expecting M-RET to create new entries, wondering why entry bodies are not hidden when I open the file (since that's how my org-mode is configured), etc.

Re: Convert some files from outline-mode to org-mode

[H. Dieter Wilhelm]

Stefan Kangas <stefan@marxist.se> writes:
> In Bug#40813, I suggest the following:
>     * CONTRIBUTE:
>     * etc/CALC-NEWS:
>     * etc/DEBUG:
>     * etc/MACHINES:
>     * etc/PROBLEMS:
>     * etc/TODO:
> Use org-mode instead of outline-mode.

I'm switching for such files to org-mode.  The usage of outline-mode is
too clunky compared with org-mode outlining!

I'd be happy to see the intuitive and newbie friendly org-mode outlining
interface for outline-minor-mode in its application to other
major-modes.

   Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Convert some files from outline-mode to org-mode

[Alan Mackenzie]

Hello, Stefan.

On Sun, Apr 26, 2020 at 17:43:55 +0200, Stefan Kangas wrote:
> In Bug#40813, I suggest the following:

>     * CONTRIBUTE:
>     * etc/CALC-NEWS:
>     * etc/DEBUG:
>     * etc/MACHINES:
>     * etc/PROBLEMS:
>     * etc/TODO: Use org-mode instead of outline-mode.

> The reason is that I believe our users are more familiar with org-mode
> than outline-mode, and that I simply think the interface is better.
> It's the forward-looking, "modern" choice, if you like.

> This was not met with undivided enthusiasm, and the suggestion was to
> bring the discussion here.

> Here's my attempt to summarize the counter-arguments:

> (1) Outline-mode is in fact more well-known than org-mode.
> (2) Org-mode increases memory consumption (by 1-3 MB).
> (3) We could improve outline-mode by adding something like org-cycle (TAB).
> (4) There's a slight delay when opening an org file for the first time
> in a session.

You fail to represent my objection, here.  Let me restate it.

org-mode is a sledgehammer and the six outline-mode files are mere nuts.
The org-mode source files are 100 times as big as outline.el.

You do not have to "know" outline-mode to use it.  I certainly don't.
It is merely text-mode adorned with a few non-essential commands for
navigating via the outlines.  Anybody who can use Emacs at all can use
outline-mode.

By contrast, org-mode is a monster.  The learning time for org-mode must
be non-trivial.  If we switch these files to org-mode, org mode gurus
will fill them up with obscure org-mode constructs leaving everybody
else unable to work on these files without leaning org-mode.  In my case
I will have to relearn it each time I use it (since I will not be using
it enough to remember it).

I would emphasise here that I don't know org-mode at all.  I would
strongly object to being forced to learn it, merely to continue actively
contributing to Emacs.

> I would say that (1) is hard to prove or disprove, and I have only
> anecdotal evidence here.  Regarding (2), this is true but I disagree
> that it's significant enough to worry about in this day and age.  It's
> hard to argue against (3) but it needs an interested party to do it.
> Finally, I don't know if anything can be done about (4).

> So please make it known how you feel about this proposal.

> Best regards,
> Stefan Kangas

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Convert some files from outline-mode to org-mode

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de>:

> You fail to represent my objection, here.  Let me restate it.

Sorry, that was an oversight on my part.  Thanks for restating it.

> You do not have to "know" outline-mode to use it.  I certainly don't.
> It is merely text-mode adorned with a few non-essential commands for
> navigating via the outlines.

The same is true for org-mode, IMHO.  One can happily use org-mode
while ignoring all of the more complicated features.

The exceptions I can think of seem unlikely to be something we would
want to use (customized agenda, tables, babel, etc.).

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[Kévin Le Gouguec]

Alan Mackenzie <acm@muc.de> writes:

> org-mode is a sledgehammer and the six outline-mode files are mere nuts.
> The org-mode source files are 100 times as big as outline.el.
>
> You do not have to "know" outline-mode to use it.  I certainly don't.
> It is merely text-mode adorned with a few non-essential commands for
> navigating via the outlines.  Anybody who can use Emacs at all can use
> outline-mode.
>
> By contrast, org-mode is a monster.  The learning time for org-mode must
> be non-trivial.

OTOH,

- I don't think I will ever manage to remember any of the keybindings
  for the outline-(show|hide)-… functions, which means I will never be
  able to use the "selective display" feature advertised in
  outline-mode's docstring without a cheatsheet.

- With org-mode, I can simply TAB my way through a document without
  figuring out whether what I want to show/hide are entries, subtrees,
  children, branches, leaves, sublevels, bodies…

So, while I agree that org-mode is a sledgehammer for e.g. idly browsing
NEWS, from a user's point-of-view (at least this user) and to borrow
your terms, outline-mode "is a monster" with countless esoteric
keybindings; meanwhile, I definitely don't "have to know" org-mode to
use it; I just mindlessly hit TAB on the thing I want to show/hide.

As I said in the bug report, to me this looks like a good opportunity to
provide a friendlier section-cycling command for outline-mode; it
boggles my mind that outline-toggle-children isn't bound by default.

Re: Convert some files from outline-mode to org-mode

[Stefan Monnier]

> - I don't think I will ever manage to remember any of the keybindings
>   for the outline-(show|hide)-… functions,

For this reason I implemented `reveal-mode` ;-)


        Stefan

RE: Convert some files from outline-mode to org-mode

[Drew Adams]

> > I don't think I will ever manage to remember any of
> > the keybindings for the outline-(show|hide)-… functions,
> 
> For this reason I implemented `reveal-mode` ;-)

1. FWIW, both Org Mode and Outline Mode offer
all anyone needs to know about showing/hiding,
navigating, etc. - in the menu-bar menus.

I can't understand people lamenting an ability
to remember key bindings.  Especially veteran
users - they should know how to ask Emacs.

If you're in a mode you don't understand well,
use `C-h m' or `C-h b'.  If such help isn't
good enough then we should improve it.

And any veteran Emacs user should expect that
an important or longstanding major mode probably
also has one or more menu-bar menus, which can
help with key bindings.  And anyone who discovers
that some mode has a poor menu (or none) can file
a bug report to improve (or create) it.

2. It sounds like trivially adding TAB as a key
for cycling among items in Outline mode would,
regardless of what mode is used for NEWS, be a
good idea.  And such a lame argument shouldn't
be put forward as a reason to switch to Org mode
for NEWS.  (I'm not saying anything here about
which mode should be used for NEWS.)

Re: Convert some files from outline-mode to org-mode

[Kévin Le Gouguec]

Drew Adams <drew.adams@oracle.com> writes:

>> > I don't think I will ever manage to remember any of
>> > the keybindings for the outline-(show|hide)-… functions,
>> 
>> For this reason I implemented `reveal-mode` ;-)
>
> 1. FWIW, both Org Mode and Outline Mode offer
> all anyone needs to know about showing/hiding,
> navigating, etc. - in the menu-bar menus.
>
> I can't understand people lamenting an ability
> to remember key bindings.  Especially veteran
> users - they should know how to ask Emacs.
>
> If you're in a mode you don't understand well,
> use `C-h m' or `C-h b'.  If such help isn't
> good enough then we should improve it.
>
> And any veteran Emacs user should expect that
> an important or longstanding major mode probably
> also has one or more menu-bar menus, which can
> help with key bindings.

Yup, those (menus, C-h m, C-h b; in this specific case C-c C-h also
works nicely) are what I was referring to as "cheatsheets":

>> > I don't think I will ever manage to remember any of the
>> > keybindings for the outline-(show|hide)-… functions, which means
>> > I will never be able to use the "selective display" feature
>> > advertised in outline-mode's docstring without a cheatsheet.

The point being that yes, hopefully Emacs users can find their way to
a menu or a help buffer; but as org-mode shows we can aim for
something slightly more ergonomic.

If I have to whip these cheatsheets out every time I want to hide a
heading (which I used to do before I finally bound
outline-toggle-children to TAB), I might as well do away with
keybindings and just M-x outline-hide- TAB *squint* (or install
which-key and C-c *squint*).

> 2. It sounds like trivially adding TAB as a key
> for cycling among items in Outline mode would,
> regardless of what mode is used for NEWS, be a
> good idea.  And such a lame argument shouldn't
> be put forward as a reason to switch to Org mode
> for NEWS.  (I'm not saying anything here about
> which mode should be used for NEWS.)

Wholehearted agreement here.

RE: Convert some files from outline-mode to org-mode

[Drew Adams]

> The point being that yes, hopefully Emacs users can find their way to
> a menu or a help buffer; but as org-mode shows we can aim for
> something slightly more ergonomic.
> 
> If I have to whip these cheatsheets out every time I want to hide a
> heading (which I used to do before I finally bound
> outline-toggle-children to TAB), I might as well do away with
> keybindings and just M-x outline-hide- TAB *squint* (or install
> which-key and C-c *squint*).

To be clear (but I know you understood), I was
saying that menus, `C-h m', etc. mean that one
doesn't _need to remember_ all key bindings for
a mode.  They serve as a quick (yes) reminder.

Clearly, if someone uses the same menu item a few
times in the same session s?he might start using
the keyboard binding for it that's shown for it.

It's definitely not that the existence of such
help requires one to use it "every time" to
carry out a command.

Re: Convert some files from outline-mode to org-mode

[Jean-Christophe Helary]

> On Apr 28, 2020, at 0:23, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> The point being that yes, hopefully Emacs users can find their way to
>> a menu or a help buffer; but as org-mode shows we can aim for
>> something slightly more ergonomic.
>> 
>> If I have to whip these cheatsheets out every time I want to hide a
>> heading (which I used to do before I finally bound
>> outline-toggle-children to TAB), I might as well do away with
>> keybindings and just M-x outline-hide- TAB *squint* (or install
>> which-key and C-c *squint*).
> 
> To be clear (but I know you understood), I was
> saying that menus, `C-h m', etc. mean that one
> doesn't _need to remember_ all key bindings for
> a mode.  They serve as a quick (yes) reminder.

Yes but the issue here is that the apparent similitude between outline and org makes it difficult to know that one file is in outline and not in org and thus creates unnecessary friction that has to be solved by such reference. There would not be such friction if outline proposed a more reasonable navigation system.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Convert some files from outline-mode to org-mode

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - I don't think I will ever manage to remember any of the keybindings
>>   for the outline-(show|hide)-… functions,
>
> For this reason I implemented `reveal-mode` ;-)

Oh, that's nifty!

A shame that point must be on the ellipsis to trigger revealing though;
in the specific case of outline-mode, it might make sense to start
revealing when point moves to a heading (maybe only after invoking
commands such as outline-(previous|next)-visible-heading, so that moving
with C-n/C-p does not become jerky).

As things stand though it does improve the reading experience already
(using e.g. forward-sentence to move through NEWS entries).

Reveal-mode (was: Convert some files from outline-mode to org-mode)

[Stefan Monnier]

>>> - I don't think I will ever manage to remember any of the keybindings
>>>   for the outline-(show|hide)-… functions,
>> For this reason I implemented `reveal-mode` ;-)
> Oh, that's nifty!
> A shame that point must be on the ellipsis to trigger revealing though;

Agreed, it needs more work (during editing it sometimes misbehaves pretty
bad, hiding/folding the text you're in the process of editing, effectively
"kicking you out").

This said, revealing when point is "anywhere on the header" could be
annoying because it would tend to unfold headers over which you just
intend to skip (e.g. with C-n C-n to skip a header, the header would be
unfolded after the first C-n).


        Stefan

Re: Convert some files from outline-mode to org-mode

[Alan Mackenzie]

Hello, Kévin.

On Sun, Apr 26, 2020 at 23:54:57 +0200, Kévin Le Gouguec wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > org-mode is a sledgehammer and the six outline-mode files are mere nuts.
> > The org-mode source files are 100 times as big as outline.el.

> > You do not have to "know" outline-mode to use it.  I certainly don't.
> > It is merely text-mode adorned with a few non-essential commands for
> > navigating via the outlines.  Anybody who can use Emacs at all can use
> > outline-mode.

> > By contrast, org-mode is a monster.  The learning time for org-mode must
> > be non-trivial.

> OTOH,

> - I don't think I will ever manage to remember any of the keybindings
>   for the outline-(show|hide)-… functions, which means I will never be
>   able to use the "selective display" feature advertised in
>   outline-mode's docstring without a cheatsheet.

Neither can I.  When I need it, which is rarely, there's C-h m.

> - With org-mode, I can simply TAB my way through a document without
>   figuring out whether what I want to show/hide are entries, subtrees,
>   children, branches, leaves, sublevels, bodies…

But you can't use TAB to indent a line, or alternatively to insert a tab
character.  And how is a non-specialist user reading NEWS for a new
release going to find out about this TAB binding?

> So, while I agree that org-mode is a sledgehammer for e.g. idly browsing
> NEWS, from a user's point-of-view (at least this user) and to borrow
> your terms, outline-mode "is a monster" with countless esoteric
> keybindings;

There are not "countless" keybindings in outline-mode; there are just 26
defined commands, only some of which will have bindings.  By contrast,
in org-mode there are 798 defined commands.  That's a factor of 30
greater.

> meanwhile, I definitely don't "have to know" org-mode to use it; I
> just mindlessly hit TAB on the thing I want to show/hide.

That may be true up until somebody decides to insert some obscure
org-mode construct into NEWS.  With over 4 magabytes of source code
implementing it, there will be more than a few such constructs.

> As I said in the bug report, to me this looks like a good opportunity to
> provide a friendlier section-cycling command for outline-mode; it
> boggles my mind that outline-toggle-children isn't bound by default.

Maybe it should be.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Convert some files from outline-mode to org-mode

[Kévin Le Gouguec]

(Apologies for the duplicate message Alan, I hit reply instead of
followup.)


Alan Mackenzie <acm@muc.de> writes:

> Hello, Kévin.
>
>> - I don't think I will ever manage to remember any of the keybindings
>>   for the outline-(show|hide)-… functions, which means I will never be
>>   able to use the "selective display" feature advertised in
>>   outline-mode's docstring without a cheatsheet.
>
> Neither can I.  When I need it, which is rarely, there's C-h m.

As I said in my reply to Drew, this is what I call a "cheatsheet" :)

I have no complaint about C-h m, C-h b, C-c C-h, as long as I need them
"rarely", as you say.  When reading an outline, I _frequently_ open and
close headings.

>> - With org-mode, I can simply TAB my way through a document without
>>   figuring out whether what I want to show/hide are entries, subtrees,
>>   children, branches, leaves, sublevels, bodies…
>
> But you can't use TAB to indent a line, or alternatively to insert a tab
> character.  

A fair point, though correct me if I'm wrong, but it does not look like
we indent NEWS entries?

org-mode has a few ways to work around this conflict:

- TAB on an "empty" heading (e.g. right after one inserts a heading)
  cycles through section levels (by adding/removing asterisks),

- If org-indent-mode is nil, sections bodies are "hard-indented"; TAB on
  section bodies indents them to (1+ section-level), C-j auto-indents
  new lines.

  (Frustratingly, org-mode uses what I think of as the "old" convention
  to use RET as "plain newline" and C-j as "smart newline with indent".)

- If org-indent-mode is t, bodies are "soft-indented" (with line-prefix
  and wrap-prefix).

Any of these could be useful additions to outline-mode IMO.

>             And how is a non-specialist user reading NEWS for a new
> release going to find out about this TAB binding?

By default, org-mode only shows top-level section headings; subheadings
and bodies are elided.  The ellipsis is a visual cue that there are
things to expand.

Once the non-specialist user has this "EXPAND-ME" cue, admittedly they
still need to learn the binding.  Luckily with org-mode, there's just
one: TAB.

I wish I could reply "well obviously the non-specialist user will just
click on the heading and voilà!", but it looks like one needs to
(require 'org-mouse) first.  Ah well.  No reason this couldn't be
enabled by default in outline-mode.

>> So, while I agree that org-mode is a sledgehammer for e.g. idly browsing
>> NEWS, from a user's point-of-view (at least this user) and to borrow
>> your terms, outline-mode "is a monster" with countless esoteric
>> keybindings;
>
> There are not "countless" keybindings in outline-mode; there are just 26
> defined commands, only some of which will have bindings.  By contrast,
> in org-mode there are 798 defined commands.  That's a factor of 30
> greater.

Right, let me qualify this better:

- There are 11 commands with bindings for selecive display in
  outline-mode (5 show, 6 hide).

- There is only 1 command I care about for selective display in
  org-mode: TAB.

>> meanwhile, I definitely don't "have to know" org-mode to use it; I
>> just mindlessly hit TAB on the thing I want to show/hide.
>
> That may be true up until somebody decides to insert some obscure
> org-mode construct into NEWS.  With over 4 magabytes of source code
> implementing it, there will be more than a few such constructs.

No argument there; I'm not advocating for using org-mode with NEWS.

Though for all of org-mode's complexity, I have yet to see an Org file
where "mindlessly hitting TAB" does not show/hide the heading at point
(… as long as point is on a heading).

Re: Convert some files from outline-mode to org-mode

[Juri Linkov]

>   (Frustratingly, org-mode uses what I think of as the "old" convention
>   to use RET as "plain newline" and C-j as "smart newline with indent".)

There are many things that are frustrating in org-mode.
Many Emacs features are disabled in org-mode, and
standard keys are redefined to behave in own way.

What is worse, often org-mode takes freedom from users for no reason.
I mean such artificial restrictions as for example preventing users
from customizing positions of Org popup windows:

  (defmacro org-no-popups (&rest body)
    "Suppress popup windows and evaluate BODY."
    `(let (pop-up-frames display-buffer-alist)
       ,@body))

that ignores user customization in display-buffer-alist.

RE: Convert some files from outline-mode to org-mode

[Drew Adams]

> There are many things that are frustrating in org-mode.
> Many Emacs features are disabled in org-mode, and
> standard keys are redefined to behave in own way.
> 
> What is worse, often org-mode takes freedom from users for no reason.
> I mean such artificial restrictions as for example preventing users
> from customizing positions of Org popup windows:
> 
>   (defmacro org-no-popups (&rest body)
>     "Suppress popup windows and evaluate BODY."
>     `(let (pop-up-frames display-buffer-alist)
>        ,@body))
> 
> that ignores user customization in display-buffer-alist.

M-x report-emacs-bug.  ;-)

Re: Convert some files from outline-mode to org-mode

[John Yates]

On Mon, Apr 27, 2020 at 4:41 PM Juri Linkov <juri@linkov.net> wrote:

> There are many things that are frustrating in org-mode.
> Many Emacs features are disabled in org-mode, and
> standard keys are redefined to behave in own way.

This is indeed my overwhelming impression every
time I muster the courage to dip my toe into org-mode.

/john

Re: Convert some files from outline-mode to org-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There are many things that are frustrating in org-mode.
  > Many Emacs features are disabled in org-mode, and
  > standard keys are redefined to behave in own way.

I am not familiar with these aspects of Org mode, but it seems to me
that part of integrating the subsystems of Org mode better into Emacs
is to eliminate these little superficial incompatibilities from them.

There could be a separae mode, perhaps a minor mode, to make
these superficial modofications, so Org mode devotees
would still find it easy to have them.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Convert some files from outline-mode to org-mode

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> There could be a separae mode, perhaps a minor mode, to make
> these superficial modofications, so Org mode devotees
> would still find it easy to have them.

I suggest we don't refer to Org mode power users as "devotees":
the religious connotation of this word sounds a bit disparaging.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Nicolas Goaziou]

Hello,

Juri Linkov <juri@linkov.net> writes:

>>   (Frustratingly, org-mode uses what I think of as the "old" convention
>>   to use RET as "plain newline" and C-j as "smart newline with indent".)
>
> There are many things that are frustrating in org-mode.
> Many Emacs features are disabled in org-mode, and
> standard keys are redefined to behave in own way.
>
> What is worse, often org-mode takes freedom from users for no reason.
> I mean such artificial restrictions as for example preventing users
> from customizing positions of Org popup windows:
>
>   (defmacro org-no-popups (&rest body)
>     "Suppress popup windows and evaluate BODY."
>     `(let (pop-up-frames display-buffer-alist)
>        ,@body))
>
> that ignores user customization in display-buffer-alist.

As a side note, I'm positively sure Org developers would love help, or
better, code, to re-enable disabled Emacs features, and to give back
freedom to their users. 

I think most of these issues are historic artifacts no one dared, or
took time, to reconsider.

Regards,

-- 
Nicolas Goaziou

Re: Convert some files from outline-mode to org-mode

[H. Dieter Wilhelm]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Juri Linkov <juri@linkov.net> writes:
>
>>>   (Frustratingly, org-mode uses what I think of as the "old" convention
>>>   to use RET as "plain newline" and C-j as "smart newline with indent".)
>>
>> There are many things that are frustrating in org-mode.
>> Many Emacs features are disabled in org-mode, and
>> standard keys are redefined to behave in own way.
>>
>
> As a side note, I'm positively sure Org developers would love help, or
> better, code, to re-enable disabled Emacs features, and to give back
> freedom to their users. 
>
> I think most of these issues are historic artifacts no one dared, or
> took time, to reconsider.

What is a bit frustrating / confusing - even for me as a longtime org
fan - is the changed behaviour of the paragraph keybindings M-h and M-{
M-}.

    Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Convert some files from outline-mode to org-mode

[Nicolas Goaziou]

Hello,

dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) writes:

> What is a bit frustrating / confusing - even for me as a longtime org
> fan - is the changed behaviour of the paragraph keybindings M-h and M-{
> M-}.

I'm not sure I follow, because Org binds M-h to org-mark-element and
M-{ (resp. M-}) to org-backward-element (resp. org-forward-element), an
"element" being the generalization of a paragraph in Text mode.

I assume there's something in the behaviour of these functions that
frustrates you, but you didn't say what it is.

Regards,

-- 
Nicolas Goaziou

Re: Convert some files from outline-mode to org-mode

[H. Dieter Wilhelm]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) writes:
>
>> What is a bit frustrating / confusing - even for me as a longtime org
>> fan - is the changed behaviour of the paragraph keybindings M-h and M-{
>> M-}.
>
> I'm not sure I follow, because Org binds M-h to org-mark-element and
> M-{ (resp. M-}) to org-backward-element (resp. org-forward-element), an
> "element" being the generalization of a paragraph in Text mode.

Thank you for your request.

text-mode:

- M-h is selecting a paragraph and the separating empty line ABOVE the
  paragraph. M-h is selecting the next paragraph when you are between
  paragraphs

- M-h in the "list paragraph" is selecting the whole list and an empty
  line ABOVE the list.

org-mode:

- M-h is selecting a paragraph and the separating emtpty line BELOW the
  paragraph.  But only when you are in the paragraph and NOT in an empty
  line above the paragraph.

- M-h in the list paragraph is only selecting one "list line".  If you
  are in the list's first line it selects the whole list and an empty
  line BELOW the list

text-mode:

- M-{ is skipping to am empty line behind the paragraph also when you
  are in a line ABOVE the paragraph

org-mode

- M-{ is skpping to the next paragraph but not when you are in the line
  ABOVE the paragraph, then it is skipping to the next header (*) line!

- M-{ in a list paragraph is only skipping to the next list line.  But
  not when you are in the first list line, then it is skipping to the
  next header in the example below.

Analogue for M-}

Please consider the following in org-mode and text-mode
----------------------------------------------------------------------
** New option 'help-enable-completion-auto-load'.

This allows disabling the new feature introduced in Emacs 26.1 which
loads files during completion of 'C-h f' and 'C-h v' according to
'definition-prefixes'.


This allows disabling the new feature introduced in Emacs 26.1 which
loads files during completion of 'C-h f' and 'C-h v' according to
'definition-prefixes'.

   - bla
   - otot
   - nix
   - hoho

** bla
----------------------------------------------------------------------

Hope that helps

      Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Convert some files from outline-mode to org-mode

[Juri Linkov]

>>>   (Frustratingly, org-mode uses what I think of as the "old" convention
>>>   to use RET as "plain newline" and C-j as "smart newline with indent".)
>>
>> There are many things that are frustrating in org-mode.
>> Many Emacs features are disabled in org-mode, and
>> standard keys are redefined to behave in own way.
>>
>> What is worse, often org-mode takes freedom from users for no reason.
>> I mean such artificial restrictions as for example preventing users
>> from customizing positions of Org popup windows:
>>
>>   (defmacro org-no-popups (&rest body)
>>     "Suppress popup windows and evaluate BODY."
>>     `(let (pop-up-frames display-buffer-alist)
>>        ,@body))
>>
>> that ignores user customization in display-buffer-alist.
>
> As a side note, I'm positively sure Org developers would love help, or
> better, code, to re-enable disabled Emacs features, and to give back
> freedom to their users. 
>
> I think most of these issues are historic artifacts no one dared, or
> took time, to reconsider.

Nice to hear.  Maybe it would be possible to group all specific
keybindings (that override the default Emacs commands) into a mode
enabled by default, but that could be easily disabled, resetting them
to their original definitions.

Re: Convert some files from outline-mode to org-mode

[Nicolas Goaziou]

Hello,

Juri Linkov <juri@linkov.net> writes:

> Nice to hear.  Maybe it would be possible to group all specific
> keybindings (that override the default Emacs commands) into a mode
> enabled by default, but that could be easily disabled, resetting them
> to their original definitions.

In recent Org releases, all keybindings are located in the same
"org-keys.el" file. So it sounds easy enough to create minor mode that
basically undoes what Org does.

However, from the Org perspective, this would be rather pointless, if
not self-defeating. The very purpose of this major mode is to provide
tooling (including bindings) to operate on Org files, i.e., text files
written in Org syntax. I think removing most of these tools would create
a terrible editing experience for no benefit. For example, having RET
inserting a plain newline would be a disaster in many locations (e.g.,
on a headline, in a table).

While I invite you to implement and test the minor mode you are
suggesting, I think ignoring what Org needs is a dead-end. It would be
more beneficial to start from those needs, and think about what can be
done to reconcile them with usual Emacs' ways. For example, Org expects
a specific, context-aware, "newline and indent" function. But it could
include support for Electric Indent mode. Would Someone™ want to help in
that area?

WDYT?

Regards,

-- 
Nicolas Goaziou

Reconciling org-mode idiosyncrasies with Emacs core (was: Convert some files from outline-mode to org-mode)

[Kévin Le Gouguec]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>                                               For example, having RET
> inserting a plain newline would be a disaster in many locations.

I don't think I've seen anybody advocating for that!  If you are
referring to this bit:

>   (Frustratingly, org-mode uses what I think of as the "old" convention
>   to use RET as "plain newline" and C-j as "smart newline with indent".)

If anything, I was advocating for RET not to insert a plain newline *at
all* (when electric-indent-mode is t, anyway).

>                                                For example, Org expects
> a specific, context-aware, "newline and indent" function. But it could
> include support for Electric Indent mode. Would Someone™ want to help in
> that area?

Do you think a patch that

- tweaked org-return (bound to RET) to default its INDENT argument to
  the current value of electric-indent-mode,

- tweaked org-return-indent (bound to C-j) to call
  electric-newline-and-maybe-indent (the new default binding for C-j
  everywhere else in Emacs, which takes care of consulting
  electric-indent-mode) instead of newline-and-indent,

would be well-received?  I would love to cook up such a patch, but I
would be loath to break the workflows of long-time Org users who have
come to rely on C-j indenting and RET inserting plain newlines …

Re: Reconciling org-mode idiosyncrasies with Emacs core

[Nicolas Goaziou]

Hello,

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>>                                               For example, having RET
>> inserting a plain newline would be a disaster in many locations.
>
> I don't think I've seen anybody advocating for that!  If you are
> referring to this bit:
>
>>   (Frustratingly, org-mode uses what I think of as the "old" convention
>>   to use RET as "plain newline" and C-j as "smart newline with indent".)

No I wasn't. I was referring to Juri Linkov's idea of providing a minor
mode to disable every single Org specific binding.

> Do you think a patch that
>
> - tweaked org-return (bound to RET) to default its INDENT argument to
>   the current value of electric-indent-mode,
>
> - tweaked org-return-indent (bound to C-j) to call
>   electric-newline-and-maybe-indent (the new default binding for C-j
>   everywhere else in Emacs, which takes care of consulting
>   electric-indent-mode) instead of newline-and-indent,
>
> would be well-received?  I would love to cook up such a patch, but I
> would be loath to break the workflows of long-time Org users who have
> come to rely on C-j indenting and RET inserting plain newlines …

It will break some workflows (mine, at least), undoubtedly, but it is
a step forward anyway. Org is a part of Emacs, there's no reason for the
former to follow a different path than the latter. Besides, undoing the
change is easy enough, since you only need to disable Electric Indent
mode.

The change will not appear overnight in Org, i.e., not in Org stable's
branch (Org 9.3.X), and it will be announced in ORG-NEWS. I do think it
is a very welcome change. Thank you.

I cleaned a bit Cc header and added Org mode list for further comments.

Regards,

-- 
Nicolas Goaziou

Re: Reconciling org-mode idiosyncrasies with Emacs core

[Kévin Le Gouguec]

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

Hi Nicolas,

I took a stab at making RET obey electric-indent-mode in org-mode.  I've
got something working; I'd like to ask for a review before moving on to
Changelog and ORG-NEWS entries (and tackling C-j… and maybe writing a
few unit tests?).

Here's the patch, with some additional comments below:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-return.patch --]
[-- Type: text/x-patch, Size: 2515 bytes --]

diff --git a/lisp/org.el b/lisp/org.el
index e82463046..681328d96 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17644,20 +17644,32 @@ call `open-line' on the very first character."
       (org-table-insert-row)
     (open-line n)))
 
-(defun org-return (&optional indent)
+(defun org--newline (indent arg interactive)
+  "Call `newline-and-indent' or just `newline'.
+
+If INDENT is non-nil, call `newline-and-indent' with ARG to
+indent unconditionally; otherwise, call `newline' with ARG and
+INTERACTIVE, which can trigger indentation if
+`electric-indent-mode' is enabled."
+  (if indent
+      (newline-and-indent arg)
+    (newline arg interactive)))
+
+(defun org-return (&optional indent arg interactive)
   "Goto next table row or insert a newline.
 
 Calls `org-table-next-row' or `newline', depending on context.
 
 When optional INDENT argument is non-nil, call
-`newline-and-indent' instead of `newline'.
+`newline-and-indent' with ARG, otherwise call `newline' with ARG
+and INTERACTIVE.
 
 When `org-return-follows-link' is non-nil and point is on
 a timestamp or a link, call `org-open-at-point'.  However, it
 will not happen if point is in a table or on a \"dead\"
 object (e.g., within a comment).  In these case, you need to use
 `org-open-at-point' directly."
-  (interactive)
+  (interactive "*i\nP\np")
   (let ((context (if org-return-follows-link (org-element-context)
 		   (org-element-at-point))))
     (cond
@@ -17708,23 +17720,20 @@ object (e.g., within a comment).  In these case, you need to use
 	 (t (org--align-tags-here tags-column))) ;preserve tags column
 	(end-of-line)
 	(org-show-entry)
-	(if indent (newline-and-indent) (newline))
+	(org--newline indent arg interactive)
 	(when string (save-excursion (insert (org-trim string))))))
      ;; In a list, make sure indenting keeps trailing text within.
-     ((and indent
-	   (not (eolp))
+     ((and (not (eolp))
 	   (org-element-lineage context '(item)))
       (let ((trailing-data
 	     (delete-and-extract-region (point) (line-end-position))))
-	(newline-and-indent)
+	(org--newline indent arg interactive)
 	(save-excursion (insert trailing-data))))
      (t
       ;; Do not auto-fill when point is in an Org property drawer.
       (let ((auto-fill-function (and (not (org-at-property-p))
 				     auto-fill-function)))
-	(if indent
-	    (newline-and-indent)
-	  (newline)))))))
+	(org--newline indent arg interactive))))))
 
 (defun org-return-indent ()
   "Goto next table row or insert a newline and indent.

[-- Attachment #3: Type: text/plain, Size: 1918 bytes --]


Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> Do you think a patch that
>>
>> - tweaked org-return (bound to RET) to default its INDENT argument to
>>   the current value of electric-indent-mode,

After taking an in-depth look at 'org-return' and 'newline', I decided
to "let the knife do the work" and simply keep calling 'newline', though
with additional arguments:

- INTERACTIVE is what makes 'newline' run 'post-self-insert-hook' (thus
  triggering indentation through electric-indent-mode),

- ARG wasn't strictly necessary, but it seemed harmless to add it, and
  it allows inserting multiple newlines, thus removing one more "Org
  idiosyncrasy".

I felt that introducing org--newline made the code clearer, but I can
understand if it seems too trivial to keep.  I took the liberty of using
this function in the "list item" case too, otherwise there's no way to
indent the trailing text.


> The change will not appear overnight in Org, i.e., not in Org stable's
> branch (Org 9.3.X), and it will be announced in ORG-NEWS.

I'll work on ORG-NEWS (plus Changelog entries, plus unit tests) as soon
as I'm confident that my approach is satisfactory.

(Out of curiosity, could it be argued that this is solving a "bug" in
org-mode and, as such, could be committed to Emacs core first, then
backported to the org-mode repository?  I don't feel strongly either
way, I wouldn't want to make things more complicated for Org
maintainers.)


Now for C-j, in order to minimize breakage (for anyone calling
org-return-indent from Lisp code) and simplify disabling the new
behaviour (by simply turning off electric-indent-mode in Org), should we
bind C-j to a new function?  E.g.:

(defun org-return-and-maybe-indent ()
  (interactive)
  (org-return (not electric-indent-mode)))


Thank you for your time.

Re: Reconciling org-mode idiosyncrasies with Emacs core

[Nicolas Goaziou]

Hello,

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I took a stab at making RET obey electric-indent-mode in org-mode.

Thank you!

> I've got something working; I'd like to ask for a review before moving
> on to Changelog and ORG-NEWS entries (and tackling C-j… and maybe
> writing a few unit tests?).

Tests for `org-return' (named "test-org/return") are in the
"test-org.el" file in the "testing/lisp" directory. We only need to test
if electric-indent-mode has an effect, but only in regular cases.

> Here's the patch, with some additional comments below:

It looks good.

> - INTERACTIVE is what makes 'newline' run 'post-self-insert-hook' (thus
>   triggering indentation through electric-indent-mode),

OK. I thought it was necessary to call
`electric-newline-and-maybe-indent'.

> - ARG wasn't strictly necessary, but it seemed harmless to add it, and
>   it allows inserting multiple newlines, thus removing one more "Org
>   idiosyncrasy".

Good idea.

> I felt that introducing org--newline made the code clearer, but I can
> understand if it seems too trivial to keep.

No, that's fine.

> I took the liberty of using
> this function in the "list item" case too, otherwise there's no way to
> indent the trailing text.

I'm not sure what you mean. It would be a regression if you didn't use
the function there, too, wouldn't it?

> (Out of curiosity, could it be argued that this is solving a "bug" in
> org-mode and, as such, could be committed to Emacs core first, then
> backported to the org-mode repository?  I don't feel strongly either
> way, I wouldn't want to make things more complicated for Org
> maintainers.)

I cannot speak for the Emacs side, but it should land in Org 9.4, not
Org 9.3.6.

It is a very visible change, one that every Org user is going to face.
This requires a new ORG-NEWS entry. Those only appear in new minor+
releases. Therefore, if you apply it in Emacs 27.1, the change will be
announced nowhere.

> Now for C-j, in order to minimize breakage (for anyone calling
> org-return-indent from Lisp code) and simplify disabling the new
> behaviour (by simply turning off electric-indent-mode in Org), should we
> bind C-j to a new function?  E.g.:
>
> (defun org-return-and-maybe-indent ()
>   (interactive)
>   (org-return (not electric-indent-mode)))

I think so. Then we can mark `org-return-indent' as obsolete and suggest
to call `org-return' instead.

Regards,

-- 
Nicolas Goaziou

Re: Reconciling org-mode idiosyncrasies with Emacs core

[Kévin Le Gouguec]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Tests for `org-return' (named "test-org/return") are in the
> "test-org.el" file in the "testing/lisp" directory. We only need to test
> if electric-indent-mode has an effect, but only in regular cases.

Thanks for the pointer!

(I forgot to mention that AFAICT, all current tests pass with this
patch.)

>> - INTERACTIVE is what makes 'newline' run 'post-self-insert-hook' (thus
>>   triggering indentation through electric-indent-mode),
>
> OK. I thought it was necessary to call
> `electric-newline-and-maybe-indent'.

Nope; took me some time to piece everything together, but the logic (as
of 24.4) seems to be

- RET runs `newline': if electric-indent-mode is disabled, then it's a
  dumb newline, otherwise electric-indent-post-self-insert-function
  kicks in *if run interactively*;

- C-j runs `electric-newline-and-maybe-indent': it's meant to be the
  "smart newline" command when electric-indent-mode is disabled,
  otherwise it shrugs and just inserts a newline.

>> I took the liberty of using
>> this function in the "list item" case too, otherwise there's no way to
>> indent the trailing text.
>
> I'm not sure what you mean. It would be a regression if you didn't use
> the function there, too, wouldn't it?

The "list-item" case currently calls `newline-and-indent'
unconditionally, because the condition for that cond branch starts with
(and indent …).  Therefore, to make this case work with
electric-indent-mode, I had to tweak the condition; I just wanted to
bring attention to this change, since it was not as "mechanical" as for
the "at-headline" and "default" branches.

> I cannot speak for the Emacs side, but it should land in Org 9.4, not
> Org 9.3.6.
>
> It is a very visible change, one that every Org user is going to face.
> This requires a new ORG-NEWS entry. Those only appear in new minor+
> releases. Therefore, if you apply it in Emacs 27.1, the change will be
> announced nowhere.

Right.  Org master it is, then.

>> Now for C-j, in order to minimize breakage (for anyone calling
>> org-return-indent from Lisp code) and simplify disabling the new
>> behaviour (by simply turning off electric-indent-mode in Org), should we
>> bind C-j to a new function?  E.g.:
>>
>> (defun org-return-and-maybe-indent ()
>>   (interactive)
>>   (org-return (not electric-indent-mode)))
>
> I think so. Then we can mark `org-return-indent' as obsolete and suggest
> to call `org-return' instead.

Alright.


I'll try to follow-up with this additional command, tests, and
changelog/news entries in the next few days.

Thank you for the review!

[PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode (was: Reconciling org-mode idiosyncrasies with Emacs core)

[Kévin Le Gouguec]

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

Hello folks,

Here's a complete patch to make RET and C-j honor electric-indent-mode
in org-mode, targeting Org's master branch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-RET-and-C-j-obey-electric-indent-mode.patch --]
[-- Type: text/x-patch, Size: 12251 bytes --]

From ec3b06f02aa875b3c78b076e846081ce4560ec18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec@gmail.com>
Date: Tue, 5 May 2020 19:01:07 +0200
Subject: [PATCH] Make RET and C-j obey `electric-indent-mode'

* etc/ORG-NEWS: Announce the change.

* lisp/org-compat.el (org-return-indent): Deprecate this command.

* lisp/org-keys.el (org-mode-map): Rebind C-j to a command emulating
`electric-newline-and-maybe-indent'.

* lisp/org.el (org-cdlatex-environment-indent): Stop using the now
obsolete function.
(org--newline): New helper function.
(org-return): Use it to transparently handle `electric-indent-mode'.
(org-return-and-maybe-indent): New command to emulate
`electric-newline-and-maybe-indent' while taking care of Org special
cases (tables, links, timestamps).

* testing/lisp/test-org.el (test-org/with-electric-indent,
test-org/without-electric-indent): New tests.

* testing/org-test.el (org-test-with-minor-mode): New helper to set a
minor mode to a specific state, and reset it afterward.
---
 etc/ORG-NEWS             | 33 +++++++++++++++++
 lisp/org-compat.el       |  9 +++++
 lisp/org-keys.el         |  2 +-
 lisp/org.el              | 43 ++++++++++++++---------
 testing/lisp/test-org.el | 76 ++++++++++++++++++++++++++++++++++++++++
 testing/org-test.el      |  9 +++++
 6 files changed, 155 insertions(+), 17 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c10e82f53..9c7e0d604 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -215,6 +215,32 @@ configured for ClojureScript will /not/ work.
 Babel Java blocks recognize header argument =:cmdargs= and pass its
 value in call to =java=.
 
+*** =RET= and =C-j= now obey ~electric-indent-mode~
+
+Since Emacs 24.4, ~electric-indent-mode~ is enabled by default.  In
+most major modes, this causes =RET= to reindent the current line and
+indent the new line, and =C-j= to insert a newline without indenting.
+
+Org-mode now obeys this minor mode: when ~electric-indent-mode~ is
+enabled, and point is neither in a table nor on a timestamp or a link:
+
+- =RET= (bound to ~org-return~) reindents the current line and indents
+  the new line;
+- =C-j= (bound to the new command ~org-return-and-maybe-indent~)
+  merely inserts a newline.
+
+To get the previous behaviour back, disable ~electric-indent-mode~
+explicitly:
+
+#+begin_src emacs-lisp
+(add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
+#+end_src
+
+*** New optional numeric argument for ~org-return~
+
+In situations where ~org-return~ calls ~newline~, multiple newlines
+can now be inserted with this prefix argument.
+
 ** New commands
 *** ~org-table-header-line-mode~
 
@@ -303,6 +329,13 @@ Use ~org-hide-block-toggle~ instead.
 This function was not used in the code base, and has no clear use
 either.  It has been marked for future removal.  Please contact the
 mailing list if you use this function.
+
+*** Deprecated ~org-return-indent~ function
+
+In Elisp code, use ~(org-return t)~ instead.  Interactively, =C-j= is
+now bound to ~org-return-and-maybe-indent~, which indents the new line
+when ~electric-indent-mode~ is disabled.
+
 *** Removed ~org-maybe-keyword-time-regexp~
 
 The variable was not used in the code base.
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index aae8efbd3..2b35535fa 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -678,6 +678,15 @@ an error.  Return a non-nil value when toggling is successful."
             (goto-char (match-beginning 0))
             (org-hide-block-toggle)))))))
 
+(defun org-return-indent ()
+  "Goto next table row or insert a newline and indent.
+Calls `org-table-next-row' or `newline-and-indent', depending on
+context.  See the individual commands for more information."
+  (declare (obsolete "use `org-return' with INDENT set to t instead."
+		     "Org 9.4"))
+  (interactive)
+  (org-return t))
+
 (defmacro org-with-silent-modifications (&rest body)
   (declare (obsolete "use `with-silent-modifications' instead." "Org 9.2")
 	   (debug (body)))
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index d358da763..7c0cc9216 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -618,7 +618,7 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names."
 (org-defkey org-mode-map (kbd "C-c C-k") #'org-kill-note-or-show-branches)
 (org-defkey org-mode-map (kbd "C-c #") #'org-update-statistics-cookies)
 (org-defkey org-mode-map (kbd "RET") #'org-return)
-(org-defkey org-mode-map (kbd "C-j") #'org-return-indent)
+(org-defkey org-mode-map (kbd "C-j") #'org-return-and-maybe-indent)
 (org-defkey org-mode-map (kbd "C-c ?") #'org-table-field-info)
 (org-defkey org-mode-map (kbd "C-c SPC") #'org-table-blank-field)
 (org-defkey org-mode-map (kbd "C-c +") #'org-table-sum)
diff --git a/lisp/org.el b/lisp/org.el
index 63de7306c..dbd072aff 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15580,7 +15580,7 @@ environment remains unintended."
       ;; Get indentation of next line unless at column 0.
       (let ((ind (if (bolp) 0
 		   (save-excursion
-		     (org-return-indent)
+		     (org-return t)
 		     (prog1 (current-indentation)
 		       (when (progn (skip-chars-forward " \t") (eolp))
 			 (delete-region beg (point)))))))
@@ -17647,20 +17647,31 @@ call `open-line' on the very first character."
       (org-table-insert-row)
     (open-line n)))
 
-(defun org-return (&optional indent)
+(defun org--newline (indent arg interactive)
+  "Call `newline-and-indent' or just `newline'.
+If INDENT is non-nil, call `newline-and-indent' with ARG to
+indent unconditionally; otherwise, call `newline' with ARG and
+INTERACTIVE, which can trigger indentation if
+`electric-indent-mode' is enabled."
+  (if indent
+      (newline-and-indent arg)
+    (newline arg interactive)))
+
+(defun org-return (&optional indent arg interactive)
   "Goto next table row or insert a newline.
 
 Calls `org-table-next-row' or `newline', depending on context.
 
 When optional INDENT argument is non-nil, call
-`newline-and-indent' instead of `newline'.
+`newline-and-indent' with ARG, otherwise call `newline' with ARG
+and INTERACTIVE.
 
 When `org-return-follows-link' is non-nil and point is on
 a timestamp or a link, call `org-open-at-point'.  However, it
 will not happen if point is in a table or on a \"dead\"
 object (e.g., within a comment).  In these case, you need to use
 `org-open-at-point' directly."
-  (interactive)
+  (interactive "*i\nP\np")
   (let ((context (if org-return-follows-link (org-element-context)
 		   (org-element-at-point))))
     (cond
@@ -17711,30 +17722,30 @@ object (e.g., within a comment).  In these case, you need to use
 	 (t (org--align-tags-here tags-column))) ;preserve tags column
 	(end-of-line)
 	(org-show-entry)
-	(if indent (newline-and-indent) (newline))
+	(org--newline indent arg interactive)
 	(when string (save-excursion (insert (org-trim string))))))
      ;; In a list, make sure indenting keeps trailing text within.
-     ((and indent
-	   (not (eolp))
+     ((and (not (eolp))
 	   (org-element-lineage context '(item)))
       (let ((trailing-data
 	     (delete-and-extract-region (point) (line-end-position))))
-	(newline-and-indent)
+	(org--newline indent arg interactive)
 	(save-excursion (insert trailing-data))))
      (t
       ;; Do not auto-fill when point is in an Org property drawer.
       (let ((auto-fill-function (and (not (org-at-property-p))
 				     auto-fill-function)))
-	(if indent
-	    (newline-and-indent)
-	  (newline)))))))
+	(org--newline indent arg interactive))))))
 
-(defun org-return-indent ()
-  "Goto next table row or insert a newline and indent.
-Calls `org-table-next-row' or `newline-and-indent', depending on
-context.  See the individual commands for more information."
+(defun org-return-and-maybe-indent ()
+  "Goto next table row, or insert a newline.
+Call `org-table-next-row' or `org-return', depending on context.
+See the individual commands for more information.
+
+When inserting a newline, indent the new line if
+`electric-indent-mode' is disabled."
   (interactive)
-  (org-return t))
+  (org-return (not electric-indent-mode)))
 
 (defun org-ctrl-c-tab (&optional arg)
   "Toggle columns width in a table, or show children.
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 2c78e1e23..d481d28e3 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1310,6 +1310,82 @@
 	    (org-return)
 	    (buffer-string)))))
 
+(ert-deftest test-org/with-electric-indent ()
+  "Test RET and C-j specifications with `electric-indent-mode' on."
+  ;; Call commands interactively, since this is how `newline' knows it
+  ;; must run `post-self-insert-hook'.
+  (org-test-with-minor-mode electric-indent-mode t
+    ;; RET, like `newline', should indent.
+    (should
+     (equal "  Para\n  graph"
+	    (org-test-with-temp-text "  Para<point>graph"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    (should
+     (equal "- item1\n  item2"
+	    (org-test-with-temp-text "- item1<point>item2"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    (should
+     (equal "* heading\n  body"
+	    (org-test-with-temp-text "* heading<point>body"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    ;; C-j, like `electric-newline-and-maybe-indent', should not indent.
+    (should
+     (equal "  Para\ngraph"
+	    (org-test-with-temp-text "  Para<point>graph"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))
+    (should
+     (equal "- item1\nitem2"
+	    (org-test-with-temp-text "- item1<point>item2"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))
+    (should
+     (equal "* heading\nbody"
+	    (org-test-with-temp-text "* heading<point>body"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))))
+
+(ert-deftest test-org/without-electric-indent ()
+  "Test RET and C-j specifications with `electric-indent-mode' off."
+  ;; Call commands interactively, since this is how `newline' knows it
+  ;; must run `post-self-insert-hook'.
+  (org-test-with-minor-mode electric-indent-mode nil
+    ;; RET, like `newline', should not indent.
+    (should
+     (equal "  Para\ngraph"
+	    (org-test-with-temp-text "  Para<point>graph"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    (should
+     (equal "- item1\nitem2"
+	    (org-test-with-temp-text "- item1<point>item2"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    (should
+     (equal "* heading\nbody"
+	    (org-test-with-temp-text "* heading<point>body"
+	      (call-interactively 'org-return)
+	      (buffer-string))))
+    ;; C-j, like `electric-newline-and-maybe-indent', should indent.
+    (should
+     (equal "  Para\n  graph"
+	    (org-test-with-temp-text "  Para<point>graph"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))
+    (should
+     (equal "- item1\n  item2"
+	    (org-test-with-temp-text "- item1<point>item2"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))
+    (should
+     (equal "* heading\n  body"
+	    (org-test-with-temp-text "* heading<point>body"
+	      (call-interactively 'org-return-and-maybe-indent)
+	      (buffer-string))))))
+
 (ert-deftest test-org/meta-return ()
   "Test M-RET (`org-meta-return') specifications."
   ;; In a table field insert a row above.
diff --git a/testing/org-test.el b/testing/org-test.el
index 6904e16d1..69cdb905b 100644
--- a/testing/org-test.el
+++ b/testing/org-test.el
@@ -230,6 +230,15 @@ point at the beginning of the buffer."
 	 (delete-file file)))))
 (def-edebug-spec org-test-with-temp-text-in-file (form body))
 
+(defmacro org-test-with-minor-mode (mode state &rest body)
+  "Run BODY after setting MODE to STATE.
+Restore MODE to its former state afterward."
+  (declare (debug (sexp sexp body)) (indent 2))
+  `(let ((old-state ,mode))
+       (,mode (if ,state 1 0))
+       ,@body
+       (,mode (if old-state 1 0))))
+
 (defun org-test-table-target-expect (target &optional expect laps
 &rest tblfm)
   "For all TBLFM: Apply the formula to TARGET, compare EXPECT with result.
-- 
2.26.2


[-- Attachment #3: Type: text/plain, Size: 1319 bytes --]


To summarize (see also the patch's changelog message, and the ORG-NEWS
entries which explain how to restore the current behaviour):

- `org-return' (bound to RET) gains new arguments, and an interactive
  spec matching `newline'.

- In situations where `org-return' must insert a newline,

    - if the INDENT argument is non-nil, `newline-and-indent' is called
      unconditionally, as before,

    - otherwise, `newline' is called with ARG and INTERACTIVE; if
      electric-indent-mode is on and INTERACTIVE is non-nil, this will
      trigger indentation.

- `org-return-indent', the previous binding for C-j, is deprecated.

- C-j is now bound to `org-return-and-maybe-indent', which calls
  (org-return t) when electric-indent-mode is disabled, and
  (org-return nil) otherwise.

- In addition to the new unit tests, there is a new test helper to
  temporarily set or unset a minor mode.


Let me know if I messed up something, or if there are things to tweak
here and there.  org-test-with-minor-mode might be overkill (and I am
not used to writing macros, let alone edebug specs, so I might have
goofed somewhere), but it does make the tests easier to read & write,
so… 🤷

(I'm surprised such a macro does not already exist; did I miss it?)


Thank you for your time.

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Nicolas Goaziou]

Hello,

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Here's a complete patch to make RET and C-j honor electric-indent-mode
> in org-mode, targeting Org's master branch.

Thank you very much.

I fixed a typo and applied your patch.

> +(defmacro org-test-with-minor-mode (mode state &rest body)
> +  "Run BODY after setting MODE to STATE.
> +Restore MODE to its former state afterward."
> +  (declare (debug (sexp sexp body)) (indent 2))
> +  `(let ((old-state ,mode))
> +       (,mode (if ,state 1 0))
> +       ,@body
> +       (,mode (if old-state 1 0))))

This is a nice macro.

However, when I have to reproduce a failing test, I don't even want to
think about the recipe and rather concentrate on the results. Hence,
I expect `should' macro's body to be self-sufficient. Therefore,
I skipped this part of the patch.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Kévin Le Gouguec]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I fixed a typo and applied your patch.

Thank you for fixing the typo in ORG-NEWS.

I see you've removed ARG from the call to `newline-and-indent'; I don't
have a strong opinion about this (though I don't see a reason not to
keep it), but I guess the docstring of `org--newline' should be changed
to match?

> However, when I have to reproduce a failing test, I don't even want to
> think about the recipe and rather concentrate on the results. Hence,
> I expect `should' macro's body to be self-sufficient. Therefore,
> I skipped this part of the patch.

Fair enough; toggling the local variant of the minor mode is probably
cleaner anyway!


Thanks for the review, and for applying.

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Nicolas Goaziou]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I see you've removed ARG from the call to `newline-and-indent'; I don't
> have a strong opinion about this (though I don't see a reason not to
> keep it), but I guess the docstring of `org--newline' should be changed
> to match?

AFAICT, `newline-and-indent' doesn't accept any argument. Keeping it
introduces a build warning and test failures. Hence the removal.

Since you were calling it with an argument I assume this may be
a novelty in Emacs 27. However Org still supports Emacs 24.4. If that's
the case, we need an additional compatibility layer to support both
cases. WDYT?

Meanwhile, I fixed the docstring. Thanks!

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Kévin Le Gouguec]

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

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> AFAICT, `newline-and-indent' doesn't accept any argument. Keeping it
> introduces a build warning and test failures. Hence the removal.
>
> Since you were calling it with an argument I assume this may be
> a novelty in Emacs 27.

Wow, you're right.  That caught me off-guard.

>                        However Org still supports Emacs 24.4. If that's
> the case, we need an additional compatibility layer to support both
> cases. WDYT?

I don't know if we want to jump through these hoops for a feature that
people have done without so far?  FWIW though, the following patch seems
to work ("make test" works with both 26.3 and 28.0 on my end):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: newline-and-indent-compat.patch --]
[-- Type: text/x-patch, Size: 1307 bytes --]

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 2b35535fa..ed12b9d18 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -102,6 +102,11 @@ is nil)."
   (defun org-time-convert-to-list (time)
     (seconds-to-time (float-time time))))
 
+(if (version< emacs-version "27")
+    (defsubst org-newline-and-indent (&optional _arg)
+      (newline-and-indent))
+  (defalias 'org-newline-and-indent #'newline-and-indent))
+
 \f
 ;;; Emacs < 26.1 compatibility
 
diff --git a/lisp/org.el b/lisp/org.el
index 8ad437a20..57e78599f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17649,12 +17649,12 @@ call `open-line' on the very first character."
 
 (defun org--newline (indent arg interactive)
   "Call `newline-and-indent' or just `newline'.
-If INDENT is non-nil, call `newline-and-indent' to indent
-unconditionally; otherwise, call `newline' with ARG and
-INTERACTIVE, which can trigger indentation if
+If INDENT is non-nil, call `newline-and-indent' with ARG (if
+supported) )to indent unconditionally; otherwise, call `newline'
+with ARG and INTERACTIVE, which can trigger indentation if
 `electric-indent-mode' is enabled."
   (if indent
-      (newline-and-indent)
+      (org-newline-and-indent arg)
     (newline arg interactive)))
 
 (defun org-return (&optional indent arg interactive)

[-- Attachment #3: Type: text/plain, Size: 92 bytes --]


(I hope I got that right.)

> Meanwhile, I fixed the docstring. Thanks!

And thanks again.

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Kévin Le Gouguec]

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

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> (I hope I got that right.)

Except I forgot the explanatory comment, and I left a typo in the
docstring.  Ahem.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1376 bytes --]

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 2b35535fa..caaf5ce58 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -102,6 +102,12 @@ is nil)."
   (defun org-time-convert-to-list (time)
     (seconds-to-time (float-time time))))
 
+;; `newline-and-indent' did not take a numeric argument before 27.1.
+(if (version< emacs-version "27")
+    (defsubst org-newline-and-indent (&optional _arg)
+      (newline-and-indent))
+  (defalias 'org-newline-and-indent #'newline-and-indent))
+
 \f
 ;;; Emacs < 26.1 compatibility
 
diff --git a/lisp/org.el b/lisp/org.el
index 8ad437a20..142bfb999 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17649,12 +17649,12 @@ call `open-line' on the very first character."
 
 (defun org--newline (indent arg interactive)
   "Call `newline-and-indent' or just `newline'.
-If INDENT is non-nil, call `newline-and-indent' to indent
-unconditionally; otherwise, call `newline' with ARG and
-INTERACTIVE, which can trigger indentation if
+If INDENT is non-nil, call `newline-and-indent' with ARG (if
+supported) to indent unconditionally; otherwise, call `newline'
+with ARG and INTERACTIVE, which can trigger indentation if
 `electric-indent-mode' is enabled."
   (if indent
-      (newline-and-indent)
+      (org-newline-and-indent arg)
     (newline arg interactive)))
 
 (defun org-return (&optional indent arg interactive)

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Nicolas Goaziou]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

>> (I hope I got that right.)

LGTM. I applied the patch on your behalf.

Now Org has future-proof support for Electric indent mode.

Thank you.

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Bastien]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>>> (I hope I got that right.)
>
> LGTM. I applied the patch on your behalf.
>
> Now Org has future-proof support for Electric indent mode.

Thanks to both of you for this welcome improvement!

-- 
 Bastien

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Stefan Monnier]

> +(defmacro org-test-with-minor-mode (mode state &rest body)
> +  "Run BODY after setting MODE to STATE.
> +Restore MODE to its former state afterward."
> +  (declare (debug (sexp sexp body)) (indent 2))
> +  `(let ((old-state ,mode))
> +       (,mode (if ,state 1 0))
> +       ,@body
> +       (,mode (if old-state 1 0))))

This should probably use `unwind-protect` in case `body` exits
non-locally.
[ And also, for buffer-local minor modes, we should try and be careful
  to restore the mode in the same buffer, tho this can be pushed as
  a responsability of `body`.  ]


        Stefan

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +(defmacro org-test-with-minor-mode (mode state &rest body)
>> +  "Run BODY after setting MODE to STATE.
>> +Restore MODE to its former state afterward."
>> +  (declare (debug (sexp sexp body)) (indent 2))
>> +  `(let ((old-state ,mode))
>> +       (,mode (if ,state 1 0))
>> +       ,@body
>> +       (,mode (if old-state 1 0))))
>
> This should probably use `unwind-protect` in case `body` exits
> non-locally.
> [ And also, for buffer-local minor modes, we should try and be careful
>   to restore the mode in the same buffer, tho this can be pushed as
>   a responsability of `body`.  ]

Thanks for confirming my nagging feeling that this macro was a bit too
naive :)

Nicolas actually ditched it and turned on/off electric-indent-local-mode
in the temporary buffer where the Org commands are run; that should take
care of these issues IIUC.

Re: Convert some files from outline-mode to org-mode

[Bastien]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> As a side note, I'm positively sure Org developers would love help, or
> better, code, to re-enable disabled Emacs features, and to give back
> freedom to their users. 

Yes, indeed.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Juri,

Juri Linkov <juri@linkov.net> writes:

> I mean such artificial restrictions as for example preventing users
> from customizing positions of Org popup windows:
>
>   (defmacro org-no-popups (&rest body)
>     "Suppress popup windows and evaluate BODY."
>     `(let (pop-up-frames display-buffer-alist)
>        ,@body))
>
> that ignores user customization in display-buffer-alist.

This is indeed something we can work on.  

Please M-x report-emacs-bug or M-x org-submit-bug-report, this will
greatly increase the odds that we spend time considering these issues.

Thanks,

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[H. Dieter Wilhelm]

Alan Mackenzie <acm@muc.de> writes:

> > So, while I agree that org-mode is a sledgehammer for e.g. idly browsing
> > NEWS, from a user's point-of-view (at least this user) and to borrow
> > your terms, outline-mode "is a monster" with countless esoteric
> > keybindings;

> There are not "countless" keybindings in outline-mode; there are just 26
> defined commands, only some of which will have bindings.  By contrast,
> in org-mode there are 798 defined commands.  That's a factor of 30
> greater.

Outline-mode is currently "wasting" 3 menus (Headings, Show, Hide) for
19 commands with keybindings (Emacs-26.3).

Org-mode is providing an intuitive outlining with only the <TAB> and
<Shift> keys.  If you need the complete functionality of outline
(movement and ordering commands), you can have it with only <ALT>, <RET>,
">", < and the `org-use-speed-commands' `n' `p' `b' 'f' and 'u'!

I'm not necessarily asking to replace outline-mode with org-mode but to
align the outline-mode interface to org-mode.

Thanks

        Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> By contrast, org-mode is a monster.  The learning time for org-mode must
> be non-trivial.  

I think we should distinguish the org-mode plain text *format* from
the set of tools that Emacs offers to manipulate these files.

For etc/TODO and friends, I certainly do not advocate for using all
the possibilities of the org syntax, just the one that's compatible
with outline, which is to use one-liners for headings.

> If we switch these files to org-mode, org mode gurus
> will fill them up with obscure org-mode constructs leaving everybody
> else unable to work on these files without leaning org-mode.  In my case
> I will have to relearn it each time I use it (since I will not be using
> it enough to remember it).

I am fine with etc/TODO being associated to outline-mode by default
but I think the current format is not readable enough, be it with
outline or anything else.

Also, I don't think Org mode gurus (or anyone else, for what matters)
can commit whatever they want to those files.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Stefan Monnier]

> Here's my attempt to summarize the counter-arguments:
> (1) Outline-mode is in fact more well-known than org-mode.
> (2) Org-mode increases memory consumption (by 1-3 MB).
> (3) We could improve outline-mode by adding something like org-cycle (TAB).
> (4) There's a slight delay when opening an org file for the first time
> in a session.

Improving outline-mode would probably be a good idea, *especially* if it
also benefits outline-minor-mode, but I think addressing (4) would be
beneficial for all Org users which might make it an even better choice.

> Finally, I don't know if anything can be done about (4).

I can't see any reason why it should take so freaking long to open
a *simple* Org file.

I think it "just" requires someone investigate where that time is spent
and how to reorganize the code so it's loaded&initialized more lazily.


        Stefan

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I can't see any reason why it should take so freaking long to open
> a *simple* Org file.
>
> I think it "just" requires someone investigate where that time is spent
> and how to reorganize the code so it's loaded&initialized more lazily.

Sure.  Help is more than welcome in this area.

Org maintainers are busy preparing the release of 9.4 but I will ask
for someone to help with this, we will see if we can make progress.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think that giving outline-mode an option to call org-mode
would enable every user to be happy.  In addition, people who like Org mode
would probably like this in general.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Convert some files from outline-mode to org-mode

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> I think that giving outline-mode an option to call org-mode
> would enable every user to be happy.  In addition, people who like Org mode
> would probably like this in general.

M-x org-mode

But I believe this is not the basic point of the request. People have
asked to "enrich" files like etc/NEWS with org-mode constructs. For the
records, I don't like this idea. I'm not an active org-mode user, and I
don't believe we shall force Emacs developers to learn org-mode in order
to edit such files.

Best regards, Michael.

Re: Convert some files from outline-mode to org-mode

[tomas]

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

On Mon, Apr 27, 2020 at 08:37:26AM +0200, Michael Albinus wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> > I think that giving outline-mode an option to call org-mode
> > would enable every user to be happy.  In addition, people who like Org mode
> > would probably like this in general.
> 
> M-x org-mode
> 
> But I believe this is not the basic point of the request. People have
> asked to "enrich" files like etc/NEWS with org-mode constructs. For the
> records, I don't like this idea. I'm not an active org-mode user, and I
> don't believe we shall force Emacs developers to learn org-mode in order
> to edit such files.

Absolutely. And I say that as a longstanding Org mode user.

The question should rather be: what constructs are missing in etc/NEWS,
if any?

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Convert some files from outline-mode to org-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think that giving outline-mode an option to call org-mode
  > > would enable every user to be happy.  In addition, people who like Org mode
  > > would probably like this in general.

  > M-x org-mode

Sorry, I don't get your meaaning.
Would you please stateyour point more explicitly?

  > But I believe this is not the basic point of the request. People have
  > asked to "enrich" files like etc/NEWS with org-mode constructs. For the
  > records, I don't like this idea. I'm not an active org-mode user, and I
  > don't believe we shall force Emacs developers to learn org-mode in order
  > to edit such files.

I agree.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Convert some files from outline-mode to org-mode

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

>   > > I think that giving outline-mode an option to call org-mode
>   > > would enable every user to be happy.  In addition, people who like Org mode
>   > > would probably like this in general.
>
>   > M-x org-mode
>
> Sorry, I don't get your meaaning.
> Would you please stateyour point more explicitly?

If you have opened /etc/NEWS, it is in outline-mode. When you call "M-x org-mode",
it switches to org-mode. No special option needed, I believe.

If something is needed for org-mode, we could add this close to the local
variables section, as Stefan has shown in his patch - it doesn't hurt:

#+STARTUP: showall
Local variables:
coding: utf-8
mode: outline
paragraph-separate: "[ 	\f]*$"
end:

Best regards, Michael.

Re: Convert some files from outline-mode to org-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > > I think that giving outline-mode an option to call org-mode
  > >   > > would enable every user to be happy.  In addition, people who like Org mode
  > >   > > would probably like this in general.

  > If you have opened /etc/NEWS, it is in outline-mode. When you call "M-x org-mode",
  > it switches to org-mode. No special option needed, I believe.

The new option I propose would allow a user to direct Emacs, with just
one action, to use Org mode automatically every time, for those files.

The method of typing M-x org-mode by hand would require the user to do
that explicitly _each time_ each time perse visits one of these files.
It might seem at first to "do the job", but really it does a different
job.

When you suggest a different solution to some problem, please
_explain_ how your solution relates to the problem.  That will enable
people to understand and see if it is really solves the same problem.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> But I believe this is not the basic point of the request. People have
> asked to "enrich" files like etc/NEWS with org-mode constructs. For the
> records, I don't like this idea. 

For the record, I agree: I don't think enriching etc/NEWS and other
such files with Org constructs would be a good idea.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

>     * CONTRIBUTE:
>     * etc/CALC-NEWS:
>     * etc/DEBUG:
>     * etc/MACHINES:
>     * etc/PROBLEMS:
>     * etc/TODO: Use org-mode instead of outline-mode.
> The reason is that I believe our users are more familiar with org-mode
> than outline-mode, and that I simply think the interface is better.
> It's the forward-looking, "modern" choice, if you like.
> So please make it known how you feel about this proposal.

I would say that Outline is much better than Org for simple
informational files, such as `NEWS', `DEBUG', or `CALC-NEWS'.

Org may be useful if we ever expand `TODO' to actually include
work-in-progress tasks, a schedule, or similar items, but I think we
should stick with Outline right now.

Re: Convert some files from outline-mode to org-mode

[Stefan Monnier]

>>     * CONTRIBUTE:
>>     * etc/CALC-NEWS:
>>     * etc/DEBUG:
>>     * etc/MACHINES:
>>     * etc/PROBLEMS:
>>     * etc/TODO: Use org-mode instead of outline-mode.
>> The reason is that I believe our users are more familiar with org-mode
>> than outline-mode, and that I simply think the interface is better.
>> It's the forward-looking, "modern" choice, if you like.
>> So please make it known how you feel about this proposal.
>
> I would say that Outline is much better than Org for simple
> informational files, such as `NEWS', `DEBUG', or `CALC-NEWS'.
>
> Org may be useful if we ever expand `TODO' to actually include
> work-in-progress tasks, a schedule, or similar items, but I think we
> should stick with Outline right now.

So, from what I gather here, we could satisfy everyone by using for the
file format a very small subset of org-mode (basically the subset
that is common with outline-mode), and for the major-mode itself
a variant of org-mode that loads faster (e.g. a stripped down version
of org-mode, or an org-mode that's been profiled&tweaked to load
faster).


        Stefan

Re: Convert some files from outline-mode to org-mode

[Jean-Christophe Helary]

> On Apr 27, 2020, at 23:36, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>    * CONTRIBUTE:
>>>    * etc/CALC-NEWS:
>>>    * etc/DEBUG:
>>>    * etc/MACHINES:
>>>    * etc/PROBLEMS:
>>>    * etc/TODO: Use org-mode instead of outline-mode.
>>> The reason is that I believe our users are more familiar with org-mode
>>> than outline-mode, and that I simply think the interface is better.
>>> It's the forward-looking, "modern" choice, if you like.
>>> So please make it known how you feel about this proposal.
>> 
>> I would say that Outline is much better than Org for simple
>> informational files, such as `NEWS', `DEBUG', or `CALC-NEWS'.
>> 
>> Org may be useful if we ever expand `TODO' to actually include
>> work-in-progress tasks, a schedule, or similar items, but I think we
>> should stick with Outline right now.
> 
> So, from what I gather here, we could satisfy everyone by using for the
> file format a very small subset of org-mode (basically the subset
> that is common with outline-mode), and for the major-mode itself
> a variant of org-mode that loads faster (e.g. a stripped down version
> of org-mode, or an org-mode that's been profiled&tweaked to load
> faster).

My reading is that org-mode users would just appreciate if outline-mode had "non-nonsense" navigation similar to org-mode.

Outline users are just happy with the status quo.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Convert some files from outline-mode to org-mode

[Howard Melman]

Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> writes:

>> On Apr 27, 2020, at 23:36, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>> So, from what I gather here, we could satisfy everyone by using for the
>> file format a very small subset of org-mode (basically the subset
>> that is common with outline-mode), and for the major-mode itself
>> a variant of org-mode that loads faster (e.g. a stripped down version
>> of org-mode, or an org-mode that's been profiled&tweaked to load
>> faster).
>
> My reading is that org-mode users would just appreciate if
> outline-mode had "non-nonsense" navigation similar to org-mode.

FWIW, I've had this in my init for several years now. I'm
not an org-mode user, though I've tried a few times. I can
never remember the outline-mode keybindings and found  that
org-mode's C-TAB and S-TAB alone were huge wins and just
worked in outline-minor-mode.  This my solution to code
folding and I use it in other modes like markdown.  Adding
org-cycle and org-global-cycle to outline mode, or some
equivalent I think would be a huge usability win.

;; I can never remember the outline keybindings,
;; grabbing C-tab and S-Tab from org-mode is genius
;; Also make the outline move commands memorable (borrowing from org)
(with-eval-after-load "outline"
  (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
  (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
  (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
  (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
  (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
  (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
)


-- 

Howard

Re: Convert some files from outline-mode to org-mode

[Jean-Christophe Helary]

Thank you Howard.

> On Apr 29, 2020, at 12:27, Howard Melman <hmelman@gmail.com> wrote:
> 
> Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org> writes:
> 
>>> On Apr 27, 2020, at 23:36, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> 
>>> So, from what I gather here, we could satisfy everyone by using for the
>>> file format a very small subset of org-mode (basically the subset
>>> that is common with outline-mode), and for the major-mode itself
>>> a variant of org-mode that loads faster (e.g. a stripped down version
>>> of org-mode, or an org-mode that's been profiled&tweaked to load
>>> faster).
>> 
>> My reading is that org-mode users would just appreciate if
>> outline-mode had "non-nonsense" navigation similar to org-mode.
> 
> FWIW, I've had this in my init for several years now. I'm
> not an org-mode user, though I've tried a few times. I can
> never remember the outline-mode keybindings and found  that
> org-mode's C-TAB and S-TAB alone were huge wins and just
> worked in outline-minor-mode.  This my solution to code
> folding and I use it in other modes like markdown.  Adding
> org-cycle and org-global-cycle to outline mode, or some
> equivalent I think would be a huge usability win.

That's excellent. I could never get used to outline-mode (even though I tried: I see that I have ouline files more than 10 years old) and that's one of the reasons why I moved to org-mode. Then I started to learn new things in org-mode and I can't go back to outline.

But what you propose is certainly a solution to all the org-moders who want to be able to seamlessly access outline files.

> 
> ;; I can never remember the outline keybindings,
> ;; grabbing C-tab and S-Tab from org-mode is genius
> ;; Also make the outline move commands memorable (borrowing from org)
> (with-eval-after-load "outline"
>  (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>  (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>  (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>  (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>  (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>  (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
> )


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Convert some files from outline-mode to org-mode

[Howard Melman]

jean.christophe.helary@traduction-libre.org writes:

> But what you propose is certainly a solution to all the org-moders who
> want to be able to seamlessly access outline files.

To be clear, it's better than just that. As I said I use it
for code folding. As long as a programming mode sets
outline-regexp then outline-minor-mode works with it and
org-cycle and org-global-cycle work in those modes. I use
S-TAB and C-TAB in emacs-lisp-mode, python-mode and othes
all the time. 

In emacs-lisp-mode:

    (setq-local outline-regexp ";;;;? \\|(....")

In python-mode:

    (setq-local outline-regexp (python-rx (* space) (or defun decorator)))

In html-mode:

    (setq-local outline-regexp "<[hH]\\([1-6]\\)\\>")

-- 

Howard

Re: Convert some files from outline-mode to org-mode

[Jean-Christophe Helary]

> On Apr 29, 2020, at 22:54, Howard Melman <hmelman@gmail.com> wrote:
> 
> 
> jean.christophe.helary@traduction-libre.org writes:
> 
>> But what you propose is certainly a solution to all the org-moders who
>> want to be able to seamlessly access outline files.
> 
> To be clear, it's better than just that. As I said I use it
> for code folding. As long as a programming mode sets
> outline-regexp then outline-minor-mode works with it and
> org-cycle and org-global-cycle work in those modes. I use
> S-TAB and C-TAB in emacs-lisp-mode, python-mode and othes
> all the time. 
> 
> In emacs-lisp-mode:
> 
>    (setq-local outline-regexp ";;;;? \\|(....")

I had to check the weird shortcuts for the hs mode the other day, naively thinking that code folding was just a TAB away... Thank yu so much for your suggestion.

> In python-mode:
> 
>    (setq-local outline-regexp (python-rx (* space) (or defun decorator)))
> 
> In html-mode:
> 
>    (setq-local outline-regexp "<[hH]\\([1-6]\\)\\>")
> 
> -- 
> 
> Howard

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Convert some files from outline-mode to org-mode

[Nicolas Goaziou]

Hello,

Howard Melman <hmelman@gmail.com> writes:

> To be clear, it's better than just that. As I said I use it
> for code folding. As long as a programming mode sets
> outline-regexp then outline-minor-mode works with it and
> org-cycle and org-global-cycle work in those modes. I use
> S-TAB and C-TAB in emacs-lisp-mode, python-mode and othes
> all the time. 
>
> In emacs-lisp-mode:
>
>     (setq-local outline-regexp ";;;;? \\|(....")
>
> In python-mode:
>
>     (setq-local outline-regexp (python-rx (* space) (or defun decorator)))
>
> In html-mode:
>
>     (setq-local outline-regexp "<[hH]\\([1-6]\\)\\>")

I wouldn't expect `org-cycle' and `org-global-cycle' to work for any
`outline-regexp' value. If it works, good for you, but Org really
expects "\\*+ " here.

Implementing `outline-cycle' and `outline-global-cycle' may be more
future-proof.

Regards,

-- 
Nicolas Goaziou

Re: Convert some files from outline-mode to org-mode

[Howard Melman]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I wouldn't expect `org-cycle' and `org-global-cycle' to work for any
> `outline-regexp' value. If it works, good for you, but Org really
> expects "\\*+ " here.

FWIW, it's worked flawlessly for me since 2014, though I
only use these bindings in the simplest ways.

> Implementing `outline-cycle' and `outline-global-cycle' may be more
> future-proof.

That's probably true.

While less game changing than the cycling commands, I think
the keybindings for M-<arrows> are great too. I use those
commands infrequently enough that having them on arrows
really aids memorability (and I've been using emacs for 30+
years so remembering keys isn't generally a problem for me)
and having them be the same in various contexts (outlines,
markdown, code, etc.) is one of the things that makes emacs
great.

-- 

Howard

Re: Convert some files from outline-mode to org-mode

[Stefan Kangas]

Howard Melman <hmelman@gmail.com> writes:

> ;; I can never remember the outline keybindings,
> ;; grabbing C-tab and S-Tab from org-mode is genius
> ;; Also make the outline move commands memorable (borrowing from org)
> (with-eval-after-load "outline"
>   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
> )

Yes, this would completely remove (from my point of view) any need of
switching from outline-mode to org-mode, as I originally suggested.

So we need to untangle 'org-cycle' and 'org-global-cycle' from
org-mode and move the functionality to outline-mode, and the rest are
just keybindings.  It would be very good if someone would work on a
patch along those lines.  I hope that this proposal is uncontroversial
also to outline-mode users.

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[H. Dieter Wilhelm]

Stefan Kangas <stefan@marxist.se> writes:

> Howard Melman <hmelman@gmail.com> writes:
>
>> ;; I can never remember the outline keybindings,
>> ;; grabbing C-tab and S-Tab from org-mode is genius
>> ;; Also make the outline move commands memorable (borrowing from org)
>> (with-eval-after-load "outline"
>>   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>>   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>>   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>>   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
>> )
>
> Yes, this would completely remove (from my point of view) any need of
> switching from outline-mode to org-mode, as I originally suggested.

I like this idea (rarely using Emacs in a terminal).

  Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Convert some files from outline-mode to org-mode

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

>> (with-eval-after-load "outline"
>>   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>>   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>>   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>>   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
>> )
>
> Yes, this would completely remove (from my point of view) any need of
> switching from outline-mode to org-mode, as I originally suggested.

The decision here seems to be that we will not convert these files, so I
have closed Bug#40813.

I have opened Bug#41129 and Bug#41130 instead:

1. outline-mode: New keybindings for demote/promote/move-subtree
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41129

2. outline-mode: Add new commands like org-cycle and org=global-cycle
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41130

Thanks to everyone participating in the discussion.  In particular,
thanks to Howard Melman for the above idea.

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[Yuri Khan]

On Fri, 8 May 2020 at 04:02, Stefan Kangas <stefan@marxist.se> wrote:
> >>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
> >>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)

These should probably be the other way round.

Re: Convert some files from outline-mode to org-mode

[Stefan Kangas]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Fri, 8 May 2020 at 04:02, Stefan Kangas <stefan@marxist.se> wrote:
>> >>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>> >>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>
> These should probably be the other way round.

Yes, thanks.  I'll point that out in the bug report.

Best regards,
Stefan Kangas

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Stefan,

thanks for the follow-up on this bug report.

Stefan Kangas <stefan@marxist.se> writes:

> I have opened Bug#41129 and Bug#41130 instead:
>
> 1. outline-mode: New keybindings for demote/promote/move-subtree
>    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41129
>
> 2. outline-mode: Add new commands like org-cycle and org=global-cycle
>    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41130

I opened bug#41497: Flawed text formatting of files like etc/TODO,
etc/NEWS, etc: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41497

I really think this is a separate issue, not one involving the org 
vs outline discussion.

Thanks for bringing up the larger issue btw.

-- 
 Bastien

Re: Convert some files from outline-mode to org-mode

[Alan Mackenzie]

Hellow, Howard.

On Tue, Apr 28, 2020 at 23:27:39 -0400, Howard Melman wrote:
> Jean-Christophe Helary
> <jean.christophe.helary@traduction-libre.org> writes:

> >> On Apr 27, 2020, at 23:36, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> So, from what I gather here, we could satisfy everyone by using for the
> >> file format a very small subset of org-mode (basically the subset
> >> that is common with outline-mode), and for the major-mode itself
> >> a variant of org-mode that loads faster (e.g. a stripped down version
> >> of org-mode, or an org-mode that's been profiled&tweaked to load
> >> faster).

> > My reading is that org-mode users would just appreciate if
> > outline-mode had "non-nonsense" navigation similar to org-mode.

> FWIW, I've had this in my init for several years now. I'm
> not an org-mode user, though I've tried a few times. I can
> never remember the outline-mode keybindings and found  that
> org-mode's C-TAB and S-TAB alone were huge wins and just
> worked in outline-minor-mode.  This my solution to code
> folding and I use it in other modes like markdown.  Adding
> org-cycle and org-global-cycle to outline mode, or some
> equivalent I think would be a huge usability win.

> ;; I can never remember the outline keybindings,
> ;; grabbing C-tab and S-Tab from org-mode is genius
> ;; Also make the outline move commands memorable (borrowing from org)
> (with-eval-after-load "outline"
>   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
> )

I disagree that these bindings are suitable for general use.

For a start, most of them only exist in GUI frames, not TTYs.  M-<left>,
etc. certainly don't (unless the keyboard has been specially enhanced,
as mine has).

Also, all these keys are "repeatable", i.e. you can let them run on
auto-repeat.  Such keys are scarce and valuable, and shouldn't be
"squandered" on commands that don't need them.  I suggest that the likes
of outline-demote don't need such bindings.

Also[2], the arrow keys, with modifiers, are highly likely to be in use
by many users for things connected with movement, and defining them like
this in outline-mode will inconvenience all of them.  For example, I've
got M-<up> and M-<down> bound to commands to scroll the other window a
single line.  I don't want to lose these, even in outline-mode.

> -- 

> Howard

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Convert some files from outline-mode to org-mode

[Howard Melman]

Alan Mackenzie <acm@muc.de> writes:

> Hellow, Howard.
>
> On Tue, Apr 28, 2020 at 23:27:39 -0400, Howard Melman wrote:
>> (with-eval-after-load "outline"
>>   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
>>   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
>>   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
>>   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
>>   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
>>   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
>> )
>
> I disagree that these bindings are suitable for general use.
>
> For a start, most of them only exist in GUI frames, not TTYs.  M-<left>,
> etc. certainly don't (unless the keyboard has been specially enhanced,
> as mine has).
>
> Also, all these keys are "repeatable", i.e. you can let them run on
> auto-repeat.  Such keys are scarce and valuable, and shouldn't be
> "squandered" on commands that don't need them.  I suggest that the likes
> of outline-demote don't need such bindings.
>
> Also[2], the arrow keys, with modifiers, are highly likely to be in use
> by many users for things connected with movement, and defining them like
> this in outline-mode will inconvenience all of them.  For example, I've
> got M-<up> and M-<down> bound to commands to scroll the other window a
> single line.  I don't want to lose these, even in outline-mode.

Fair points, but I'll note these are bindings that org
currently uses (maybe not C-tab, I think org just uses tab).

The cycle commands are a bigger win then the others because
they save the user from having to remember several outline
bindings.

I think org has shown having such commands on the arrow keys
with some modifers is very popular and perhaps outline could
borrow from it.  And of course any user is free to override
them.

-- 

Howard

Re: Convert some files from outline-mode to org-mode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ;; I can never remember the outline keybindings,
  > ;; grabbing C-tab and S-Tab from org-mode is genius
  > ;; Also make the outline move commands memorable (borrowing from org)
  > (with-eval-after-load "outline"
  >   (define-key outline-minor-mode-map (kbd "C-<tab>") 'org-cycle)
  >   (define-key outline-minor-mode-map (kbd "S-<tab>") 'org-global-cycle)
  >   (define-key outline-minor-mode-map (kbd "M-<left>") 'outline-demote)
  >   (define-key outline-minor-mode-map (kbd "M-<right>") 'outline-promote)
  >   (define-key outline-minor-mode-map (kbd "M-<up>") 'outline-move-subtree-up)
  >   (define-key outline-minor-mode-map (kbd "M-<down>") 'outline-move-subtree-down)
  > )

Adding bindings for those commands might be good, but those key
bindings have problems.  C-TAB and S-TAB do not exist on ttys.
M-arrows may not exist either.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Convert some files from outline-mode to org-mode

[Bastien]

Hi Stefan,

thanks for the suggestion and sorry for being late to the party.

Here is my simple take on this:

- The current way etc/TODO and friends are written is flawed,
  independantly of what mode you use to navigate it. E.g.:

    ** Improve the byte-compiler to recognize immutable (lexical)
    bindings and get rid of them if they're used only once and/or
    they're bound to a constant expression.

  Is it a paragraph?  Is it a heading?  Is it a whole section?  I
  cannot decide.  It is just some text.  Outline fontifies the first
  line of such text but this can hardly be considered as syntactic
  fontification, since the first fontified line is sometimes a whole
  sentence, sometimes just the start of a paragraph.

- We shall discuss plain text formatting enhancements instead of
  discussing outline vs org.  I am in favor of rewriting "paragraphs"
  in these files as proper heading + contents -- e.g.:

    ** Improve the byte-compiler to recognize immutable (lexical) bindings 
  
    Also get rid of them if they're used only once and/or they're
    bound to a constant expression.
  
And this is it.  This would a welcome enhancement over the current
situation and we would not really need to have the outline vs org
discussion.

If nobody is against this enhancement, I am willing to start working
on these files and send a patch.

Thanks,

-- 
 Bastien