emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: indentation cycling
Date: Wed, 7 Oct 2009 11:07:57 -0700	[thread overview]
Message-ID: <20524da70910071107s55fff3ecj4d92f2bc9511b970@mail.gmail.com> (raw)

Here are two ideas for cycling indentation in body text.

I often find myself doing TAB in the expectation that it
will execute them.  I wonder if others also do that.

These operations affect only the current line.[1]


I always indent the plain list top level to column 2 like

  - top level
    `continuation line'
    - child
  - top level (sibling)

I also like to indent text sometimes.

        like this.

Here is how it would work.

If the line /does not/ look like a `continuation line'
(i.e. it does not follow an item or (recursively) a
`continuation line'), then these are the cycle states.  (The
"here" line is being indented differently.)

  - here

This cycling command can be a separate command (e.g. on
C-M-TAB) or it can be combined with org-cycle (which does
visibility cycling).  If it is a separate command, there are
no conflicts.  If it is combined, the conflicts can be

If does not turn out to be too complicated, I'd prefer
org-cycle to do it, because that is the natural place for
the user to try.  Or perhaps we can experiment with it on a
separate command first, then integrate it with org-cycle

I tried to implement it but it was difficult for me.


If the current line /does/ look like a `continuation line',
cycling looks like this.  (The "[]" (location of point) is
being indented differently but the only thing being indented
is a blank line.)

  - top level
    - hello
      [] (`continuation line')

Then this.

  - top level
    - hello
      - [] (`child')

Then this.

  - top level
    - hello
    - [] (`sibling')

Then optionally[3] this.

  - top level
    - hello
  - [] (`aunt/uncle')

Again, this can be a separate command (e.g. on C-M-TAB) or
it can be combined with org-cycle (which does visibility
cycling).  If it is a separate command, there are no
conflicts.  If it is combined, the conflicts can be

Counterargument to idea 2: with the exception of
`continuation line', idea 2 is redundant with M-r/l and
S-M-r/l.  The justification is that list entry is faster,
and that, since we want to deal with `continuation line' (I
think this is important), we might as well also do other
indentation things similarly to how we do with idea 1.  It
feels more consistent with idea 1 to have this extra way of
demoting and (optionally) promoting.

Will be interested in comments.


[fn:40] Alternative: only allow this on blank lines (other
than "-" and whitespace).

[1] They could affect the active region also, if

[2] For the org-cycle case:
  Cycling from the bullet stage to the next stage conflicts
  with visibility cycling.  To fix that, check to see if the
  previous command was at stage 1.  If not, the user is not
  trying to modify the hierarchy at all, so cycle
  In other words, if you are on an existing hierarchy, TAB
  will never change to zero indentation or
  extended-quote-like indentation.  Thus, if you combine
  with org-cycle, idea 1 is only for new indentation.  It is
  for fast creation.
  I have org-adapt-indentation set to nil.  If there is a
  conflict with this variable set to t, the variable can
  override. Perhaps somebody can confirm that there are no
  other conflicts.

[3] It could also be promoted more than once.  We can
choose to cycle all the way back to the top level, here.
Normally, I'd reject such a solution for being too many
cycle states, but in this case it's at least visually
obvious what's going on, and how many states are necessary
until you wrap around.  Still, we can optionally cycle back
after the sibling, merely cycling '(CONTINUATION CHILD

[4] For the org-cycle case:
  Note that stages 3, 4, and back to 1 would conflict with
  visibility cycling.  That can be resolved as with idea 1,
  by checking to see whether the previous command was the
  previous stage.[fn:40]

             reply	other threads:[~2009-10-07 18:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 18:07 Samuel Wales [this message]
2009-10-08 22:12 ` indentation cycling Samuel Wales

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:

  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=20524da70910071107s55fff3ecj4d92f2bc9511b970@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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


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).