1. 34
skuz.xyz
1.

2. 22

It’s unclear if there’s any advantage to using this.

I like the idea of metadata, but there are already markdown extensions for that.

Unordered lists are enclosed with [] and ordered lists are enclosed with {}.

That’s the exact reverse of common notation, where {} is a set and [] is an array.

But nice effort.

1. 4

This is my reaction as well.

I think it’s great that @skuzzmiglet could scratch their own itch and build this, but to be honest I’ve been SO INCREDIBLY grateful for the widespread support of Markdown as a near universal markup supported in more and more contexts and applications that I look at every new variant and unfairly think “NOoooOOOOOooo! Here we go again!”.

1. 1

I like the idea of metadata, but there are already markdown extensions for that.

MultiMarkdown’s is only at the start of the document and does weird auto-detecting, frontmatter adds a dependency (YAML and TOML are overkill, JSON is verbose) and Pandoc’s metadata is limited to dates, titles and manpage data.

That’s the exact reverse of common notation, where {} is a set and [] is an array.

Aren’t sets and arrays both order-preserving?

1. 11

Arrays are order-preserving, sets are not. A set is an unordered collection of unique elements. Many programming languages order their sets, but that’s either purely an implementation detail or an intentional deviation from the math definition.

1. 2

an intentional deviation from the math definition

It’s not a deviation, but an extension; ordered sets are still valid as sets, so long as they have a membership predicate. Math sets are not ordered simply because they don’t need to be.

1. 3

Math sets are not ordered simply because they don’t need to be.

1. 2

Ha, good point. If we don’t accept the axiom of choice then there may be unordered sets which cannot be represented in terms of an ordered data structure. (That being said, I think the existence of an ordered data structure kind of assumes well-ordering is possible, but.)

2. 1

It’s not a deviation, but an extension; ordered sets are still valid as sets, so long as they have a membership predicate.

Nope! Ordering violates the first axiom of set theory:

https://en.m.wikipedia.org/wiki/Axiom_of_extensionality

1. 1

It does not. That is a definition of equality based on membership, and you can still define it that way on ordered sets. (It’s fine to have another, separate equivalence relation which takes order into account.)

1. 1

Oh there’s a subtle miscommunication going on here. You’re assuming that “ordered set” means what it would mean in math: a set with a pre-defined ordering of its elements?

I was assuming that “ordered set” meant what it (might) mean in a programming context: a “set that remembers original insertion order.” https://code.activestate.com/recipes/576694/

The first definition is compatible with the axiom of extensionality. But the second definition violates it because the set {A, B} would be quite different than the set {B, A}.

1. 1

I was operating under the programming definition of ‘ordered’.

My point is that you can construct an equivalence relation for ordered sets that treats {A, B} as equivalent to {B, A}, without sacrificing the ability to construct other equivalence relations that would distinguish the two.

2. 1

Order is not a well-defined operation on sets.

1. 1

Sets are basically just predicates denoting membership. Bags add duplicates (which is what an unordered list is) and lists add a order on top of that.

3. 8

I like the metadata and table syntax, and I like the idea of a simpler-to-parse, indentation-insensitive Markdown alternative. But I don’t think I’d ever get used to [] for bulleted lists. The standard - format for lists is intuitive, and it’s the way I automatically type in text documents anyway, because most of my notes end up being deeply-nested bulleted lists.

Is it even possible to put multiple paragraphs under a single list item in typeup? From the looks of the spec, that can’t be done, which is a problem. Multiline list entries are a problem in most markup languages (Markdown implementations sometimes disagree on the level of indentation), so I was hoping that a less-finicky Markdown-like syntax would make this easier.

1. 6

Multiline list entries are a problem in most markup languages (Markdown implementations sometimes disagree on the level of indentation),

Have you heard the good word of CommonMark

(with apologies to @hwayne)

1. 3

Multiline list entries are a problem in most markup languages (Markdown implementations sometimes disagree on the level of indentation),

Have you heard the good word of reStructuredText

2. 6

As the once long-time maintainer of cmark-gfm (which powers many comment fields around the internet, Lobsters included) and contributor to the CommonMark spec, .. I really like this!

• Simplifying the rules for bold/italics is such a breath of fresh air. The alternative is mind-rending (scroll down to the numbered list of rules for defining emphasis and strong emphasis).
• Simple link syntax is very pleasant.
• It may be a bug that you can’t link an image:

