Much nicer method view panel

[pfitzseb]

This implements a nicer and searchable frontend for the toggle methods command, as mentioned in #76.

Julia side.
Ink side.

ToDo:

• Default shortcut!
• style improvements, maybe? I'm open to suggestions. cc @spencerlyon2, @mfcd
• highlighting of matched keywords. That is actually not all that hard, see here, but I didn't feel like copying their method just like that...
• Just thought of it -- this should probably be implemented with a promise, right?
• Errors should be handled gracefully instead of not at all.

[MikeInnes]

So to clarify, this is designed to replace the Juno/LT approach of just displaying the methods inline, right? Or is it more to augment it?

[pfitzseb]

Yeah, pretty much. Could also be viewed as a replacement for Ctrl-R in plain Atom.

This doesn't change the rendering of e. g. methods(sin).

[pfitzseb]

Highlighting is implemented:

If no one has any problems with the styling or any other suggestions, this should be good to merge.

[pfitzseb]

We should really have a default shortcut for this!
Suggestion:
Use C-Shift-J C-Shift-M for selecting modules and C-J C-M for getting methods? Would be close to the C-J C-D we currently use for docs. Thoughts? cc @one-more-minute

[sglyon]

Quick question, will the path separator be / on unix systems?

[pfitzseb]

Yup. Should be exactly the same as in backtraces and the like.

[sglyon]

OK great! I like your keymap suggestion

[sglyon]

What would it look like if each method had a shorter list item? It'd be nice to see more at a time

[pfitzseb]

What about this?

[sglyon]

I like it

[MikeInnes]

This is looking really good – big 👍 for screenshots ;) Any chance of having the sig on the left and the path on the right? There's also a method somewhere which will humanise package paths, i.e. C:\Users\...\Lazy\... ➡️ Lazy\src\Lazy.jl -- may well be worth applying that.

I've been thinking a bit how these things should fit together, so that all of our UI components have a clear purpose. Here's my proposal:

• We have one docs command which folds docstrings and methods together in a tree view (similar to the rendering of functions currently). Docstring is shown and methods are hidden by default for click-and-browse exploration.
• We also have a jump to definition command which loads up the appropriate file/location for the given object. If there's only one go straight there, if not launch this method view to navigate quickly to the right one. The command itself would no longer be method-specific.

How does that sound? It's not critical that this is all working thoroughly for this PR to be worth merging, of course, but I think that's what we should aim towards. (Open to other ideas of course!)

[pfitzseb]

Yeah, that sounds like a good plan.

Couple of thoughts:

• This PR implements methodswith(word) when word is a type instead of a method -- would we drop that functionality or fold it into the docs command (not ideal, since that's not searchable)?
• How could jump to definition be implemented? Combination of the symbols-view approach (for local definitions) and methods?
• Do you have any ideas how refs ot other methods should work in the inline docs? Open a new pane or a browser window to display those or have it all inline? Matlab for example takes the first approach -- you get short docs with help method and clicking on the links to related methods opens a separate documentation browser. I think this may be better than doing all that inline, but I'm not sure.
• Imho getting to the definition isn't everything there is to a method view command -- it's also great for exploration of the available functions. We could conceivably have some way to open docs from there as well.
• The methodview logic should probably be used by autocomplete as well: It'd be super cool to get a list of methods (and maybe even a short doc string) after typing the opening paren, kinda like in VS:
  
  Of course we won't quite get to that level since Julia is a dynamic language, but I really like that direction.

Okay, went a bit on a tangent there, but a bit of brainstorming can't hurt ;)

Also: Maybe we could draft a design spec somewhere, @one-more-minute? Just so we'll have all these thoughts written down in one place and can implement things according to that.

[pfitzseb]

This is now mostly superseded by JunoLab/atom-ink#34.