Consistent inline formatting with curly braces only

[rmnldwg]

First off, thanks for starting this project! It sounds super useful and promising to me.

While diving through this repo, the docs and the discussions, I had a thought: Since the syntax using openers and closers (e.g. {_text_} instead of _text_) resolves ambiguity and allows using many other punctuation characters for formatting (like discussed in #10), why not allow only that syntax? Wouldn't it be super clean and consistent to do all inline formatting using curly braces?

If I had to come up with a syntax, ignoring what I am used to from Markdown, it could be something like this: {/emphasis/}, {*strong*}, {_underlined_}, {-deleted-}, {+inserted+}, {$ maths $}, {`code`}, {^superscript^}, {~subscript~}, {=highlighted=}, {,small caps,}, ...

Would that be too obtrusive to read, compared to using the shorthand emphasis characters? If I look at the example below and squint a little, the {} are quite ignorable:

Here is a test paragraph with some {/emphasis/}. I am not sure,
but I think this is {*not too bad*}. Is it still readable
without too much {_distraction_}?

Another advantage is that at some point code editors could auto-close any {char opener with the appropriate char} closer.

Regarding maths, I think it may even be more intuitive and practical: With $`E=mc^2` the backticks indicate verbatim content, in contrast to {$ E=mc^2 $} where the syntax even allows to simply copy and paste equations from LaTeX and surround them with curly braces.

I'm curious to hear your thoughts on this. In any way, I'm a fan of djot already!

[jgm]

I've been tempted by this idea myself.

As for math, I think there'd still be an advantage to using verbatim backticks. The problem with {$..$} is that tex math can contain the string $}, e.g. in $x = \text{why not $y$}$ which is legal if odd. So we start to get ambiguities, which are completely eliminated if we reuse verbatim syntax.

[rmnldwg]

Oh, I see! Thanks for clarifying 👍

[waldyrious]

For prior art, Textile¹ does this with [] (i.e. it supports [**foobar**] in addition to **foobar**, and similarly for other markup), although it doesn't require it.

Footnotes

1. I realize I may sound like a Textile fanboy as I've mentioned it in several of my comments here, but I did go through various lightweight markup languages looking for this feature, and except for those that use HTML-like tag names (e.g. XMLite, SexpCode, PML, etc.), Textile was indeed the only one that seems to support this kind of delimited markup. ↩

[gavinhoward]

This is probably true. Can you tell me what languages use braces more?

[waldyrious]

To be clear, I wasn't advocating for brackets instead of braces :) I just wanted to give an example of a LML with broad support for such delimiters.

That said, I do think it would be nice if Djot consistently used brackets to wrap visible content (like the label of links, emphasised text, etc.), and braces to implicit content like classes and other attributes (or, dare I say, the URL of links 😁). Or the other way around; I don't have a preference as I said above.

[vassudanagunta]

I don't know. I'm just saying if we want a markup to not be English-centric, you can't make statements like that without analysis. There is wide variation in how different languages do things, e.g. quotations: « Le singe est sur la branche ! » vs „Der Affe ist auf dem Ast!‟ vs 「樹枝上的猴子！」. Chinese also uses 《》〈〉 for titles and quotations, though they are full width so distinguishable from <> (I don't know if Chinese writers use the latter for convenience). Also 「...」 is also used in Chinese for emphasis so no additional markup is needed.

It's very easy to neglect this since English dominates even the discussion of the design of plain text formats.

I wonder if formats like Markdown are de facto English or at least European-language oriented and if there simply should be other markup languages for other language families.

[bpj]

@vassudanagunta I’m not sure if I’m with you here. In Chinese you simply don’t need emphasis in the Western sense because punctuation already takes care of it but in mixed-language texts it comes back in if you have quotations in Western scripts. I'm all with you WRT international quote marks: smart quotes should be configurable!

As for the original proposal I tend to be in favor of it since it removes most ambiguity. Not least intra-word underscores and such things as my old discipline’s use of literal asterisks before/after words, which i never remember to escape the first time around, would become non-problematic and uniformity would increase.

I agree that curlies probably are better for balanced delimiters than square brackets but I think that ideally brackets for delimiters, spans, links, attributes etc. and at least smart quotes — in Pandoc we who use Western languages other than English use filters to localize quotes! — should be configurable. Smart quotes are probably best configured in metadata on a per-document basis while delimiters for the parser probably should be configured in a table of directives passed to the parser by the host program. The only requirement should be that there should be a delimiter pair for each kind, and that each delimiter is unique. People will be punished by themselves if they choose too weird delimiters.

One thing that worries me about djot is that both balanced delimiters and attributes use curlies, since that prevents using . # % for balanced delimiters! :-) Part of me wishes that any (at least any non-paired) punctuation characters could be used as balanced delimiters and stored in the AST in such a way that renderers could do whatever they please with them.

In my homegrown LML which I used to generate LaTeX before I discovered Pandoc I actually used {*textbf*} {_textit_} {/emph/} etc. with always required curlies, and later I wrote a “preprocessor” which replaced/wrapped chunks of text inside possibly nested delimiters (using perl >= 5.10.1 regexes¹) with/in arbitrary markup/texts, taking configuration from a YAML file. In short it faked Pandoc’s span and div syntax and then some before Pandoc supported it, including the possibility to interpolate argument values and other predefined data in the replacement text with String::Formatter. I still sometimes find this tool easier to use than a ton of bespoke Pandoc filters.

Footnotes

1. Not the world’s most efficient regexes in that they use things like (?s:(?!$open|$close).)+ but I never use this tool in anything time critical! ↩

[vassudanagunta]

I’m not sure if I’m with you here.

I think you're 100% with me. My point wasn't that {} shouldn't be used, but

if we want a markup to not be English-centric, you can't make statements like ["brackets are more likely to be used in actual text"] without analysis.

You followed up with some analysis, even if you didn't show that using {} for markup won't collide with its use as natural punctuation in other languages. I have a feeling that braces are safe to use, but that's a feeling, anecdotal, not data. The rest of my comment was only providing examples of how an English-centric view can result in markup design that won't work for many other languages.

As to your thoughts about configurability, I'd measure their alignment with djot's goals.

[itraveller1]

The idea is very tempting, but unfortunately ergonomics and unambiguity are at different poles of syntax. Rejection of natural markers will move Djot towards a declarative syntax, where everything is unambiguous, but not very convenient.

A healthy balance is probably needed when the necessary minimum of markers is maintained, which expresses the most requested part of the handwriting syntax. These markers, of course, must be duplicated in a declarative style, like the rest of the functionality. I think @jgm did a very good job of that.