Join GitHub today
Use presentation compiler for REPL tab completion #4725
This brings tab-completion in the REPL in line with the experience in IDEs and ENSIME-powered editors.
Review by @som-snytt
referenced this pull request
Sep 2, 2015
Sorry I've been squeezed for time by life + work, the classic rock + hard place respectively.
I think I included that SI-1931 commit b/c what it touches and likely conflicts, ugh. Including test output. I tried & failed one day to normalize the line numbering; I didn't try hard.
I see some of the previous commits were squashed? I'm not partial to history that way, but hard to track at a distance. You've got to raise the barrel a bit and account for wind, then maybe you hit the target? etc.
Soon we can use "resugar" without quotes. I mean resugar.
I hope someday you can comment on an ammonite issue, "fixed in scala repl." Which I guess needs a name now, someone should create an issue.
I'm not going to include this in this PR, but I couldn't resist trying out some of this hole driven programming that the cool kids are raving about:
Another teaser: we can hijack keybindings in
Could use this for a more convenient version of
This isn't your fault, but right arrow sorts to the bottom. VBAR too. As opposed to category symbols coming first. Because we love symbols and encourage their use.
OK, I see how the getCamel thing works, neat.
I kind of think this should work:
Basically, all my woes are due to caps; I was going to add ignorecase eventually. I have one machine where it's enabled in shell, another not because I'm lazy to look up the syntax, so I suffer. Yes, I suffer, but I appreciate it all the more when it works.
So I'd want not only
I guess we'd want
You probably noticed it offers
I don't suppose you'll be offering XML completion?
The new name for Typesafe could be
It's biased to beans:
isn't there a danger that this clears messages other than those created during the specific
Regarding memory, we create and discard the presentation compiler at each press of TAB. This is in addition to the resident compiler that is held for the duration of the REPL session. I think this is fairly low risk: for applications that are embedding the interpreter and that might be memory sensitive, no cost is incurred (they don't trigger autocompletion). For interactive users with JLine, the short lifetime should avoid the extra objects surviving to the old generation.
FWIW my memory usage conclusion wasn't wrt total memory held, but memory retention behavior. You guys set a max of 256mb somewhere in your she'll script, which works great, but I wanted to leave Ammonite's open ended because I've used it for some relatively large non-memory small-dara work.
The interesting conclusion is that G1 keeps the heap smallish when the working set is smallish, whereas the default GC let's it grow to the max heap size, e.g. 4gb on my laptop, even if the working set never goes above 100-200mb.
Ammonite keeps the pressy around but initializes it lazily, so it isn't part of that trial either =)