michaelt/pandoc — comment on commit 2d1703e8a00349a1f76961a78688cb52f4d4e903
File:  line 0
By jgm:

+++ Michael Thompson [Mar 07 12 14:29 ]:
> I was consciously presupposing that the readers would always deliver `[..., Inline, Str ".", Str "foo", ...]` -- I guess for the sake of this kind of pattern matching, but I see this is fragile and hadn't thought of `--normalize`. (The problem I guess is `[..., Inline, Str ".foo", ...]` rather than `[..., Inline, Str "foo.", ...]` which would be okay for this bug.) In any case, is it just a question of a closer match:
>
> (LineBreak: Str ('.':chars): inlines) -> (as ++ [LineBreak], Str "." : Str chars : inlines)
>
> assuming there is nothing suspicious about `Str ""`? Or if so, the yet more verbose:
>
> (LineBreak: Str ('.':[]): inlines) -> (as ++ [LineBreak], Str "." : inlines)
> (LineBreak: Str ('.':chars): inlines) -> (as ++ [LineBreak], Str "." : Str chars : inlines)
>
> If that's right, I can send a replacement -- or of course you can just revise it as you please! The bracketed `isSentenceEndInline (LineBreak)` and unspaced `++[LineBreak]` are ugly anyway as I see now.
>
> The real worry I had about the patch is that it repairs a micro-bug I produced investigating the one reported, and I'm not sure there aren't others just like it.
>
> By the way, is the man writer supposed to oriented only to reading with `man thisProgram` or also to allow `groff -Tps -mandoc -c`, which I was using to test since it gives the line where something is wrong. It seems a little touchier than the in-terminal reader in general, at least on OS X, and makes a mess of tables in particular, which I suppose are not that uncommon in man pages.

It should work with ps output also.

I haven't looked at the man output in some time, and you're right,
the tables are messed up. Time to take a closer look.