wrong translation of index terms inside parenthesis in DocBook backend

[shahryareiv]

This:

(something ((some indexterm)))

translates to:

(something <indexterm><primary>some indexterm)</primary></indexterm>some indexterm)

please note the extra ) in the index term.

[mojavelinux]

This bug is present in AsciiDoc Python too, so it looks like we inherited it.

The workaround is to insert a zero-width space before the last ), though I recognize that is not ideal.

(something ((some indexterm)){zwsp})

[mojavelinux]

In this case, I'd probably recommend the use of the indexterm2 inline macro.

(something indexterm2:[some indexterm])

When using the parenthetical form, it can be hard to determine the boundaries when adjacent to a parenthesis in the content. I'll see if I can find a way, but we'll have to see.

[shahryareiv]

Thanks! I can see it is now scheduled for v1.5.5 so waiting is probably the best strategy for most of us.

[mojavelinux]

I was able to work out how to solve this. We just needed to check more carefully about which surrounding brackets were captured.

[ecki]

I think this is not entirely fixed, when I have the following doc

= Test
Author
Version
:doctype: book

== chapter 1
test (((Index1)) is not hidden) but ((((Index2)))Index 2 is)

[index]
== Index

the followng result can be seen in the PDF:

chapter 1
test (Index1 is not hidden) but Index 2 is)
Index
@
(Index2, 1
I
Index1, 1

Instead of "test (Index1 is not hidden) but (Index 2 is)" with "Index2, 1"

I see this with asciidoctor.maven.plugin.version 1.5.5, asciidoctorj.version 1.5.6 and <asciidoctorj.pdf.version 1.5.0-alpha.15 on java 8u141 with jruby 9.1.8.0 on Win10 with Maven 3.5.0

[mojavelinux]

I should be clear. There are going to be exceptions. The round bracket form a convenient short-hand. The regular-expression based parser simply doesn't have enough context to sort out what is content and what is markup when the content contains lots of round brackets. We shoot for making the most common cases work. Fo all others, I highly recommend the more definitive indexterm/indexterm2 macro.

[ecki]

I understand it is not always possible, one improvement would be to not count ( or ) to the indexterm ever (unless inside quotes) can't imagine a situation where this would be desired

[mojavelinux]

This may be covered in part by #2363.

Beyond that, we can't do anything until we fix #61. We have no way to look backwards or forwards in the string or to keep context. All we can do is try to make sense of what was matched...and we already do the checking we can do (when you add #2363).