emacs-orgmode
[Top][All Lists]
Advanced

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

Re: Orgmode plain list bullet : change automatically with list depth


From: Tim Cross
Subject: Re: Orgmode plain list bullet : change automatically with list depth
Date: Sat, 18 Jun 2022 10:17:40 +1000
User-agent: mu4e 1.7.27; emacs 28.1.50

Samuel Wales <samologist@gmail.com> writes:

> sure.
>
> iiuc i think op wants 2 things:
>
>   1] graphical bullets.  i.e. not the - + etc. that are in the org
> plain text as saved to disk.
>   2] each level of a list to have the same bullet style
>
>
> examples of 2]:
>
> a conforming list:
>
> - this is level 1.  for this list, we always want level 1 to
>   use the - bullet style in the org plain text.
>   + this is level 2.  for this list, we always want level 2
>     to use the + bullet style in the org plain text.
>   + another level 2
> - another level 1
>   + another level 2
>   + the + is CONSISTENT with the + in the level 2 of the
>     previous list item
>
>
> a non-conforming list:
>
>
> - this is level 1.  for this list, we always want level 1 to
>   use the - bullet style in the org plain text.
>   + this is level 2.  for this list, we always want level 2
>     to use the + bullet style in the org plain text.
>   + another level 2
> - another level 1
>   * another level 2
>   * these * markers are INCONSISTENT with the + markers in
>     the level 2 previous list item.
>
>
> the idea is for org [as opposed to fontification] to enforce this
> level correspondence.  whenever we do a bullet style change at any
> level, org could change ALL BULLETS AT THE SAME LEVEL.  this keeps the
> list conforming.
>
> currently, org does not do this.  instead, it allows you to
> say that /demotion/ makes a + when you have a -.  but
> without enforcement, the list can quickly become
> non-conforming after the user edits it.
>
> this idea is independent (orthogonal) to fontification /
> displayed graphical glyph.  i think op's 2] idea can make
> sense.  and then fontification / displayed graphical glyph
> can be done perhaps with a fontification package.
>
> in any case, fontification can merely say that + looks
> like 😺 or so.  orthogonal to levels.
>
>

Sorry, but I think this idea is misguided. 

The 'bullets' in lists are largely irrelevant to org. Lists are
determined by the indentation level. I don't think org actually cares
about wither an item starts with '-', '+', or '*'. I also don't think it
matters (from an org perspective) if a list has a mix of different
bullets. This might be 'offensive' for users, but is largely irrelevant
for org. 

This means the questions now becomes "Do we add the additional complexity
and possible performance hit to enforce bullet consistency?" and "Are
there any use cases where people might want different bullets at the
same level in a list?". 

As having mixed bullets does not impact on org export, I'm inclined to
leave this as a user issue i.e. if you want things to be consistent,
then be consistent. The current behaviour I think is pretty good i.e. if
you start using a different bullet, new items at the same level will use
that bullet and when you shift an item to be at the parent level, it
will change the bullet to be the same as the parents. If you indent an
item, it will use the same bullet as the parent, but you can change it
and then all additional items at that level will use the same bullet. 

As the bullet type has no baring on org's processing of lists, I think
this is a purely presentation issue and therefore anything we want to do
wrt enforcement should in fact occur at the font-lock layer. e.g. allow
code which will just set the bullet to some preferred mapping based on
level. As the user won't see which 'real' character is being used, it
won't matter if it uses mixed bullet styles. This also has the advantage
that the user can just use the one bullet 'type' and see different
bullet rendering based on level, so you won't have any 'inconsistency'
anyway as all entries just use the same bullet. 






reply via email to

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