Philipp Haselwarter writes:
> Is there any particular reason for it to be hardcoded? Apart from the
> fact that /well it just is this way right now/ I mean.
I don't know the truth here, but I'd guess it is about keeping Org
structure in ASCII. Org is about simplicity and portability (and about
depth and flexibility, but those come after in the motto). Having to
type unicode symbols for such a basic task as creating an headline may
be considered as a failure from this point of view. I'm not even talking
about using some other ASCII character, as it would bring
incompatibilities with existing structures, like lists or comments.
In the same vein, I had thought about offering the user to choose list
bullets among unicode symbols ("-", "+" are not very convenient if
you write mathematics in the item). But I changed my mind:
- creating an item would require the user to type the unicode symbol,
which may not always be easily accessible on a keyboard.
- adding subsequent items would imply, for the same reason, the use of
M-RET, making it difficult to modify the Org file from outside of
Even if you choose some accessible unicode symbol, it will still be one
order of magnitude harder to reach than "*".
> That'd be useful information for anyone interested in changing it. Then
> you can still just tell them to write a patch if they care that much
> ('cause even in org-mode-land patches don't write themselves just yet)
> [I just had the most awesome idea for a feature request].
> If it's "just" about inheriting from a variable in some 300 places it
> could at least be discussed.
I think some parts of Org code use `outline-regexp', some others use
`org-outline-regexp' and some parts have it hard-coded.
For the sake of consistency, It would certainly be a good idea to
generalize the use of `org-outline-regexp'. But considering that the
actual code for headlines is very stable, and that no one reported an
impossibility to accommodate to stars there, I guess such changes are at
a very low priority.
 I even considered adding unicode overlays on standard bullets in
order to help readability. But:
1. Too much overlays slow down Org drastically,
2. I don't like to have hidden information in my buffers,
3. Once again, I would stray away from simplicity.