Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling robe-doc-for from elsewhere #11

Open
purcell opened this issue Nov 5, 2013 · 15 comments
Open

Calling robe-doc-for from elsewhere #11

purcell opened this issue Nov 5, 2013 · 15 comments

Comments

@purcell
Copy link
Contributor

purcell commented Nov 5, 2013

Hey Dmitry! I'm writing an auto-complete source for inf-ruby-mode, and I'd like to hook the pop-up documentation into robe when it's available. robe-doc-for is the obvious entry point for this, but it expects a spec rather than just a symbol name. Is there an easy way to get the former from the latter? I didn't see anything in inf-ruby itself for querying documentation.

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

Hi Steve,

Spec is a more or less resolved/disambiguated method. To get the list of them for a method name, you make a call to method_targets in the backend.

robe-jump-modules does more or less that on the Elisp side. It also tries to resolve the context at point, so I should probably extract the relevant piece of code to another function.

@purcell
Copy link
Contributor Author

purcell commented Nov 5, 2013

That'd be cool. I just released an initial simple version of ac-inf-ruby without any documentation support for now.

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

Actually, why don't you just call (robe-request "method_targets" target module instance super robe-jump-conservative), like robe-jump-modules does in the end?

Let me know if you need help deciphering the arguments.

@purcell
Copy link
Contributor Author

purcell commented Nov 5, 2013

Can do, if the signature of that method is going to remain fairly stable for a while.

@purcell
Copy link
Contributor Author

purcell commented Nov 5, 2013

Yeah, I think it's not practical to do that, because I'd have to reproduce the logic in robe-call-context, which works off the buffer contents, which won't be the same as the selected completion candidate. I guess I'd need something like a (robe-parse-call-context str)...

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

Can do, if the signature of that method is going to remain fairly stable for a while.

It's likely to change at some point, but I'll make sure to let you know.

I guess I'd need something like a (robe-parse-call-context str)

I was thinking you'd just ignore everything surrounding the method name. But if you'd like to at least recognize when the call target is a class, you can do (with-temp-buffer ...), insert the repl text after the prompt there, replace the prefix with the completion candidate and then call robe-jump-modules there.

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

I just released an initial simple version of ac-inf-ruby without any documentation

I like the difference in verbosity. :)

@purcell
Copy link
Contributor Author

purcell commented Nov 5, 2013

Re. the verbosity, yes, I need to give company another try. I switched over for a while several months ago, but eventually reverted, for reasons I don't now recall. And similarly, I'm now on about my 3rd attempt to live with smartparens instead of paredit.

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

It would be nice if you could recall the reason you went back the last time. Lack of integration with various packages, like Tern?

I've never tried smartparens myself, paredit and autopair work reasonably well so far. Maybe in a couple of years... :)

@purcell
Copy link
Contributor Author

purcell commented Nov 5, 2013

Yep, I wish I could remember. I'll try flipping back so that I can give more useful feedback.

Re smartparens, I've just today gone back to paredit in lisps, and electric-pair-mode + paredit-everywhere elsewhere. Yesterday I suggested that the author copy the paredit test suite, which he agrees is a good plan. I like the idea of smartparens - and of providing feedback to help it improve - but some of the quirks have been frustrating on a day-to-day basis. I'd rather have something less complex which does 80% of the same thing but with 100% reliability.

@dgutov
Copy link
Owner

dgutov commented Nov 5, 2013

I'd rather have something less complex which does 80% of the same thing but with 100% reliability.

Same here.

With electric-pair-mode, I mostly miss the Autopair newline feature, when if point is directly between two parens, it adds two newlines, one before and one after point, and indents the current line. Does smartparens do that?

@purcell
Copy link
Contributor Author

purcell commented Nov 6, 2013

I haven't noticed it doing that, but smartparens was doing a lot of unexpected stuff by default, e.g. if you had:

(foo-b|ar-baz "one")

where | is point, and you pressed C-k, you'd get:

("one")

which confused me. There's lots of magic whitespace behaviour too, and special behaviour inside strings. It can all be configured, but I really just want paredit + reasonable pairing.

What finally turned me off was that there's a show-smartparens-mode which does nice things like highlighting the corresponding end in a ruby buffer if you have the point on def. But in certain buffers this became very slow, because the ruby syntax isn't regular enough to make it easy.

Still, give it a try sometime and see what you think.

@dgutov
Copy link
Owner

dgutov commented Nov 6, 2013

that there's a show-smartparens-mode which does nice things like highlighting the corresponding end

FWIW, Ruby with SMIE enabled integrates with show-paren-mode and also highlights paired keywords. And does it rather snappily, I'd say.

@purcell
Copy link
Contributor Author

purcell commented Nov 6, 2013

Ooh, shiny! -> dashes off to try it out

@purcell
Copy link
Contributor Author

purcell commented Nov 6, 2013

Works nicely! I've been using mic-paren for a while, and I'm thinking I might be able to drop that in favour of plain show-paren-mode now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants