[mhd]

The difference here is that we're not talking about describing data, like XML does (most of the time), where sexpr-based markup is pretty great. For actual markup, SGML wasn't all that bad (closing tags are useful if the start of the current section is a few screenfuls away), or the more "do what I mean" approach as commonly used by markdown, asciidoc, rst or org-mode. And while Emacs might be "in love" with lisp, it's also all about dwim.

(Never mind the texinfo legacy)

[616c]

But what are we describing then. I like to see org, HTML, asciidoc, and XML as taking any data, in a very moronic basic sense, and annotating it or reshaping it for different kinds of parsers to accept.

Am I missing the mark somehow in your comment?

[mhd]

Isn't that a bit ad absurdum? Sure, in a sense this comment, the works of Shakespeare, the contents of this web page and the last 24 hours of stock trading exported as CSV are all just data/information. Go one step further and you could say that we might as well abolish English and instead write the content itself in some sexpr-structured Lojban.

But we don't operate in pure data structures, AST's, etc, so there has to be some kind of abstraction. Sexpr are one approach, but even die-hard lisp-heads usually don't contend that it's the only one. The aforementioned scribble isn't sexpr-based, either. Most markup languages these days really try to avoid spurious line noise for something as simple as paragraphs.

The working elements of your average program are much more complicated and varied than those of your average marked up document, and quite often much easier to heuristically derive -- significant line-ends being one prime example. Quite rarely is there a need for deep hierarchies, for example.

HTML these days isn't just about formating content, so there's a much higher signal/noise ratio, where something like sexpr markup could improve upon spurious end tags, attributes etc. And this is even more true for most XML data.

So I'd see a use case for these kinds of complicated and generic scenarios. But for simple annotated content, outlines and the occasional date? Do you really want to write tables as nested s-expressions instead of just working automagically with a neat ascii-art representation?