Proposal: Relax the strong and other inline rules

[criloz]

Current behavior

The current strong rule *..* only works if there is no white space after the first * and before the last *, there are other rules similar to this, also it requires both, one starting * and one ending * to be effective

• *sds * not strong
• *sds not strong

Problem

this creates a weird typing behavior in djot editors (I am currently working in one) so the user do this typing sequence

1. *hello*
2. *hello *
3. *hello world*
4. *hello world *
5. *hello world ...*

As you can see, every time that the user type a space the whole span get marked as not strong until the user start typing other word and the cycle start again, giving a weird intermittent and not continuous user experience

Proposals

1. allow whitespace before the last *, do the same for other similar rules

Why not whitespace after the first *? Because it will create an ambiguity with bullet list. Another option is to allow whitespace after the first *, but in case of ambiguity with bullet list give priority to the bullet list.

2. [optionally] just considered anything that follows an asterisk without space a strong structure, that is close when * match, this repeated in other similar inline structures.

You can see this behavior in the obsidian editor that use Markdown, something like **sdasd will be marked as strong even if there is not a final matching **.

The second proposal is marked as optional because there is no need to be in the spec for a theoretical djot editor to have this behavior, and they can post-process the file and produce a valid djot output anyway.

[Omikhleia]

Allow whitespace before the last *,

But then, regarding: Triconsonantal roots *ZBD or *ZBN are different...

Is it showing any strong content, is is this just two star-prefixed words (as often seen e.g. for reconstructions in linguistics)?

[vassudanagunta]

this creates a weird typing behavior in djot editors

This is an editor UX problem, not a syntax design problem.

[criloz]

@vassudanagunta not always, some editors use the parser to decorate subregion of the text and assign some classes, like codemirror, basically if you want to build an editor with djot this rule will by default create this intermittent behavior, the only option will be implementing a new djot parser with those relaxed rules and do the fixes in a post-processing step to produce a valid djot document, but it means that the official implementation or the official grammar could not be used by default. not a fundamental problem but is something that could be considered

[vassudanagunta]

@criloz, respectfully, that doesn't change my point. Even more so for a plain text syntax. Whatever the desired editor UX, it should and can be solved without changing the syntax.

[criloz]

@Omikhleia your example will render like

Triconsonantal roots <strong>ZBD or </strong> ZBN are different...

[criloz]

@vassudanagunta I understand your concerns, those are just suggestion, they are open discussion and I think should not be discarded so quickly, it allows anyone to just use the default djot parser without need to write a new one to implement an editor that does not feel hacky, it can potentially increase the speed of adoption of djot, also by my experience, more relaxed rules create also simple parsers.