Introducing the File Finder | Hacker News Reader

Introducing the File Finder

github.com

158 pointsmattyb39 comments

This solves one of my largest annoyances when using Github as a Rails developer, namely, "Oh yay, time to walk five levels up and four levels down to find the place in the code of this gem where the function caused in the line causing the problem is actually defined."

Previously if I had to do it more than once I would copy the gem to disk, import to Netbeans, and then use Netbean's equivalent function. (Which I use so frequently during development I should really map it to, I dunno, tab.)

As a Rails developer I agree, although not as much as a Java developer agrees:

  com/ => company/ => moar_hierarchy/ => etc/ => even_more/ => files

Clicking though all of those empty directories, even with new slide from earlier this year, was still a pain in the butt.

http://p.hagelb.org/maven.jpg

You know, by the spec, you don't actually need levels called "etc" and "moar_hierarchy". You can even skip com if you want.

try http://gemedit.rubyforge.org/

lets you type

     gem edit <gem>

and it opens the gem dir in your $EDITOR

Bundler allows you to do the same thing from a bundled environment with:

bundle open <gem>

with vim, NERDTree, ack, and gem edit: once you `gem edit` and the directory list opens, go to the directory listing (e.g. /Users/you/.rvm/gems/ruby-1.9.2-p136/gems/twitter-1.1.1/) and type "cd". This changes your current working directory to the gem root, which in turn allows you to `:Ack some_text` from the gem root which is very useful.

Or create a little script to launch your editor in the right directory:

  $ echo $GEMEDITOR
  editgem.sh
  $ cat ~/bin/editgem.sh 
  #!/bin/sh
  cd $1 && mvim $1

This is no longer necessary since version 1.0, it now opens your editor from the gem's directory. https://github.com/lmarlow/gemedit/blob/master/History.txt#L...

So, a lot of small files create inconvenience and then one need a tool to navigate the mess?

You don't need that if you put everything in OneBigFile. Mine is 24KLOC. http://simplijs.com/OneBigFileFormat

Modern editors can handle big files.

BTW: I'm still looking for an editor that could open multiple files in a single buffer/window.

Surely you don't get the same level of organisation (particularly hierarchical) by having everything in one file? And doesn't that mean you are constantly scanning up and down the file?

Actually the content of my one big file is made of "sections" (I wrote a tool to extract them, http://simpliwiki.com/sections.html)

"Search" is my friend to move around in my one big file.

I think of it like a the same shift introduced by Google Mail with their "label" thing. At the time it was quite disturbing, we used to classify mails in hierarchical directories. Nowadays, when I want to retrieve a msg, do I navigate a directory structure? No. I just "search".

Same for source code.

If you like OneBigFile, you'll really love OneBigFunction!

Is that from the same people who brought you AllInOneClass?

Well... If you look at the source code of a Smalltalk program, you'll tons of small functions.

You'll probably enjoy that.

Problem is, grasping what they means turn to be difficult, it's like wherever you look you just have to look elsewhere and feel like the real job is done... no where. You basically struggle to get the "big picture".

Well... it's probably better than Forth.

There is more than one way to do it. I don't split a big function in two until the other function is called from at least two places. What's the point of having a function when all calls to it come from a single place?

But let the code speak, have a look at mine if you wish, this nice javascript loader for example http://simpliwiki.com/loadfire.js.html -- extracted automatically from my one big file of course. :)

Don't jump to conclusions about what I'd like or dislike... Adele Goldberg said about Smalltalk: "Everything happens somewhere else." I don't think that was meant as praise.

;-)

That's the quote I was looking for, you have a better memory that I :)

Awesome.

It's speedy too. I fired up Chrome Inspector and it looks like it works by Ajaxing in a full list of files in your repo the first time you hit "t", then doing the actual searching in the browser. Here's the URL it loaded for one of my projects:

https://github.com/simonw/bugle_project/tree-list/1c7793bf60...

Perhaps I'm special but I've never wanted to search for a filename in a github repository. Fulltext search on the other hand, that's a feature I have missed often.

I agree. Navigating a source tree with fulltext search is obviously much simpler. I wonder why it's not "obvious" to most developers, habits maybe.

Yep, A searchbox for the actual repos would be a nice feature. Filenames and content please ;)

There's actually a search box in private repositories in the upper right-hand corner that searches within the project. It was turned off for public repositories for performance reasons, I think. Tom's sort of spearheading revamping search in 2011, though, (see: new Gist search), so I wouldn't be surprised if he just improves all the things.

Even though public repositories lack a search box, they are still searchable by adding /search?q=$keyword to the url:

https://github.com/ry/node/search?q=runshell

Are there any greasemonkey gurus out there who could write a script which adds a box for this onto public pages?

I find it handy. Often I'll want to look at a file, but can't recall the exact name or location. I have a shell script that does a find, skipping certain things, and matching on some parameters.

I can also tell it to open what it finds in vim.

But I probably use the "grep files of a certain type for a certain string and open them in vim" version more often.

That's so awesome. I've wanted this forever.

Next (desired) feature in the pipeline: online vim on top of github.

And no, I don't think Bespin/Skywriter/Ace is good enough right now.

They're not.

I wonder how one could make money with a javascript version of Vim...

Well, http://code.google.com/p/emscripten/ is a converter from LLVM to C. Build an ncurses wrapper around one of the many JavaScript terminal emulators, and hook all the file I/O into Dropbox, and it should not be particularly difficult.

For emacs, I use the following:

1. I create a TAGS file with exuberant ctags (not the default etags - note that both have a file called etags, to find out which one you have, issue `etags -v`.).

2. Use the ido-find-file-in-tag-files mentioned here: http://www.emacswiki.org/emacs/TextMate Answer 3, mapped to `C-x C-g`.

This might be a bad choice due to C-g, but it's close to C-x C-f, so I prefer that.

That's a great feature for bigger projects.

I would love to see a similar grep-type feature, where I can quickly search through the files in a repository for text. (Yes, I know there's advanced search, but that's so disruptive to my code reading.)

Is github going to be textmate 2?

Even _ Allan Odgaard_ is working for GitHub now?

More seriously, I wonder if this would be an interesting direction for GitHub to move in; sorta picking up where Heroku left off. They already do let you edit files via the web, it'd just be keybindings... and a ton of other details since I know nothing of GitHub's internals.

In fact, that's probably a terrible idea. But something to think about...

Wow, really well implemented! Normally I git clone, open the repo in vim, then use ack.

Github also has very good keyboard shortcuts in the Issues section. Gmail shortcut users will feel right at home.

I'm so blown away by this it makes me want to ask for another one, ack in project? :)

Oh I just want to give github the biggest bear hug. You guys rock.

Github just beat the internet

EPIC WIN!

Reply on news.ycombinator.com