CreativePro Forum

Return to Member Forum

• Author
  Posts
• • April 21, 2011 at 8:29 pm #59377
    Lala Lala

    Participant

    So just for educational purposes, I wanted to make a grep query that checks for screwups in a CSS stylesheet. CSS follows a simple rigid format that should be ripe for GREPing but I flat-out can't make it work. I don't know if it's a badly formed grep query or an indesign problem. Ideally it would look for instances where the coder forgot a closing curly brace. For example:

    p { color: #000; }

    em { color: #555;

    a { color: #f00; }

    I figure, let's start simple and just try to style everything between two open curly braces (even the code that has its matching closing brace). That would be… Lookbehind for the { character. Lookahead for another { character. Style anything (spaces, line breaks, any character) in between these two characters. Shortest match.

    I can't get the shortest match to work. Here's the expression without the shortest match, it successfully styles everything up to the very last {

    (?<={)(n.*)+(?={)

    So how do I shortest-match this? I won't drag it out with examples of what didn't work. Can someone show me what does work?

  • April 21, 2011 at 8:33 pm #59378
    Lala Lala

    Participant

    sigh. forum that can't format grep queries even if you surround them in

    tags, and won't let you edit posts. There's a backslash before the n. So (backslashn.*) describes a full line that has 0 or more characters in it.

  • April 22, 2011 at 1:50 am #59380
    Rhiannon Miller

    Member

    According to the above, you're looking for a (forced line break followed by some other stuff) immediately after an open brace. Which wouldn't match the example you give, but would probably work given a stylesheet with the right sort of formatting, for example:

    p {

    color: #000;

    }

    em {

    color: #555;

    a {

    color: #f00;

    }

    So I'm going to assume that's what you meant to do. In my experiments, using the above example rather than the one you gave, I found that both 'shortest' and 'longest' searches matched the same text.

    However, it might not be the best idea to specify the forced line break at the start – you might not always have the contents of the braces on a separate line. Perhaps it would be better to find 'some stuff that might include one or more line breaks'? If so, you'd be better off with something like:

    (?>={)([rn]|.)+(?={)

    Now this one does work with a 'shortest' match:

    (?>={)([rn]|.)+(?={)

    But of course, what you're actually wanting to pick up is unmatched braces. So what you need to do is specify that you want to find stuff between an opening and an opening brace that doesn't contain a closing brace. How about something like this?

    (?<={)([rn]|[^}])+?(?={)

    Let us know how you get on!

  • April 22, 2011 at 1:53 am #59381
    Theunis De Jong

    Member

    There is an Edit button for when you post-and-reread — it looks like a lil' pencil icon. Oh — and the secret for is to double them: \ (and to type that, I actually had to enter “\” !)

    Now on to your GREP: because of the missing backslashes it's kinda hard to see what you tried. First off, the curly braces are special characters in GREP, so you have to escape them. In case you did: the error probably lies in that 'n' in the middle of your GREP (assuming it was actually an 'n' ). GREP styles usually don't work at all with multi-line stuff, but I must admit you seem to have found a workaround: they do work with shift+returns. Well, perhaps that's because a shift+return doesn't count as a paragraph break (triple clicking it will select the entire paragraph, shift+returns and all). But it does force you to exclusively use shift+returns in your CSS!

    A short word on “shortest match”: usually, +, * and ? use the longest possible match. Following this character with a “?” will make it force to use shortest instead. Without your examples of the stuff that didn't work, I can't comment on why they didn't work

    I think this comes closest to what you want:

    (?<={)[^}]+(?![^{]*})

    It did give me a spot of a head-ache so I'll leave it as an exercise to the reader to find out how it works.

    (Edit — a reply to a message after this original post!)

    And as far as I can see, you can only edit your post until another post has been added after it. Once there's another post – yours or someone else's – the edit facility disappears.

    No it doesn't. (Although I must admit I've seen this happen as well. Dunno what the exact parameters are…)

    (Edit/Edit) Oh nooo! I forgot to reinstate all double/triple/quadruple backslashes after editing!

  • April 22, 2011 at 1:57 am #59382
    Rhiannon Miller

    Member

    Dammit! I edited my post twice, once to put in the double slashes, and then again to remove some bold and italic formatting that had put itself round my grep searches. And the second edit removed my double slashes. And now it won't let me edit it again (pencil icon has disappeared).

    This is what I was trying to say in my last search:

    (?<=//{)([//r//n]|[^//}])+?(?=//{)

    Can't we have a better post formatting engine that can cope with this syntax, since it comes up so often?

  • April 22, 2011 at 1:58 am #59383
    Rhiannon Miller

    Member

    What the hell?! That one's brought my double-slashes through as written! What's going on?

  • April 22, 2011 at 2:02 am #59384
    Rhiannon Miller

    Member

    Here, again, is what I was trying to say:

    (?<={)([rn]|[^}])+?(?={)

    And as far as I can see, you can only edit your post until another post has been added after it. Once there's another post – yours or someone else's – the edit facility disappears.

  • April 22, 2011 at 2:07 am #59385
    Rhiannon Miller

    Member

    And now I've just got round to reading Jongware's post. GREP searches do work with returns and shift-returns, but not if you try to use them as part of a character range, which is why I separated them out into their own half of an or declaration.

    (And yes, I've now figured out that I used forward-slashes instead of backslashes, which is why they came through doubled.)

  • April 22, 2011 at 2:41 am #59386
    Theunis De Jong

    Member

    GREP searches do work with returns and shift-returns, but not if you try to use them as part of a character range, which is why I separated them out into their own half of an or declaration.

    I think using either the single-line or the multi-line modifier can fix this (one of them makes the period match paragraph breaks as well). Somewhere along the line I got the idea CreeDo intended to use this as a GREP style, hence my warning about it not working cross-multi-paragraph-y. But for plain searching it'd do nicely.

    It's funny you got almost exactly what I got. Well, plus some returns and minus the backslashes :D

  • April 22, 2011 at 8:05 am #59387
    Lala Lala

    Participant

    Thanks grep experts for the ideas so far. My original post wasn't super clear, but yes, I'm trying to apply a grep style (not a search and replace, though that would be pretty sporty… why highlight the problem when you can run a replace that automatically fixes it?)

    I do also make css the way oriel describes, with breaks, and yeah, I use shift+enter breaks so grep doesn't hate it. However even then there's frustration… grep's period does not match the shift+enter “character” (if that's what it is)… so I have to hold its hand and put in something like (n)? in every place where I think one might appear. And then there might be more than one. And then there might tab or white space or characters before or after it. I also just figured out that while some grep styles apply dynamically as your text changes, this is one where you must manually apply the paragraph style after, say, deleting a brace, or it doesn't show up.

    Jong's final version worked best, and seems to handle manual line breaks wherever I put them. It also handled whitespace and random text between the opening braces. Seems like we have a winner. Oriel, I can see how yours works but it didn't work with my css. I think it's less “bulletproof” than jong's. Jong's I'm still parsing… lookahead for the opening curly brace, then… match anything in the [] character set, that is not a single closing brace? one or more times. Then …negative lookahead and match if there is …NOT NOT an opening brace? haha. I can't understand it much less describe it. Followed by match if } is NOT there.

    edit: thanks for the tip about the pencil. Doh.

• Author
  Posts