From: Daniel Clemente <n142857@gmail.com>
To: Org-mode Org-Mode <emacs-orgmode@gnu.org>
Subject: Re: Fwd: demoting a heading inserts spaces in column-0 text
Date: Fri, 09 Jan 2015 23:02:23 +0700 [thread overview]
Message-ID: <87bnm8j628.wl-n142857@gmail.com> (raw)
In-Reply-To: <87sig7x6ij.fsf@nicolasgoaziou.fr>
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,
next prev parent reply other threads:[~2015-01-09 16:02 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
2014-12-22 15:28 ` Sebastien Vauban
2014-12-23 8:41 ` Nicolas Goaziou
2015-01-09 16:02 ` Daniel Clemente [this message]
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=87bnm8j628.wl-n142857@gmail.com \
--to=n142857@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).