Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
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? Why wouldn't it? I thought this could also kill kittens. Would you be so kind to allow this as an option for org-adapt-indentation? This is the most similar to the default behaviour that org-mode had until 2014, it looks nice, it's flexible and it doesn't break structure. Or could you provide some steps to implement this? (E.g. functions that need to be taken care of). About the 2nd proposal: 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. I fail to see how this would be useful. In particular, it fails if the section has contents prior to the scheduling step. Also, it doesn't solve Sébastien's problem. Both Sébastien and I agree that this…: Some text [2014-12-14 Sun 18:55] …looks nicer than this: Some text [2014-12-14 Sun 18:55] With the algorithm above, you'll get the nice version with the downside that org-mode won't handle indentation for you from now on. If org-adapt-indentation=nil is useful, this is useful and a bit nicer. If the section has contents prior to the scheduling line, you can still follow the rule that new things inherit the indentation of the previous element. The first option seems better anyway, but the second one seems easier to implement. Greetings
Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
Daniel Clemente n142...@gmail.com writes: 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? Why wouldn't it? 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. This is what I explained already. Indenting by type will fail in some cases. Indenting until some location is fine, as long as we are cautious about the said location. 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. I fail to see how this would be useful. In particular, it fails if the section has contents prior to the scheduling step. Also, it doesn't solve Sébastien's problem. Regards,
Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
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 n142...@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: e :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
Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Regarding CLOCK lines, I guess we all agree it's not user-input, but data managed by Org, right? Right. But the problem, which I explained already, is different here. - user-inputted text - Org-managed stuff (such as clock line, timestamps or property drawers) Note that I wrote timestamps instead of planning info because I also would find it clearer to get: Some text [2014-12-14 Sun 18:55] than Some text [2014-12-14 Sun 18:55] (when one wants to insert the timestamp in a captured note or task) This is not possible in the general case since timestamps can be located almost anywhere. I suggest to live with it. Again, I suggest to sync indentation of planning info and all adjacent drawers. Nothing smarter. Including the LOGBOOK, then? That would already fulfill several above cases IIUC As long as LOGBOOK is located at the top of the section, right after planning info or some drawers, it should be fine. If it is located elsewhere, it will not be indented automatically. not the timestamp one, though. See above. Regards, -- Nicolas Goaziou
Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
Daniel Clemente n142...@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: e :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,
Re: [O] Fwd: demoting a heading inserts spaces in column-0 text
Hello, Nicolas Goaziou wrote: Daniel Clemente n142...@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. Regarding CLOCK lines, I guess we all agree it's not user-input, but data managed by Org, right? 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: e :PROPERTIES: :ou: 22 :END: Text That is 1) uglier than the default. This is subjective. I agree this is probably suggestive, but *I* also find it clearer to have the indentation different for: - user-inputted text - Org-managed stuff (such as clock line, timestamps or property drawers) Note that I wrote timestamps instead of planning info because I also would find it clearer to get: Some text [2014-12-14 Sun 18:55] than Some text [2014-12-14 Sun 18:55] (when one wants to insert the timestamp in a captured note or task) Again, I suggest to sync indentation of planning info and all adjacent drawers. Nothing smarter. Including the LOGBOOK, then? That would already fulfill several above cases IIUC -- not the timestamp one, though. Best regards, Seb -- Sebastien Vauban
[O] Fwd: demoting a heading inserts spaces in column-0 text
(I'm resending this old e-mail because it seems it didn't get to the list, according to Gmane). 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: e :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
