dgutov
Calling robe-doc-for from elsewhere
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.
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.
That'd be cool. I just released an initial simple version of ac-inf-ruby without any documentation support for now.
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.
Can do, if the signature of that method is going to remain fairly stable for a while.
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)...
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.
I just released an initial simple version of ac-inf-ruby without any documentation
I like the difference in verbosity. :)
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.
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... :)
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.
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?
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.
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.
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...