emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nicolas Goaziou
Subject: Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
Date: Mon, 22 Dec 2014 12:34:28 +0100

Daniel Clemente <address@hidden> 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,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]