Re: Xcode's Find in Project
Re: Xcode's Find in Project
- Subject: Re: Xcode's Find in Project
- From: Laurence Harris <email@hidden>
- Date: Mon, 19 Feb 2007 13:50:07 -0500
On Feb 19, 2007, at 11:26 AM, John Daniel wrote:
On Feb 18, 2007, at 10:10 PM, Laurence Harris wrote:
Then I think you're just lost. LOL I know a lot of people who hate
Xcode's Find in Project window.
I think if any of us cared that much about what other people though
we'd all be using Windows and Visual Studio :)
Why? I don't know anyone who uses Windows because he cares what
people think. ;-) OTOH, I know lots of people who only use Windows
because they have to or they've never used a Mac.
- It doesn't have an option to put the results of searches in
their own windows. This becomes a real pain when I want to work
with the results of multiple -- but related -- searches at once.
The current implementation makes about as much sense to me as only
being able to view the contents of one source file at a time. I
know I can use the drop down history to switch back to the results
of other searches, but that list only contains the text for which
you searched. If you searched for a term once in your headers and
another time in your source, there's no way to distinguish the two
in that list. This is a serious shortcoming in the Find in Project
window.
- There's no simple way to just search a folder. To do that you
have to open the Options dialog and use or create a find set.
- In general the whole business of having to use a second dialog
to set up searches is klunky. Maybe you're used to klunky, but
I've been using Macs for a long time and I'm used to more elegant
ways of doing things. Many of the options in the Options dialog
should be in the main Find in Project window so that a) I don't
have to open a separate dialog to use them, and b) using an option
one time doesn't require the use of a find set. Sure, I could
create a whole slew of find sets to cover everything I might want
to do, but the more of them I have the harder it is for me to
remember what each one does unless -- you guessed it -- I open
that second stupid dialog and look.
I really don't get it. You think Xcode is clunky and prefer
CodeWarrior's find? I never used the MacOS X versions CodeWarrior
so I don't know if they improved it. But the Classic versions of
CodeWarrior had a truly awful Find feature. I remember there were
several clicks and selections you had to use.
Sometimes, depending on what you want to do. I rarely had to use
*several* clicks.
If you wanted to search headers at all, you had to manually choose
them.
And clicking a checkbox is worse than clicking a button to open a
second window, use that to configure the search to find headers, and
then switch back to the main Find window? Any mechanism is going to
involve some interaction from the user to specify search criteria. I
don't see having to use a separate dialog as being less work or more
intuitive than clicking a checkbox or two in the main window.
- There's no Replace All option. You have to do a search first,
then do a replace on the results. I've never seen a text search
window in any other application, be it CodeWarrior, Word, BBEdit,
whatever, that didn't have an option to just replace all
occurrences directly, without having to do a search for all
occurrences first. Even Xcode's Single File Find window has a
Replace All button. Certainly there are times when the Xcode way
is handy, but the normal approach also has value and when that's
what I want to do, the Xcode way feels awkward.
I like the Xcode way. If you make a mistake in Single File Find,
you can just undo. What happens if you do that in Find in Project?
For multiple files, I like the (one) extra step.
CW used to open each file in which the changes were applied and make
the changes without saving the file. If it's a change that could be
made in a hundreds of locations I found it easier and way faster to
watch them being made to ensure the results were what I expected than
scrolling through a long list, selecting each occurrence, and
figuring out the effect of the change. More than once I saw a change
I'd requested changing things I hadn't anticipated. Within seconds I
canceled the process and closed the windows without saving the
changes. Much faster and simpler than manually examining each of a
hundred or two hundred locations where something was found to ensure
the change I'm about to request will have the desired result. It was
very nice to be able to view the changes after they were made before
saving them. As I understand it, Xcode won't let you do that.
- There's no way as far as I can tell to find the first occurrence
in a multi-file search. In CW you could find the first, do
whatever editing you wanted to do, and then find the next
occurrence whether in that file or another. That came in handy
sometimes and I miss it. CW had Find and Find All buttons.
Didn't CW open up every file with a find result in a new window?
In that mode, yes, it opened the file in its own window if it wasn't
already open.
I seem to remember having to type Apple-S, Apple-W 27 times in a row.
Actually, we say Command-S and Command-W. Windows users say Apple-S
and Apple-W. ;-)
That said, no, you didn't have to use those commands 27 times.
Command-Option-S would save all of them at once, and Command-Option-W
would close all of them. Xcode supports closing all if you Option-
click the close button, but alas the menus don't support the standard
Save All and Close All commands (go figure -- another useful standard
Mac behavior not seen in Xcode). If you use SubEthaEdit you'll see
that the Save and Close Window commands change to Save All and Close
All Windows when the Option key is pressed.
Maybe there was a close all.
Yep.
I don't remember for sure. I really haven't used CW much in 5 years
or so. I definitely remember that Find and Replace was the one
thing I didn't like about CW. I also know it is one of my favorite
features of Xcode.
I think your complaints are more nits than serious shortcomings.
Don't you think it's a bit pretentious to pass this kind of judgement
on someone else's work style?
Does the Find in Project feature actually get in your way every day?
Oh, absolutely. The lack of separate windows to hold the results of
separate searches is a major inconvenience at times.
And is there no acceptable workaround?
No. There's a workaround, which is to continually use the combo box
to switch between search results in the Find window, but that's a
hassle and prevents me from comparing two sections of code by looking
at both at the same time. Wouldn't you consider it a significant
limitation if you could only view the contents of one source file at
a time? If that's the ideal way to present information, why don't we
just go back to using the whole screen and bag this whole "window"
thing?
That is my criteria for "serious shortcoming".
Then it's a serious shortcoming.
There are very few parts of Xcode that get in my way on a regular
basis. The only thing that really comes close is the debugger, and
that is just GDB. There isn't much Apple can do with that.
I respect that it works well for you, and I'm sure for others too.
You in turn should understand and respect that it doesn't work well
for a lot of other people instead of telling people who don't work
the way you do that they're nitpicking. I see this as a big part of
the problem. The people with a Unix background love all these Unixy
tools and think anyone who doesn't is just a whiner or doesn't
deserve to be called a serious programmer instead of recognizing and
respecting that different people just work and think differently.
That doesn't make either group inferior or less deserving of tools
that work well for them. That's why options are good. Unfortunately,
with the demise of CW a major option was taken off the table. If
something in Xcode is a good match for the way you work, you're in
luck. If it isn't, you're screwed. Some people prefer vehicles that
allow them to sit high off the road so they can see more. Others
prefer vehicles that put them closer to the ground because they
they're concerned about rollovers and prefer the handling of cars
lower to the ground. Now, if we could just determine which of these
groups are the nitpickers we could eliminate a whole class of
vehicles. ;-)
FWIW, I hear a significant number of Apple's own engineers use BBEdit
for searches because even they prefer it to Xcode's Find in Project.
I can't verify that, but it comes from someone inside Apple whom I
believe I can trust.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden