-
Notifications
You must be signed in to change notification settings - Fork 172
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
Add hover functionality for dependencies in Gemfile #1279
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really neat idea. Thanks for proposing this. I left some comments, but they are mostly details
When testing this, I noticed problems with some gemspecs that use heredocs, e.g.: https://github.com/lsegal/yard/blob/2d197a381c5d4cc5c55b2c60fff992b31c986361/yard.gemspec#L7-L12 Since the lines contain leading whitespace, the markdown treats that as code, so it renders like this: Really the gemspecs should be using |
I think we should match rubygems.org: |
lib/ruby_lsp/requests/hover.rb
Outdated
info = [spec.description, spec.summary, "This rubygem does not have a description or summary."].find do |text| | ||
!text.nil? && !text.empty? | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can use #present?
here since it's an Active Support extension—not the prettiest thing in the world but I think it's roughly the same in terms of functionality based on this guide.
@vinistock Thanks for the review! I think I incorporated all the feedback, let me know if there's anything else missing. |
I think this actually points out two issues, one being the incorrect use of heredocs and the other being that the content itself isn't actually markdown anyways. I see a couple options:
Doesn't solve the original issue with heredocs but I think it might preserve the intentionality better in some cases, e.g. Minitest: I'm fine w/ any solution (or something else entirely, or a combination of them). |
Option 1 makes sense to me. I can't think of a situation where there would be intentional leading whitespace in the description. (Minitest is an odd one, I wouldn't worry too much about it since Rubygems.org doesn't render it well either: https://rubygems.org/gems/minitest/versions/5.20.0). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried the latest update and YARD now displays correctly. Great work!
# Remove leading whitespace if a heredoc was used for the summary or description | ||
info = info.gsub(/^ +/, "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the desire to make the presentation look good, but I wonder if we should instead create incentive for authors to fix their descriptions.
For example, YARD clearly wanted to use the ~
version of heredocs given that the entire description is indented at the same level. Feels like changing that in YARD would also ensure other tools display it correctly, rather than trying to account for that in the LSP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, even the example in the Rubygems docs uses <<-
with leading whitesapce:
https://guides.rubygems.org/specification-reference/#description
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can open a PR on https://github.com/rubygems/guides to use the squiggly heredoc. I would assume the docs pre-date the newer syntax itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that would be a helpful.
I still think we should strip the leading whitespace though, since some gems will never get around to updating, and it results in a disjointed experience for the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more, even if it was supported in all non-EOL Ruby versions, it might actually restrict the gem from being installed on older versions due to invalid syntax, which might not be a reasonable trade-off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened rubygems/guides#352 to address it in the RubyGems guides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more, even if it was supported in all non-EOL Ruby versions, it might actually restrict the gem from being installed on older versions due to invalid syntax, which might not be a reasonable trade-off.
The .gemspec
file is not actually part of the distributed .gem
package so I don't think it would be a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL they're stored separately. It looks like the heredoc itself actually gets stripped out anyways and converted to a plain-old string literal (looking at my local copy of ~/.gem/ruby/3.3.0/specifications/yard-0.9.34.gemspec
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let's ship this PR and we can always revisit the blank spaces thing later. No need to hold it back.
@@ -181,7 +181,6 @@ def test_hovering_over_gemfile_dependency | |||
|
|||
assert_includes(response.contents.value, spec.name) | |||
assert_includes(response.contents.value, spec.version.to_s) | |||
assert_includes(response.contents.value, spec.description) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think CI was failing on this line. Since we're stripping the description, I don't think we should assert on it anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the contribution!
# Remove leading whitespace if a heredoc was used for the summary or description | ||
info = info.gsub(/^ +/, "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let's ship this PR and we can always revisit the blank spaces thing later. No need to hold it back.
Motivation
I've noticed that engineers are often inclined to litter their Gemfile with comments that summarize each and every gem dependency (often just pulling out the summary straight from the gemspec). This feels like a job for an LSP.
Implementation
Check for gem dependency definitions and add hover based on gem specification if applicable.
Overall, this PR could probably use some additional refactoring and test cases, but I wanted to present the concept for validation first.
Some open questions:
Automated Tests
Added a simple test case.
Manual Tests
Gemfile