
Am I the Only One Who Uses a Text Editor to Edit Files? - sant0sk1
http://blog.peepcode.com/tutorials/2010/file-navigation-in-text-editors
======
btipling
Am I the only one that found staring at orange hard on the eyes? I guess I
should give the author credit for all the work that they put into this rant,
seems like a blog post could have done just the same without all the fancy
graphics and what not.

~~~
MaysonL
If you happen to be on a mac, control-option-command-8 is your friend. Also,
the readability bookmarklet does wonders for the appearance of sites like
these. (And thanks to the people on HN who originally introduced me to these)

~~~
petercooper
_control-option-command-8 is your friend_

Ditto for if you go to Best Buy or any other non Apple store that sells Macs.
They never know about this delightful key combo. </8 year old level of humor>

~~~
gommm
Glad I'm not the only one to sometimes be a bit childish and do this :-)

------
sjbach
I wrote a snappy Ruby-based Vim plugin called LustyExplorer which does
fuzzy/flex matching for opening files and switching buffers:
<http://www.vim.org/scripts/script.php?script_id=1890>

~~~
FlemishBeeCycle
Not to downplay your contributions (thank you), but just letting people know
about other options:

FuzzyFinder Textmate <http://github.com/jamis/fuzzyfinder_textmate>
(Unfortunately only works with fuzzyfinder up until v2.16)

and more recently

Command-T <http://www.vim.org/scripts/script.php?script_id=3025>

~~~
gurraman
i've written a plugin as well. it's extremely simple: it uses find (or
globpath() if you do not like external dependencies) to build a local cache.
matching isn't approximate but you get results on partial matches and can
browse files in directories (something i really missed in some other
solutions).

i recorded a quick screencast: <http://pipsq.com/s.mov>

note that i'm matching against the linux source; searching smaller source
trees should be a lot faster.

you can try it out by downloading the following files:

[http://github.com/strange/dotfiles/blob/master/.vim/plugin/p...](http://github.com/strange/dotfiles/blob/master/.vim/plugin/pyxis.vim)
[http://github.com/strange/dotfiles/blob/master/.vim/autoload...](http://github.com/strange/dotfiles/blob/master/.vim/autoload/pyxis.vim)

launch with :Pyxis or create a map:

noremap <leader>e :Pyxis<CR> noremap <silent> <leader>E :PyxisUpdateCache<CR>

------
psyklic
Am I the only one who almost didn't scroll down, thinking that the keyboard
graphic was the thing to see?

~~~
devinj
No. It's a terrible webpage design.

Am I the only one who still values things like
<http://www.useit.com/alertbox/scrolling-attention.html> ?

~~~
armandososa
Yes. The "user's don't scroll" meme has been confirmed as a myth.

~~~
daleharvey
"confirmed" by who? every blog post I see titled "the fold is a myths" follows
the same path where there author lays out a bunch of opinion of why they think
it is "honestly people scroll fine, honest"

every empirical study (like the one linked) seems to confirm that there is an
obvious bias towards content above the fold.

Dont think its particularly important here, I was pretty impressed by his
design and not everyone needs to stick to strict usability constraints, but
still handy to know what they are.

~~~
MartinCron
Anecdotal evidence, but evidence nonetheless: We did some testing of how
people interact with icanhascheezburger.com and found that most people
basically _just_ scroll and then click the "next page" link at the bottom.

------
futuremint
Did anyone ever think that maybe the problem is the FILES?

Let me ask that one more time. Would people be ranting like this if there were
NO FILES?

I still believe the "future of programming" is where your code objects are not
arbitrarily mapped onto files in the file system, you just manipulate them
directly!

A few Smalltalks and Lisps out there do this using image-based development.
This is where it's at. If you can't use a image-based Smalltalk or Lisp to get
your work done, then use a JetBrains/Eclipse IDE. They're generally modeled
off of the Smalltalk IDE and are the next best thing if you're forced to use a
broken file-based language.

If you just take "files" for granted and think that the UNIX design philosophy
is the best thing ever, then accept your fate and stop bitching.

~~~
plinkplonk
" If you can't use a image-based Smalltalk or Lisp to get your work done, then
use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk
IDE and are the next best thing if you're forced to use a broken file-based
language."

I've worked in smalltalk, and yes it is an interesting way to work but images
had almost as many problems as hey solved. primarily version controlling and
syncing code were terrible (yes there were some tools, and yes they all broke
on weird edge cases).

If forced to choose these days, I'd rather use files + git + (+ emacs + grep +
... ) than images, Images are nice as an _additional_ dev time artifact, but I
believe files are more natural than images for source code.

"If you just take "files" for granted and think that the UNIX design
philosophy is the best thing ever, then accept your fate and stop bitching."

This is provocative nonsense. smalltalk, while hugely influential and
innovative is hardly the ultimate superior dev env that some old geezers make
it out to be. I think it is mostly "the lost cause" style romanticism.

~~~
blasdel
That's just the thing, git doesn't give a shit about files internally, it
tracks the content instead and uses heuristics to figure out the file
metadata.

Files and their artifacts do show up everywhere in git's UIs, because noone's
found a better model yet of exposing the content to the user.

------
eitland
Sounds like some people still haven't learned NetBeans or Eclipse.

Takes some time getting used to, -just like vim or emacs, but once you get
used to the keyboard shortcuts you get everything the author asked for. No
mouse needed: check, fuzzy search: check, paths: check, metadata: check,
beautiful: check

~~~
technomancy
Works over SSH: not so much.

~~~
viraptor
Try with X forwarding turned on next time ;) Most GUI apps work just fine over
SSH.

