Allow using multiple characters for each level.
dangom opened this issue · comments
Does org-superstar-mode support using multiple characters for heading stars?
I'm trying to mimick Bear's behavior, as seen below:
I tried changing the headline-bullets-alist but couldn't get it to do multiple characters. My skills with composition rules is also non-existent, and when I tried composing strings according to the rules of compose-region, as mentioned in the docstrings, all I manage to do is get two characters overlaid on top of each other.
Any advice would be welcome and thank you for sharing this lovely package!
Hi @dangom! Interesting, I remember having played with the thought before, but never went through with looking too deeply into it. I'll have to play a little with this myself before being able to give a thorough answer, but I remember there was a technical issue why I didn't implement it immediately. I'll keep you updated!
I was thinking in similar lines, wanting to have some more control over the display of bullets (specifically if it would be possible to add a face to the todo bullets). What I thought of then was to just use the display property instead of compose. Seemed to work (outdated and ugly testing branch here, but I'm confused why it worked without adding display to font-lock-extra-managed-props). But I suppose there is a good reason for using compose over display that I have missed (Maybe relating to indentation?).
Right, I forgot about the display property entirely, there was indeed something. The fact you found this discussion regarding Prettify Symbols mode is no coincidence. A lot of the structural decisions made both in Org Superstar and Org Bullets strongly relates to Prettify Symbols, in fact that is why the internals use the prettify/unprettify nomenclature. You can find a more elaborate explanation of the moving parts of Superstar here, where I outlined a recipe to create similar modes for different outline modes. I hope to see things like md-bullets spring from it someday.
Seemed to work (outdated and ugly testing branch here, but I'm confused why it worked without adding display to font-lock-extra-managed-props)
It also may be that display is already added to the properties Font Lock is bookkeeping by default, but that is mere conjecture.
I also find this comment particularly interesting, I believe this calls for another Issue until I had a talk with the Emacs mailing list.
UPDATE: I opened a new Issue for this, see below.
Good news! It may be the case that this feature may become possible in the future, when I migrate from compose to display!
I will, however, have to put in a decent amount of legwork first. See #25 for more details.