From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Clemente Subject: Re: Fwd: demoting a heading inserts spaces in column-0 text Date: Fri, 09 Jan 2015 23:02:23 +0700 Message-ID: <87bnm8j628.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> <87k31vr7pi.wl-n142857@gmail.com> <877fxvabdz.fsf@nicolasgoaziou.fr> <87iohequ70.wl-n142857@gmail.com> <87sig7x6ij.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]:48376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9c1G-0001Qe-GN for emacs-orgmode@gnu.org; Fri, 09 Jan 2015 11:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9c1D-0000EG-8G for emacs-orgmode@gnu.org; Fri, 09 Jan 2015 11:02:38 -0500 Received: from mail-pd0-x230.google.com ([2607:f8b0:400e:c02::230]:56369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9c1C-0000E3-TR for emacs-orgmode@gnu.org; Fri, 09 Jan 2015 11:02:35 -0500 Received: by mail-pd0-f176.google.com with SMTP id r10so18196391pdi.7 for ; Fri, 09 Jan 2015 08:02:33 -0800 (PST) Received: from la4.gmail.com ([182.253.242.56]) by mx.google.com with ESMTPSA id ul5sm7572679pab.36.2015.01.09.08.02.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 08:02:31 -0800 (PST) In-Reply-To: <87sig7x6ij.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 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, =C3= =A0 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 bec= ause 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, bu= t people who only use :CLOCK: and SCHEDULED at the top (and that's the defa= ult) could use this option. This is not about =E2=80=9Eindenting by type=E2=80=9C, but about =E2=80= =9Eindenting until point X=E2=80=9C, and the trick is to find the right X. 2. I'd rather have org-adapt-indentation =3D 'initial-only which works like = like org-adapt-indentation =3D nil with the extra that =E2=80=9EProperty dr= awers and planning information is inserted indented=E2=80=9C. 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 indentation= s for each line. Or maybe both options are interesting? -- Daniel El Mon, 22 Dec 2014 12:34:28 +0100 Nicolas Goaziou va escriure: >=20 > Daniel Clemente writes: >=20 > > 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 m= ay > >> 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 do= n't > > need to remember whether it was manually inputted or not. >=20 > It matters here. You want to control indentation of what is handled by > Org. >=20 > >> 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. >=20 > This is subjective. >=20 > > 2) violating the rule you said: new lines should be indented at the > > same level as the element above. >=20 > It doesn't. Headline has level 0 indentation (per > `org-adapt-indentation'), so are properties drawer and paragraph. >=20 > > I want no change at all? No, my proposal is to move planning info in = the > > top and not move the things below it. >=20 > As explained already in this thread, the problem is not about planning > info, but about regular drawers. >=20 > > 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 >=20 > See: this is not about planning info. >=20 > 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. >=20 > * Headline > - something > :CLOCK: > ... > :END: >=20 > 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. >=20 > > "Some lines moved and others not" makes sense for a partial indentati= on. > > You can call it 'only-top so that it's clear which lines are updated. >=20 > I don't mind the name, but I need to find a proper definition for it. >=20 > > 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. >=20 > I think the default is fine. Your use-case doesn't look like a default > one. >=20 > >> Another option would be to have another option to indent only planning > >> info, properties drawer, and every drawer located right after it, =C3= =A0 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. >=20 > No. `org-log-beginning' is not a good idea. It can be located before, > after, or even in the middle of CLOCK lines. >=20 > Again, I suggest to sync indentation of planning info and all adjacent > drawers. Nothing smarter. >=20 >=20 > Regards,