
Searching a Million Lines of Lisp - pmoriarty
http://www.wilfred.me.uk/blog/2016/09/30/searching-a-million-lines-of-lisp/
======
alphapapa
Wilfred is a genius. The OP article is from about a year ago, but it laid the
foundation for the Emacs package he just released:
[http://www.wilfred.me.uk/blog/2017/08/30/helpful-adding-
cont...](http://www.wilfred.me.uk/blog/2017/08/30/helpful-adding-contextual-
help-to-emacs/)

~~~
sooheon
Ah this is where I've been seeing that domain before. Yeah, the other package
suggest.el is also a gem.

------
olewhalehunter
Tim Teitelbaum, one of the first researchers on IDEs summarized problems like
this in a quote from one of his papers.

"Programs are not text; they are hierarchical compositions of computational
structures and should be edited, executed, and debugged in an environment that
consistently acknowledges and reinforces this viewpoint."

It is unfortunate that most major code editors and IDEs today do not store
units of code (like Lisp SEXPs) as databases to be updated as you edit, which
would make problems like this or other operations like metaprogramming, formal
analysis, or documentation much easier to solve.

~~~
skrebbel
There are editors that do this. Notable, Jetbrains MPS comes to mind. It looks
like a text editor but once you use it you quickly notice that you're actually
editing the abstract syntax tree directly.

It's cool, but it has some major downsides too. For example, MPS stores the
source as XML, not text (since it isn't text, it's a tree). This makes lots of
basic tools we've taken for granted a lot harder, such as git merging etc.
They've had to make a custom mergetool just to make basic collaborative coding
feasible.

I bet there's other ways around that, all I'm saying is that text has major,
major upsides because of the enormous ecosystem support.

~~~
coldtea
> _It 's cool, but it has some major downsides too. For example, MPS stores
> the source as XML, not text (since it isn't text, it's a tree). This makes
> lots of basic tools we've taken for granted a lot harder, such as git
> merging etc. They've had to make a custom mergetool just to make basic
> collaborative coding feasible._

Doesn't solving this just require a text-to-AST, AST-to-text input and output
step?

Anyplace outside the editor the programmer just sees regular text.

~~~
ilikebits
The issue with this is that operations on text don't necessarily preserve a
valid AST. Doing `git merge` on the plain text of a source file may result in
invalid code, at which point you have other annoying questions to answer about
how to handle text that doesn't parse into a valid AST.

------
tyingq
Github's search went the other direction, where it's decidedly less useful
than grep. Case insensitive, and drops search string characters that provide
context. Like quotes, =, $, etc.

[https://help.github.com/articles/searching-
code/#considerati...](https://help.github.com/articles/searching-
code/#considerations-for-code-search)

------
vcdimension
He should try speeding it up further by compiling to C-code using this:
[https://github.com/tromey/el-compilador](https://github.com/tromey/el-
compilador)

