* [RFC]: Uniform indentation for lists
@ 2013-06-24 21:58 Jambunathan K
2013-06-25 9:44 ` Suvayu Ali
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Jambunathan K @ 2013-06-24 21:58 UTC (permalink / raw)
To: emacs-orgmode
This request is a result of adding Org-mode support to Oddmuse. (See my
earlier mail that introduces Orgmuse).
When lists are "normalized", the sub-lists are introduced by varying
amout of spaces depending on the type of the parent list. It's 3 spaces
if the parent is numbered and 2 spaces if the parent is bulleted.
1. One
2. Two
- Bullet One
- Bullet Two
1. One
2. Two
Oddmuse wiki and possibly Usemod (and even other Wiki engines) do a
linear scan of text (much like what the old org-html.el used to do) and
emits HTML by looking at thing at point. Having the list items
introduced by varying amout of spaces makes the parser "more" stateful.
I was wondering whether there would be some interest in
1) To eliminate the separators - "." or ")" - in the numbered list
2) Enhance the list repair routine so that it will alway indent by 3 spaces.
With (1) above, the earlier list becomes,
1 One
2 Two
- Bullet One
- Bullet Two
1 One
2 Two
This gives a uniform indentation of 2 spaces.
With (2) or (3), the earlier list becomes,
1. One
2. Two
- Bullet One
- Bullet Two
1. One
2. Two
This gives an indentation of 3 spaces. The 3 spaces could either be
mandated by the canonical Org-markup spec or it could be ensured by the
author of Org document himself (by using the proposed new repair option)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC]: Uniform indentation for lists
2013-06-24 21:58 [RFC]: Uniform indentation for lists Jambunathan K
@ 2013-06-25 9:44 ` Suvayu Ali
2013-06-26 4:38 ` Jambunathan K
2013-06-25 15:33 ` Carsten Dominik
2013-06-25 21:02 ` Achim Gratz
2 siblings, 1 reply; 6+ messages in thread
From: Suvayu Ali @ 2013-06-25 9:44 UTC (permalink / raw)
To: emacs-orgmode
Hello Jambunathan,
On Tue, Jun 25, 2013 at 03:28:34AM +0530, Jambunathan K wrote:
>
> I was wondering whether there would be some interest in
>
> 1) To eliminate the separators - "." or ")" - in the numbered list
> 2) Enhance the list repair routine so that it will alway indent by 3 spaces.
>
> With (1) above, the earlier list becomes,
>
> 1 One
> 2 Two
> - Bullet One
> - Bullet Two
> 1 One
> 2 Two
I think it will still break for long lists (greater than 9 items).
9 item
10 item
That said, if this is followed up, I would prefer (2). The "." and ")"
tend to serve as useful indicators for me. I also find them helpful
when I use the @ syntax.
3. [@3] Item
4. Another item
Cheers,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]: Uniform indentation for lists
2013-06-24 21:58 [RFC]: Uniform indentation for lists Jambunathan K
2013-06-25 9:44 ` Suvayu Ali
@ 2013-06-25 15:33 ` Carsten Dominik
2013-06-25 21:02 ` Achim Gratz
2 siblings, 0 replies; 6+ messages in thread
From: Carsten Dominik @ 2013-06-25 15:33 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Hi,
the indentation rules for lists in Org are ancient, and I don't thing we
want to break so many existing files. And we certainly cannot change the
numbered bullets.
The only thing I would accept is an option to enforce 3 space indentation
on TAB, but the parser must read 2 space indentation as well. And, as
Savayu points out, lists longer than 9 items will always be an issue.
- Carsten
On 24.6.2013, at 23:58, Jambunathan K <kjambunathan@gmail.com> wrote:
>
> This request is a result of adding Org-mode support to Oddmuse. (See my
> earlier mail that introduces Orgmuse).
>
> When lists are "normalized", the sub-lists are introduced by varying
> amout of spaces depending on the type of the parent list. It's 3 spaces
> if the parent is numbered and 2 spaces if the parent is bulleted.
>
> 1. One
> 2. Two
> - Bullet One
> - Bullet Two
> 1. One
> 2. Two
>
> Oddmuse wiki and possibly Usemod (and even other Wiki engines) do a
> linear scan of text (much like what the old org-html.el used to do) and
> emits HTML by looking at thing at point. Having the list items
> introduced by varying amout of spaces makes the parser "more" stateful.
>
> I was wondering whether there would be some interest in
>
> 1) To eliminate the separators - "." or ")" - in the numbered list
> 2) Enhance the list repair routine so that it will alway indent by 3 spaces.
>
> With (1) above, the earlier list becomes,
>
> 1 One
> 2 Two
> - Bullet One
> - Bullet Two
> 1 One
> 2 Two
>
> This gives a uniform indentation of 2 spaces.
>
>
> With (2) or (3), the earlier list becomes,
>
> 1. One
> 2. Two
> - Bullet One
> - Bullet Two
> 1. One
> 2. Two
>
> This gives an indentation of 3 spaces. The 3 spaces could either be
> mandated by the canonical Org-markup spec or it could be ensured by the
> author of Org document himself (by using the proposed new repair option)
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]: Uniform indentation for lists
2013-06-24 21:58 [RFC]: Uniform indentation for lists Jambunathan K
2013-06-25 9:44 ` Suvayu Ali
2013-06-25 15:33 ` Carsten Dominik
@ 2013-06-25 21:02 ` Achim Gratz
2013-06-26 4:27 ` Jambunathan K
2 siblings, 1 reply; 6+ messages in thread
From: Achim Gratz @ 2013-06-25 21:02 UTC (permalink / raw)
To: emacs-orgmode
Jambunathan K writes:
> When lists are "normalized", the sub-lists are introduced by varying
> amout of spaces depending on the type of the parent list. It's 3 spaces
> if the parent is numbered and 2 spaces if the parent is bulleted.
>
> 1. One
> 2. Two
> - Bullet One
> - Bullet Two
> 1. One
> 2. Two
>
> Oddmuse wiki and possibly Usemod (and even other Wiki engines) do a
> linear scan of text (much like what the old org-html.el used to do) and
> emits HTML by looking at thing at point. Having the list items
> introduced by varying amout of spaces makes the parser "more" stateful.
I don't think this is ever going to work unless you restrict either the
number of items or the types of enumeration. But you could easily
normalize on export into those formats by indenting with a number of
tabs corresponding to the indent level. That would look strange in a
buffer (unless you set the tab-width appropriately), but it would be
parseable more easily. But Oddmuse is in Perl, so keeping a stack of
indents really isn't a big deal (and I don't think it'd be in other
languages like Python, PHP or Ruby).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC]: Uniform indentation for lists
2013-06-25 21:02 ` Achim Gratz
@ 2013-06-26 4:27 ` Jambunathan K
0 siblings, 0 replies; 6+ messages in thread
From: Jambunathan K @ 2013-06-26 4:27 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> I don't think this is ever going to work unless you restrict either the
> number of items or the types of enumeration.
My item will most likely look this.
1. One
1. Two
1. Hundredth item
1. Thousandth item
Works well both in Org and the Wiki engine.
What I need is a way to suppress "electric repair" of Lists or have the
repair work in restricted ways.
> But Oddmuse is in Perl, so keeping a stack of indents really isn't a
> big deal (and I don't think it'd be in other languages like Python,
> PHP or Ruby).
True.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-26 4:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-24 21:58 [RFC]: Uniform indentation for lists Jambunathan K
2013-06-25 9:44 ` Suvayu Ali
2013-06-26 4:38 ` Jambunathan K
2013-06-25 15:33 ` Carsten Dominik
2013-06-25 21:02 ` Achim Gratz
2013-06-26 4:27 ` Jambunathan K
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).