demoting a heading inserts spaces in column-0 text

demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

  There was a change (cba2f0a2a3024ae5bf71e1a12ba99778a92902a2, Sat Nov 8 14:35:24 2014 +0100) which made :CLOCK: etc entries shift to the right when the tree is being shifted to the right („demoted“, e.g. using M-S-Right).


But now it changes from this:

**** some
	:CLOCK:
	CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
	:END:
Text



  to this:
  
***** some
	 :CLOCK:
	 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
	 :END:
 Text



   while what I expected was this:
   
***** some
	 :CLOCK:
	 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
	 :END:
Text




   Proposal: if text starts in column 0, don't move the text; move only the headers.
   An old behaviour (reported in http://permalink.gmane.org/gmane.emacs.orgmode/92450) was not to move anything in this case, that's bad and was fixed. I think the proposal is better.
   org-adapt-indentation=nil would write all headers in column 0 by default, which is ugly and doesn't give the desired result.

   If some people prefer „move header+text even if text is in column 0“ (current behaviour) over „move header but not text if text is in column 0“ (proposal), org-adapt-indentation could select choose between the two.
   

   Thanks,
Daniel

Re: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Hello,

Daniel Clemente <n142857@gmail.com> writes:

>   There was a change (cba2f0a2a3024ae5bf71e1a12ba99778a92902a2, Sat
>   Nov 8 14:35:24 2014 +0100) which made :CLOCK: etc entries shift to
>   the right when the tree is being shifted to the right („demoted“,
>   e.g. using M-S-Right).
>
>
> But now it changes from this:
>
> **** some
> 	:CLOCK:
> 	CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> 	:END:
> Text
>
>
>
>   to this:
>   
> ***** some
> 	 :CLOCK:
> 	 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> 	 :END:
>  Text
>
>
>
>    while what I expected was this:
>    
> ***** some
> 	 :CLOCK:
> 	 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> 	 :END:
> Text
>
>
>
>
>    Proposal: if text starts in column 0, don't move the text; move
>    only the headers.

Then, in this case, :CLOCK: drawer will not move either. Unless
"headers" is defined as "stuff not too far from the headline". But it is
too vague to be usable.

>    An old behaviour (reported in http://permalink.gmane.org/gmane.emacs.orgmode/92450) was not to move anything in this case, that's bad and was fixed. I think the proposal is better.
>    org-adapt-indentation=nil would write all headers in column 0 by
>    default, which is ugly and doesn't give the desired result.

There no such thing as a your "headers" in Org. :CLOCK: and "Text" are
treated equally, as contents of the headline.


Regards,

-- 
Nicolas Goaziou

Re: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

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

> >    Proposal: if text starts in column 0, don't move the text; move
> >    only the headers.
>
> Then, in this case, :CLOCK: drawer will not move either. Unless
> "headers" is defined as "stuff not too far from the headline". But it is
> too vague to be usable.

> There no such thing as a your "headers" in Org. :CLOCK: and "Text" are
> treated equally, as contents of the headline.

  Of course everything's text, but if there's no distinction between
drawers/headers and text, that's the problem. Those headers are metadata
written and managed by org and must follow some rules, whereas the rest of
text is data typed by the user and relatively free. Those headers must even
follow strict processes (like being "repaired" to make CLOCK appear after
PROPERTIES), so I wouldn't say they are normal text.
  Maybe you are referring to the non-drawers metadata, i.e. to those notes
that you can add with C-c C-z. That's in the limbo between org data and
text, that's the tricky part. I don't know whether that should be indented
together with the drawers, probably yes.
  So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
do automatic changes only to its own syntax, not to text typed by the user
unless the user asks for it.

--
Daniel

On Sat, Dec 6, 2014 at 6:40 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Daniel Clemente <n142857@gmail.com> writes:
>
> >   There was a change (cba2f0a2a3024ae5bf71e1a12ba99778a92902a2, Sat
> >   Nov 8 14:35:24 2014 +0100) which made :CLOCK: etc entries shift to
> >   the right when the tree is being shifted to the right ("demoted",
> >   e.g. using M-S-Right).
> >
> >
> > But now it changes from this:
> >
> > **** some
> >       :CLOCK:
> >       CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> >       :END:
> > Text
> >
> >
> >
> >   to this:
> >
> > ***** some
> >        :CLOCK:
> >        CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> >        :END:
> >  Text
> >
> >
> >
> >    while what I expected was this:
> >
> > ***** some
> >        :CLOCK:
> >        CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> >        :END:
> > Text
> >
> >
> >
> >
> >    Proposal: if text starts in column 0, don't move the text; move
> >    only the headers.
>
> Then, in this case, :CLOCK: drawer will not move either. Unless
> "headers" is defined as "stuff not too far from the headline". But it is
> too vague to be usable.
>
> >    An old behaviour (reported in
> http://permalink.gmane.org/gmane.emacs.orgmode/92450) was not to move
> anything in this case, that's bad and was fixed. I think the proposal is
> better.
> >    org-adapt-indentation=nil would write all headers in column 0 by
> >    default, which is ugly and doesn't give the desired result.
>
> There no such thing as a your "headers" in Org. :CLOCK: and "Text" are
> treated equally, as contents of the headline.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

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

Re: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente <n142857@gmail.com> writes:

>   Of course everything's text, but if there's no distinction between
> drawers/headers and text, that's the problem. Those headers are metadata
> written and managed by org and must follow some rules,

This is incorrect.

:CLOCK: or :LOGBOOK: or whatever the value of `org-clock-into-drawer'
is, are regular drawers conveniently provided to collect clocks and
allow to hide them away. They have no special meaning in Org, and may
not even exist (i.e., when `org-clock-into-drawer' is nil). There is no
reason to treat them specially.

OTOH, clocks themselves are pure metadata. They could be indented
specifically, but since they are allowed anywhere in a section, it might
be dangerous to do so (e.g. it could break a list). Actually, this is
true for anything that need to appear at the very beginning of the
section, i.e., anything but planning info and properties drawers.

> whereas the rest of text is data typed by the user and relatively
> free. Those headers must even follow strict processes (like being
> "repaired" to make CLOCK appear after PROPERTIES)uà, so I wouldn't say
> they are normal text.

This is also wrong. PROPERTIES drawer, which is metadata, has to be
moved before anything else in the section (with the exception of
planning info). This has nothing to do with CLOCK drawers, which are not
even considered in the process.

>   So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
> do automatic changes only to its own syntax, not to text typed by the user
> unless the user asks for it.

Again, :CLOCK:...:END: is user's decision, not Org's. So are all
drawers, but, of course, PROPERTIES. The latter is the exception, not
the rule.


Regards,

Re: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Fri, 12 Dec 2014 19:25:25 +0100 Nicolas Goaziou va escriure:
> 
> >   Of course everything's text, but if there's no distinction between
> > drawers/headers and text, that's the problem. Those headers are metadata
> > written and managed by org and must follow some rules,
> 
> This is incorrect.
> 
> :CLOCK: or :LOGBOOK: or whatever the value of `org-clock-into-drawer'
> is, are regular drawers conveniently provided to collect clocks and
> allow to hide them away. They have no special meaning in Org, and may
> not even exist (i.e., when `org-clock-into-drawer' is nil). There is no
> reason to treat them specially.
> 
> OTOH, clocks themselves are pure metadata. They could be indented
> specifically, but since they are allowed anywhere in a section, it might
> be dangerous to do so (e.g. it could break a list). Actually, this is
> true for anything that need to appear at the very beginning of the
> section, i.e., anything but planning info and properties drawers.
>
> > […]
> This is also wrong. PROPERTIES drawer, which is metadata, has to be
> moved before anything else in the section (with the exception of
> planning info). This has nothing to do with CLOCK drawers, which are not
> even considered in the process.
> 
> >   So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
> > do automatic changes only to its own syntax, not to text typed by the user
> > unless the user asks for it.
> 
> Again, :CLOCK:...:END: is user's decision, not Org's. So are all
> drawers, but, of course, PROPERTIES. The latter is the exception, not
> the rule.

  But these are technical details, not relevant to a non-programmer. What a new user sees with the default settings as of today is:
- he writes a new tree and some text inside
- he clocks in
- he demotes the tree (shift+right) because he wants to change the tree structure. Result: his text also is modified
  This breaks user's expectations. At least it breaks my expectations, because in a logical tree of nodes, demoting does not mean „shift contents“. And I thought org was supposed not to break my content.
  I also lose controllability because I have no way to rearrange nodes without side effects.
  
  I suggest:

1. New default for org-adapt-indentation = 'partial, which shifts every line until the first line which starts at column 0. This may not shift all drawers in complex cases where you have them in the bottom of the tree; therefore it's called partial. This is handling the most common cases. And in case you had indentation in all lines, all lines will be shifted.

2. With org-adapt-indentation = 'partial, new lines added by org (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the heading, not at column 0

3. The other options stay the same: org-adapt-indentation=t means everything will be shifted, org-adapt-indentation=nil means nothing will be shifted (new text starts at column 0)



-- Daniel

Re: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente <n142857@gmail.com> writes:

>   But these are technical details, not relevant to a non-programmer.

Which basically means nothing, because everything ultimately boils down
to technical details.

> What a new user sees with the default settings as of today is:

Aren't you confusing your expectations and new users'?

> - he writes a new tree and some text inside
> - he clocks in
> - he demotes the tree (shift+right) because he wants to change the tree structure. Result: his text also is modified

FUD. Neither the text nor its structure are modified. Only indentation
is. How it is done is explained in `org-adapt-indentation' docstring.

>   This breaks user's expectations. At least it breaks my expectations,

There we are.

> because in a logical tree of nodes, demoting does not mean „shift
> contents“.

Huh? "Citation needed".

> And I thought org was supposed not to break my content.

It also kills kittens, in the background.

>   I also lose controllability because I have no way to rearrange nodes
>   without side effects.

We might fix them. What are exactly these side-effects?

>   I suggest:
>
> 1. New default for org-adapt-indentation = 'partial, which shifts
> every line until the first line which starts at column 0. This may not
> shift all drawers in complex cases where you have them in the bottom
> of the tree; therefore it's called partial.

I'm not really against it, but this is really hackish and probably
surprising.

AFAICT, you erroneously think regular drawers are an Org internal
artifact whereas they are really meant for users. They should be
indented like their contents, no like planning info.

In any case, I'd favor a solution that takes into consideration the real
structure of the section.

> This is handling the most common cases.

Let's focus on your use case instead of a "most common case" we both
know very little about.

> 2. With org-adapt-indentation = 'partial, new lines added by org
> (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the
> heading, not at column 0

This would be plain wrong. Indentation is relative to the element above.
Heading indentation is but the fallback value.


Regards,

Re: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Sat, 13 Dec 2014 12:33:16 +0100 Nicolas Goaziou va escriure:
> >   But these are technical details, not relevant to a non-programmer.
> 
> Which basically means nothing, because everything ultimately boils down
> to technical details.
> 

  That's always true. But UIs still need to be simple.
  No need to teach the user the differences of a :CLOCK: vs a :PROPERTIES: or drawer vs. metadata. Users who type can do a simpler distinction:
  1. things you type yourself
  2. things that appear/change/disappear after invoking org functions (C-something, S-something, M-something). E.g.: the words SCHEDULED, TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, …

  I speak for myself, but I expect class 1 not to be changed by org, and class 2 to be handled only by org (I can always edit manually, but I shouldn't need to do it). I know that you can actually type everything in class 2, but you shouldn't NEED to.  
  Any other opinions are welcome.


> > - he writes a new tree and some text inside
> > - he clocks in
> > - he demotes the tree (shift+right) because he wants to change the tree structure. Result: his text also is modified
> 
> FUD. Neither the text nor its structure are modified. Only indentation
> is. How it is done is explained in `org-adapt-indentation' docstring.
> 

  Indentation is for me as important as the other letters I type. I don't want it changed.
  It's a personal preference. Emacs respects it to great extents.


> > because in a logical tree of nodes, demoting does not mean „shift
> > contents“.
> 
> Huh? "Citation needed".

  Maybe I should clarify that I see the text inside my org files as a tree of knowledge. The position inside the tree of a particular item does not affect how I write the text (e.g. how many indentation spaces). I can move nodes freely from one place to another and I have no indentations to fix. „Tree structure“ and „item content“ are disconnected.
  If you really need other sources, you can see how tree operations in other contexts don't modify the contents of each node: http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
  I wouldn't want titles, clocks, IDs, indentations, properties, priorities etc. changed when the tree structure changes.
  Maybe other people think the same; you can survey the list.
  

> >   I also lose controllability because I have no way to rearrange nodes
> >   without side effects.
> 
> We might fix them. What are exactly these side-effects?
> 
  The only one: indentation is added:


After demoting, it changes from this:

**** some
        :CLOCK:
        CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
        :END:
Text



  to this:
  
***** some
         :CLOCK:
         CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
         :END:
 Text


This will happen in all subtrees.


> >   I suggest:
> >
> > 1. New default for org-adapt-indentation = 'partial, which shifts
> > every line until the first line which starts at column 0. This may not
> > shift all drawers in complex cases where you have them in the bottom
> > of the tree; therefore it's called partial.
> 
> I'm not really against it, but this is really hackish and probably
> surprising.

  That's similar to a not-so-bad old behaviour. But it's still a bit better (it avoids the problem described in http://permalink.gmane.org/gmane.emacs.orgmode/92450)


> AFAICT, you erroneously think regular drawers are an Org internal
> artifact whereas they are really meant for users. They should be
> indented like their contents, no like planning info.

  I do the typed-by-me/not-typed-by-me distinction.
 
> 
> > 2. With org-adapt-indentation = 'partial, new lines added by org
> > (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the
> > heading, not at column 0
> 
> This would be plain wrong. Indentation is relative to the element above.
> Heading indentation is but the fallback value.
> 

Ok, make it:

2. With org-adapt-indentation = 'partial, new lines added by org
(:CLOCK: drawer, CLOCK lines etc) are indented at the same level as the element above.



--
Daniel

Re: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente <n142857@gmail.com> writes:

>   No need to teach the user the differences of a :CLOCK: vs
>   a :PROPERTIES: or drawer vs. metadata.

The difference is important, e.g., wrt export.

> Users who type can do a simpler distinction:
>   1. things you type yourself
>   2. things that appear/change/disappear after invoking org functions
>   (C-something, S-something, M-something). E.g.: the words SCHEDULED,
>   TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, … 
>
>   I speak for myself, but I expect class 1 not to be changed by org,
> and class 2 to be handled only by org (I can always edit manually, but
> I shouldn't need to do it). I know that you can actually type
> everything in class 2, but you shouldn't NEED to.
>   Any other opinions are welcome.

You are free to make any distinction you want. Unfortunately, Org does
a different one. In particular, as you noticed, there are some areas
where things are not as clear. For example, Org cannot be sure that
a given drawer wasn't inserted manually, so altering its indentation may
or may not be a good choice.

>   Indentation is for me as important as the other letters I type. I don't want it changed.
>   It's a personal preference. Emacs respects it to great extents.

I understand. Simply set `org-adapt-indentation' to nil.

>   Maybe I should clarify that I see the text inside my org files as
> a tree of knowledge. The position inside the tree of a particular item
> does not affect how I write the text (e.g. how many indentation
> spaces). I can move nodes freely from one place to another and I have
> no indentations to fix. „Tree structure“ and „item content“ are
> disconnected.
>   If you really need other sources, you can see how tree operations in
> other contexts don't modify the contents of each node:
> http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
>   I wouldn't want titles, clocks, IDs, indentations, properties, priorities etc. changed when the tree structure changes.
>   Maybe other people think the same; you can survey the list.

So, what's wrong with `org-adapt-indentation' set to nil?

>   The only one: indentation is added:
>
>
> After demoting, it changes from this:
>
> **** some
>         :CLOCK:
>         CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
>         :END:
> Text
>
>
>
>   to this:
>   
> ***** some
>          :CLOCK:
>          CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
>          :END:
>  Text

See above.

>   That's similar to a not-so-bad old behaviour. But it's still a bit better (it avoids the problem described in http://permalink.gmane.org/gmane.emacs.orgmode/92450)

The problem described there is different: the OP wants some changes when
tree structure is modified (e.g., planning info moved). You claim to
want no change at all, which is easier, and already implemented.

>> AFAICT, you erroneously think regular drawers are an Org internal
>> artifact whereas they are really meant for users. They should be
>> indented like their contents, no like planning info.
>
>   I do the typed-by-me/not-typed-by-me distinction.

See above.

> Ok, make it:
>
> 2. With org-adapt-indentation = 'partial, new lines added by org
> (:CLOCK: drawer, CLOCK lines etc) are indented at the same level as
> the element above.

This is better, but there is still the hack about text at column 0.

Also, this only makes sense if these lines are also moved when headline
is promoted or demoted. But, then, contents will change along with tree,
which you don't like, and it could break section structure (some lines
being moved and not others), which cannot happen currently.

Another option would be to have another option to indent only planning
info, properties drawer, and every drawer located right after it, à la
`org-log-state-notes-insert-after-drawers'. At least, it couldn't break
structure.


Regards,

Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

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

(I'm resending this old e-mail because it seems it didn't get to the list,
according to Gmane).

El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:
>
> > Users who type can do a simpler distinction:
> >   1. things you type yourself
> >   2. things that appear/change/disappear after invoking org functions
> >   (C-something, S-something, M-something). E.g.: the words SCHEDULED,
> >   TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, ...
> >
> >   I speak for myself, but I expect class 1 not to be changed by org,
> > and class 2 to be handled only by org (I can always edit manually, but
> > I shouldn't need to do it). I know that you can actually type
> > everything in class 2, but you shouldn't NEED to.
> >   Any other opinions are welcome.
>
> You are free to make any distinction you want. Unfortunately, Org does
> a different one. In particular, as you noticed, there are some areas
> where things are not as clear. For example, Org cannot be sure that
> a given drawer wasn't inserted manually, so altering its indentation may
> or may not be a good choice.

  Does it matter in practice? If the user manually inserts things that are
normally handled by org, they can be also handled by org. Lckily you don't
need to remember whether it was manually inputted or not.

>
> >   Indentation is for me as important as the other letters I type. I
don't want it changed.
> >   It's a personal preference. Emacs respects it to great extents.
>
> I understand. Simply set `org-adapt-indentation' to nil.
>
> >   Maybe I should clarify that I see the text inside my org files as
> > a tree of knowledge. The position inside the tree of a particular item
> > does not affect how I write the text (e.g. how many indentation
> > spaces). I can move nodes freely from one place to another and I have
> > no indentations to fix. "Tree structure" and "item content" are
> > disconnected.
> >   If you really need other sources, you can see how tree operations in
> > other contexts don't modify the contents of each node:
> >
http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
> >   I wouldn't want titles, clocks, IDs, indentations, properties,
priorities etc. changed when the tree structure changes.
> >   Maybe other people think the same; you can survey the list.
>
> So, what's wrong with `org-adapt-indentation' set to nil?

  This. By default (tested on emacs -Q), when you have this tree:

**** Some text
Hi

  ...and you clock in, you get:

**** Some text
CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =>  0:02
Hi

Same with properties:
**** eeeee
:PROPERTIES:
:ou:       22
:END:
Text

  That is 1) uglier than the default. 2) violating the rule you said: new
lines should be indented at the same level as the element above.



> >   That's similar to a not-so-bad old behaviour. But it's still a bit
better (it avoids the problem described in
http://permalink.gmane.org/gmane.emacs.orgmode/92450)
>
> The problem described there is different: the OP wants some changes when
> tree structure is modified (e.g., planning info moved). You claim to
> want no change at all, which is easier, and already implemented.
>

  I want no change at all? No, my proposal is to move planning info in the
top and not move the things below it. Therefore I called it partial
indentation, as opposed to t (always indent) or nil (never indent).
  Sorry for the examples I sent in my first e-mail (
http://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00091.html), it
seems that some e-mail program has reformatted the spaces (or maybe I sent
TABs instead of spaces) and the indentation doesn't make sense. I should
have switched spaces to something else.

  I'll try again. An underscore means a space:

  Before demoting:

** some
___:CLOCK:
___CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
___:END:
Text

   What I expect after demoting:

*** some
____:CLOCK:
____CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
____:END:
Text


>
> > Ok, make it:
> >
> > 2. With org-adapt-indentation = 'partial, new lines added by org
> > (:CLOCK: drawer, CLOCK lines etc) are indented at the same level as
> > the element above.
>
> This is better, but there is still the hack about text at column 0.
>
> Also, this only makes sense if these lines are also moved when headline
> is promoted or demoted. But, then, contents will change along with tree,
> which you don't like, and it could break section structure (some lines
> being moved and not others), which cannot happen currently.
>
  "Some lines moved and others not" makes sense for a partial indentation.
You can call it 'only-top so that it's clear which lines are updated.

  I think the default behaviour should be not to change indentation,
because org-mode can be used in combination with other modes. E.g. I'm
using org-mode in beancount files (a ledger program), and lines need to
start in column 0.

> Another option would be to have another option to indent only planning
> info, properties drawer, and every drawer located right after it, à la
> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
> structure.
>
  Interesting. Yes, you could indent until (org-log-beginning).
  That would exclude notes, which are more akin to text than to drawers.
Users who want to force indent notes could switch to a full indentation
that shifts everything including contents.


--
Daniel

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

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente <n142857@gmail.com> writes:

> El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:
>>
>> You are free to make any distinction you want. Unfortunately, Org does
>> a different one. In particular, as you noticed, there are some areas
>> where things are not as clear. For example, Org cannot be sure that
>> a given drawer wasn't inserted manually, so altering its indentation may
>> or may not be a good choice.
>
>   Does it matter in practice? If the user manually inserts things that are
> normally handled by org, they can be also handled by org. Lckily you don't
> need to remember whether it was manually inputted or not.

It matters here. You want to control indentation of what is handled by
Org.

>> So, what's wrong with `org-adapt-indentation' set to nil?
>
>   This. By default (tested on emacs -Q), when you have this tree:
>
> **** Some text
> Hi
>
>   ...and you clock in, you get:
>
> **** Some text
> CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =>  0:02
> Hi
>
> Same with properties:
> **** eeeee
> :PROPERTIES:
> :ou:       22
> :END:
> Text
>
>   That is 1) uglier than the default.

This is subjective.

> 2) violating the rule you said: new lines should be indented at the
> same level as the element above.

It doesn't. Headline has level 0 indentation (per
`org-adapt-indentation'), so are properties drawer and paragraph.

>   I want no change at all? No, my proposal is to move planning info in the
> top and not move the things below it.

As explained already in this thread, the problem is not about planning
info, but about regular drawers.

>   I'll try again. An underscore means a space:
>
>   Before demoting:
>
> ** some
> ___:CLOCK:
> ___CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> ___:END:
> Text
>
>    What I expect after demoting:
>
> *** some
> ____:CLOCK:
> ____CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> ____:END:
> Text

See: this is not about planning info.

Again, it is not desirable to decide to move an element by its type
because it could alter structure of the document. In the following
example, demoting headline would move the clock drawer within the list,
which was not intended initially.

  * Headline
    - something
    :CLOCK:
    ...
    :END:

Elements can only be moved by their location. Hence, planning info and
properties drawer can be freely indented, not because of their type, but
because their location prevent them from altering the structure of the
section.

>   "Some lines moved and others not" makes sense for a partial indentation.
> You can call it 'only-top so that it's clear which lines are updated.

I don't mind the name, but I need to find a proper definition for it.

>   I think the default behaviour should be not to change indentation,
> because org-mode can be used in combination with other modes. E.g. I'm
> using org-mode in beancount files (a ledger program), and lines need to
> start in column 0.

I think the default is fine. Your use-case doesn't look like a default
one.

>> Another option would be to have another option to indent only planning
>> info, properties drawer, and every drawer located right after it, à la
>> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
>> structure.
>>
>   Interesting. Yes, you could indent until (org-log-beginning).
>   That would exclude notes, which are more akin to text than to drawers.
> Users who want to force indent notes could switch to a full indentation
> that shifts everything including contents.

No. `org-log-beginning' is not a good idea. It can be located before,
after, or even in the middle of CLOCK lines.

Again, I suggest to sync indentation of planning info and all adjacent
drawers. Nothing smarter.


Regards,

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Sebastien Vauban]

Hello,

Nicolas Goaziou wrote:
> Daniel Clemente <n142857-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:
>>>
>>> You are free to make any distinction you want. Unfortunately, Org does
>>> a different one. In particular, as you noticed, there are some areas
>>> where things are not as clear. For example, Org cannot be sure that
>>> a given drawer wasn't inserted manually, so altering its indentation may
>>> or may not be a good choice.

Regarding CLOCK lines, I guess we all agree it's not user-input, but
data managed by Org, right?

>>> So, what's wrong with `org-adapt-indentation' set to nil?
>>
>>   This. By default (tested on emacs -Q), when you have this tree:
>>
>> **** Some text
>> Hi
>>
>>   ...and you clock in, you get:
>>
>> **** Some text
>> CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =>  0:02
>> Hi
>>
>> Same with properties:
>> **** eeeee
>> :PROPERTIES:
>> :ou:       22
>> :END:
>> Text
>>
>>   That is 1) uglier than the default.
>
> This is subjective.

I agree this is probably suggestive, but *I* also find it clearer to
have the indentation different for:

- user-inputted text
- Org-managed stuff (such as clock line, timestamps or property drawers)

Note that I wrote timestamps instead of planning info because I also
would find it clearer to get:

>> **** Some text
>>      [2014-12-14 Sun 18:55]

than

>> **** Some text
>> [2014-12-14 Sun 18:55]

(when one wants to insert the timestamp in a captured note or task)

> Again, I suggest to sync indentation of planning info and all adjacent
> drawers. Nothing smarter.

Including the LOGBOOK, then?  That would already fulfill several above
cases IIUC -- not the timestamp one, though.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Regarding CLOCK lines, I guess we all agree it's not user-input, but
> data managed by Org, right?

Right. But the problem, which I explained already, is different here.

> - user-inputted text
> - Org-managed stuff (such as clock line, timestamps or property drawers)
>
> Note that I wrote timestamps instead of planning info because I also
> would find it clearer to get:
>
>>> **** Some text
>>>      [2014-12-14 Sun 18:55]
>
> than
>
>>> **** Some text
>>> [2014-12-14 Sun 18:55]
>
> (when one wants to insert the timestamp in a captured note or task)

This is not possible in the general case since timestamps can be located
almost anywhere. I suggest to live with it.

>> Again, I suggest to sync indentation of planning info and all adjacent
>> drawers. Nothing smarter.
>
> Including the LOGBOOK, then?  That would already fulfill several above
> cases IIUC

As long as LOGBOOK is located at the top of the section, right after
planning info or some drawers, it should be fine. If it is located
elsewhere, it will not be indented automatically.

> not the timestamp one, though.

See above.


Regards,

-- 
Nicolas Goaziou

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

Two proposed solutions:

1.

> >> Another option would be to have another option to indent only planning
> >> info, properties drawer, and every drawer located right after it, à la
> >> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
> >> structure.

  Is this possible?

  This indents drawers located at the top, which I think is good enough because it's where org puts the common ones by default.
  Your examples are more complex, with drawers in the middle of the text or in the middle of lists. In those cases you might need full indentation, but people who only use :CLOCK: and SCHEDULED at the top (and that's the default) could use this option.

  This is not about „indenting by type“, but about „indenting until point X“, and the trick is to find the right X.


2.


  I'd rather have org-adapt-indentation = 'initial-only which works like like org-adapt-indentation = nil with the extra that „Property drawers and planning information is inserted indented“.

  That is, new things appear with the same indentation as the element above.
  And demoting doesn't indent anything.

  Example:


** something


  You press C-c C-s and you get:


** something
   SCHEDULED: <2051-01-09 Mon>


  You press S-M-right and you get:


*** something
   SCHEDULED: <2051-01-09 Mon>


  The user can then manually decide whether he wants to correct indentations for each line.



  Or maybe both options are interesting?


--
Daniel

El Mon, 22 Dec 2014 12:34:28 +0100 Nicolas Goaziou va escriure:
> 
> Daniel Clemente <n142857@gmail.com> writes:
> 
> > El Sat, 13 Dec 2014 15:10:32 +0100 Nicolas Goaziou va escriure:
> >>
> >> You are free to make any distinction you want. Unfortunately, Org does
> >> a different one. In particular, as you noticed, there are some areas
> >> where things are not as clear. For example, Org cannot be sure that
> >> a given drawer wasn't inserted manually, so altering its indentation may
> >> or may not be a good choice.
> >
> >   Does it matter in practice? If the user manually inserts things that are
> > normally handled by org, they can be also handled by org. Lckily you don't
> > need to remember whether it was manually inputted or not.
> 
> It matters here. You want to control indentation of what is handled by
> Org.
> 
> >> So, what's wrong with `org-adapt-indentation' set to nil?
> >
> >   This. By default (tested on emacs -Q), when you have this tree:
> >
> > **** Some text
> > Hi
> >
> >   ...and you clock in, you get:
> >
> > **** Some text
> > CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =>  0:02
> > Hi
> >
> > Same with properties:
> > **** eeeee
> > :PROPERTIES:
> > :ou:       22
> > :END:
> > Text
> >
> >   That is 1) uglier than the default.
> 
> This is subjective.
> 
> > 2) violating the rule you said: new lines should be indented at the
> > same level as the element above.
> 
> It doesn't. Headline has level 0 indentation (per
> `org-adapt-indentation'), so are properties drawer and paragraph.
> 
> >   I want no change at all? No, my proposal is to move planning info in the
> > top and not move the things below it.
> 
> As explained already in this thread, the problem is not about planning
> info, but about regular drawers.
> 
> >   I'll try again. An underscore means a space:
> >
> >   Before demoting:
> >
> > ** some
> > ___:CLOCK:
> > ___CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> > ___:END:
> > Text
> >
> >    What I expect after demoting:
> >
> > *** some
> > ____:CLOCK:
> > ____CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> > ____:END:
> > Text
> 
> See: this is not about planning info.
> 
> Again, it is not desirable to decide to move an element by its type
> because it could alter structure of the document. In the following
> example, demoting headline would move the clock drawer within the list,
> which was not intended initially.
> 
>   * Headline
>     - something
>     :CLOCK:
>     ...
>     :END:
> 
> Elements can only be moved by their location. Hence, planning info and
> properties drawer can be freely indented, not because of their type, but
> because their location prevent them from altering the structure of the
> section.
> 
> >   "Some lines moved and others not" makes sense for a partial indentation.
> > You can call it 'only-top so that it's clear which lines are updated.
> 
> I don't mind the name, but I need to find a proper definition for it.
> 
> >   I think the default behaviour should be not to change indentation,
> > because org-mode can be used in combination with other modes. E.g. I'm
> > using org-mode in beancount files (a ledger program), and lines need to
> > start in column 0.
> 
> I think the default is fine. Your use-case doesn't look like a default
> one.
> 
> >> Another option would be to have another option to indent only planning
> >> info, properties drawer, and every drawer located right after it, à la
> >> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
> >> structure.
> >>
> >   Interesting. Yes, you could indent until (org-log-beginning).
> >   That would exclude notes, which are more akin to text than to drawers.
> > Users who want to force indent notes could switch to a full indentation
> > that shifts everything including contents.
> 
> No. `org-log-beginning' is not a good idea. It can be located before,
> after, or even in the middle of CLOCK lines.
> 
> Again, I suggest to sync indentation of planning info and all adjacent
> drawers. Nothing smarter.
> 
> 
> Regards,

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente <n142857@gmail.com> writes:

