From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Daniel Clemente <n142857@gmail.com>
Cc: Org-mode Org-Mode <emacs-orgmode@gnu.org>
Subject: Re: Fwd: demoting a heading inserts spaces in column-0 text
Date: Mon, 22 Dec 2014 12:34:28 +0100 [thread overview]
Message-ID: <87sig7x6ij.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <CAJKAhPAcin_FdR3jRcXpWag1+ZDXzWmLZyyfVzm5L3B87=Sdqw@mail.gmail.com> (Daniel Clemente's message of "Mon, 22 Dec 2014 12:43:20 +0700")
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,
next prev parent reply other threads:[~2014-12-22 11:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 13:02 demoting a heading inserts spaces in column-0 text Daniel Clemente
2014-12-05 23:40 ` Nicolas Goaziou
2014-12-11 12:36 ` Daniel Clemente
2014-12-12 18:25 ` Nicolas Goaziou
2014-12-13 10:28 ` Daniel Clemente
2014-12-13 11:33 ` Nicolas Goaziou
2014-12-13 13:38 ` Daniel Clemente
2014-12-13 14:10 ` Nicolas Goaziou
[not found] ` <87iohequ70.wl-n142857@gmail.com>
2014-12-22 5:43 ` Fwd: " Daniel Clemente
2014-12-22 11:34 ` Nicolas Goaziou [this message]
2014-12-22 15:28 ` Sebastien Vauban
2014-12-23 8:41 ` Nicolas Goaziou
2015-01-09 16:02 ` Daniel Clemente
2015-01-13 11:10 ` Nicolas Goaziou
2015-01-16 14:29 ` Daniel Clemente
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sig7x6ij.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=n142857@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).