public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Staal <DStaal-Jdbf3xiKgS8@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: build customizability
Date: Mon, 4 May 2020 10:47:06 -0400	[thread overview]
Message-ID: <75f238b6-2ae0-2e73-66c9-54245b7cd655@usa.net> (raw)
In-Reply-To: <f9fd9cfe-e03f-45d3-bcb5-07267c28e565-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>

On 5/4/20 2:45 AM, brainchild wrote:
> *Markdown reader dependencies: *I now understand the conflict. In many 
> potential deployment scenarios, for example applications that employ 
> Markdown source, the embedding of snippets in some target language is 
> unlikely to be needed, except perhaps as narrowly allowed for equations. 
> Thus, if this functionality were entirely enclosed in extensions, and if 
> those extensions could be disabled in the build, then in principle it 
> may be possible to realize the benefit of removing the dependencies on 
> the parsers. I understand that it would require restructuring the code.

Just replying to this - in this case, you're getting far removed from 
Pandoc's processing, to the point where the input file for Pandoc is no 
longer compatible with your system.  What - at this point - is the 
benefit for using the Pandoc codebase?  If all you want is to parse 
Markdown or Latex or some other input format, there's lots of 
specialized parsers out there.

And further than that - what is the benefit to *Pandoc* of you using the 
Pandoc code base?  Since this would require a large restructure of the 
core code, what makes that restructure worthwhile to the Pandoc project? 
  Again, you're getting well off of Pandoc's goals and aim - and there 
are other products that do aim for that use.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------


  parent reply	other threads:[~2020-05-04 14:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 13:57 brainchild
     [not found] ` <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-01 15:51   ` John MacFarlane
     [not found]     ` <m2wo5vy7pz.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-05-03  8:05       ` brainchild
     [not found]         ` <a9b39338-0830-45dc-bf30-59d8de61278b-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-03 12:39           ` Albert Krewinkel
     [not found]             ` <87wo5tgpkn.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
2020-05-03 12:55               ` brainchild
     [not found]                 ` <459f63cf-31b3-48a4-adfe-21d5f23f9d22-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-03 13:39                   ` Ivan Lazar Miljenovic
     [not found]                     ` <CA+u6gbwbuU9QhDFygzHh259Pa99qCTNBAq6-Jym6z24hhCF=PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-03 14:05                       ` BPJ
2020-05-03 15:07                   ` Albert Krewinkel
2020-05-04  6:45   ` brainchild
     [not found]     ` <f9fd9cfe-e03f-45d3-bcb5-07267c28e565-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-05-04 14:47       ` Daniel Staal [this message]
     [not found]         ` <75f238b6-2ae0-2e73-66c9-54245b7cd655-Jdbf3xiKgS8@public.gmane.org>
2020-05-05  2:11           ` brainchild
2020-05-05  8:39           ` Colored text R. Wils
     [not found]             ` <CAJPsUMeBTr2BcSL8V8mQuh=50LDx+z8+547MUcMzZYqahF9CAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-05  8:42               ` brainchild
2020-05-04  8:36   ` build customizability brainchild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=75f238b6-2ae0-2e73-66c9-54245b7cd655@usa.net \
    --to=dstaal-jdbf3xikgs8@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).