How to combine shortest match with location, using GREP styles?

[SilvioGabriel]

HI

This question is probably easy for those more experienced, but I'm having problem to make it work. I want to apply a GREP style to some text between parentheses, but not to all of them, only in a certain location (in my case, just when the parentheses are at the end of the paragraph).

I started with this, and it worked well, selecting all texts between parentheses:

Then, I thought that inserting a $ at the end of my expression, it would  select just the cases when the parentheses ocurred at the end of the paragraph. But it didn't work, and the selection came back to the "greedy" mode, as seen in the picture:

It worked in the second paragraph, in which we have just on occasion of parentheses, and they are at the end. But in the first paragraph, I want the GREP to be applied just  in (nsdvnsvk). How can I have the expected result?

Thanks,

[Peter Kahrel]

\(.+?\)$

should do it.

P.

[SilvioGabriel]

Hi Peter

Have you tested it? Because that's exactly what I did, but for me it doesn't work. It applies from the first opening parentheses in the paragraph to the last closing parentheses right before the end of the paragraph, instead of appplying just to the shortest match before the end of the paragraph…

[Peter Kahrel · Accepted solution]

Ah, yes, that one. I described it even in the PDF, p. 53:

\([^)]+\)$

\(      match an opening parenthesis

[^)]+   continue matching while not a closing parenthesis

\)       then match that parenthesis . . .

$       . . . at the end of the paragraph.

Peter

[SilvioGabriel]

Thank you very much! That's it, now it worked perfectly!

By the way, what PDF are you talking about?

[Peter Kahrel]

> By the way, what PDF are you talking about?

This one: GREP in InDesign - O'Reilly Media

P.

[SilvioGabriel]

Thanks!

[Obi-wan Kenobi]

Hi,

I've detected a problem on all our proposals!

This case doesn't work correctly:

It's not taken in account by  (?>\(.+?\))$  [normal!] but this code has another default (too greedy!).

… there's another approach! It will need 2 codes:

1/  \(([^()]|(?R))*\)  with a grep style associated to a "X" cur style. I use this code to validate ( ), [ ], " " constructions that by default work per pairs.

2/ A really simple find/replace  .+$  based on this "X" char style.

(^/) 

[Obi-wan Kenobi]

Hi Peter,

(?>\(.+?\))$

(^/) 

[Obi-wan Kenobi]

Hi Uwe,

(?-s)(.+)?\K\(.+\)$

(^/) 

[Peter Kahrel]

Not sure how (?>\(.+?\))$ works, Michel. Could you elaborate?

[Obi-wan Kenobi]

Peter,

(?> …) is called "atomic group". It's a indivisible entity!

It is totally relevant here. It means here "the shortest occurrence from the para end"!  Cool!

When you gave your first answer, I've validated it too because it seems to us as an evidence!

… But, as the target is the end of the para, I forgot it and we're wrong: the first ( found is not the first one from the end of the para! 

Your 2nd code is totally relevant! … but I like this new code! 

(^/)

[Peter Kahrel]

Interesting. Didn't know about atomic groups.

[Obi-wan Kenobi]

I've tested our 4 grep codes! … with grep styles, grep find/replace … and ID version (mine is from Tatooine, in a galaxy far, far away!).

… The results are … very astonishing!

Don't forget, I use ID CC 2015 (from Tatooine)

Grep Styles:

Peter's code:  \([^(]+\)$ seems better!

Uwe's code: nothing catched! [I've already discussed about this point with Jean-Claude Tremblay who had no problem and seems to use a similar version as Uwe's one!]

Ben's code 1:

Ben's code 2:

Find/Replace: I've used different color conditions for the 4 codes

Temporary conclusion:

It seems that, with my ID version, the more relevant code, working in the same way with grep style and find/replace, is:

(?>\(.+?\))$

+ a gift: it avoids a "catch" error!

Catching:

(rectibus maxim vernam exere atia (velliquodis nis reiur?))

