Customizable Inlines
kalhauge opened this issue · 3 comments
Fantastic project! Here is a possible feature that would make it a game changer for me.
I would like to see support for inline references like citations @cite and @sec:introduction; that way it would be easier to use in
academic writing. But potentially is the problem much broader: every back end needs different syntax for different things.
A Keyword in a book could be {! Hydrostatic !}, a citation could be @Knuth1968, a reference to another section could be
!!introduction, math is $`x^2`, changes could be {- remove this -}, a tag references in knowledge bases are #my-interesting-topic, and hidden solutions to an exercise could be {!? the answer is 42 ?!}.
For example, there are different things wanted by people: #10 #13
So, what about making inlines completely customizable? By this I mean that parser will not try to impose an interpretation on the syntax simply note what's there, e.g., {*a*} is not parsed as bold a, but as *'ed a. This means that we can define new
wild operators, as long as they do not conflict with normal writing. I suggest the following characters to be part of the operator span: !?-+&*^%$#@|/=_~: and any combinations of these. So, !! is an operator, @# is an operator, and even @#!#$ is an operator. It's then up to the back end to interpret these suggestions. In html, {* bold *} could be bold,
{** strong **} could be strong, {_ em _} could be em, {__ italic __} could be italic, and so on.
I suggest that there are three ways to use the operators, which are already being used in djot today:
{!? a ?!}multi word, notice that the ending operator is reversed, just flair.!?asingle word, and!?`asd v`verbatim word.
Concerns:
- But what if I wanted to type
!!!word? You probably don't, but then we could use\as an escape\\!!!wordis just !!!word. - But what with syntax like
*bold*? I suggest that the special cased for*and_remain special cases for{* *}and{_ _}, this makes syntax like*aimpossible, but it should still allow for*`a`. - But what if I want to write {-- ? I suggest
{{to be escaping {, so you'll write{{--.
As I just commented in #13 I'm also thinking in terms of allowing doubled delimiters inside curly brackets. I think @jgm makes a good case for disallowing them without curly brackets, but I think a case can be made for using them with curly brackets. However I'm not sure I agree that any sequence of punctuation characters next to curly brackets should be an automatic custom delimiter. Also I'm not sure a proliferation of delimiters is a good idea if they just are a shorthand for spans with attributes.
I think its a question of standardization vs customization! A standard format will allow djot to be generally readable, as soon as you open a djot file you know what it does. A customizable format will allow djot to be generally applicable, meaning that in any setting that need writing we can use djot. The two goals are sadly at odds, but ultimately up to the values of the project.
My suggestion would be a customizable parser, but a standardized HTML back-end. Deciding on how the HTML is rendered will guide (but not limit) other renders as they (hopefully) would like to stay compatible.