This should be simple, and you can do it in every other app I can think of. I want to search for a return character (in the particular case, I have a long list I created in BBEdit and I want to separate the items with continuation characters.
I can use a return character in SD’s replace field, but not the find field. Instead I have to copy out of SD and in another app, and do the find and change there, then back into SD.
I agree we should be able to search for RETURN, and it looks like Chris has shown you how to do so.
However, I never use the SD Find/Replace for complicated stuff.
I always go to BBEdit, whose Find/Replace UI is great – my favorite.
And it is easy from SD6:
From SD Help:
Open the same script in an external editor and edit it there. To do so:
Choose File > Edit With XXX. A temporary text copy of the script is created, and is opened in the external editor application.
The application name (“XXX”) depends on which applications you have and which ones are running. Script Debugger will prefer a running application to one that is not running, and among running applications or non-running applications it will prefer the order BBEdit, TextWrangler, TextMate.
While the external editor is editing the script, Script Debugger’s version of the script remains open but locked. You’ll see a dialog advising you that the script is being edited elsewhere, and a “Locked” watermark at the lower right of the script window.
image
In the external editor application, save and close the document. Script Debugger automatically adopts the changes you made in the external editor.
Whenever you save the document in the external editing application, the Script Debugger copy is updated to match.
When you close the document in the external editing application, the warning dialog is removed from the Script Debugger script window (and Script Debugger comes to the front). This is the normal way in which an external editing session ends in good order.
Alternatively, you might change your mind and decide to break off the external editing session prematurely without reflecting the changes from the external editing application back into the Script Debugger document. To do so:
Switch back to Script Debugger and click Cancel in the warning dialog.
OK, guys, thanks. Yes there are workarounds and they should solve my problem, but this is a beta testing and bug reporting forum. And this seems to be an issue that should be fixed.
Searching for a return isn’t a complicated search, and it should be as easy for SD as it is for Script Editor. (This is one of the few things I still use SE for.)
If this is something that can be fixed it should, unless those workarounds should be put in the help files? (Although I doubt Mark or Matt would want to tell users to use SE or BBE to do any complicated searches.)
Script Debugger’s Find field does not accept a RETURN character because RETURN/ENTER are the default End Editing keys for OS X text fields. This allows you to initiate a search by pressing enter. If you want to explicitly search for CR or LR, use \n and \r as Chris suggests.
Further, OSX search fields don’t allow you to paste in a newline character which is frustrating. I spent some time trying to allow this, but in the end I had to give up and live with the default behaviour.
Yes, that’s the part that I find frustrating. The other thing is I can just go to TextWrangler, BBEdit or Script Editor to paste in a return and go. They have a search dialog come up, maybe that would be a good option?
and maybe the /n /r should be mentioned in the help file?
Hey guys, now that we know we can use \n and \r in the SD6 search box, is this really something that we want to worry Mark with?
How often do you really need to perform a search with RETURN? I don’t think I’ve ever had that need in SD6. If I’m dealing with EOL character, it usually means I have a more complicated Find & Replace, and therefore I go to BBEdit (or TextWrangler for those that don’t have BBEdit).
IMO, Mark has much bigger fish to fry than this minnow.
If this were a support forum or a users list I’d agree with you. But this is a beta-testing forum, where we give mark (and Chris and Shane and Matt) our feedback from our perspective as customers and users (in addition to finding bugs and testing new versions).
I don’t think the fact that we’re circulating undocumented solutions amongst ourselves or that some of us have come up with our own workarounds that involve other apps, helps Mark. We’re not here to placate ourselves. We are like a focus group representing his customer base.
I find this feature frustrating, and since Mark has talked about a SD 7 it’s definitely something I hope he would revisit. (And of course if there’s an easy SD 6 fix, I’d like to see that too, but he has investigated the issue.)
Also, I happily and gladly drop these things when Mark says enough, and he’s not shy about telling me that when needed.
And my feedback is I don’t want him to waste any more time on this very, very minor issue, that IMO, affects very few SD users. Now, If Mark were to get many complaints outside of the Beta group about this, it might change things.
Okay, I’ve got it - The existing implementation is unsatisfactory despite the workarounds. This has come up before and I’m aware of the issue. Its not something I feel I can address in an SD6 maintenance release. If there is a SD7, I’ll look into it then.