From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Clemente Subject: Re: demoting a heading inserts spaces in column-0 text Date: Sat, 13 Dec 2014 20:38:01 +0700 Message-ID: <87k31vr7pi.wl-n142857@gmail.com> References: <87k326i71d.wl-n142857@gmail.com> <871tod3bu5.fsf@nicolasgoaziou.fr> <87388mvxgd.fsf@nicolasgoaziou.fr> <87lhmbrgi1.wl-n142857@gmail.com> <87bnn7aio3.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzmth-0004g0-T6 for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 08:38:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xzmtc-0000VY-UP for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 08:38:13 -0500 Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]:60047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzmtc-0000VH-It for emacs-orgmode@gnu.org; Sat, 13 Dec 2014 08:38:08 -0500 Received: by mail-pa0-f50.google.com with SMTP id bj1so9040992pad.9 for ; Sat, 13 Dec 2014 05:38:07 -0800 (PST) Received: from cil.gmail.com ([36.78.5.20]) by mx.google.com with ESMTPSA id ta9sm4283263pbc.50.2014.12.13.05.38.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Dec 2014 05:38:06 -0800 (PST) In-Reply-To: <87bnn7aio3.fsf@nicolasgoaziou.fr> 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 El Sat, 13 Dec 2014 12:33:16 +0100 Nicolas Goaziou va escriure: > > But these are technical details, not relevant to a non-programmer. >=20 > Which basically means nothing, because everything ultimately boils down > to technical details. >=20 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-so= mething, S-something, M-something). E.g.: the words SCHEDULED, TODO, CLOCK,= PROPERTIES, EFFORT, checkboxes [ ], timestamps, =E2=80=A6 I speak for myself, but I expect class 1 not to be changed by org, and cl= ass 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. =20 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 >=20 > FUD. Neither the text nor its structure are modified. Only indentation > is. How it is done is explained in `org-adapt-indentation' docstring. >=20 Indentation is for me as important as the other letters I type. I don't w= ant it changed. It's a personal preference. Emacs respects it to great extents. > > because in a logical tree of nodes, demoting does not mean =E2=80=9Eshi= ft > > contents=E2=80=9C. >=20 > 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 af= fect how I write the text (e.g. how many indentation spaces). I can move no= des freely from one place to another and I have no indentations to fix. =E2= =80=9ETree structure=E2=80=9C and =E2=80=9Eitem content=E2=80=9C are discon= nected. If you really need other sources, you can see how tree operations in othe= r 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. =20 > > I also lose controllability because I have no way to rearrange nodes > > without side effects. >=20 > We might fix them. What are exactly these side-effects? >=20 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] =3D> 0:55 :END: Text to this: =20 ***** some :CLOCK: CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =3D> 0:55 :END: Text This will happen in all subtrees. > > I suggest: > > > > 1. New default for org-adapt-indentation =3D '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. >=20 > 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. =20 >=20 > > 2. With org-adapt-indentation =3D 'partial, new lines added by org > > (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the > > heading, not at column 0 >=20 > This would be plain wrong. Indentation is relative to the element above. > Heading indentation is but the fallback value. >=20 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 ele= ment above. -- Daniel