Back

If your email is not recognized and you believe it should be, please contact us.

  • You must be logged in to reply to this topic.Login

Different results from GREP find/change, and the FindChangeByList script

Return to Member Forum

  • Author
    Posts
    • #75762
      Chris Court
      Member

      Sometimes our writers put a bunch of extra returns at the end of their stories. Why? I have no idea. But it causes issues on occasion – for example indicating overset copy when there is none – so I’d like to get rid of them and have the story end immediately after the final period.

      So, in the Find/Change dialog, I enter the following into the GREP Find What field:

      \r+\z

      I leave the Change To field empty, hit the Change All button and voila, all the extra returns disappear, the final period is followed directly by the end of story marker, and all is good in the world.

      HOWEVER. To keep things streamlined, I would like to add this to my customised FindChangeByList script.

      So I add the following line to the FindChangeList.txt file:

      grep {findWhat:”\r+\z”} {changeTo:””}

      And it gets rid of all the returns EXCEPT FOR ONE.

      I can’t for the life of me imagine why? Surely these two actions should give the same result?

      I also tried \r+(?=\z) which gives the same result.

      Any ideas, brainiacs?

      Chris

    • #75764

      Hm hah. I thought I got it but maybe I don’t. Still, worth a try. (Indulge me. All will be clear, even why I possibly don’t get it.)

      The texts in the FindChangeList.txt file are not ‘normal’ text; they do not get copied literally into the GREP find & change fields. It’s more complicated than that: the entire file is loaded into Javascript, as a single large Javascript object, before processed and fed one by one into the Find and Change dialog – and so, Javascript’s Text Rules are applied to this file.

      There are lots of rules, most of them logical (“all of the text strings must start and end with a double quote” is one, and so is “there may not be a loose ” inside a text string”), but one rule in particular remains sneaky and elusive, as often as it does get mentioned:

      ALL BACKSLASHES ARE PROCESSED IMMEDIATELY BY JAVASCRIPT.

      yes, i used full caps for that. sorry. to make up for it, i typed this sentence all lowercase.

      This statement means that an entry such as ‘\r’ is not “copied” straight into the GREP field; the CODE for a Hard Return is. That is not something you can do in the user interface – pressing the “Return” key will not insert a return. Fortunately, it does not matter whether GREP receives the code for a hard return or the two characters ‘\’ and ‘r’; the latter is a Known Code (for GREP) and so it converts it to Code For A Hard Return. No big deal.

      BUT since ALL BACKSLASHES (etc.), this not only means that ‘\r’ gets fed into GREP as a literal hard return (because Javascript processes the text), but the same goes for the ‘\z’. And what does Javascript translates ‘\z’ in? Um – it is not one of the (very few!) backslash escape codes that it knows, so it throws away the backslash and only the ‘z’ remains. The text that is sent to GREP is then “[Code For A Literal Hard Return]+z”, which is Not What You Meant.

      The trick is to DOUBLE UP BACKSLASHES. A Double Backslash is a known escape code for Javascript, and it means “please insert a Single backslash here”. A text “r+z” gets read by Javascript and then passed on as “\r+\z” into GREP, exactly the way you want it to.

      So why am I unsure? Well: “… it gets rid of all the returns EXCEPT FOR ONE.” According to my little story above, it should not have worked at all (unless you happened to have a single ‘z’ at the very end of your story).

      But don’t despair. Doubling-up the backslashes will remove all uncertainties, and it ought to make all of your GREP codes do what you meant by design, rather by accident.

    • #75766

      Chris,

      Have you got any other find string after this one?

      One of the examples in the FindChangeList.txt file gives your result:
      {find what:”\r\r+”} {change to:”\r”}

      Backslash in \r does not need to be escaped (as well as ), as Jongware said, but in \z does. So \r+z should also work.

    • #75770
      Chris Court
      Member

      Thanks for your help, amigos,

      As you guessed, Carles, yes, I still have the remove double return line in there…

      Duh!

      Thanks again!
      Chris

Viewing 3 reply threads
  • The forum ‘General InDesign Topics (CLOSED)’ is closed to new topics and replies.
Forum Ads