emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Daniel Clemente <n142857@gmail.com>
To: Org-mode Org-Mode <emacs-orgmode@gnu.org>
Subject: Fwd: demoting a heading inserts spaces in column-0 text
Date: Mon, 22 Dec 2014 12:43:20 +0700	[thread overview]
Message-ID: <CAJKAhPAcin_FdR3jRcXpWag1+ZDXzWmLZyyfVzm5L3B87=Sdqw@mail.gmail.com> (raw)
In-Reply-To: <87iohequ70.wl-n142857@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5590 bytes --]

(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:
**** 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] =>  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
> `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

[-- Attachment #2: Type: text/html, Size: 7192 bytes --]

  parent reply	other threads:[~2014-12-22  5:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 13:02 demoting a heading inserts spaces in column-0 text Daniel Clemente
2014-12-05 23:40 ` Nicolas Goaziou
2014-12-11 12:36   ` Daniel Clemente
2014-12-12 18:25     ` Nicolas Goaziou
2014-12-13 10:28       ` Daniel Clemente
2014-12-13 11:33         ` Nicolas Goaziou
2014-12-13 13:38           ` Daniel Clemente
2014-12-13 14:10             ` Nicolas Goaziou
     [not found]               ` <87iohequ70.wl-n142857@gmail.com>
2014-12-22  5:43                 ` Daniel Clemente [this message]
2014-12-22 11:34                   ` Fwd: " Nicolas Goaziou
2014-12-22 15:28                     ` Sebastien Vauban
2014-12-23  8:41                       ` Nicolas Goaziou
2015-01-09 16:02                     ` Daniel Clemente
2015-01-13 11:10                       ` Nicolas Goaziou
2015-01-16 14:29                         ` Daniel Clemente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJKAhPAcin_FdR3jRcXpWag1+ZDXzWmLZyyfVzm5L3B87=Sdqw@mail.gmail.com' \
    --to=n142857@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).