This is an interesting idea, though I'd be worried that it could complicate the editing process compared to mixed content and markup. In particular, the examples of selectors in Aftertext rely on the words that are being marked up. This means that if a word or name is going to be changed, then you would have to edit two places in order to make the change correctly rather than just one.
Neat idea, though as I was playing around with it I noticed right away that the following seems to be impossible (or else very non-obvious) via Aftertext:
"How much wood could a woodchuck chuck if a woodchuck could chuck wood?"
I tried
How much wood could a woodchuck chuck if a woodchuck could chuck wood?
italics wood
italics wood
which only seemed to italicize the first "wood", and
How much wood could a woodchuck chuck if a woodchuck could chuck wood?
italics wood wood
which obviously failed because it can't find the substring "wood wood". And of course neither of these would match the "wood" in either of the "woodchuck" instances, so no italicization there, either.
That looks very inflexible for later edits, marking characters or words means a potentially cumbersome recounting if something is reworded or just if a typo is fixed.
Also, I get the second and subsequent number issue are the three locations to highlight, but what instruction does the first, -6:-3, give to the formatter in your example?
Not a big fan of byte/rune counting. Maybe regex. Maybe more verbosity, like:
aftertext
How much wood could a woodchuck chuck if a woodchuck could chuck wood?
context How much wood
italics wood
context could a woodchuck
italics wood
context a woodchuck could
italics wood
context chuck wood
italics wood
The current implementation just matches the first match, as that was the simplest and most common occurrence. But I have indeed hit this footgun (though it in my case involving my Aunt and a cat), so think will extend soon, probably with an "index" or "matchAll" parameter.
This is really cool. A bit verbose for my taste, but OTOH it could be easier to remember than markdown or html. For example, I often forget the syntax for links in markdown - do the square brackets and parentheses come around the text and link respectively, or is it vice versa?
Here's an interesting benefit this has over inline markup languages: it's natively compatible with text-based CRDTs. Normally, collaborative rich text editing is a strictly harder problem than plain text editing [0]. This is because there is extra structure (e.g., if someone puts a beginning "*" bold in the middle of a sentence, and that sentence is deleted by someone else, then you might end up with an unterminated bold sequence).
But if you swap out inline syntax for per-line syntax, then it seems like plain text CRDT should be enough for collaborative Aftertext editing. Pretty cool
This will be lovely for parallel text: annotating each word with its translation AND retaining the original as well as the annotations in readable form.
Even overlapping ranges can be annotated conveniently.
The thing I like about markdown and similar syntax's are the simplicity and succinctness. When you take the markup out of context, well you lose context.
My issue with this would be it's verboseness and the extra time it would take to write and understand. I have to read the sentence, then read the first markup and work out which part of the previous sentence it applies to, potentially rereading/scanning the sentence again. This is repeated for each markup.
I don't have enough experience with it yet to say. Also, I think improved productivity will be a function of the utility of the markup directives. For example, I just added a new one today ("dateline"), that solves a minor pain point for me. It feels promising, but will have to check back in in 6 months.
I like this a lot, and I think it's an important contribution!
I think it's a major advantage that the formatting description is provided using words rather than combinations of symbols. Symbols need to be learned, aren't always intuitive (like the markdown link example), and there are only so many combinations of them. Instructions in words can be far more flexible.
I think this a great v1.0, and I look forward to v2.0 and beyond. (I expect that now that this idea has been shared, several people will create spin offs, which is a good thing.)
Some ideas (most of which are no doubt bad but might generate other ideas):
Aftertext to Markdown would be useful and help take advantage of the existing Markdown tool ecosystem.
I wonder if it would be useful to introduce ONE or a very limited set of symbols? For example, perhaps a symbol like ">" or "#" at the beginning of a line to indicate that the following content is formatting instructions for the previous line. But maybe this takes the idea backward.
I wonder if some kinds of formatting could be indicated before rather than after the content, in a way that would be more readable? For example: "heading:". Maybe this is where a symbol or two could be used to differentiate between whether formatting applies to the preceding or following content, or perhaps a colon (:) at the end of the formatting instruction indicates that.
Maybe this could co-exist as an alternative, more expressive syntax within Markdown? For example, for less intuitive constructs like link(this)[that], Aftertext would provide a more intuitive and readable interface even for someone who didn't know Markdown. Maybe Aftertext style isn't needed for things like bold, underline, and italics, because using * or _ or / may be intuitive enough (although Aftertext would be available if it isn't).
Aftertext could also give higher level directives, such as to create links for ALL instances of a particular phrase, or to format the document in a particular way or prefer a type of font if available.
Aftertext could be used to introduce and set the meaning of special symbols that could then be used more conveniently in the document. For example: "*phrase* means bold".
Could Aftertext be made inline with a small number of symbols and result in a net reduction of symbols and greater explicitness and intuitiveness? For example, could an unusual pairing of characters like (! or (: begin an inline Aftertext instruction? Example: (!link to ...). Certain complex Markdown instructions could be removed that way, or alternatives provided, or additional configuration enabled. This could also be configured with: "(!phrase) means inline instructions".
> Could Aftertext be made inline with a small number of symbols and result in a net reduction of symbols and greater explicitness and intuitiveness? For example, could an unusual pairing of characters like (! or (: begin an inline Aftertext instruction? Example: (!link to ...).
I think at that point, you start moving a bit toward Pollen, a Lisp-like fully programmable markup system that's sort of a spiritual relative of troff or TeX aimed specifically at generating HTML. You could absolutely recreate an inline version of aftertext with it.
aftertext
You write some text. After your text, you add your markup instructions with selectors to select the text to markup, one command per line.
italics After your text
italics selectors
Would, in an "aftertext-like Pollen", look like
You write some text. ◊italics{After your text}, you add your markup instructions with ◊italics{selectors} to select the text to markup, one command per line.
While I find Pollen rather fiddly in practice, it's very powerful.
