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