Closed jordwalke closed 10 years ago
A couple of things that might come from a potential refactor (cc @nomothetis)
myFunction(varOne, varTwo)
- where varOne
and varTwo
are snippet placeholders where you can tab through to specify each. I'll add these to the master issue.These things are really separate features altogether, and we'll be implementing them as such. Making the completion window non-modal is critical for a variety of internal reasons as well as the obvious annoyances that you're running into, and I think it's a good starting point, but there's a whole lot of stuff we can do to improve it.
As an aside, I think completion used to try to invoke a snippet when you selected it. I removed it, but that may be worth plugging back in at some point. We'll see how things go.
As an aside, I think completion used to try to invoke a snippet when you selected it. I removed it, but that may be worth plugging back in at some point. We'll see how things go.
I like the current behavior that you've implemented. It seems better to perfect the simplest case first. I'd eventually like to invoke snippets when selecting an entry, but sometimes that is a task that can't be determined by Vico in the first place - it has to be a plugin that does it (because it can run the type system/compiler and get the method args etc - for method completion) so I agree with your decision to leave it out of the core. (As long as the autocomplete refactor allows room for plugins to assist (eventually)).
Ah, I see what you mean by snippet then. Yes, allowing placeholders in pluggable completions is definitely a goal.
I've done an initial round of work on this. It's not perfect yet, but it's behaving better than the old version in every way already, I believe.
Strange: On Mac OSX 10.8.5, I only get one row - everything else is invisible. But for that first row the completion window seems to be working correctly, except for snippets. While in a snippet, I am having a hard time getting the completion window to open.
One row meaning one completion result or one row of the file?
Is the snippets thing a regression or is it a new issue? Can you give me steps to reproduce it?
So I cloned your branch, and I open a Vico window:
Start typing on the first line in the document - everything is normal.
Hit enter to go to the second line.
(Cursor isn't shown on the second line - it's oddly shown at the first character on the first line)
Start typing - can't see typing on the second line (but it's actually there!)
(I know the text on the second line is secretly there because if I hit J
to join them, the second line is joined to the first and I can see the text I typed).
As far as the snippets thing being a regression, I think it's the same issue as before (https://github.com/vicoapp/vico/issues/69), but slightly worse because now the window doesn't pop up at all - I'm sure you could solve it in a follow up diff.
But it feels so much better - more responsive - less heavyweight. Clearly a better solution.
Awesome. The single line thing doesn't happen to be related to #62 with no line numbers causing issues, does it?
As a Cocoa noob, can you explain why you went with an NSPanel
over something lighter weight like a UIView
subclass?
Ha! It just might be related to that ;)
It was confusing because you only see that bug when you restart Vico.
The weight was less important than the position in the view hierarchy in this case. NSPanel
is an NSWindow
, which means that it can be taller than the text window. In the situation where the Vico window is 4 lines tall but there's a lot more screen real estate below, we want our completion popup to be able to overflow the editor window. It also saves us the headache of having to think about the broader view hierarchy within a Vico window altogether.
(Side note: UIView
is Cocoa Touch, NSView
is Cocoa :) )
I'll be looking at 62 again very soon, as that's a pretty annoying bug.
I see, thank you. I'll keep playing with it. Definitely feels like a step forward already! Looking at some of the mocks in the discourse group has me salivating at what this popup panel could look like :)
I confirmed that the snippet behavior (only when mirroring) is not a regression.
Perfect. I'll hopefully have time to fix some of the small oddities (e.g., switching to another app and then back while the completion popup is up makes it disappear, but the application still thinks it's up) tonight.
All right, this seems more or less ready to go. Let me know if you find any nasty bugs.
I'll hopefully get the chance to take this guy for a spin today.
Ok, got some positive feedback all around here, and it's been behaving well in my experience. Going to go ahead and merge to master and then refine from there.
Sounds great! I wasn't able to spot any serious regressions.
Question for @Shadowfiend: Having the completion window pop up as you type is a necessary feature for a modern editor, but have you personally began to appreciate the feature yet in your daily use? (having the autocomplete window always-open) :)
It's a wash right now. The ranking of the results is pretty terrible, so half the time it's more annoying than useful. The other half it makes life easier. I'll be working on result ranking soon, based on longest common subsequence and proximity to the current line, and possibly also based on scope (that one might be a bit harder, though). If that all seems to go well, I'll probably switch the autocomplete default to fuzzy matching rather than the current exact match.
(Some initial work on that is in the rankling-ranks
branch.)
The new autocompletion is quite awesome, but it's distracting to see a new modal window pop up for completion. It's great that it's always there, but the visual style of the window feels so heavy handed - the focus is lost from Vico. Sublime and Vim's autocompletion appears to be embedded int the document which has a much nicer ambient feel. Change your mac os's three circle buttons to be red[close]/green/yellow (instead of the gray theme) to really see the effects of a modal window - the colors of the window's close button changes as you type!