Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible to duplicate "Find Fix" functionality for "Project" search pane? #10

Open
mralexgray opened this issue Nov 10, 2012 · 4 comments

Comments

@mralexgray
Copy link
Contributor

No description provided.

@davekeck
Copy link
Owner

This is certainly possible (and I would definitely find it useful!), but I have yet to attempt implementing it. (If you care to take a crack at it, I would reverse-engineer Xcode and find a reference to the pop-up menu that switches between Find/Replace modes, and emulate a click on "Replace" whenever the Search Navigator is activated.) I was planning on implementing this eventually...

@tom-seddon
Copy link
Collaborator

Xcode 4.5.2 (on my Mac at least) remembers the search navigator 'show find options' settings between runs, and also whether you were using the Replace mode or not. So each time I bring it up, it's already in replace mode, and has the options visible. Could this be something that the save state data plugin inhibits? I don't use that plugin...

--Tom

@mralexgray
Copy link
Contributor Author

I have all "State Saving" disabled... by locking the folder in ~/Library... This hasn't affected usability (besides making Xcode WAY faster).... i guess.. until now. I had just sort of assumed that the project search area was as equally as clueless as the single-page was - in terms of inferring your purpose for visiting it... maybe.. I'll turn state saving back on for a while to confirm that 4.5.2 is indeed exhibiting the "correct" state retention for search, find, replace scopes, blah blah blah.

btw.. i did look at how the other "fix-ins" were done... and i see how youre doing it... but besides a class-dump.. how are you ascertaining the exact needed calls and signatures that xCode is expecting from its preference parsing routines. it's all suprisingly readable and matter-of-fact... but it's either a: shocking that all Objective C code (even apple's) can this easily be mercilessly introspected to the point of being violated, or b: that xcode is just such a cumbersome vestige that XPC security is the least of their concerns... anyways...

@davekeck
Copy link
Owner

Tom: I completely overlooked that, that behavior happens in Xcode 4.5 too.

Alex: gdb and class-dump are the main tools I use to reverse engineer Xcode. otool, nm, and vmmap have also been of use.

Regarding your security concerns: Objective-C is a dynamic language by design and supporting ObjC's many features requires metadata about classes and their methods, so it shouldn't be too shocking that that data can be read. (What's somewhat shocking to me is that Xcode has a plugin architecture that's happy to load unsigned, 3rd party plugins. Great for us, but certainly surprising given Apple's current heading...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants