emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] indentation cycling


From: Samuel Wales
Subject: [Orgmode] indentation cycling
Date: Wed, 7 Oct 2009 11:07:57 -0700

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]


1.

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

  - 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
        here
  here
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
fixed.

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
later.[2]

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


2.

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
fixed.[4]

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.

Thanks!


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

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

[2] For the org-cycle case:
\par
  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
  visibility.
\par
  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.
\par
  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
SIBLING).

[4] For the org-cycle case:
\par
  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 via email to

[Prev in Thread] Current Thread [Next in Thread]