Show HN: Aftertext

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.

Nice concept. I wrote a 10 line Javascript to convert HTML to aftertext for no reason.

https://jsfiddle.net/crazyontap/hcL1j2mq/

It's actually extremely old school. ROFF is similar to this

You can just make it .p, .i, .b, etc. .br for line break.

https://www.systutorials.com/docs/linux/man/7-groff_man/

Interesting lang.

    aftertext
      It's the difference between helping your Uncle Jack off a horse and helping your uncle jack off a horse.
     italics off
     italics off

Yields (in your playground)

> It's the difference between helping your Uncle Jack off a horse and helping your uncle jack off a horse.

So it appears I’d have to chain multiple aftertext blocks to highlight both “off”s.

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

[0] https://www.inkandswitch.com/peritext/

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.

Thank you for this idea!

> but with Aftertext the bytes increase linearly with N, the size of the span you are marking up

Maybe allow regexes for the span?

Could be good for dictating markup to by voice to an ASR interface like a smart-speaker.

Seems verbose having to repeat everything so often. Given how often I alias stuff after only a few repeats, I can see this becoming annoying quick.

Still always cool to see something new(ish) out there.

Interesting. Seems like there is some overlap with reStructuredText.

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.

Very cool, I'm curious have you noticed any productivity improvements after using this to write?

> problem [..] when markup is semantic and not just an augmentation. "*I* did not say that" is different from "I did not say *that*".

I consider this a feature. Domain-specific markup goes e.g.:

  aftertext
    *I* did not say that.
    italics *I*

How do you distinguish between *text that looks like this* and _text that looks like this_?

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".