From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Orgmode plain list bullet : change automatically with list depth
Date: Sat, 18 Jun 2022 10:17:40 +1000 [thread overview]
Message-ID: <87iloyree8.fsf@gmail.com> (raw)
In-Reply-To: <CAJcAo8u670vkkMFhZgPej=9cMkXD4xiFLgBioCSk2q6qk0+QeQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-06-18 0:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 15:03 Orgmode plain list bullet : change automatically with list depth DEBRY.Edouard
2022-06-15 4:31 ` Ihor Radchenko
2022-06-16 9:14 ` DEBRY.Edouard
2022-06-16 9:59 ` Ihor Radchenko
2022-06-16 23:26 ` Samuel Wales
2022-06-16 23:27 ` Samuel Wales
2022-06-17 11:54 ` Ihor Radchenko
2022-06-17 23:27 ` Samuel Wales
2022-06-18 0:17 ` Tim Cross [this message]
2022-06-19 13:40 ` Edouard Debry
2022-06-19 22:50 ` Tim Cross
2022-06-19 13:55 ` Edouard Debry
2022-06-19 14:03 ` Ihor Radchenko
2022-06-19 14:49 ` Edouard Debry
2022-06-24 14:28 ` DEBRY.Edouard
2022-06-25 3:27 ` Ihor Radchenko
2022-06-29 12:42 ` DEBRY.Edouard
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=87iloyree8.fsf@gmail.com \
--to=theophilusx@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).