Text generic verbatim option

[bexelbie]

Should we add a verbatim option to the text processor that forces all lines to be treated was non-rewrappable?

[jnavila]

As a matter of fact, for the asciidoc filter, the implicit literal style triggered by indenting the lines of a paragraph isn't properly processed and all the lines are wrapped.

For instance, in this text:

patch::

  This lets you choose one path out of a 'status' like selection.
  After choosing the path, it presents the diff between the index
  and the working tree file and asks you if you want to stage
  the change of each hunk.  You can select one of the following
  options and type return:

       y - stage this hunk
       n - do not stage this hunk
       q - quit; do not stage this hunk or any of the remaining ones
       a - stage this hunk and all later hunks in the file
       d - do not stage this hunk or any of the later hunks in the file
       g - select a hunk to go to
       / - search for a hunk matching the given regex
       j - leave this hunk undecided, see next undecided hunk
       J - leave this hunk undecided, see next hunk
       k - leave this hunk undecided, see previous undecided hunk
       K - leave this hunk undecided, see previous hunk
       s - split the current hunk into smaller hunks
       e - manually edit the current hunk
       ? - print help

the second indented paragraph should be imported verbatim, and it is not.

[bexelbie]

@jnavila I have a suspicion there are a few more holes in the AsciiDoc importer. I have been trying (albeit slowly) to find a good test document that we could use to exercise the importer to identify the bugs for future testing and fixing. Do you have others you've found?

[jnavila]

This is the first issue I've encountered while trying to use git4a for the git man pages. If you wish, when pursuing, I can open an issue for any problem. I'm not at all fluent in Perl, so that will only be issues, not PRs.

[mquinson]

@jnavila I have a very sparse free time nowadays so I cannot promise to fix all issues in a timely manner, but I'd still appreciate if you could report any issue you see.

If you could open PR with only the test files, that would already be a huge help to the rest of us, who know some Perl but sometimes fail to see what exactly is needed to make po4a usable in contexts that we are not familiar with.

[mquinson]

many thanks for the pull request with the test files, but I am still unsure of what is going wrong here, sorry. When you say that the list is not taken as a litteral, you mean that it is missing the "no-wrap" decoration, right?

[jnavila]

There is the need for no-wrap decoration, but most importantly, the formatting mustn't be changed. Running po4a on this file, All the lines of the should-be verbatim paragraph should be preserved but they are concatenated without line endings:

msgid ""
"y - Vivamus fringilla mi eu lacus n - Vivamus fringilla mi eu lacus q - "
"Vivamus fringilla mi eu lacus ? - Vivamus fringilla mi eu lacus"
msgstr ""

instead of

msgid ""
"        y - Vivamus fringilla mi eu lacus\n"
"        n - Vivamus fringilla mi eu lacus\n"
"        q - Vivamus fringilla mi eu lacus\n"
"        ? - Vivamus fringilla mi eu lacus\n"
msgstr ""

[mquinson]

Ok, I think I got it. My code needs more reviews and cleanups, but I'll commit it later today.

[mquinson]

btw, there is already several literal paragraph in the list example, so I will not integrate your PR as is. But still, without your help I would never have understood the problem. Thanks for that.

[jnavila]

Thanks for digging this

[mquinson]

The proposed fix is not enough because the git dudes play a weird game here: https://github.com/git/git/blob/master/Documentation/git-add.txt#L307

[jnavila]

Should I push a change in the formatting of this text? Asciidoc and Asciidoctor seem both to handle it correctly.

[mquinson]

Nope, I just pushed a new test case for this one. Thanks.

[jnavila]

It works. Thanks!