Orgmode plain list bullet : change automatically with list depth

Orgmode plain list bullet : change automatically with list depth

[DEBRY.Edouard]

When making a plain list in orgmode, I would like to change of bullet
autmatically depending on the list depth.

Currently, I use this to prettify bullets :

(font-lock-add-keywords 'org-mode
                        '(("^ *\\([-]\\) "
                           (0 (prog1
                                  ()
                                (setq bullet "•")
                                (compose-region (match-beginning 1) (match-end 1) bullet))))))

I attempted to this :
(font-lock-add-keywords 'org-mode
                         '(("^ *\\([-]\\) "
                            (0 (let* ((depth (org-list--depth (org-element-at-point)))
                                      (bullet (cond ((= depth 1) "•")
                                                    ((= depth 2) "▸")
                                                    (t "-"))))
                                 (prog1 () (compose-region (match-beginning 1) (match-end 1) bullet)))))))

for the bullet to change with respect to the org list depth, so to have
(e.g.) :
• test
  ▸ test1
  ▸ test2

But it breaks the org file.

How could I achieve this ?

Regards

___________________________________________________________________________________________________________________________________

This email and any attachments are confidential to the intended recipient and may also be privileged.
If you are not the intended recipient please delete it from your system and notify the sender. 
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
 

Ce courriel et ses pieces-jointes sont envoyes de maniere confidentielle et doivent etre traites avec attention.
Si vous n'etes pas le destinataire, merci de le detruire et d'en informer son auteur. 
Vous ne devez pas copier, utiliser, reveler ou diffuser son contenu a quiconque.

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

[Ihor Radchenko]

DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:

> But it breaks the org file.

What do you mean by "breaks the org file"?

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

[DEBRY.Edouard]

I mean that all custom set faces disappear, just try, if it works for
you i am interested

Ihor Radchenko <yantar92@gmail.com> writes:

> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Attention, ce courriel provient d'Internet. L'emetteur n'est peut-etre pas celui que vous pensez. 
> Merci de considerer ce point en lisant ce courriel, avant d'y repondre, de cliquer sur
> les liens ou d'ouvrir les pieces jointes.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:
>
>> But it breaks the org file.
>
> What do you mean by "breaks the org file"?
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

___________________________________________________________________________________________________________________________________

This email and any attachments are confidential to the intended recipient and may also be privileged.
If you are not the intended recipient please delete it from your system and notify the sender. 
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
 

Ce courriel et ses pieces-jointes sont envoyes de maniere confidentielle et doivent etre traites avec attention.
Si vous n'etes pas le destinataire, merci de le detruire et d'en informer son auteur. 
Vous ne devez pas copier, utiliser, reveler ou diffuser son contenu a quiconque.

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

[Ihor Radchenko]

DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:

> I mean that all custom set faces disappear, just try, if it works for
> you i am interested

I see. FYI, you can try to run M-x font-lock-debug-fontify to identify
the problem.

The issue you are seeing is because org-element-at-point alters match
data and thus your (match-beginning 1) are not returning what you expect
(they return nil).

Best,
Ihor

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

[Samuel Wales]

i wonder if org could do the semantics in the text, while
fontification could do the appearance only.

org allows you to change the bullet style [real text bullets rather
than fontification] upon demotion.

thus, you can have it consistent that demoting + from top level will
create - on level 2 for 1 item.  until you change it.

but org does not enforce by level.  so you can't keep the results of
your demotion strategy in the rest of the list.  an enforced scheme
would have it so that a change to new bullet style at a level, or
level 1 otherwise, would style that level.

so perhaps via a hook, lists could enforce bullet style by level
instead of by demotion.

then fontification would change bullet style according to the real
bullet style.  same result for op.  just a brainstorm.


On 6/14/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:
>
>> But it breaks the org file.
>
> What do you mean by "breaks the org file"?
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

[Samuel Wales]

grr i meant "item 1" not "level 1".