~~~
vidarh
Not so much over high latency trans-atlantic connections with low bandwidth,
which is something that works perfectly fine with a terminal based editor.

------
alexfarran
No mention of ctags. I use that more than anything to navigate around files in
emacs: M-. SomeIdentifier takes you straight to the definition. I hardly care
which file its in.

~~~
CUViper
I prefer cscope & vim, but yes, I often have no idea what file I'm in.

------
jhaile
Uh..have you never heard of IntelliJ IDEA or Eclipse? Or RubyMine? Or Netbeans
even...

They pretty much do everything you're talking about.

~~~
dusklight
Yeah, why was the OP upvoted? Are there seriously that many people on Hacker
News who have never used a real ide?

~~~
nostrademons
Depending on the language, IDEs are often not worth the trouble. I was big
Eclipse and then Netbeans user when I did Java dev. When I started working in
C++, I used Eclipse for about two days before I went back to vim. The Eclipse
functions I depended upon most in Java - navigation, autocomplete, and
refactoring - just didn't work all that well in C++.

IntelliJ IDEA has exactly what the author implemented, but IntelliJ IDEA can
also take about 5 minutes to start up, and takes up _all_ your screen real
estate. When you work in 5 languages on a regular basis and just want your
editor to start up quickly, that can be quite a pain.

------
ErrantX
My favourite text editor still has to be Notepad++ on Windows. I've never
found another (both for Windows or Linux) that was as snappy and simple.

 _shrug_

(never quite "got" emacs - it reminds me of the crappy, buggy, horrid PIC IDE
we used at uni)

~~~
TallGuyShort
I was very impressed with Notepad++. I've switched to vim simply because I've
been doing more and more work on remote unix machines - and it's so much
easier to just open up vim through ssh. Now that I'm used to how to use it, I
also appreciate how easy it is to get a dark color scheme that's easy on the
eyes.

But yes - a big upvote for notepad++. Very lightweight and easy to work with.

------
matthavener
VIM has a similar file finder using a plugin called Fuzzy Finder
<http://www.vim.org/scripts/script.php?script_id=1984>

~~~
jrockway
It's almost like programmers _write programs_ to help them get work done! And
I thought you were supposed to solve problems by making a big orange web page
whining about them...

~~~
guitsaru
You mean like what the author did?

"This article started with pain, developed into an idea, and ended up as an
unexpected prototype implemented in MacRuby. I’m using it daily and am fine-
tuning the interaction, visuals, features, and performance."

~~~
jrockway
A window that displays filenames next to a larger-font-version of their
extensions?

------
docgnome
In my experience, Anything provides better file and buffer location for Emacs.
<http://www.emacswiki.org/emacs/Anything>

------
camwest
I'm not sure this matters for what I do mostly: Use Rails.vim where you are
moving around typically with :Rmodel or :Rcontroller and splitting windows to
see the implementation and test side-by-side.

------
artsrc
A pretty, re-invented, better Emacs would nice.

Till one exists use the current emacs.

------
breck
One solution:

Use fewer files. I try to keep the number of files and folders for a project
to as few as possible.

Then you spend much less time opening and searching for files. As more people
get involved with a project, you'll have more files, but you should make an
active effort to keep the numbers minimized.

Here's a little script I wrote to give quick stats on a project's size:

<http://breckyunits.com/metrics_for_programmers>

~~~
viraptor
> Use fewer files.

Why? What does that have to do with text editing capabilities? The number of
files depends (or at least should) on what you do, not on how bad your tools
are. If you limit the number of files to limit the file-opening time, you
increase the fragment-searching time in the gigantic-file-of-doom. Also you
lose the possibility to make local one-file changes which are self-explanatory
if you look at the VCS history.

