Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org]

It is good to exchange, as I almost never communicate with other
people who use markdown, even it is so much the part of publishing
process.

On Wed, May 03, 2017 at 12:23:02PM -0700, Kolen Cheung wrote:
> And regarding optimization, actually in the real world, a lot of people 
> don't care about it. An example is a workflow to generate a large document 
> from many smaller ones outlined in [Repeated Footnotes Anchors and Headers 
> Across Multiple Files — Pandoc Tricks · jgm/pandoc Wiki · 
>
> GitHub](https://github.com/jgm/pandoc/wiki/Pandoc-Tricks#repeated-footnotes-anchors-and-headers-across-multiple-files).

I have looked on that, and I try to lessen down the complexity, not to
widen it.

> Going back to your use case, it seems you requires every last drop of 
> performance.

It sounds to me surprising when you say it so. Yet again, I don't like
too many pages being generated slow. I have already removed those
websites that generated thousands of pages.

> In markdown rendering, one thing you should shop for besides
> rendering speed is the feature sets (markdown extensions) and the
> syntaxes.  In your case, you should narrow down the minimal set of
> features you need, and given that feature set, you choose the one
> that's fastest.

What I use is just images and text.

Video is expaned by use of plugins, something like:

<% (princ (cl-user::plugin-video :src "video.webm" :width 400 :height 300)) %>

then if the page is sent by email, video may show just as link, if it
is published, it gets its proper HTML,

Before I was using the fastest Perl templating engine I found the
Text::NeatTemplate and now I use the Lisp's CL-EMB templating, which
gives me more freedom and is as fast I guess.

I have tied the processing or filtering program to the template, and
multitudes of templates in the website revision system.

If I copy same template and tie it to pandoc, the template's content
would expand with pandoc.

That way I could use any variety of markdown.

For example, I use the Org mode processing by using GNU Emacs, for
some pages. The Org mode is then converted to markdown, which is then
expanded into HTML within a template, because the template is tied to
Org mode conversion.

So I can mix Org mode, pandoc, other markdowns, all together in one
website.

My process is to simply write new pages, variables are expanded before
markdown, and markdown or other filtering language expands into HTML
within a template. Each page may have different template tied to
different processor.

> I can't speak for the others, but I can guess that for most pandoc users, 
> we never care about performance but look for the feature set.

When you say so. I deal with number of pages and like when it is
fast. And I had to re-program the system to make it faster, as at some
point of time it became too bloated. My programming is dirty.

> When I said "future compatibility", I mean in the future, when I
> write new contents, what if I need one more feature that the current
> software stack I setup didn't support? How large will the migration
> / work-around cost be in the future? In order words, we trade the
> computer time for the programmers/writers' time.

I used markdown since its inception, and before that I used M4 macro
processor.

Since that time until today, I did not switch to any new features,
just pictures and text, sometimes a table and videos, maps and
similar.

If I use a plugin for video or map, I can always adapt the expansion
of HTML without changing the source of the file.

> And regarding compiling from source, you actually don't need to do
> that if you are using the platforms that pandoc releases official
> binaries — Windows, Mac, Linux (`.deb`) 64-bit.

All software is compiled from source, that is how I build the
GNU/Linux system, and I don't use distributions any more.

When I referred to compiling pandoc, I think all, including haskell
and anything else. Almost impossible task.

> From my experience, compiling from source on Mac with homebrew is
> easy, as well as using stack, but less so when using cabal.

You refer only to pandoc.

> P.S. Haskwell is actually a very interesting language, and as far as
> I can tell, the most mathematical language. It seems such a language
> would be suited for scientific computing because all we do in
> science involves Math.  But unfortunately, virtually no body is
> doing Science in Haskell, at least in HPC application, exactly
> because of the lack of performance. By the way, AFAIK in Haskell you
> almost get parallelization for free, but in other language a lot of
> time has to be spent on thinking about how to parallelize a
> particular algorithm (and to implement it!). IMO, the "guarantee in
> correctness" and "free parallelism" of Haskell should be major
> selling points of Haskell to scientists but for various other
> reasons scientists doesn't really use it.

I am sure it is used in science too, it is large and usable.

Now I am using Lisp, Common Lisp and all is good and fine for
me. There are similarities to Haskell, even I did not do anything with
it.

Jean

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170503203659.GD11153%40protected.rcdrun.com.
For more options, visit https://groups.google.com/d/optout.