On 6/16/22, Samuel Wales <samologist@gmail.com> wrote:
> i wonder if org could do the semantics in the text, while
> fontification could do the appearance only.
>
> org allows you to change the bullet style [real text bullets rather
> than fontification] upon demotion.
>
> thus, you can have it consistent that demoting + from top level will
> create - on level 2 for 1 item.  until you change it.
>
> but org does not enforce by level.  so you can't keep the results of
> your demotion strategy in the rest of the list.  an enforced scheme
> would have it so that a change to new bullet style at a level, or
> level 1 otherwise, would style that level.
>
> so perhaps via a hook, lists could enforce bullet style by level
> instead of by demotion.
>
> then fontification would change bullet style according to the real
> bullet style.  same result for op.  just a brainstorm.
>
>
> On 6/14/22, Ihor Radchenko <yantar92@gmail.com> wrote:
>> DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:
>>
>>> But it breaks the org file.
>>
>> What do you mean by "breaks the org file"?
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> i wonder if org could do the semantics in the text, while
> fontification could do the appearance only.
>
> org allows you to change the bullet style [real text bullets rather
> than fontification] upon demotion.
>
> thus, you can have it consistent that demoting + from top level will
> create - on level 2 for 1 item.  until you change it.
>
> but org does not enforce by level.  so you can't keep the results of
> your demotion strategy in the rest of the list.  an enforced scheme
> would have it so that a change to new bullet style at a level, or
> level 1 otherwise, would style that level.

Could you please provide an example. I do not understand what you are
trying to suggest.

Best,
Ihor

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

[Samuel Wales]

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.


On 6/17/22, Ihor Radchenko <yantar92@gmail.com> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> i wonder if org could do the semantics in the text, while
>> fontification could do the appearance only.
>>
>> org allows you to change the bullet style [real text bullets rather
>> than fontification] upon demotion.
>>
>> thus, you can have it consistent that demoting + from top level will
>> create - on level 2 for 1 item.  until you change it.
>>
>> but org does not enforce by level.  so you can't keep the results of
>> your demotion strategy in the rest of the list.  an enforced scheme
>> would have it so that a change to new bullet style at a level, or
>> level 1 otherwise, would style that level.
>
> Could you please provide an example. I do not understand what you are
> trying to suggest.
>
> Best,
> Ihor
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

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

[Tim Cross]

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. 

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

[Edouard Debry]

Are you sure bullet lists are irrelevant to org ?

I tried without success to make a list without "-" or "+" in my
*scratch*.

Regards

Tim Cross <theophilusx@gmail.com> writes:

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

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

[Edouard Debry]

What I am looking forward to is
1) not modifying the true "bullet" in the raw text, it will always be
"-" I just want the appearance to look "nicer"
2) having a bullet appearance level depth specific, e.g.
▪ this is first level of a list
▪ still first level
  ➤ this is the second level
  ➤ this is again the second level
    • a third level
  ➤ yet another second level

which means that de facto a specific bullet appearance would be
associated to a specifc list level depth, e.g. • is 3, ▪ is 1 (I assume
index begins at 1 ?)

Built like this, putting this list into the first level of another one
would shift all levels depth by +1 and consequently change the
appearance.

Currently, appearance is changed by :

(font-lock-add-keywords 'org-mode
                        '(("^ *\\([-]\\) "
                           (0 (prog1
                                  ()
                                (setq bullet "•")
                                (compose-region (match-beginning 1) (match-end 1) bullet))))))

The key point is the regexp. I do not know if it is possible to capture
the depth level with a regexp. That is why I tried to use
org-list--depth in :

(font-lock-add-keywords 'org-mode
                         '(("^ *\\([-]\\) "
                            (0 (let* ((depth (org-list--depth (org-element-at-point)))
                                      (bullet (cond ((= depth 1) "•")
                                                    ((= depth 2) "▸")
                                                    (t "-"))))
                                 (prog1 () (compose-region (match-beginning 1) (match-end 1) bullet)))))))

but it seems that "org-element-at-point" messes things.





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.
>
> On 6/17/22, Ihor Radchenko <yantar92@gmail.com> wrote:
>> Samuel Wales <samologist@gmail.com> writes:
>>
>>> i wonder if org could do the semantics in the text, while
>>> fontification could do the appearance only.
>>>
>>> org allows you to change the bullet style [real text bullets rather
>>> than fontification] upon demotion.
>>>
>>> thus, you can have it consistent that demoting + from top level will
>>> create - on level 2 for 1 item.  until you change it.
>>>
>>> but org does not enforce by level.  so you can't keep the results of
>>> your demotion strategy in the rest of the list.  an enforced scheme
>>> would have it so that a change to new bullet style at a level, or
>>> level 1 otherwise, would style that level.
>>
>> Could you please provide an example. I do not understand what you are
>> trying to suggest.
>>
>> Best,
>> Ihor
>>

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

