Edouard Debry <edouard.de...@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).
