ANN: pandoc 1.14.1

ANN: pandoc 1.14.1

[John MacFarlane]

I'm pleased to announce the release of pandoc 1.14.1.

A changelog and binary downloads can be found here:
https://github.com/jgm/pandoc/releases/1.14.1

If you use cabal to install pandoc, just

    cabal update && cabal install --reinstall pandoc

In general this release just cleans up a few problems
with the 1.14.0.x series.

You can once again put a reference.docx in your ~/.pandoc
directory, and it will override defaults.  You can also
once again do `pandoc --print-default-data-file
reference.docx`.

`--self-contained` should also work better with complex
CSS files.

Packagers take note:  the man pages are no longer built
during the Cabal build process.  Instead, pandoc can now
generate its own man pages:

    pandoc --man1 > pandoc.1
    pandoc --man5 > pandoc_markdown.5

Re: ANN: pandoc 1.14.1

[Magnus Therning]

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

On Tue, Jun 30, 2015 at 10:54:19PM -0700, John MacFarlane wrote:
> I'm pleased to announce the release of pandoc 1.14.1.
> 
> A changelog and binary downloads can be found here:
> https://github.com/jgm/pandoc/releases/1.14.1
> 
> If you use cabal to install pandoc, just
> 
>    cabal update && cabal install --reinstall pandoc
> 
> In general this release just cleans up a few problems
> with the 1.14.0.x series.
> 
> You can once again put a reference.docx in your ~/.pandoc
> directory, and it will override defaults.  You can also
> once again do `pandoc --print-default-data-file
> reference.docx`.
> 
> `--self-contained` should also work better with complex
> CSS files.
> 
> Packagers take note:  the man pages are no longer built
> during the Cabal build process.  Instead, pandoc can now
> generate its own man pages:
> 
>    pandoc --man1 > pandoc.1
>    pandoc --man5 > pandoc_markdown.5

Is there a way to run these commands at build time, i.e. without first
installing `pandoc`?

Just running `pandoc --man1` fails since it doesn't find `README`, and
it seems to look for it in its final destination
(`/usr/share/x86_64-linux-ghc-7.10.1/pandoc-1.14.1/` in my case).
Using `--data-dir` seems to have no effect on this behaviour.

Is it possible to build them manually?

I tried using 

    ./dist/build/pandoc/pandoc -t man \
    --template=data/pandoc.1.template -s README \
    > pandoc.1

but that doesn't produce the same output as `pandoc --man1`.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org   jabber: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org
twitter: magthe               http://therning.org/magnus

Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
     -- Alan Kay

Re: ANN: pandoc 1.14.1

[Manolo Martínez]

So, if we install from cabal, will `man pandoc` display the latest man
page?

Manolo

On 06/30/15 at 10:54pm, John MacFarlane wrote:
> I'm pleased to announce the release of pandoc 1.14.1.
> 
> A changelog and binary downloads can be found here:
> https://github.com/jgm/pandoc/releases/1.14.1
> 
> If you use cabal to install pandoc, just
> 
>    cabal update && cabal install --reinstall pandoc
> 
> In general this release just cleans up a few problems
> with the 1.14.0.x series.
> 
> You can once again put a reference.docx in your ~/.pandoc
> directory, and it will override defaults.  You can also
> once again do `pandoc --print-default-data-file
> reference.docx`.
> 
> `--self-contained` should also work better with complex
> CSS files.
> 
> Packagers take note:  the man pages are no longer built
> during the Cabal build process.  Instead, pandoc can now
> generate its own man pages:
> 
>    pandoc --man1 > pandoc.1
>    pandoc --man5 > pandoc_markdown.5
> 
> 
> -- 
> 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/20150701055418.GA60820%40localhost.hsd1.ca.comcast.net.
> For more options, visit https://groups.google.com/d/optout.

-- 

Re: ANN: pandoc 1.14.1

[John MacFarlane]

+++ Magnus Therning [Jul 01 15 09:14 ]:
>Is there a way to run these commands at build time, i.e. without first
>installing `pandoc`?
>
>Just running `pandoc --man1` fails since it doesn't find `README`, and
>it seems to look for it in its final destination
>(`/usr/share/x86_64-linux-ghc-7.10.1/pandoc-1.14.1/` in my case).
>Using `--data-dir` seems to have no effect on this behaviour.

