These are chat archives for ensime/ensime-atom
This is interesting. It would be super-cool if someone would help me with getting full session logs on traffic between client and server for a "working client" compared to atom to understand what the difference is. I STILL think after @fommil 's info about contents vs contentsIn that this might be the issue. However, some false positives remain. The issue is that ensime-atom sends file content over the wire while at least emacs writes it out to file and just sends the file path to ensime-server. This I haven't fixed yet, but might be able later today.
One thing I HAVE fixed is that I noticed that ensime-atom unnescessarily always sent a typecheckBuffer request just before asking for implicits. This I put under conditions (only if buffer is edited). I think that the whole typecheckBuffer with contents over the wire is what making atom provoking weird server behaviour.
I'm going to put out a release now so that you can test if you get rid of the false positives on imports. I can't seem to get them anymore locally :)
Just noticed I hadn't cleaned up properly after moving to linter. Here that is: hedefalk/ensime-atom@2d206e5.
@jeffwilde, sorry to remove that really nice code :'(
By the way, the extra red thing in the gutter is removed in a later commit hedefalk/ensime-atom@2d206e5. That was our own, but linter just use that red circle.
@ThomasMeijers Hi Thomas! Glad you like it!
What's missing for import suggestions is UI. As you saw, I have added the API call to get a list but then I just picked the first suggestion as a super-quick-hack when I was "doing real work". I agree that autocomplete-plus is not the right tool to create a view, other than maybe to look at for inspiration. I think what we want to do is create a general ui component for that kind of dialogs. "select something from a list that is shown at a point of the text editor/cursor". For instance, we also have the "show implicits" functionality that currently just displays a list without any actions on it. However, I'm thinking this could later be an "expand implicit" function when selecting one such item.
Anyway, I think we should try to create a coherent UI with components we can re-use for different use cases. Personally, I was planning to implement this using vuejs. (vuejs.org) which I have used half-arsed for a few use cases currently, like here: https://github.com/ensime/ensime-atom/blob/master/lib/views/public-symbol-search-vue.coffee
I want to remove code duplication and be dry about it though. Right now everything is a bit of a mess.
I don't want to specify to much though as this probably just makes it harder for you or anyone else to feel confident in contributing. I'm game for anything that makes it better than currently and when have time we can re-design if we want. So if you have any idea that works - go ahead!
I just noticed one thine: The package default keymapping of cmd-shift-T to ensime:search-public-symbol seems to clash with a new core binding to reopen last close pane giving really weird results. If you want to use that feature with that keymapping, paste
'atom-text-editor': 'shift-cmd-T': 'ensime:search-public-symbol'
or similar in your private keymap file.
I think the problem might be the linter. I struck some outofbounds-things with my ugly hack here:
I knew I would sooner or later. Problem is that we get range as beginning row, col + beg, end in absolute character offsets while the linter uses the Atom style of [[row, col], [row, col]] for a range. We can't actually translate that without reading the files which is kind of something we don't want to do I think.
both defined in terms of point
def line: Int = if (hasSource) source.offsetToLine(point) + 1 else 0 def column: Int = if (hasSource) calculateColumn() else 0
val end = pos.withShift(pos.end-pos.start) end.line, end.col
setMessages(JSON.parse(JSON.stringify(messages)))to not make linter blow up my CPU :)