I'm not sure why would I want to make my work harder just to make up for the
tool's features...

~~~
breck
The OP complains that:

> For most programming tasks, editing involves opening several files at once
> and switching between them (e.g. HTML/JavaScript/CSS).

His idea of a solution is for better file navigation.

My claim is that often the real problem is a bloated set of files and
directories in a project.

I find when the set of files is small, opening and switching between them is
much faster and more productive.

This applies particularly to the beginning of a project. As classes/files
mature, then I recommend splitting them up into more files.

For example, when starting a new MVC project I'll create one models file. All
the models go in there at first because the project will be heavily edited.

Once it's become more stable, I'll split it into a file for each model/class.

This way when you make small changes you'll have the VCS history benefit you
mention, but often you don't really need that at the beginning of a project.

------
fexl
Vim has this nice feature where you can edit directories as well as files.
Just say:

    
    
      vi dir
    

Now you're looking at a directory listing, and you can move down to an entry
and press Enter to go there.

When you're inside a file, you can go back up with:

    
    
      :e ..
    

You can also use wildcards and tab completion. I suppose for finding routines
you can use ctags, though I haven't bothered with that in quite a while.

~~~
silentbicycle
That didn't work for me with nvi or vim, it just says, "/usr is a directory".
Does it require an extension? (I'm assuming your 'vi' is a symlink to 'vim',
which is not always the case.)

Similarly, Emacs has dired, and in some extensions you can edit the file
metadata in place and hit save to rename files, chmod, etc.

~~~
fexl
Right, I'm talking about vim. On Ubuntu, by default, my "vi" is vim.

I'm surprised it didn't work for you using vim explicitly. It works for me
using versions 7.1.138 and 7.2.245, from fresh installs, by default, with no
fancy configuration or add-ons.

When I run vim on /usr, it shows me a directory listing which I can browse and
edit. I can create, delete, and rename directories and files right there.

~~~
silentbicycle
I probably just don't have the relevant plugins installed. I installed vim on
this computer for some reason or another, but I usually use Emacs or nvi.

------
dwiel
Kate comes close to providing what he is looking for:

It doesn't do an x/y fuzzy search, or an x y fuzzy search though it does to
single word search.

It colors files by how recent they were opened and by if they were most
recently edited or just viewed (changing/reference code). The file searches
include folder names. All navigation tasks work through the keyboard. It has
GUI beauty.

------
jrockway
Typical designer. "Oh no, my text editor displays its status to me using
text."

Yeah. Some people get their eye-candy feed from lolcat videos, and then use
their tools for work. (My desktop doesn't even have wobbly windows! Just a
1-px red border! How can I get any work done that way!)

Also, I'm fairly certain that eproject gets rid of the "wall of text" that
disqualifies Emacs. In a perl project, for example, I can hit C-c C-f to find
project files, but the files are displayed as the names of their resources --
instead of lib/Foo/Bar.pm, I see "Foo::Bar".

Personally, though, I just "eproject-open-all-project-files" when I start
working, and then just iswitchb to the file I want to work in. Usually, you
are two or three characters away from any file you want.

Learning and thinking > pretty.

~~~
cscotta
I think your attitude is overly dismissive. At least, I'd have a hard time
writing someone off as a "typical designer" (a bit of a tired stereotype) if
they're experienced in both vim and emacs, let alone work for Peepcode. The
author offered a sustained, reasoned argument for better navigation within
projects.

I agree that as a programmer, I care about functionality and tools that get
out of my way so that I can get my work done quickly and efficiently. But I
don't think that means that everything has to look ugly (or better - that it
couldn't be more elegantly presented).

I'm a Vim user, and rarely leave full-screen mode. It's a great app, but on
large projects even with the Fuzzy File Finder plugin, I agree that navigating
can be cumbersome. I'd like to try out Jamis Buck's "Fuzzy Finder Textmate"
plugin that builds on this, but have had trouble getting it installed on both
my desktop and laptop.

tl/dr: The author knows what s/he's talking about, and things can be pretty
and functional, too.

~~~
r00k
If you've had trouble setting up fuzzy_finder textmate, check out my post:
[http://codeulate.com/2010/02/installing-
fuzzyfinder_textmate...](http://codeulate.com/2010/02/installing-
fuzzyfinder_textmate-textmates-cmdt-in-vim/)

I walk you through it step by step.

~~~
latortuga
I've gone through this process a number of times on different computers so I
imagine that others will find this quite useful. Thanks for writing it up!

As an aside, I think you can just download the 2.16 version of fuzzyfinder
from vim.org and it will work with Jamis' plugin. That's the version I use -
love this plugin and I doubt I'd be able to use vim without it!