Yes, you need to install (unless you've used
`-fembed_data_files`).  Is this a problem?  I figured
distribution packagers would simply install into a sandbox
or use a fakeroot or something.

>Is it possible to build them manually?
>
>I tried using
>
>    ./dist/build/pandoc/pandoc -t man \
>    --template=data/pandoc.1.template -s README \
>    > pandoc.1
>
>but that doesn't produce the same output as `pandoc --man1`.

Correct.  The man page construction involves some
transformations of the README (including dividing it into
two parts, for man 1 and man5).

You can do this, though.  Create the following Haskell
program in the pandoc source directory:

``` manpages.hs
import Text.Pandoc.ManPages

main = do
  manPandoc1 >>= writeFile "pandoc.1"
    manPandocMarkdown5 >>= writeFile "pandoc_markdown.5"
```

Run it with the interpreter:

```
runghc -Isrc manpages.hs
```

Re: ANN: pandoc 1.14.1

[John MacFarlane]

+++ Manolo Martínez [Jul 01 15 16:32 ]:
>So, if we install from cabal, will `man pandoc` display the latest man
>page?

No.  Long ago we used to have the cabal build process
install the man pages, but this hasn't been done since
around 1.12, I think.

You'll need to install them manually if you want them.

Unfortunately, Cabal doesn't seem to have any built in
support for installing man pages.  I used to have some
custom code in Setup.hs that did this, but it was fragile
and for reasons I can't recall I removed it.

-- 
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/20150701164944.GE61054%40localhost.hsd1.ca.comcast.net.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: pandoc 1.14.1

[John MacFarlane]

Actually, looking at the man page situation, I'm tempted
to change to using one big man page (pandoc.1) instead of
pandoc.1 and pandoc_markdown.5.

Currently these are carved out of the README.  But parts
of pandoc.1 actually refer to sections that end up
in pandoc_markdown.5.

If we did this, we'd be closer to being able to generate
the man page using a straightforward pandoc command with
README and a custom template.  We'd also need custom
filters for the other transformations we do (remove links,
capitalize headers).

Man page generation would then be something like:

    pandoc README -t man -s --template man/man_template.1 \
      --filter man/removeLinks.hs \
      --filter man/capitalizeHeaders.hs \
      -o pandoc.1

I like that better than including `--man1` and `--man5`
in pandoc itself, and I don't know why I didn't think of
doing it this way.

Re: ANN: pandoc 1.14.1

[Magnus Therning]

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

On Wed, Jul 01, 2015 at 09:44:57AM -0700, John MacFarlane wrote:
> +++ Magnus Therning [Jul 01 15 09:14 ]:
> >Is there a way to run these commands at build time, i.e. without first
> >installing `pandoc`?
> >
> >Just running `pandoc --man1` fails since it doesn't find `README`, and
> >it seems to look for it in its final destination
> >(`/usr/share/x86_64-linux-ghc-7.10.1/pandoc-1.14.1/` in my case).
> >Using `--data-dir` seems to have no effect on this behaviour.
> 
> Yes, you need to install (unless you've used `-fembed_data_files`).
> Is this a problem?  I figured distribution packagers would simply
> install into a sandbox or use a fakeroot or something.

Well, sure, the package building does use `fakeroot` (inside a docker
instance in my case), but that's only to be able to build as a
non-root user and still set the files to be owned by `root`.  Anyway,
this is sort beside the point :)

The steps I use for packaging are (somewhat shortened):

~~~ { .sh }
    runhaskell Setup configure -O --enable-library-profiling --enable-shared \
        --prefix=/usr --docdir="/usr/share/doc/${pkgname}" \
        --libsubdir=\$compiler/site-local/\$pkgid \
            -f-old-locale -fnetwork-uri -fhttps -f-trypandoc -f-embed_data_files

    runhaskell Setup build

    runhaskell Setup copy --destdir="${pkgdir}"
~~~

