From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Clemente Subject: Fwd: demoting a heading inserts spaces in column-0 text Date: Mon, 22 Dec 2014 12:43:20 +0700 Message-ID: References: <87k326i71d.wl-n142857@gmail.com> <871tod3bu5.fsf@nicolasgoaziou.fr> <87388mvxgd.fsf@nicolasgoaziou.fr> <87lhmbrgi1.wl-n142857@gmail.com> <87bnn7aio3.fsf@nicolasgoaziou.fr> <87k31vr7pi.wl-n142857@gmail.com> <877fxvabdz.fsf@nicolasgoaziou.fr> <87iohequ70.wl-n142857@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d869339484b050ac789ea Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2vmE-0007Ch-48 for emacs-orgmode@gnu.org; Mon, 22 Dec 2014 00:43:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2vm6-0008VG-KC for emacs-orgmode@gnu.org; Mon, 22 Dec 2014 00:43:30 -0500 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:56219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2vm6-0008Uk-7F for emacs-orgmode@gnu.org; Mon, 22 Dec 2014 00:43:22 -0500 Received: by mail-wi0-f170.google.com with SMTP id bs8so9489769wib.5 for ; Sun, 21 Dec 2014 21:43:20 -0800 (PST) In-Reply-To: <87iohequ70.wl-n142857@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org-mode Org-Mode --047d7b5d869339484b050ac789ea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (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-tre= es > > 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] =3D> 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] =3D> 0:55 ___:END: Text What I expect after demoting: *** some ____:CLOCK: ____CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =3D> 0:55 ____:END: Text > > > Ok, make it: > > > > 2. With org-adapt-indentation =3D '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, =E0 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 --047d7b5d869339484b050ac789ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(I'm resending this old e-mail because it seems it did= n'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 wo= rds SCHEDULED,
> >   TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], time= stamps, …
> >
> >   I speak for myself, but I expect class 1 not to be ch= anged 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 indentati= on may
> or may not be a good choice.

  Does it matter in practice? If the user manually inserts thin= gs that are normally handled by org, they can be also handled by org. Lckil= y you don't need to remember whether it was manually inputted or not.
>
> >   Indentation is for me as important as the other lette= rs 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 „i= tem content“ are
> > disconnected.
> >   If you really need other sources, you can see how tre= e operations in
> > other contexts don't modify the contents of each node:
> > http://pythonhosted.org/ete2/tut= orial/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 tre= e:

**** Some text
Hi

  …and you clock in, you get:

**** Some text
CLOCK: [2014-12-14 Sun 18:55]--[2014-12-14 Sun 18:57] =3D>  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 ht= tp://permalink.gmane.org/gmane.emacs.orgmode/92450)
>
> The problem described there is different: the OP wants some changes wh= en
> 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 par= tial 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.htm= l), it seems that some e-mail program has reformatted the spaces (or ma= ybe I sent TABs instead of spaces) and the indentation doesn't make sen= se. 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] =3D>  0:55=
___:END:
Text

   What I expect after demoting:

*** some
____:CLOCK:
____CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =3D>  0:5= 5
____:END:
Text


>
> > Ok, make it:
> >
> > 2. With org-adapt-indentation =3D 'partial, new lines added b= y 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 headlin= e
> is promoted or demoted. But, then, contents will change along with tre= e,
> which you don't like, and it could break section structure (some l= ines
> 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 clea= r which lines are updated.

  I think the default behaviour should be not to change indentation, b= ecause org-mode can be used in combination with other modes. E.g. I'm u= sing org-mode in beancount files (a ledger program), and lines need to star= t 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, =E0 = la
> `org-log-state-notes-insert-after-drawers'. At least, it couldn= 9;t break
> structure.
>
  Interesting. Yes, you could indent until (org-log-beginning).=
  That would exclude notes, which are more akin to text than to drawer= s. Users who want to force indent notes could switch to a full indentation = that shifts everything including contents.


--
Daniel

--047d7b5d869339484b050ac789ea--