Markdown: simple syntax for arbitrary nesting

Markdown: simple syntax for arbitrary nesting

[Fritz Fritzy]

[-- Attachment #1.1: Type: text/plain, Size: 1924 bytes --]

Hi,

Using markdown, I've often been frustrated by


   1. 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.
   2. 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.
In some more details:

   - The format would just be `{ content }` or `{ content }{#id .class}` to 
   be able to add attributes to a block. 
   - If the content between braces contains new lines, the first new line 
   sets the indentation level for the rest.

There could be a point to be made to put the attributes before the content, 
but I'm not sure what kind of form that would take. Maybe something like 
`#id{content}{.class}` could be used: only the identifier can come before 
the content, and has to be a valid identifier (alphanum, underscore, dash)?

I think this syntax would not clash with that much of what's already 
existing: mostly just the already existing attribute syntax. A potential 
solution to that would be to use a different character pair for nested 
blocks, but `[]` is already used a lot.

I've looked at implementing that as a custom filter, but I think it has to 
be an extension baked in pandoc itself.

Cheers


-- 
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/5573f042-48a4-4115-8b1d-a86c13eb319an%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2416 bytes --]

Re: Markdown: simple syntax for arbitrary nesting

[John MacFarlane]

> On Oct 24, 2023, at 11:06 PM, Fritz Fritzy <emile.valjean-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/297BE1CF-4874-44E3-B6AA-9B9B87378A6B%40gmail.com.

Re: Markdown: simple syntax for arbitrary nesting

[Fritz Fritzy]

[-- Attachment #1.1: Type: text/plain, Size: 4060 bytes --]

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 <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-discuss+unsubscribe-/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.

[-- Attachment #1.2: Type: text/html, Size: 5112 bytes --]

Re: Markdown: simple syntax for arbitrary nesting

[Guillaume Dehaene]

[-- Attachment #1: Type: text/plain, Size: 6420 bytes --]

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 <emile.valjean-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> 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-discuss+unsubscribe-/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
> <https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-5017ce7a1baen%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAKOoOVWTtzokYLhLNdd5C67_FVor2RREFebCTA73s4jb76_Zwg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 8282 bytes --]

AW: Markdown: simple syntax for arbitrary nesting

[denis.maier-NSENcxR/0n0]

[-- Attachment #1: Type: text/plain, Size: 7478 bytes --]

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-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> Im Auftrag von Guillaume Dehaene
Gesendet: Donnerstag, 26. Oktober 2023 09:42
An: pandoc-discuss-/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:

     *   I'm worried about conflicts / confusion with the html syntax {#id .class key=foo}
     *   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

     *   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)?
     *   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 <emile.valjean-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<mailto:emile.valjean-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> 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

     *   emphasized text containing asterisks, one could just start with *{}*, and not have to fear that the emphasis gets dropped.
     *   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 <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<mailto:emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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<https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-5017ce7a1baen%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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<https://groups.google.com/d/msgid/pandoc-discuss/CAKOoOVWTtzokYLhLNdd5C67_FVor2RREFebCTA73s4jb76_Zwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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/GV0P278MB021102C19E4D996E3773D91283DDA%40GV0P278MB0211.CHEP278.PROD.OUTLOOK.COM.

[-- Attachment #2: Type: text/html, Size: 17346 bytes --]

Re: Markdown: simple syntax for arbitrary nesting

[Fritz Fritzy]

[-- Attachment #1.1: Type: text/plain, Size: 10141 bytes --]

@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 <https://paste.rs/YBW8L.js> 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 <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 <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 
> <https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-5017ce7a1baen%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> -- 
> 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 
> <https://groups.google.com/d/msgid/pandoc-discuss/CAKOoOVWTtzokYLhLNdd5C67_FVor2RREFebCTA73s4jb76_Zwg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

[-- Attachment #1.2: Type: text/html, Size: 17004 bytes --]