As you see the configuration uses `--prefix` while the copying uses
`--destdir` to get all files into the correct hierarchy, but rooted at
`${pkgdir}/` rather than at `/`.  This is where the hardcoded path to
the README causes problems -- I'd have to pollute the build system by
copying the README into `/usr/share/...` in order to create the man
pages.  This would require that I build the package as root, something
that I explicitly *don't* want (in fact, the package building tools in
Arch Linux recently removed the option to build as root!)

> >Is it possible to build them manually?
> >
> >I tried using
> >
> >   ./dist/build/pandoc/pandoc -t man \
> >   --template=data/pandoc.1.template -s README \
> >   > pandoc.1
> >
> >but that doesn't produce the same output as `pandoc --man1`.
> 
> Correct.  The man page construction involves some
> transformations of the README (including dividing it into
> two parts, for man 1 and man5).
> 
> You can do this, though.  Create the following Haskell
> program in the pandoc source directory:
> 
> ``` manpages.hs
> import Text.Pandoc.ManPages
> 
> main = do
>  manPandoc1 >>= writeFile "pandoc.1"
>    manPandocMarkdown5 >>= writeFile "pandoc_markdown.5"
> ```
> 
> Run it with the interpreter:
> 
> ```
> runghc -Isrc manpages.hs
> ```

Yes, I might have to do something like this... but as you realise it's
bit of a hassle to have package building steps that depend on the
pandoc API.  I'd rather avoid it if possible.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org   jabber: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org
twitter: magthe               http://therning.org/magnus

McBryan's Law: You can't make it better until you make it work.

Re: ANN: pandoc 1.14.1

[Magnus Therning]

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

On Wed, Jul 01, 2015 at 10:20:06AM -0700, John MacFarlane wrote:
> Actually, looking at the man page situation, I'm tempted to change
> to using one big man page (pandoc.1) instead of pandoc.1 and
> pandoc_markdown.5.
> 
> Currently these are carved out of the README.  But parts of pandoc.1
> actually refer to sections that end up in pandoc_markdown.5.
> 
> If we did this, we'd be closer to being able to generate the man
> page using a straightforward pandoc command with README and a custom
> template.  We'd also need custom filters for the other
> transformations we do (remove links, capitalize headers).
> 
> Man page generation would then be something like:
> 
>    pandoc README -t man -s --template man/man_template.1 \
>      --filter man/removeLinks.hs \
>      --filter man/capitalizeHeaders.hs \
>      -o pandoc.1
> 
> I like that better than including `--man1` and `--man5` in pandoc
> itself, and I don't know why I didn't think of doing it this way.

I do like this!  Maybe even putting it into a small shell script, or
something else that can be distributed with the source (as well as
updated and tested with each release ;)

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org   jabber: magnus-prvltyMypuNg9hUCZPvPmw@public.gmane.org
twitter: magthe               http://therning.org/magnus

Code as if whoever maintains your program is a violent psychopath who knows
where you live.
     -- Anonymous

Re: ANN: pandoc 1.14.1

[John MacFarlane]

+++ Magnus Therning [Jul 02 15 01:06 ]:
>On Wed, Jul 01, 2015 at 10:20:06AM -0700, John MacFarlane wrote:
>> Actually, looking at the man page situation, I'm tempted to change
>> to using one big man page (pandoc.1) instead of pandoc.1 and
>> pandoc_markdown.5.
>>
>> Currently these are carved out of the README.  But parts of pandoc.1
>> actually refer to sections that end up in pandoc_markdown.5.
>>
>> If we did this, we'd be closer to being able to generate the man
>> page using a straightforward pandoc command with README and a custom
>> template.  We'd also need custom filters for the other
>> transformations we do (remove links, capitalize headers).
>>
>> Man page generation would then be something like:
>>
>>    pandoc README -t man -s --template man/man_template.1 \
>>      --filter man/removeLinks.hs \
>>      --filter man/capitalizeHeaders.hs \
>>      -o pandoc.1
>>
>> I like that better than including `--man1` and `--man5` in pandoc
>> itself, and I don't know why I didn't think of doing it this way.
>
>I do like this!  Maybe even putting it into a small shell script, or
>something else that can be distributed with the source (as well as
>updated and tested with each release ;)

pandoc 1.15 does this.

But now I'm working on something even better, which will
cabal build the man pages and install them.