@denis: Thanks for the links, I quite liked scribble and pollen, but it's hard to beat markdown/pandoc for its sheer universality! As for pml, that's very close to a markup form I've been playing with for some time, and it seems very close to ideal imo. Here is a tree-sitter grammar for it with a comment explaining the basic idea of the structure, if that interests anyone. @Guillaume Thanks for your reply! 1. 1. The confusion is already there with parameter blocks for titles and custom spans in pandoc's markdown (iiuc), and I guess the original idea behind that {.class #id key=val} syntax is that what's inside the braces already kind of matches what one might know from html/css selectors. 2. The idea is that this extension would be used as an alternative to the current div/span syntax extensions, I guess. 2. 1. As far as I can tell, it should be doable to make it flexible: in my mind, opening a brace block would more or less "reset" the parsing context until finding the closing brace. Thus, opening braces after say opening a list item would allow writing anything, never getting out of this item, no matter how messed up our indentation is, and the same idea for italic or whatever. 2. It might make sense that if we're already "inline", we can't create "block" content, even inside braces, so that e.g. we can't start a list inside emphasis. But that's a pretty natural restriction as far as I can tell. I agree that in a sense, this would maybe almost deserve to not be called markdown anymore, but two counterpoints: 1. It's really almost just an extension of markdown. I expect people don't write lots of braces outside of code blocks, so that one should usually be able to start with plain md, and if needs be, start adding nested blocks "transparently". 2. Pandoc already has plenty of extensions, and adding this one, one might still benefit from all others: separating it into its own language would mean duplicating all this working code. Thanks all for the feedback :) On Thursday, October 26, 2023 at 7:57:31 AM UTC denis...-NSENcxR/0n0@public.gmane.org wrote: > For inspiration, maybe have a look at > > - https://docs.racket-lang.org/scribble/index.html > - https://docs.racket-lang.org/pollen/index.html > - > https://pml-lang.dev/docs/articles/practical-document-markup-language/index.html > > > > > > *Von:* pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org *Im > Auftrag von *Guillaume Dehaene > *Gesendet:* Donnerstag, 26. Oktober 2023 09:42 > *An:* pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > *Betreff:* Re: Markdown: simple syntax for arbitrary nesting > > > > Hello all, > > > > Fritz, you make good points. > (NB: are you aware of the typst project? It's a very different markup, but > it does offer some ideas of nesting that you might find appealing; it's > also supported in pandoc) > > I agree that pandoc markdown goes beyond the initial markdown "manifesto" > and introduces additional complexity > But I'm not sure if your proposal: > > 1. Meshes well with pandoc markdown structures: > > > 1. I'm worried about conflicts / confusion with the html syntax {#id > .class key=foo} > 2. I'm worried that any nesting constructs would overlap with the > div syntax: > as a user, it might be hard to figure out exactly the intended use > cases for both > as a strong believer in python, let me quote Guido Van Rossum > > There should be one-- and preferably only one --obvious way to do it. > > > 1. Meshes well with the fundamentals of a markup language > > > 1. Can we make wrapping extremely flexible (I think that's what you > want)? > If so, isn't that going to cause issues for the wrapped content and > the "wrappee" content? > can we put arbitrary marks on the wrapped content (for italics, > etc)? > 2. If we are restricted somehow, what is the restriction? is it > obvious to the user? > > To be clear, it's really good to think about these ideas, and I believe > that there is potential here to construct an improved language > > but maybe it needs to diverge from pandoc markdown to get there > > I'd be interested to hear your future thoughts on this > > > > Best > Guillaume > > > > Le jeu. 26 oct. 2023 à 08:36, Fritz Fritzy a écrit : > > Thanks for the answer! > > > > RE nesting: > > I mean things like the use of asterisk inside emphasis/bold spans, or the > different ways paragraphs/lists/quotes/pre blocks work together wrt > indentation and newlines. > > I understand that when one knows the parsing rules, it's probably always > doable to make them do what one wants, but personally I often get them > wrong. > > > > RE markdown's design: > > As far as I can tell, markdown has grown way farther than those initial > goals, and is now used for more than simple email-like content. > > Looking at all the different extensions defined and e.g. provided by > pandoc, I believ that ease of readability has been already left out: one > has to know the semantics of footnotes, custom spans, custom divs, > attribute blocks already to know how to read them. > > Obviously, adding yet another new syntax construct can be seen as just > adding to the already present overhead, but it seems to me like: > > 1. It's easy to reason about, in that nesting is natural to > understand, and its parsing rules being (close to?) context free makes > figuring out how to make it work easier. > 2. It would be enough to replace/cover quite a few of the already > present constructs (e.g. all the divs and spans, and maybe also attribute > blocks for titles?), thus reducing the cognitive cost both for writing and > reading markdown. > 3. On a similar note, it would mean that e.g. when writing things like > > > 1. emphasized text containing asterisks, one could just start with > *{}*, and not have to fear that the emphasis gets dropped. > 2. any kind of block, say a list item, or a quote block, one could > use braces again to reset the indentation to any value we like. > > In short, it seems to me that it's a simple enough, orthogonal and rather > powerful syntax that doesn't _have_ to be used, but makes writing complex > documents that much easier. > > > > I understand that you and many people have probably spent way more time > thinking about this than I have, and won't try to push my point further if > it hasn't been in any way convincing so far :) > > > > Thanks for your time, and for pandoc, which has already proven incredibly > useful to me! > > > > On Wednesday, October 25, 2023 at 2:58:32 PM UTC John MacFarlane wrote: > > > > > On Oct 24, 2023, at 11:06 PM, Fritz Fritzy wrote: > > > > Hi, > > > > Using markdown, I've often been frustrated by > > > > • Its flat/non-recursive/non-nested nature, by which I mean that you > mostly cannot write "arbitrary" markdown inside most elements, and if you > can, you have to be very careful with whitespaces/indentation/etc. > > > I'm not sure what you mean: generally you can nest things, you just have > to pay attention to the syntax. Examples? > > > > • The impossibility to easily interlink to arbitrary parts of the > document. > > To solve both issues, I'd like to propose an extension that allows > "simply" using braces (or some other punctuation pair) to allow nesting, > with an option to tag/add attributes to the contents like that. > > > I think this goes against the spirit of Markdown, which prioritizes source > readability rather than easy writeability. > > "The overriding design goal for Markdown’s formatting syntax is to make it > as readable as possible. The idea is that a Markdown- formatted document > should be publishable as-is, as plain text, without looking like it’s been > marked up with tags or formatting instructions." ( > http://daringfireball.net/projects/markdown/) > > -- > You received this message because you are subscribed to the Google Groups > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit > https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-5017ce7a1baen%40googlegroups.com > > . > > -- > You received this message because you are subscribed to the Google Groups > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To view this discussion on the web visit > https://groups.google.com/d/msgid/pandoc-discuss/CAKOoOVWTtzokYLhLNdd5C67_FVor2RREFebCTA73s4jb76_Zwg%40mail.gmail.com > > . > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/c841a3cc-54a6-4a92-96d6-d4af58893ecen%40googlegroups.com.