From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/33235 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Fritz Fritzy Newsgroups: gmane.text.pandoc Subject: Re: Markdown: simple syntax for arbitrary nesting Date: Thu, 26 Oct 2023 02:24:27 -0700 (PDT) Message-ID: References: <5573f042-48a4-4115-8b1d-a86c13eb319an@googlegroups.com> <297BE1CF-4874-44E3-B6AA-9B9B87378A6B@gmail.com> <80b20bbf-1f3f-4473-9d0d-5017ce7a1baen@googlegroups.com> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2420_1939356654.1698312267521" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15921"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBDOITKNXR4IRBTPA5CUQMGQEP47BW3Y-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Thu Oct 26 11:24:33 2023 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oo1-f62.google.com ([209.85.161.62]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1qvwbR-0003z5-9F for gtp-pandoc-discuss@m.gmane-mx.org; Thu, 26 Oct 2023 11:24:33 +0200 Original-Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-581d922dab4sf802359eaf.2 for ; Thu, 26 Oct 2023 02:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1698312272; x=1698917072; darn=m.gmane-mx.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=juZ3gXboPz62i+sRqJVyBBD7eilPtJUNOEMFub7/wpU=; b=Zye7zL3BGJSiv1LDSlBNtZKl+myli1WkLL810Lo2WPsWmBMHXr3xnPeWu0Nj4ccD+Q /JuRYvtv4IKhyujMAPqjaD3KRye2bexmkNBYjtonCSUH7Gk+wdWKzCnoMVxoc3XBSR0E dpZEMaJ88LClf6Dv51yNrYKsS0eBtckLE/LExTK8dvMmNuiJYScuPOXc4DtJPKfZ31Z2 KdaBuEEDiUpsVcZQL6FHzDOyNQORRO+d99UkR8ZjbpbXMaEaCIo7zc3LzMpcnA8PXgsQ JiPdtgKbgnKEnxsF+QSAFL32z+c1fJgkLozVQ11yxYZRj5ZHC1AfBWk6LP+ddkC5/ctn JTHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698312272; x=1698917072; darn=m.gmane-mx.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=juZ3gXboPz62i+sRqJVyBBD7eilPtJUNOEMFub7/wpU=; b=aoKKkRfbShF8hFESvsGnLCf2vKOiuKpN5VvRkTlAzEOy2HGFmaeYE6CR3YbVidGBuR qVrGEkT6r7mLRzvLun15CaJ/ZJMDD32PhZ7iDP0hNWVq4o+EVGuT5CiCJaSyPaE504Rt 6KGkXnb8ALyjJm9TJvZ7Kj9w951Of0O1/mR77m5HrxYiw6OOps+sX96F/cYaM6Pi+LPL uT6aE2Qyh0bPfokWRS+8PI8p8wkVNJ6oNkdVz2jMMd3B3PgXxIqLbrHL3rLEgoGWBi0A uYLxEhjHJDyIWBfGldMgLJkVVB19+7sSOemK0yWfoaTTLeuIAyDi+mq+cWk8xCWPSa8P 7O6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698312272; x=1698917072; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence:reply-to :x-original-sender:mime-version:subject:references:in-reply-to :message-id:to:from:date:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=juZ3gXboPz62i+sRqJVyBBD7eilPtJUNOEMFub7/wpU=; b=U2PEgiBDeeRgU5PwvcpBuUnLDY2YsOeGqyvyHbAvquVVYcSVdQ2eGeUDk/EwIAWzss kdKn/MYxuZpQo1YZL2zaoq7heC7W9Saikn2O8vHho7JwVm30hq2bGZcVdON0yZr5PnnE hVACFmFJzbWWCihXof+FjfkKP/Ipxwd7L9nj5rohsNCuxxzvT2jk0ijJH1S5DuoPPiz8 zbXSCFvKeR61tzaYFGmxfxftiL5DnSQctNT8CZT3FvmImYVt0yAsOZ/VcqXgYQFYxhAv TLsB5YkOw65H3njlk5eq6RQa4ecxn92iMFCbyZD0W36vHTePBh Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AOJu0Yz+hOqgwe9ionGR2w1rgGfGhEByBbVlv69gdSsyrWKWGbdMz5MR +aQpk3e+arAG402C2BxDuH0= X-Google-Smtp-Source: AGHT+IGrXYzYit0ru+qZ+sXQ1q8hLJcW5Ev7/pqiIgmod4SpLA8Qv9C6HP8YxRRlDWOmGpZminBViw== X-Received: by 2002:a4a:ba12:0:b0:581:f2de:25f8 with SMTP id b18-20020a4aba12000000b00581f2de25f8mr15437014oop.0.1698312272095; Thu, 26 Oct 2023 02:24:32 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a4a:52d5:0:b0:581:e081:95d7 with SMTP id d204-20020a4a52d5000000b00581e08195d7ls708907oob.0.-pod-prod-00-us; Thu, 26 Oct 2023 02:24:28 -0700 (PDT) X-Received: by 2002:a05:6830:360e:b0:6cd:ed53:128b with SMTP id bg14-20020a056830360e00b006cded53128bmr508781otb.2.1698312268297; Thu, 26 Oct 2023 02:24:28 -0700 (PDT) In-Reply-To: X-Original-Sender: Emile.Valjean-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:33235 Archived-At: ------=_Part_2420_1939356654.1698312267521 Content-Type: multipart/alternative; boundary="----=_Part_2421_756969454.1698312267521" ------=_Part_2421_756969454.1698312267521 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @denis: Thanks for the links, I quite liked scribble and pollen, but it's hard to= =20 beat markdown/pandoc for its sheer universality! As for pml, that's very close to a markup form I've been playing with for= =20 some time, and it seems very close to ideal imo.=20 Here is a tree-sitter grammar for it with a=20 comment explaining the basic idea of the structure, if that interests=20 anyone. @Guillaume Thanks for your reply! 1. =20 1. The confusion is already there with parameter blocks for titles=20 and custom spans in pandoc's markdown (iiuc), and I guess the origina= l idea=20 behind that {.class #id key=3Dval} syntax is that what's inside the b= races=20 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= =20 the current div/span syntax extensions, I guess. 2.=20 1. As far as I can tell, it should be doable to make it flexible: in my= =20 mind, opening a brace block would more or less "reset" the parsing co= ntext=20 until finding the closing brace. Thus, opening braces after say opening a list item would allow=20 writing anything, never getting out of this item, no matter how messe= d up=20 our indentation is, and the same idea for italic or whatever.=20 2. It might make sense that if we're already "inline", we can't=20 create "block" content, even inside braces, so that e.g. we can't sta= rt a=20 list inside emphasis.=20 But that's a pretty natural restriction as far as I can tell. =20 I agree that in a sense, this would maybe almost deserve to not be called= =20 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=20 that one should usually be able to start with plain md, and if needs be,= =20 start adding nested blocks "transparently". 2. Pandoc already has plenty of extensions, and adding this one, one=20 might still benefit from all others: separating it into its own language= =20 would mean duplicating all this working code. Thanks all for the feedback :) On Thursday, October 26, 2023 at 7:57:31=E2=80=AFAM UTC denis...-NSENcxR/0n0@public.gmane.org w= rote: > For inspiration, maybe have a look at=20 > > - https://docs.racket-lang.org/scribble/index.html > - https://docs.racket-lang.org/pollen/index.html > -=20 > https://pml-lang.dev/docs/articles/practical-document-markup-language/= index.html > > =20 > > =20 > > *Von:* pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org *Im=20 > 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 > > =20 > > Hello all, > > =20 > > Fritz, you make good points. > (NB: are you aware of the typst project? It's a very different markup, bu= t=20 > it does offer some ideas of nesting that you might find appealing; it's= =20 > also supported in pandoc) > > I agree that pandoc markdown goes beyond the initial markdown "manifesto"= =20 > 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= =20 > .class key=3Dfoo} > 2. I'm worried that any nesting constructs would overlap with the= =20 > div syntax: > as a user, it might be hard to figure out exactly the intended use= =20 > cases for both > as a strong believer in python, let me quote Guido Van Rossum > =20 > 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=20 > want)? > If so, isn't that going to cause issues for the wrapped content and= =20 > the "wrappee" content? > can we put arbitrary marks on the wrapped content (for italics,=20 > etc)? > 2. If we are restricted somehow, what is the restriction? is it=20 > obvious to the user? > =20 > To be clear, it's really good to think about these ideas, and I believe= =20 > 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 > > =20 > > Best > Guillaume > > =20 > > Le jeu. 26 oct. 2023 =C3=A0 08:36, Fritz Fritzy a = =C3=A9crit : > > Thanks for the answer! > > =20 > > RE nesting:=20 > > I mean things like the use of asterisk inside emphasis/bold spans, or the= =20 > different ways paragraphs/lists/quotes/pre blocks work together wrt=20 > indentation and newlines. > > I understand that when one knows the parsing rules, it's probably always= =20 > doable to make them do what one wants, but personally I often get them=20 > wrong. > > =20 > > RE markdown's design:=20 > > As far as I can tell, markdown has grown way farther than those initial= =20 > goals, and is now used for more than simple email-like content. > > Looking at all the different extensions defined and e.g. provided by=20 > pandoc, I believ that ease of readability has been already left out: one= =20 > has to know the semantics of footnotes, custom spans, custom divs,=20 > attribute blocks already to know how to read them. > > Obviously, adding yet another new syntax construct can be seen as just=20 > 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=20 > understand, and its parsing rules being (close to?) context free makes= =20 > figuring out how to make it work easier. > 2. It would be enough to replace/cover quite a few of the already=20 > present constructs (e.g. all the divs and spans, and maybe also attrib= ute=20 > blocks for titles?), thus reducing the cognitive cost both for writing= and=20 > reading markdown. > 3. On a similar note, it would mean that e.g. when writing things like= =20 > > > 1. emphasized text containing asterisks, one could just start with=20 > *{}*, 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= =20 > use braces again to reset the indentation to any value we like. > =20 > In short, it seems to me that it's a simple enough, orthogonal and rather= =20 > powerful syntax that doesn't _have_ to be used, but makes writing complex= =20 > documents that much easier. > > =20 > > I understand that you and many people have probably spent way more time= =20 > thinking about this than I have, and won't try to push my point further i= f=20 > it hasn't been in any way convincing so far :) > > =20 > > Thanks for your time, and for pandoc, which has already proven incredibly= =20 > useful to me! > > =20 > > On Wednesday, October 25, 2023 at 2:58:32=E2=80=AFPM UTC John MacFarlane = wrote: > > > > > On Oct 24, 2023, at 11:06 PM, Fritz Fritzy wrote:= =20 > >=20 > > Hi,=20 > >=20 > > Using markdown, I've often been frustrated by=20 > >=20 > > =E2=80=A2 Its flat/non-recursive/non-nested nature, by which I mean tha= t you=20 > mostly cannot write "arbitrary" markdown inside most elements, and if you= =20 > can, you have to be very careful with whitespaces/indentation/etc.=20 > > > I'm not sure what you mean: generally you can nest things, you just have= =20 > to pay attention to the syntax. Examples?=20 > > > > =E2=80=A2 The impossibility to easily interlink to arbitrary parts of t= he=20 > document.=20 > > To solve both issues, I'd like to propose an extension that allows=20 > "simply" using braces (or some other punctuation pair) to allow nesting,= =20 > with an option to tag/add attributes to the contents like that.=20 > > > I think this goes against the spirit of Markdown, which prioritizes sourc= e=20 > readability rather than easy writeability.=20 > > "The overriding design goal for Markdown=E2=80=99s formatting syntax is t= o make it=20 > as readable as possible. The idea is that a Markdown- formatted document= =20 > should be publishable as-is, as plain text, without looking like it=E2=80= =99s been=20 > marked up with tags or formatting instructions." ( > http://daringfireball.net/projects/markdown/)=20 > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-= 5017ce7a1baen%40googlegroups.com=20 > > . > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "pandoc-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/pandoc-discuss/CAKOoOVWTtzokYLhLNdd5C67= _FVor2RREFebCTA73s4jb76_Zwg%40mail.gmail.com=20 > > . > --=20 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 e= mail 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. ------=_Part_2421_756969454.1698312267521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@denis:

Thanks for the links, I quite liked= scribble and pollen, but it's hard to beat markdown/pandoc for its sheer u= niversality!
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-sitte= r grammar for it with a comment explaining the basic idea of the structure,= if that interests anyone.

@Guillaume
=
Thanks for your reply!
  1. =C2=A0=
    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 be= hind that {.class #id key=3Dval} syntax is that what's inside the braces al= ready 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 curr= ent div/span syntax extensions, I guess.

    1. As= far as I can tell, it should be doable to make it flexible: in my mind, op= ening a brace block would more or less "reset" the parsing context until fi= nding the closing brace.
      Thus, opening braces after say opening a list= item would allow writing anything, never getting out of this item, no matt= er how messed up our indentation is, and the same idea for italic or whatev= er.
    2. It might make sense that if we're already "inline", we c= an't create "block" content, even inside braces, so that e.g. we can't star= t a list inside emphasis.
      But that's a pretty natural restriction as = far as I can tell.
I agree that in a sense, this wo= uld maybe almost deserve to not be called markdown anymore, but two counter= points:
  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, s= tart adding nested blocks "transparently".
  2. Pandoc already has plent= y of extensions, and adding this one, one might still benefit from all othe= rs: separating it into its own language would mean duplicating all this wor= king code.
Thanks all for the feedback :)


On Thursday, October 26, 2023 at 7:57:31=E2=80=AFAM= UTC denis...-NSENcxR/0n0@public.gmane.org wrote:

For inspiration, maybe have a l= ook at

  • https://docs.racket-lang.o= rg/scribble/index.html
  • https://docs.racket-lang.org/pollen/index.html=
  • <= a href=3D"https://pml-lang.dev/docs/articles/practical-document-markup-lang= uage/index.html" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D= "https://www.google.com/url?hl=3Den&q=3Dhttps://pml-lang.dev/docs/artic= les/practical-document-markup-language/index.html&source=3Dgmail&us= t=3D1698397889047000&usg=3DAOvVaw18i6Ux3bCDQI6--5xOOHBo">https://pml-la= ng.dev/docs/articles/practical-document-markup-language/index.html

=C2=A0

=C2=A0

Von: pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <pandoc-...@googlegroups.c= om> Im Auftrag von Guillaume Dehaene
Gesendet: Donnerstag, 26. Oktober 2023 09:42
An: pandoc-...@googlegrou= ps.com
Betreff: Re: Markdown: simple syntax for arbitrary nesting=

=C2=A0

Hello all,

=C2=A0

Fritz, you make good points.
(NB: are you aware of the typst=C2=A0project? It's a very different mar= kup, 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 "manifes= to"=C2=A0 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 .clas= s key=3Dfoo}
    2. I'm worried that any nesting constructs would overlap with the div synt= ax:
      as a user, it might be hard to figure out exactly the intended use cases fo= r both
      as a strong believer in python, let me quote Guido Van Rossum=

There should be one-- and preferably only one --obvi= ous way to do it.

  1. Meshes well with the fundamentals of a markup language
      1. Can we make=C2=A0wrapping extremely flexible (I think that's what you w= ant)?
        If so, isn't=C2=A0that going to cause issues for the wrapped=C2=A0conte= nt and the=C2=A0"wrappee" content?
        can we put arbitrary=C2=A0marks on the wrapped content (for italics, etc)?<= u>
      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 the= se ideas, and I believe that there is potential here to construct an improv= ed language

    but maybe it needs to diverge from pandoc markdown t= o get there

    I'd be interested to hear your future thoughts on this

    =C2=A0

    Best
    Guillaume

=C2=A0

Le=C2=A0jeu. 26 oct. 2023 =C3=A0=C2=A008:36, Fritz F= ritzy <emile....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a =C3=A9crit=C2=A0:

Thanks for the answer!

=C2=A0

RE nesting:

I mean things like the use of asterisk inside emphas= is/bold spans, or the different ways paragraphs/lists/quotes/pre blocks wor= k 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 persona= lly I often get them wrong.

=C2=A0

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 c= an 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, an= d its parsing rules being (close to?) context free makes figuring out how t= o make it work easier.
  2. It would be enough to replace/cover quite a few of the already present cons= tructs (e.g. all the divs and spans, and maybe also attribute blocks for ti= tles?), thus reducing the cognitive cost both for writing and reading markd= own.
  3. On a similar note, it would mean that e.g. when writing things like=C2=A0
    1. emphasized text containing asterisks, one could just start with *{}*, and n= ot 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 enou= gh, orthogonal and rather powerful syntax that doesn't _have_ to be use= d, but makes writing complex documents that much easier.

=C2=A0

I understand that you and many people have probably = spent way more time thinking about this than I have, and won't try to p= ush my point further if it hasn't been in any way convincing so far :)<= u>

=C2=A0

Thanks for your time, and for pandoc, which has alre= ady proven incredibly useful to me!

=C2=A0

On Wednesday, October 25, 2023 at 2:58:32=E2=80=AFPM= 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
>
> =E2=80=A2 Its flat/non-recursive/non-nested nature, by which I mean th= at you mostly cannot write "arbitrary" markdown inside most eleme= nts, and if you can, you have to be very careful with whitespaces/indentati= on/etc.


I'm not sure what you mean: generally you can nest things, you just hav= e to pay attention to the syntax. Examples?


> =E2=80=A2 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=E2=80=99s formatting syntax i= s to make it as readable as possible. The idea is that a Markdown- formatte= d document should be publishable as-is, as plain text, without looking like= it=E2=80=99s 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 &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pandoc-discus...-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.org= m.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/80b20bbf-1f3f-4473-9d0d-50= 17ce7a1baen%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pandoc-discus...-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.org= m.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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.
------=_Part_2421_756969454.1698312267521-- ------=_Part_2420_1939356654.1698312267521--