… it takes the good parentheses!

May The Force Be With You!

(^/) 

[Laubender]

Obi-wan Kenobi wrote:

Hi Peter,

(?>\(.+?\))$

(^/)

Cool!

Here my test with your "atomic group" at the end of a paragraph (or before a line separator sign) and is working as expected:

Regards,
Uwe

[Jongware]

pkahrel wrote:

Ah, yes, that one.

Am I missing something, or should Silvio's attempt actually have worked? Because I've been scratchin' my head over it and from the looks of it, it ought to work.

[Peter Kahrel]

It's the $ that throws a spanner in the wheels, I fell for it (again). Without it, \(.+?\) matches every shortest parenthetical. But with the $, the expression tries to match from the first opening parenthesis to the first closing parenthesis that's at the end of the paragraph.

[Jean-Claude Tremblay]

Nice use of the Atomic Group Michel! It make my head spin «explode», so I’m more pacific and use one of these three queries that will also works.

\([^(]+?\)(?=$)

\([^(]+?\)(?=[\r\n])

\([^(]+?\)(?=\p{Cc})

or this one too in CS6 only:

^.+\K\(.+?\)(?=\p{Cc})

^.+\K\(.+?\)(?=[\r\n])

^.+\K\(.+?\)(?=$)

or removing the ^ like this in CS6 and above:

.+\K\(.+?\)(?=\p{Cc})

.+\K\(.+?\)(?=[\r\n])

.+\K\(.+?\)(?=$)

PS: In CC, a bug seems to have been introduced that make regex with the ^ to fail after the first line break.

[Peter Kahrel]

Jean-Claude,

The lookahead in \([^(]+?\)(?=$) is not necessary because $, the paragraph end, is a position, not a character. And $ works before \n as well, so \([^(]+?\)$ works for both \([^(]+?\)(?=$) and \([^(]+?\)(?=[\r\n])

The last one doesn't work for paragraphs at story/cell end which that don't terminate in a paragraph return, so \([^(]+?\)$ is really the better one.

Peter

[Jean-Claude Tremblay]

You’re right Peter, thanks.

And thanks Jongware. Now can someone explain me realllllly slowly how Atomic Group is working?

[Jongware]

pkahrel wrote:

... with the $, the expression tries to match from the first opening parenthesis to the first closing parenthesis that's at the end of the paragraph.

After someone explained it real slow to me, I finally got it.

Why this happens is that it is not only the shortest match (in fact, the question mark in the ".+?" part is a red herring), but it is the only possible match! The regex always starts at the beginning of the paragraph, and there is only one opening parenthesis which ends with the combination ")$".

Sure, there is another opening parenthesis inside that line – but a regex match always starts at the beginning (!!) and so that one is never considered and it gets silently eaten by the ".+". Since the start condition "(" already has been matched, there is no reason to check for it again.

[Laubender]

Hi Silvio,

could you test the one below for InDesign CS6 ( and versions above)?

^(.+)?\K\(.+?\)(?=\r)

\K is a "postive look behind" with the ability to catch strings of different length.

Regards,
Uwe

[SilvioGabriel]

Hi Uwe

It worked partially. It worked just if it appears in the first parapraph of the story. If there's more than one occurrence (or even if there's just one, but not in the first paragraph), it doesn't work…

[Laubender]

SilvioGabriel wrote:

Hi Uwe

It worked partially. It worked just if it appears in the first parapraph of the story. If there's more than one occurrence (or even if there's just one, but not in the first paragraph), it doesn't work…

Hi Silvio,

interesting…

I tested with CS6 v8.1.0 on OSX 10.7.5 and it seemed to work on my side.

The whole story is formatted with "ParaStyle-1":

What is your version of InDesign on what OS?

Regards,
Uwe

[SilvioGabriel]

Hi

I'm working with Indesign CC 2017.0 Release, 12.0.0.81 x64, Windows 7 Enterprise.