------
zakj
Command-T is a relatively new Vim plugin that does fuzzy matching on the
entire path, giving greater weight to characters immediately following slashes
or other word separators in the pathname. I've been using it for a few days
now and can attest that it is extremely fast and seems to "know" exactly which
file I want after just a few keystrokes.

<http://www.vim.org/scripts/script.php?script_id=3025> |
<http://github.com/wincent/Command-T>

------
jff
I use Acme, it's got a smashing way to browse, open, and manage files.

~~~
Flow
Is there a port of Acme to OS X?

Or are there any similar editors?

~~~
silentbicycle
Wily (<http://www.cse.yorku.ca/~oz/wily/>) is a major Unix port. Some quick
googling says that it should work on OS X, though you need a three-button
mouse for its chording-based interface. Its design is strongly influenced
inspired by Oberon (<http://ignorethecode.net/blog/2009/04/22/oberon/>) (the
OS, not the beer).

I find its design very novel, but the mouse-centric UI is a dealbreaker for
me. (I went back to Emacs.) If you're already using a Mac, you're probably a
bit more forgiving of mice, though.

~~~
Flow
That's what people think. But Mac OS X is actually short-cut land. There are
loads of short-cuts.

~~~
silentbicycle
Can you use OS X entirely without a mouse?

~~~
Flow
I don't know. Never tried it.

I'm just very happy common things like closing a window(cmd-w), quitting and
app(cmd-q) have sane and comfortable short-cuts compared to Windows.

------
LiveTheDream
For file finding, I use FuzzyFinder with a shortcut to the recursive search.
So far that and ctags been good enough that I haven't wrestled with fuzzy file
finder textmate. The Command-T plugin looks neat though.

    
    
        " vim-fuzzyfinder plugin
        map <Leader>t :FufFile<Enter>
        " start recursive search with a comma. see help for 'fuf-abbreviation'
        let g:fuf_abbrevMap = {
                \   "^," : [
                \     "**/",
                \   ],
                \ }

------
cjauvin
I wrote a simple fuzzy file finder extension for Emacs that tries to address
some of the things I don't like about IDO (namely the "big paragraph"
presentation that this article tells about), but does much less of course. I
use it myself all the time, and if it could be of interest to the readers of
this thread, here it is: <http://code.google.com/p/find-file-suggest>

------
icco
This is really well done, and especially interesting because I am doing
research on making a text editor right now.

------
sgoranson
I'm so close to getting vim to be my ideal editor...7.0 for tab support, and
ctags opens tags in a new tab, not a new buffer.

But I can't figure out how to search currently open tabs instead of opening a
new tab no matter what; I end up with duplicate tabs very easily. So his 3rd
major "what I want" point really rings true.

~~~
graywh
Your problem is trying to use the tabbar as a replacement for
:ls/:files/:buffers. Stop, and learn what tabpages really are--work spaces, or
view ports.

~~~
erlanger
I agree. Now that I know how to use buffers, splits and the jumplist, I don't
often open buffers in new tabs.

------
mhartl
I'm suprised Geoffrey doesn't mention that you can switch between TextMate
tabs without the mouse using ⌘1, ⌘2, ⌘3, etc. I navigate Rails projects
through a combination of ⌘t (fuzzy search), ⌘ _n_ (move focus to tab _n_ ),
and the occasional side-menu mouse click, which works well for me.

------
mcantor

      cd ~/code
      ctags -R .
      echo "set tags=~/code/tags" >> ~/.vimrc
      vim -t SomeClass

------
takaaki
GoToFile bundle is an alternative to default Command-T in TextMate. It does
filter by path for instance.
<http://github.com/subtleGradient/gotofile.tmbundle>

------
iisbum
<http://www.sublimetext.com> has a feature almost exactly like this (missing
the modified timestamp -- not sure how useful that would be anyway).

------
ableal
_At the risk of ending anticlimactically, I plan to release it as a serious
helper application with painless TextMate, Vim, and Emacs integration for a
small fee (payable with PeepCode credits or free to Unlimited subscribers)._

Good to know. We're saved. For a small fee.

------
roundsquare
A case study in how not to layout your website for easy readability.

------
h3h
I like it.

Feature Request: Allow it to run invisibly (no Dock or menubar icon).

------
sunchild
I get it. Yes, I want.

------
EwanMacLeod
Yup, I use Coda

------
araneae
Where's the geany integration? _sniff_

------
mrcharles
I shall subscribe to your mailing list.

------
henrikschroder
I find it funny that about half of the comments are about the "horrible" web
design of the article.

If you agreed with the message you would never have wasted that much breath on
it, but you don't agree with it, and you don't have any good arguments against
the article, so "Too orange!" it is. :-)