[Ihor Radchenko]

Edouard Debry <edouard.debry@gmail.com> writes:

> The key point is the regexp. I do not know if it is possible to capture
> the depth level with a regexp. That is why I tried to use
> org-list--depth in :
>
> ...
> but it seems that "org-element-at-point" messes things.

Sorry, I though that I gave you enough information to fix the issue.

Just wrap (org-element-at-point) into save-match-data:
(save-match-data (org-element-at-point))

That's it.

P.S. I actually plan to fix `org-element-at-point' modifying match data
(which is not documented), but it will probably be a part of a bigger
font-lock-related patchset.

Best,
Ihor

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

[Edouard Debry]

Thanks for your information complement. Indeed, I know too few about
emacs to guess that by myself.

And it works !

For anyone interested, here are the settings :

(font-lock-add-keywords 'org-mode
                        '(("^ *\\([-]\\) "
                           (0 (let* ((depth (org-list--depth (save-match-data (org-element-at-point))))
                                     (bullet (cond ((= depth 1) "●")
                                                   ((= depth 2) "◆")
                                                   ((= depth 3) "▪")
                                                   ((= depth 4) "▸")
                                                   ((= depth 5) "•")
                                                   ((= depth 6) "↪")
                                                   (t "↪"))))
                                (prog1 () (compose-region (match-beginning 1) (match-end 1) bullet)))))))

Many thanks for your help.

Regards

Ihor Radchenko <yantar92@gmail.com> writes:

> Edouard Debry <edouard.debry@gmail.com> writes:
>
>> The key point is the regexp. I do not know if it is possible to capture
>> the depth level with a regexp. That is why I tried to use
>> org-list--depth in :
>>
>> ...
>> but it seems that "org-element-at-point" messes things.
>
> Sorry, I though that I gave you enough information to fix the issue.
>
> Just wrap (org-element-at-point) into save-match-data:
> (save-match-data (org-element-at-point))
>
> That's it.
>
> P.S. I actually plan to fix `org-element-at-point' modifying match data
> (which is not documented), but it will probably be a part of a bigger
> font-lock-related patchset.
>
> Best,
> Ihor

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

[Tim Cross]

Edouard Debry <edouard.debry@gmail.com> writes:

> Are you sure bullet lists are irrelevant to org ?
>
> I tried without success to make a list without "-" or "+" in my
> *scratch*.
>

Sorry, I wasn't clear enough. The 'marker' which is at the start of a
list item is important to org. What isn't important is the type of list
marker i.e. '-', '+', and '*' are all the same token which designate the
start of a list item when the first character of an indented line. There
is no relationship to item nesting depth. 

The point I was trying to make is that the token when used to convey
other meanings, like nesting depth, sits at the 'human' layer and
therefore, should be 'tweaked' using font-lock i.e. if you want
different tokens to mark different list nesting levels, use font-lock to
adjust the appearance of the token at each level rather than changing
underlying syntax to give '-', '+' and '*' additional meanings they
don't have at the code layer now. This also has the advantage of not
imposing a specific use for different tokens on all users i.e. some
users might want to use all 3 tokens in a list, but not simply to
reflect nesting levels. The disadvantage of using font-lock is that
currently, defining the regular expression can be hard. However, I think
other work being done to allow font-lock to leverage off information
supplied by the parser might simplify that situation. 

So to be clear, I was not saying that the ability to have different
characters to represent different nesting depth in lists was misguided,
only implementing that as part of the syntax and having org enforce it
with actual characters in the file was. Remapping to a different
character for display purposes based on the depth of the list item is
perfectly fine and in-line with similar techniques to do things like
replacing multiple '*' in headers with different single unicode
characters (like the various 'bullets' packages do). 

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

[DEBRY.Edouard]

The only trouble with this is that if I have a list with both numbers
and bullets :
1. first
   - ssdsd
     - mmdffff
2. second