$cat test.tup [![alt text https://placekitten.com/200/200] http://placekitten.com]$ typeup < test.tup
<p><a href="https://placekitten.com/200/200">![alt text</a> http://placekitten.com]</p>
$ • I don’t love pipes for quoting; it seems a bit arbitrary when use of > is widespread (e.g. in Markdown) because > was what we were already using in text emails. • The arbitrariness of [] for unordered and {} for ordered is a little awkward, as is the lack of proper/“full” nesting support. List parsing is one of the more awkward parts of CommonMark, but it also gives a real sense of deep expressiveness (like the code block I embedded in the list item above). This might be the one place that makes typeup feel like it lacks enough power for real-world use. • Table syntax is novel and workable, I like it. Nice work! 1. 2 Simplifying the rules for bold/italics is such a breath of fresh air. The alternative is mind-rending (scroll down to the numbered list of rules for defining emphasis and strong emphasis). I didn’t know it was this complex! It’s nice to be able to keep the spec in mind for sure. One thing I have basically ignored in the first version is escaping, so if your text contains _ or *, you’re out of luck for now. I don’t know whether forcing people to escape these will be good enough It may be a bug that you can’t link an image: This is because of a circular dependency. In the grammar, I implemented link/image parsing in a function to use from the grammar, which can’t use the grammar to do styled text (which no bolding/italic in images either). This is mostly because I needed a quick and dirty way to do it (Janet’s greedy PEGs are less intuitive than just string/splitting it). This shouldn’t be hard to fix but it’s made harder by the fact that you can’t pass a capture to a rule in Janet PEGs (you can pass it to another PEG but that can cause circular dependencies). I enjoyed writing the parser but a from-scratch parser would probably be more robust I don’t love pipes for quoting; it seems a bit arbitrary when use of > is widespread (e.g. in Markdown) because > was what we were already using in text emails. Yeah, pipe quotes don’t have much benefits apart from maybe looking more like rendered quotes. Probably best to change it back to > though The arbitrariness of [] for unordered and {} for ordered is a little awkward I largely chose these because [ looks like “list” and { looks like “different list” to me. The list syntax is pretty unintuitive but it reflects my habit of just writing lists as paragraphs (I hate my keyboard so I am incredibly impatient typing the least of characters) lack of proper/“full” nesting support I agree this needs work, as does escaping. Probably a special syntax for “interpret as a paragraph wherever it is”. Also, some things aren’t nestable like quotes, much work to be done there (trying to write a draft spec made me realize just how little I’d thought about it) 2. 5 I don’t really see why I want his vs the dozens of existing wiki languages. It even sharea the thing I like least about markdown (using # for headers) 1. 3 Funnily enough using # for headers is the biggest thing I miss when writing rST instead of markdown. 1. 3 The annoying thing (to me) about MD header syntax is that the lower-level headers are much more visible than the higher level ones, which is backwards. I’m not sure how to fix that, but it’s still annoying. (Textile’s “.h1” syntax just made no headers particularly visible, which wasn’t any better, really.) 1. 2 To me it’s that so many syntaxes use = for headings and # for ordered lists and Markdown breaks both of those at once with the weird header choice. 1. 1 Interesting. More # for lower-level headings is unintuitive to type, and increasing numbers of # reflect nesting better. I chose # for typeup because it’s the same for markdown, and as a character it can’t be improved much (I don’t mind borrowing from markdown) 2. 5 Markdown is so ubiquitous, I can’t see anything unseating it, no matter how objectively superior it might be. I like that I can use Markdown almost everywhere (and I get a little irritated when I try to use it, but it’s interpreted differently (Jira, Slack)). 1. 2 I have a dream that a good pandoc-like markdown parser will emerge that allows users to pick and choose their own syntax extensions, and that every Markdown input box on the web will adopt it as a standard, instead of say, the current de-facto default of markdown-it. 2. 3 Did you write the typeup site in typeup? If so, could you share the source for the site? 1. 2 Sadly not, the current nesting rules don’t allow for multiline code in tables (I handwrote the HTML). I would love to bootstrap, though it may take some syntax bending. If you’re looking for more examples, https://git.sr.ht/~skuzzymiglet/typeup-doc/tree/master/item/example-document.tup has them. New markup formats are sorta hard to actually use since so many webpages just take plain markdown. You could make scripts to open Vim and dump the converted text back but it’s a bit of a hassle for a rather small benefit (unless Lobsters, GitHub and MS Teams start supporting typeup :)). The hard solution would be Chrome/Firefox plugins and custom-extending everything. 2. 3 Why do you think that list syntax gets in the way? One thing that people seem to forget about Markdown is that it should both be human readable in plain text as well as in rendedered form, ideally even if you don’t know a lot about Markdown. Lists reflect this, as their synax mimics how you would write in on paper or see it in a book. 1. 1 Only if you write it using consecutive numbers, which is not required and would be a huge pain to actually do. 1. 1 In my experience (writing Markdown basically since Gruber released it), numbered lists rarely exceed 3 items. Of course, your mileage may vary, but crucially, if you’re writing a document that requires numbered items, the tool generally takes care of it. Word dynamically renumbers (badly), HTML and as far as I recall, LaTeX simply render the numbers on output, and Markdown follows a similar trend. You can just prepend each item with 1. and it will be renumbered as HTML, or you can do the extra work and renumber manually if you’re absolutely sure that the MD source will be the primary. 2. 3 The metadata and table syntax is much better than markdown. 1. 2 Have you considered how users might express LaTeX math notation in your markup language? Users who write math-heavy documents are often an afterthought when designing specs like this. There’s the traditional $...$ and $$...$$ for inline and block math, but if you want something less intrusive you might take Scholarly Markdown’s approach that fails gracefully in the absence of a math renderer. 1. 1 if you want something less intrusive you might take Scholarly Markdown’s approach that fails gracefully in the absence of a math renderer This just seems to be backwards-compatibility with other Markdown renderers, which I’m not really striving for. Nor do I want to overload existing syntax, that would be quite messy. Of course, falling back to just printing the raw expression could be done. What syntax you consider for something less intrusive than $ and $$? 1. 2 Some options: • I think the ... and $$... syntax is what people who write math will reach for out of habit. But if it poses parsing difficulties, you might choose to use ... for inline and choose another method for block math. • I’m not a fan of the LaTeX  syntax for block math, mostly because the \ character can be a burden to type on some non-English keyboard layouts. Nevertheless it’s an option. • You could go full LaTeX and look for $$...$$ and \begin{align}...\end{align} etc. • Instead of overloading existing code block syntax, you could always introduce a new type of block delimiter like this, to be consistent with your existing markup. This would also placate users who like the ...$$ syntax. :) $$$block math here$


I do personally think that in the absence of special notation just for math, “named” code blocks are the way to go. That way each block can be sent to the appropriate postprocessor, and you have a simple avenue for extensibility later. (for example, chemists might ask you to support SMILES diagrams)

You can also take a look at how Madoko and MathPix Markdown handle math.

1. 2

I do personally think that in the absence of special notation just for math, “named” code blocks are the way to go. That way each block can be sent to the appropriate postprocessor, and you have a simple avenue for extensibility later. (for example, chemists might ask you to support SMILES diagrams)

That’s what rST does: there’s general inline (role) and block (directive) syntax, and the build process exposed an intermediate doctree representation. Opens up all sorts of useful extensions.

2. 2

My biggest issue with it is that this doesn’t solve the most severe issue with MD I have - lack of backward-compatible extensibility. ASCIIDoc have that in form of the extensions syntax and I am looking forward creating something like that, that would support extensions.

1. 1

Extensibility has been left out of the first version for sanity. I was thinking of having a very simple syntax for passing raw text to transforming functions, but then stuff like TOC would be hard. Filters on the AST, pandoc-style, are also an option. It’ll have to be added at some point, because the core is quite lean for most people (no syntax highlighting, no TOC, etc)

2. 1

It looks really nice!

I think something that gets forgotten about, especially with the various Markdown dialects is that a nice property of the original Markdown was that it was pretty close to what one would write in a Readme or an email, Usenet, etc. if there was only regular text (ASCII for example) available.

This has the advantage that unless the author doesn’t care just doing cat README.md or similar would still be very readable.

Of course there is a lot of extension and of course there is now many other use cases, like static site generators, websites, chat applications, manuals, etc. where the extensions are interesting. While it of course would be nice to have a “one size fits all” type small markup languages, I wonder if it wouldn’t make sense for some of these projects to start with clearly defined use cases (and what isn’t). That gives both developers a measure to prevent feature creep and users a quick way to see if it fits their project.

So I am curious. What would be the target applications for this specific markup language?

1. 2

Originally, the goal was to be “easy to type”. Initially, I made a point of avoiding the use of the shift key, which lead to duplication being favored (code was initially wrapped in ''), but that’s harder to type really. I have found typeup makes it really easy to reformat notes written in no format at all. My notes often use paragraphs instead of lists and never use Markdown tables because of their overhead. In typeup, they look almost the same except some wrapping. For example, instead of the trouble of a markdown table, you’d just write:

Irish: Celtic
Swahili: Bantu


and to make it typeup:

#:{
Language: Family
Irish: Celtic