
Mac Text Editors and Navigation - hboon
http://inessential.com/2011/11/27/mac_text_editors_and_navigation
======
divtxt
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._

~~~
tutysara
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.

~~~
divtxt
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.

~~~
oddthink
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.

~~~
divtxt
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.

~~~
oddthink
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.

------
Jacked
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.

------
gregschlom
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.

That's just dumb.

~~~
johncoltrane
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.

~~~
jamesrcole
But I think they had a valid point.

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.

~~~
johncoltrane
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.

~~~
gregschlom
>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.

~~~
johncoltrane
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.

------
Stwerner
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?

~~~
adolph
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.

------
stephenr
How does Mail make it into a comparison of text editors!?

~~~
lazugod
Why not? It's the only proper text editor that lets someone else see what
you're writing with the click of a single button.

~~~
nicpottier
Although you make an interesting point, I'm really having a hard time thinking
of where a "Go to line.." command comes in handy in Mail though.

E-mail is so often reformatted, munged and quoted that depending on line
numbers being the same on the sender's side seems foolish.

~~~
hboon
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.

~~~
nicpottier
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.

~~~
hboon
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.)

~~~
nicpottier
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)

~~~
masklinn
> 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.

[0] where `e` is an alias for `emacsclient -n`

------
pilif
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_.

------
lazerwalker
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.

------
wwkeyboard
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.