if I perform Alt-leftarrow on mmdffff, this element is shift on the left
but then the whole list is turned into :
- first
   - ssdsd
   - mmdffff
- second

Is there a way to avoid that ?

Regards

Edouard Debry <edouard.debry@gmail.com> writes:
>
> Thanks for your information complement. Indeed, I know too few about
> emacs to guess that by myself.
>
> And it works !
>
> For anyone interested, here are the settings :
>
> (font-lock-add-keywords 'org-mode
>                         '(("^ *\\([-]\\) "
>                            (0 (let* ((depth (org-list--depth (save-match-data (org-element-at-point))))
>                                      (bullet (cond ((= depth 1) "●")
>                                                    ((= depth 2) "◆")
>                                                    ((= depth 3) "▪")
>                                                    ((= depth 4) "▸")
>                                                    ((= depth 5) "•")
>                                                    ((= depth 6) "↪")
>                                                    (t "↪"))))
>                                 (prog1 () (compose-region (match-beginning 1) (match-end 1) bullet)))))))
>
> Many thanks for your help.
>
> Regards
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Edouard Debry <edouard.debry@gmail.com> writes:
>>
>>> The key point is the regexp. I do not know if it is possible to capture
>>> the depth level with a regexp. That is why I tried to use
>>> org-list--depth in :
>>>
>>> ...
>>> but it seems that "org-element-at-point" messes things.
>>
>> Sorry, I though that I gave you enough information to fix the issue.
>>
>> Just wrap (org-element-at-point) into save-match-data:
>> (save-match-data (org-element-at-point))
>>
>> That's it.
>>
>> P.S. I actually plan to fix `org-element-at-point' modifying match data
>> (which is not documented), but it will probably be a part of a bigger
>> font-lock-related patchset.
>>
>> Best,
>> Ihor
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

___________________________________________________________________________________________________________________________________

This email and any attachments are confidential to the intended recipient and may also be privileged.
If you are not the intended recipient please delete it from your system and notify the sender. 
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
 

Ce courriel et ses pieces-jointes sont envoyes de maniere confidentielle et doivent etre traites avec attention.
Si vous n'etes pas le destinataire, merci de le detruire et d'en informer son auteur. 
Vous ne devez pas copier, utiliser, reveler ou diffuser son contenu a quiconque.

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

[Ihor Radchenko]

DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:

> if I perform Alt-leftarrow on mmdffff, this element is shift on the left
> but then the whole list is turned into :
> - first
>    - ssdsd
>    - mmdffff
> - second
>
> Is there a way to avoid that ?

I am unable to reproduce on the latest main and bugfix.

Best,
Ihor

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

[DEBRY.Edouard]

Finally, it has nothing to do with my own settings.

It happens with this :
- zeze
- ghrghrgh
- lqlqsqs

1. sdsdsd
   - sdsd
   - mcpscls

because there is only one line between both lists and (I did not know
it) orgmode thinks they are the same, then any depth change in second
list changes the 1. into a bullet. Putting two lines between both lists
makes them independent.

Regards

Ihor Radchenko <yantar92@gmail.com> writes:

> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Attention, ce courriel provient d'Internet. L'emetteur n'est peut-etre pas celui que vous pensez. 
> Merci de considerer ce point en lisant ce courriel, avant d'y repondre, de cliquer sur
> les liens ou d'ouvrir les pieces jointes.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> DEBRY.Edouard <edouard.debry@mbda-systems.com> writes:
>
>> if I perform Alt-leftarrow on mmdffff, this element is shift on the left
>> but then the whole list is turned into :
>> - first
>>    - ssdsd
>>    - mmdffff
>> - second
>>
>> Is there a way to avoid that ?
>
> I am unable to reproduce on the latest main and bugfix.
>
> Best,
> Ihor
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

___________________________________________________________________________________________________________________________________

This email and any attachments are confidential to the intended recipient and may also be privileged.
If you are not the intended recipient please delete it from your system and notify the sender. 
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
 

Ce courriel et ses pieces-jointes sont envoyes de maniere confidentielle et doivent etre traites avec attention.
Si vous n'etes pas le destinataire, merci de le detruire et d'en informer son auteur. 
Vous ne devez pas copier, utiliser, reveler ou diffuser son contenu a quiconque.