>> >> Another option would be to have another option to indent only planning
>> >> info, properties drawer, and every drawer located right after it, à la
>> >> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
>> >> structure.
>
>   Is this possible?

Why wouldn't it?

>   This indents drawers located at the top, which I think is good
>   enough because it's where org puts the common ones by default.

>   Your examples are more complex, with drawers in the middle of the
>   text or in the middle of lists. In those cases you might need full
>   indentation, but people who only use :CLOCK: and SCHEDULED at the
>   top (and that's the default) could use this option.

>   This is not about „indenting by type“, but about „indenting until
>   point X“, and the trick is to find the right X.

This is what I explained already. Indenting by type will fail in some
cases. Indenting until some location is fine, as long as we are cautious
about the said location.

>   I'd rather have org-adapt-indentation = 'initial-only which works
>   like like org-adapt-indentation = nil with the extra that „Property
>   drawers and planning information is inserted indented“.
>
>   That is, new things appear with the same indentation as the element above.
>   And demoting doesn't indent anything.
>
>   Example:
>
>
> ** something
>
>
>   You press C-c C-s and you get:
>
>
> ** something
>    SCHEDULED: <2051-01-09 Mon>
>
>
>   You press S-M-right and you get:
>
>
> *** something
>    SCHEDULED: <2051-01-09 Mon>
>
>
>   The user can then manually decide whether he wants to correct
>   indentations for each line.

I fail to see how this would be useful. In particular, it fails if the
section has contents prior to the scheduling step. Also, it doesn't
solve Sébastien's problem.


Regards,

Re: Fwd: demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

> 
> >> >> Another option would be to have another option to indent only planning
> >> >> info, properties drawer, and every drawer located right after it, à la
> >> >> `org-log-state-notes-insert-after-drawers'. At least, it couldn't break
> >> >> structure.
> >
> >   Is this possible?
> 
> Why wouldn't it?
> 

  I thought this could also kill kittens.

  Would you be so kind to allow this as an option for org-adapt-indentation? This is the most similar to the default behaviour that org-mode had until 2014, it looks nice, it's flexible and it doesn't break structure.
  Or could you provide some steps to implement this? (E.g. functions that need to be taken care of).


  About the 2nd proposal:
> 
> >   I'd rather have org-adapt-indentation = 'initial-only which works
> >   like like org-adapt-indentation = nil with the extra that „Property
> >   drawers and planning information is inserted indented“.
> >
> >   That is, new things appear with the same indentation as the element above.
> >   And demoting doesn't indent anything.
> >
> >   Example:
> >
> >
> > ** something
> >
> >
> >   You press C-c C-s and you get:
> >
> >
> > ** something
> >    SCHEDULED: <2051-01-09 Mon>
> >
> >
> >   You press S-M-right and you get:
> >
> >
> > *** something
> >    SCHEDULED: <2051-01-09 Mon>
> >
> >
> >   The user can then manually decide whether he wants to correct
> >   indentations for each line.
> 
> I fail to see how this would be useful. In particular, it fails if the
> section has contents prior to the scheduling step. Also, it doesn't
> solve Sébastien's problem.
> 

  Both Sébastien and I agree that this…:
  
>> **** Some text
>>      [2014-12-14 Sun 18:55]

…looks nicer than this:

>> **** Some text
>> [2014-12-14 Sun 18:55]

  With the algorithm above, you'll get the nice version with the downside that org-mode won't handle indentation for you from now on. If org-adapt-indentation=nil is useful, this is useful and a bit nicer.
  If the section has contents prior to the scheduling line, you can still follow the rule that new things inherit the indentation of the previous element.


  The first option seems better anyway, but the second one seems easier to implement. 


Greetings