Re: [O] demoting a heading inserts spaces in column-0 text
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: [O] demoting a heading inserts spaces in column-0 text
Daniel Clemente n142...@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: [O] demoting a heading inserts spaces in column-0 text
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: [O] demoting a heading inserts spaces in column-0 text
Daniel Clemente n142...@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,
Re: [O] demoting a heading inserts spaces in column-0 text
Daniel Clemente n142...@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: [O] demoting a heading inserts spaces in column-0 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. 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 m...@nicolasgoaziou.fr wrote: Hello, Daniel Clemente n142...@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
[O] demoting a heading inserts spaces in column-0 text
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: [O] demoting a heading inserts spaces in column-0 text
Hello, Daniel Clemente n142...@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
