another thing the Jetbrains IDEs get right. They fail in their selection of shortcuts (Cmd-G which is "Search again" in every other Mac app) for it though, but that's easily remedied.
I totally agree with the article by the way. Selecting the line is idiotic. While programming, you never ever want it to select the whole line - in fact, I don't think I have in fact ever selected a line at all.
Your cursor is at line 200. You read through your email and want to make a change in a certain paragraph. That happens to be at line 180. So you "Go to..." 180.
Interesting.. I've never used "Go to line" in that way, probably because my text editor never has line numbers showing. For me it is always to jump to the point of an exception or somesuch.. maybe I'll try it for a while.
PS. I use Emacs for virtually everything so C-N, C-P and M-N, M-P get used for that kind of navigation.
I use MacVim. When you want to edit or add some code, isn't it more common to want to do it at a particular spot rather than reacting to a exception/warning?
That's how I do it anyway. The only reasons I can come up with off the top of my head to do otherwise is if someone is doing heavy TDD or banging code into a Smalltalk debugger instead of a browser.
How do you do it? (Genuine question. I almost always code by myself and have never been around anyone while they are productively working with an editor.)
I've actually never met a developer that navigates a file using line numbers. Maybe it is the norm but I haven't seen it having worked with a few dozen developers over the years.
Getting quick at line up/line down (C-N, C-P) and page up/page down (M-P, M-V in Emacs) seems to be a more common way of navigation. (C-S for quick search in Emacs being the other)
I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error. (TDD or not, stack traces are a way of life)
> I've actually never met a developer that navigates a file using line numbers. Maybe it is the norm but I haven't seen it having worked with a few dozen developers over the years.
> I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error.
yes that's pretty much it: use external tool to find some row (diff tells you this is where a chunk was changed, grep or ack tells you what you're looking for is there, ...), jump straight to row.
Although usually I'll open the file directly at the right line in emacs (`e +line file`[0]), goto-line is only for the IDE.
Looks like Sublime Text 2 meets his requirements. Goto Line is simply Ctrl-G, and up pops a simple input line, similar to hitting ":" in vim.
As an added bonus, the input line disappears if you press Ctrl-G again, hit <esc>, or press enter without entering anything. So, fast and easy to get into, fast and easy to get out of.
On the Mac, I no longer think about this level of workflow optimization because there's a much bigger negative that make these irrelevant: the Mac's Alt-Tab behavior.
The most basic web page development exercise - 1 browser window and 2 editor windows for html and css - is ruined because I can no longer MRU cycle the 3 windows.
I would say this is one of the biggest usability mistakes on the Mac. Sadly, Unity & Gnome 3 have both copied this. Meanwhile, I don't fight the platform but use it the way it was meant to be - keyboard + mouse. But I'll be shifting back to Linux or Windows for all non Mac/iOS development.
Update: thanks to comments pointing me to Witch. However, I still stand by my criticism of the built-in Mac desktop behavior.
Thanks - trying it now! The MRU behavior is spot on, including across Spaces!
I'm finding the list style still has high mental overhead compared to the Windows/Linux style of bringing the target window (or it's outline) transiently forward.
Still, looks like it's 80/20 enough that I'll be parting with $14 soon!
I have it bound to alt+tab. Super customizable, I have things like ignore all minimized applications, only windows in this space and ignore any window from adium.
Lets me easily switch between terminals, vim windows and browsers that are on the same space. Highly recommend.
Just the usual offenders, esp. MS Word and Adobe apps. They love to generate false "windows" like that goddamn "smart copy" doo-dad and palettes, etc. Witch allows you to work around all of it, if you're patient.
Yup this alt+tab switching behavior change is a real pain for me.I was under the impression that this is an issue only with Unity/Gnome3, now I got to know the actual place from where it all started. After seeing this change consistently across all the major UIs, I am starting to feel that this change in alt+tab behavior should have some strong reason for doing so and I am not aware of its actual purpose/use. I would be glad to know from someone on how this feature has simplified their work or improved their productivity.
I'm finding it a bit painful on Unity now too, but I'm wondering whether the problem is actually with the terminal programs rather than with the alt-tab behaviour. Most of the time I actually do want to treat all the windows of a single application as a group. But terminal sessions seem different to me - two terminal windows are not related closely to each other just because they are managed by the same application. Perhaps I need to find the setting that stops terminal windows from being grouped together...
I'm guessing the justification is that switching apps is consistent with the fact that the OS X Dock shows apps, not windows. Probably Unity & Gnome 3 made the alt-tab change to match their move to the Dock model?
Whatever the reason, they're wrong for us power users. And possibly for intermediate & beginners users as well.
I prefer the Mac way. I'm stuck using Windows at work, and it's annoying to have to Alt-Tab through the last five Excel (or mail or whatever) documents to get back to the editor. I much prefer to be able to go the application I want, then find the document within it that I'm looking for.
Then again, I'm not doing web development, so I'm not trying to cycle between my editor and one particular browser window.
I don't think it's a power-user vs. beginner issue; it's more of a workflow style issue.
It's not really personal preference if that's what you mean. It's about your work splits across apps & windows.
For example, chat is mostly fine. I'm either switching between multiple chat windows or mentally switching from chat to another task in which case I have no problem switching out of the whole chat app.
The same setup goes wrong when one chat window is for work, and I'm going back and forth with another non-chat work window.
No, I'm not saying it's preference. I think we agree, actually. By "workflow", I meant the way your particular work tends to split across apps and windows.
For me, it's a better default to switch entire applications than windows. There are edge cases, sure, like the chat one you mention, or different browser windows, but I'd rather just switch from Excel to IE to Outlook than have to tab through my history of open documents and browser tabs (curse you IE) to get back to my Outlook window.
It sounds like for you, it's the opposite: the better default would be to switch windows, not apps.
The question then is which is the most common pattern, but I don't know of any actual research on this. You can't generalize from personal experience, plural of anecdote and all that.
It's obviously nowhere near as full-featured as vim or emacs proper when it comes to navigation, but worth noting is that OS X does support a subset of the standard emacs key bindings for text navigation (Ctrl+a, Ctrl+e, etc). They even work in iOS with an external keyboard.
Another thing that drives me crazy on Mac text editors: selecting something and hitting Cmd-F won't use the selected text for the search. (at least on Xcode, Sublime Text, and Google Chrome).
So I have to constantly do the sequence: swear out loud - press escape - Cmd-C - Cmd-F again - Cmd-V.
Most Mac OS X apps (including the ones in your list) allow you to press Cmd-E - Cmd-F to search for the currently highlighted word. Even better: once you have pressed Cmd-E you can hit Cmd-G to cycle through the results.
With all due respect, what is just dumb is not reading the manual of the powertools you use every day and blaming them for your lazyness.
You don't have to read the manual to perform the most common tasks. But if you want to perform more advanced/specific tasks, reading the manual is necessary.
Cmd-F searching for the highlighted text involves one key-press. What you describe requires two key-presses.
The former is quicker and easier, and I think that makes it preferable.
Pretty much everything to do with computers, from Operating System features, to program and UI features, are ultimately about making it quicker and easier to perform tasks.
Wanting more convenience is not laziness. The goal of computer systems should be to provide more convenience.
I agree that one of the goals of software is to make performing common tasks quicker and easier.
However, binding two different actions to one trigger is pushing the logic too far.
It could happen that I have some text selected and I want to search for something within that text, or that I've selected something by mistake and I want to search something else… In that kind of situation having the search field populated by the content of the selection by default would obviously lead to a less than ideal experience.
I believe the people behind these choices actually ran extensive usability tests and decided to compromise on what they found to be the most common use case: poping a search window and inputing the search term.
I agree this system is maybe a little dumb but I think that is what makes it robust and dependable. Which is in my opinion the single more important attribute of any system.
I don't think the parent wanting more convenience is lazy. But I think that not reading the manual and complaining about the absence of an obviously present feature is proof of lazyness. That's very different and so very common. And I wasn't mocking him, just improvising a pun based on his last line.
My point was: the parent wants a different behaviour for Cmd-F but it turns out the different behaviour he asks for is already provided by another shortcut.
Yours is: it sucks and these different behaviours should be triggered by the same shortcut for the sake of "quicker and easier".
I think that such a move would actually go the opposite of "quicker and easier".
The most basic case for which the "Find" feature provided by Mac OS X is this: you need to locate a word in some text. This can happen if you want to jump quickly to a specific paragraph or if you want to read the definition of a word or the address of a person or if you want to bypass the LOC… Cmd-F is the way to go: it pops up a window with a textfield and a "Find" button. Exactly what you need to achieve your goal.
The case addressed by the Cmd-E Cmd-F combo has different predicate: you already have the word highlighted and you want to jump to another instance of the same word in the document. This may happen in fewer situations than the above case. In such a situation, comparatively rare, I believe, Mac OS X provides another shortcut.
Different actions -> different triggers.
-
I expect of course any software to go as far as possible on the road to "quicker and easier" but such a goal shouldn't impede clarity, simplicity and robustness. Making all of these requirements work together is what makes good software.
You (and others) prefer Cmd-E Cmd-F? Fine, I'm happy with that.
For your needs, that is quicker and easier.
But for other people's needs, Cmd-F using selected text may be quicker and easier.
I hope we can all agree on that.
My point was that: if someone wants to be able to achieve a goal G by some a particular means X (because the nature of X is helpful for them), it's not a valid point to say "but you can already achieve G by means Y" (where Y is not as helpful for them and their needs).
Imagine if the Cmd-E Cmd-F feature didn't exist and you said it'd be good if it did, and I responded that the behavior you want is already provided by another shortcut: by typing Cmd-F and then typing in the highlighted term.
EDIT: actually, I think a better analogy would be if you had said it'd be good if there was the Cmd-E Cmd-F feature and I responded that there's already shortcuts for the behavior you want: typing Cmd-C Cmd-F Cmd-V
--
I think clarity, simplicity and robustness are means of making it quicker and easier to achieve tasks.
> But for other people's needs, Cmd-F using selected text may be quicker and easier.
I agree.
I don't think your analogy applies here: the parent doesn't ask if feature X exists, he complains about the fact that feature Y doesn't work like an hypothetical feature X and concludes that Mac text editors don't have feature X.
My answer is that feature X is in fact available but that you don't access it like you access feature Y.
Different features accessed by different means.
Here, the features are not "Cmd-F" or "Cmd-E - Cmd-F", these are only interfaces or triggers or proxys or whatever you want to call it.
The features are "searching for some arbitrary text" or "searching for the highlighted text". They are both different, present in the system without any hacks, accessible via shortcuts. If you want to use one you use it's shortcut, if you want to use the other you use its shortcut.
If the end is to search for arbitrary text there is a mean: Cmd-F.
If the end is to search for another instance of the selected text there is a mean: Cmd-E - Cmd-F.
There are actually more means for each end: the edit menu, right click, buttons in the toolbar…
I'm not confused about them.
Confusion happens when you think, wrongly, that one mean (Cmd-F) allows to reach another end than the one it's designed for.
Confusion happens when you don't know the full capabilities of your tool and you use the most readily available mean, Cmd-F, to reach every conceptually related ends. Such a strategy is neither efficient nor sustainable at all.
Confusion happens when you keep doing the same mistake over and over without searching for a better way and complain about the dumbness of your tool and by extension of its authors.
>I don't think the parent wanting more convenience is lazy. But I think that not reading the manual and complaining about the absence of an obviously present feature is proof of lazyness.
Parent commenter here. Some points:
1. Just because it's buried in a submenu doesn't make it obviously present.
2. When a user notices that something doesn't behave as it's expected, he/she won't think: "oh, let's look in the manual, maybe there's some way to do this". He'll just think the software is broken.
3. Another very true example of this is cut and paste of files. For years you could not cut and paste a file on Mac like in any other OS. Lion adds this, but instead of the simple and obvious Cmd-X, Cmd-V, you have to do Cmd-C, Cmd-Option-V.
When a user tries Cmd-X to move a file and discover it doesn't work, you can say he's lazy for not looking up in the manual. Or you can agree that some things are just badly designed, period. And I believe Cmd-F to search for selected text falls in that category too, despite of you arguing it's more robust.
And no, they don't always run "extensive usability tests". It's not because it's Apple that they get _everything_ right. They're humans, too.
I answered curtly to you calling me lazy, but I think now you're a bit biased here.
1. Yes, it makes it obviously present. Menus are the primary way (besides the manual) to explore a Mac app.
2. How did you create such an expectation? Searching the selected text on Cmd-F is not and has never been the default behaviour on Mac. Cmd-F not working as expected would be "the textfield is already populated by some random text and I have to delete it to input the text I want to search for".
You simply hit a well defined and stable and robust shortcut expecting it to do something different than what it has been designed for. Of course you are wrong.
When I moved to Mac OS X (leopard, I took my time) from Mac OS 9 I fell in love with Cmd-H but it didn't work in Photoshop where it was bound to something related but different. My mind was conflicted between my long time hardwired photoshop shortcuts and the new ones I used intensively.
Who sucked more? Adobe for not following the OS's guidelines and default or Apple for hijacking shortcuts used for years by their most loyal customers?
3. Totally agree, it's extremely stupid.
I do agree that some things are badly designed (coverflow, your cut & paste example, window/app switching…). I don't agree that Cmd-F is badly designed.
I'm not at all an Apple-lover (no iPod/iPad/iPhone - my dumbphone is great, thanks - Ubuntu at home since 1 year after 14 or 15 years of Mac OS and Mac OS X). Not everything they do is right, obviously. But they have to make compromises for their software to work well.
Cmd-F is an example of such a compromise where they make the feature good enough for most but too dumb for some while providing an easy alternative.
The Cut & pate fiasco is another example where they completely fuck up their belated attempt at adding a feature wanted by all the Windows switchers they managed to bring in.
Also I'm extremely sorry for calling you lazy. I was writing my reply and didn't notice the implications.
I can see your point but here two key presses makes more sense as it allows me the flexibility to decide whether I want that highlight to mean something. I am often blending cut'n'paste actions with search actions and it would be an extra key/mouse press for me to get the functionality I want.
Different people have different work flows, and impossible to make everyone happy. However, in this case the extra-key press (which is easy as same modifier key and the E,F & G keys are all nearby) allows for greater flexibility and doesn't do unexpected stuff for newbie users.
Cmd-F (if it searched for the highlighted text) requires two: Cmd-F, return. Cmd-E requires two: Cmd-E, Cmd-G. You only need to press Cmd-F if you need to change search options, which the vast majority of the time, you do not.
This is not so bad in my book.
There's one thing that drives me crazy though; PgUp and PgDown. Why doesn't that also move the cursor? Why only move the viewpoint?
I use both Windows and OSX and this is the one thing that bothers me most.
Yes, it truly is annoying that, in Windows, one cannot use a few page up presses to quickly look up say a function name, then hit, say, cursor right to automatically scroll back at the point one was at :-)
The rationale for choosing this behavior in the Macintosh human interface guidelines was one of consistency: the keys simulate clicking the page up area, and clicking there does not move the cursor.
The keys _had_ to emulate mouse behavior because not all users had page up/down keys. The original Mac keyboard did not even have cursor keys.
I also think Apple that way avoided the difficult choice of what to do with the cursor. Should it stay at the same screen position, move to the top of the window, or something else? What if scrolling hits the top/bottom of the document? What if one hits page up while already scrolled upwards as far as possible? Should the cursor move within the document?
Finally, there is consistency with other programs. Drawing programs, photoshop, file explorers, etc, typically do not move the selection on page up/down.
I think they made the best choice for that time. It may no longer be the best choice in today's world where six year olds have six years of experience working with GUIs, but the eighties were quite different.
I've been noticing a lot of talk about BBEdit lately and am having a hard time finding what features might set it apart from apps like Textmate or VIM. Are there any features that aren't in other editors that I'm just missing? Two of my coworkers use it and I haven't been able to witness anything in particular, but with a line in the article like "I'm a big BBEdit fan" there has to be something I am missing, right?
As a long time BBEdit user, a lot of it has to do with the vast spread of features that cover just about everyone's needs. As a vim pre-novice, I think that part of BBEdit's appeal is that the features you may not use often enough to remember a command for are just a little mouse-hunting away. Having used Textmate a couple of time and the somewhat similar e.exe for Windows a lot, the appeal of BBEdit is that features are integrated into the application instead of loosely coupled in bundles that may or may not work well.
Another far under-appreciated feature of Textmate(and emacs, probably vi as well) is incremental search. Ctrl-s and start typing what you are looking for, if you want to find the next item hit Ctrl-s again. I use this whenever I'm traveling more than 5-6 lines in either direction.
I've stayed on vim for the fact that I can use ctags/cscope on pretty much any grand tree of docs and be able to navigate through it all with extreme ease.
cscope is not just for C/C++ projects, btw, you can set it up for any text filetype with ease. So for navigation front-end, I use cscope (find text), while within vim a full structure of detail is available to me with a simple keypress. This ability to navigate text is also one of the reasons, I believe, that Visual Studio is still so popular in spite of the grand cruft it brings with it, as a 'text editor'-derived product concept. edit: outside the edit/make/run/inspect loop that vim+cscope+gdb gives, Visual Studios huge offerings seem a bit 'crufty' to me. Call me an old, over the hill kind of guy, but I didn't mean to insult Visual Studio fanatics, fans, or users.
52 comments
[ 2.8 ms ] story [ 93.9 ms ] threadI totally agree with the article by the way. Selecting the line is idiotic. While programming, you never ever want it to select the whole line - in fact, I don't think I have in fact ever selected a line at all.
E-mail is so often reformatted, munged and quoted that depending on line numbers being the same on the sender's side seems foolish.
PS. I use Emacs for virtually everything so C-N, C-P and M-N, M-P get used for that kind of navigation.
That's how I do it anyway. The only reasons I can come up with off the top of my head to do otherwise is if someone is doing heavy TDD or banging code into a Smalltalk debugger instead of a browser.
How do you do it? (Genuine question. I almost always code by myself and have never been around anyone while they are productively working with an editor.)
Getting quick at line up/line down (C-N, C-P) and page up/page down (M-P, M-V in Emacs) seems to be a more common way of navigation. (C-S for quick search in Emacs being the other)
I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error. (TDD or not, stack traces are a way of life)
> I use "Go-to-line" almost exclusively to jump to the line where a stack trace is telling me there's an error.
yes that's pretty much it: use external tool to find some row (diff tells you this is where a chunk was changed, grep or ack tells you what you're looking for is there, ...), jump straight to row.
Although usually I'll open the file directly at the right line in emacs (`e +line file`[0]), goto-line is only for the IDE.
[0] where `e` is an alias for `emacsclient -n`
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
As an added bonus, the input line disappears if you press Ctrl-G again, hit <esc>, or press enter without entering anything. So, fast and easy to get into, fast and easy to get out of.
The most basic web page development exercise - 1 browser window and 2 editor windows for html and css - is ruined because I can no longer MRU cycle the 3 windows.
I would say this is one of the biggest usability mistakes on the Mac. Sadly, Unity & Gnome 3 have both copied this. Meanwhile, I don't fight the platform but use it the way it was meant to be - keyboard + mouse. But I'll be shifting back to Linux or Windows for all non Mac/iOS development.
Update: thanks to comments pointing me to Witch. However, I still stand by my criticism of the built-in Mac desktop behavior.
I'm finding the list style still has high mental overhead compared to the Windows/Linux style of bringing the target window (or it's outline) transiently forward.
Still, looks like it's 80/20 enough that I'll be parting with $14 soon!
I have it bound to alt+tab. Super customizable, I have things like ignore all minimized applications, only windows in this space and ignore any window from adium.
Lets me easily switch between terminals, vim windows and browsers that are on the same space. Highly recommend.
I get a warning that some apps might not like command-tab being taken by Witch - have you faced any issues?
Whatever the reason, they're wrong for us power users. And possibly for intermediate & beginners users as well.
Then again, I'm not doing web development, so I'm not trying to cycle between my editor and one particular browser window.
I don't think it's a power-user vs. beginner issue; it's more of a workflow style issue.
For example, chat is mostly fine. I'm either switching between multiple chat windows or mentally switching from chat to another task in which case I have no problem switching out of the whole chat app.
The same setup goes wrong when one chat window is for work, and I'm going back and forth with another non-chat work window.
For me, it's a better default to switch entire applications than windows. There are edge cases, sure, like the chat one you mention, or different browser windows, but I'd rather just switch from Excel to IE to Outlook than have to tab through my history of open documents and browser tabs (curse you IE) to get back to my Outlook window.
It sounds like for you, it's the opposite: the better default would be to switch windows, not apps.
The question then is which is the most common pattern, but I don't know of any actual research on this. You can't generalize from personal experience, plural of anecdote and all that.
So I have to constantly do the sequence: swear out loud - press escape - Cmd-C - Cmd-F again - Cmd-V.
That's just dumb.
With all due respect, what is just dumb is not reading the manual of the powertools you use every day and blaming them for your lazyness.
>With all due respect, what is just dumb is not reading the manual of the powertools you use every day and blaming them for your lazyness.
I thought the point of Mac was that you didn't have to read the manual ;)
But yes, in this case, mea culpa.
You don't have to read the manual to perform the most common tasks. But if you want to perform more advanced/specific tasks, reading the manual is necessary.
Cmd-F searching for the highlighted text involves one key-press. What you describe requires two key-presses.
The former is quicker and easier, and I think that makes it preferable.
Pretty much everything to do with computers, from Operating System features, to program and UI features, are ultimately about making it quicker and easier to perform tasks.
Wanting more convenience is not laziness. The goal of computer systems should be to provide more convenience.
However, binding two different actions to one trigger is pushing the logic too far.
It could happen that I have some text selected and I want to search for something within that text, or that I've selected something by mistake and I want to search something else… In that kind of situation having the search field populated by the content of the selection by default would obviously lead to a less than ideal experience.
I believe the people behind these choices actually ran extensive usability tests and decided to compromise on what they found to be the most common use case: poping a search window and inputing the search term.
I agree this system is maybe a little dumb but I think that is what makes it robust and dependable. Which is in my opinion the single more important attribute of any system.
I don't think the parent wanting more convenience is lazy. But I think that not reading the manual and complaining about the absence of an obviously present feature is proof of lazyness. That's very different and so very common. And I wasn't mocking him, just improvising a pun based on his last line.
The feature you're talking about is not the same as that.
-
What benefits do you think are provided by software that don't ultimately come down to making things quicker and easier to do?
My point was: the parent wants a different behaviour for Cmd-F but it turns out the different behaviour he asks for is already provided by another shortcut.
Yours is: it sucks and these different behaviours should be triggered by the same shortcut for the sake of "quicker and easier".
I think that such a move would actually go the opposite of "quicker and easier".
The most basic case for which the "Find" feature provided by Mac OS X is this: you need to locate a word in some text. This can happen if you want to jump quickly to a specific paragraph or if you want to read the definition of a word or the address of a person or if you want to bypass the LOC… Cmd-F is the way to go: it pops up a window with a textfield and a "Find" button. Exactly what you need to achieve your goal.
The case addressed by the Cmd-E Cmd-F combo has different predicate: you already have the word highlighted and you want to jump to another instance of the same word in the document. This may happen in fewer situations than the above case. In such a situation, comparatively rare, I believe, Mac OS X provides another shortcut.
Different actions -> different triggers.
-
I expect of course any software to go as far as possible on the road to "quicker and easier" but such a goal shouldn't impede clarity, simplicity and robustness. Making all of these requirements work together is what makes good software.
You (and others) prefer Cmd-E Cmd-F? Fine, I'm happy with that.
For your needs, that is quicker and easier.
But for other people's needs, Cmd-F using selected text may be quicker and easier.
I hope we can all agree on that.
My point was that: if someone wants to be able to achieve a goal G by some a particular means X (because the nature of X is helpful for them), it's not a valid point to say "but you can already achieve G by means Y" (where Y is not as helpful for them and their needs).
Imagine if the Cmd-E Cmd-F feature didn't exist and you said it'd be good if it did, and I responded that the behavior you want is already provided by another shortcut: by typing Cmd-F and then typing in the highlighted term.
EDIT: actually, I think a better analogy would be if you had said it'd be good if there was the Cmd-E Cmd-F feature and I responded that there's already shortcuts for the behavior you want: typing Cmd-C Cmd-F Cmd-V
--
I think clarity, simplicity and robustness are means of making it quicker and easier to achieve tasks.
I agree.
I don't think your analogy applies here: the parent doesn't ask if feature X exists, he complains about the fact that feature Y doesn't work like an hypothetical feature X and concludes that Mac text editors don't have feature X.
My answer is that feature X is in fact available but that you don't access it like you access feature Y.
Different features accessed by different means.
Here, the features are not "Cmd-F" or "Cmd-E - Cmd-F", these are only interfaces or triggers or proxys or whatever you want to call it.
The features are "searching for some arbitrary text" or "searching for the highlighted text". They are both different, present in the system without any hacks, accessible via shortcuts. If you want to use one you use it's shortcut, if you want to use the other you use its shortcut.
Easy.
If the end is to search for arbitrary text there is a mean: Cmd-F.
If the end is to search for another instance of the selected text there is a mean: Cmd-E - Cmd-F.
There are actually more means for each end: the edit menu, right click, buttons in the toolbar…
I'm not confused about them.
Confusion happens when you think, wrongly, that one mean (Cmd-F) allows to reach another end than the one it's designed for.
Confusion happens when you don't know the full capabilities of your tool and you use the most readily available mean, Cmd-F, to reach every conceptually related ends. Such a strategy is neither efficient nor sustainable at all.
Confusion happens when you keep doing the same mistake over and over without searching for a better way and complain about the dumbness of your tool and by extension of its authors.
But I think we are going to stick to our guns.
Parent commenter here. Some points:
1. Just because it's buried in a submenu doesn't make it obviously present.
2. When a user notices that something doesn't behave as it's expected, he/she won't think: "oh, let's look in the manual, maybe there's some way to do this". He'll just think the software is broken.
3. Another very true example of this is cut and paste of files. For years you could not cut and paste a file on Mac like in any other OS. Lion adds this, but instead of the simple and obvious Cmd-X, Cmd-V, you have to do Cmd-C, Cmd-Option-V.
When a user tries Cmd-X to move a file and discover it doesn't work, you can say he's lazy for not looking up in the manual. Or you can agree that some things are just badly designed, period. And I believe Cmd-F to search for selected text falls in that category too, despite of you arguing it's more robust.
And no, they don't always run "extensive usability tests". It's not because it's Apple that they get _everything_ right. They're humans, too.
I answered curtly to you calling me lazy, but I think now you're a bit biased here.
2. How did you create such an expectation? Searching the selected text on Cmd-F is not and has never been the default behaviour on Mac. Cmd-F not working as expected would be "the textfield is already populated by some random text and I have to delete it to input the text I want to search for".
You simply hit a well defined and stable and robust shortcut expecting it to do something different than what it has been designed for. Of course you are wrong.
When I moved to Mac OS X (leopard, I took my time) from Mac OS 9 I fell in love with Cmd-H but it didn't work in Photoshop where it was bound to something related but different. My mind was conflicted between my long time hardwired photoshop shortcuts and the new ones I used intensively.
Who sucked more? Adobe for not following the OS's guidelines and default or Apple for hijacking shortcuts used for years by their most loyal customers?
3. Totally agree, it's extremely stupid.
I do agree that some things are badly designed (coverflow, your cut & paste example, window/app switching…). I don't agree that Cmd-F is badly designed.
I'm not at all an Apple-lover (no iPod/iPad/iPhone - my dumbphone is great, thanks - Ubuntu at home since 1 year after 14 or 15 years of Mac OS and Mac OS X). Not everything they do is right, obviously. But they have to make compromises for their software to work well.
Cmd-F is an example of such a compromise where they make the feature good enough for most but too dumb for some while providing an easy alternative.
The Cut & pate fiasco is another example where they completely fuck up their belated attempt at adding a feature wanted by all the Windows switchers they managed to bring in.
Also I'm extremely sorry for calling you lazy. I was writing my reply and didn't notice the implications.
Different people have different work flows, and impossible to make everyone happy. However, in this case the extra-key press (which is easy as same modifier key and the E,F & G keys are all nearby) allows for greater flexibility and doesn't do unexpected stuff for newbie users.
Horses for courses.
Muscle memory dies hard.
/rant
The rationale for choosing this behavior in the Macintosh human interface guidelines was one of consistency: the keys simulate clicking the page up area, and clicking there does not move the cursor.
The keys _had_ to emulate mouse behavior because not all users had page up/down keys. The original Mac keyboard did not even have cursor keys.
I also think Apple that way avoided the difficult choice of what to do with the cursor. Should it stay at the same screen position, move to the top of the window, or something else? What if scrolling hits the top/bottom of the document? What if one hits page up while already scrolled upwards as far as possible? Should the cursor move within the document?
Finally, there is consistency with other programs. Drawing programs, photoshop, file explorers, etc, typically do not move the selection on page up/down.
I think they made the best choice for that time. It may no longer be the best choice in today's world where six year olds have six years of experience working with GUIs, but the eighties were quite different.
cscope is not just for C/C++ projects, btw, you can set it up for any text filetype with ease. So for navigation front-end, I use cscope (find text), while within vim a full structure of detail is available to me with a simple keypress. This ability to navigate text is also one of the reasons, I believe, that Visual Studio is still so popular in spite of the grand cruft it brings with it, as a 'text editor'-derived product concept. edit: outside the edit/make/run/inspect loop that vim+cscope+gdb gives, Visual Studios huge offerings seem a bit 'crufty' to me. Call me an old, over the hill kind of guy, but I didn't mean to insult Visual Studio fanatics, fans, or users.