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

Webri - a new console app for accessing Ruby online HTML docs [expermental] #1213

Draft
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

BurdetteLamar
Copy link
Member

This is seriously experimental, and is best seen as a proof-of-concept.

I have not liked ri, so have worked up this app to get at the online docs.

@@ -0,0 +1,170 @@
# frozen_string_literal: true
require 'open-uri'
require 'nokogiri'
Copy link
Member

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 assume users would have these gems installed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed (for nokogiri); I think open-uri is installed with Ruby. But, better to avoid both.


def initialize(target_name, options)
release_name = get_release_name(options[:release])
entries = get_entries(release_name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we'd have sent 2 requests by this point just to get the release and entries list. Considering both of them are rarely changed, I think we may introduce something like rdoc-data used to do that packages all these information into a gem. And a tool like this can simply use it to generate the target url without making additional requests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On my machine(!), making the two requests is much faster than reading the static RI files.

So a new gem would include the data that this app gathers from the two requests? And thus not need nokogiri? Interesting. But would not have master (though I'm not sure that's a drawback).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more think about this idea (the gem, already containing the data for each release), the better I like it. Will explore.

@simi
Copy link

simi commented Nov 24, 2024

I have not liked ri, so have worked up this app to get at the online docs.

Can you explain on this a little? What's problem with ri? Why online docs? Can't we show simliar page but locally using ri --server and opening related page (for Array#join - http://localhost:8214/ruby/Array.html#method-i-join)?

@BurdetteLamar
Copy link
Member Author

I have not liked ri, so have worked up this app to get at the online docs.

Can you explain on this a little? What's problem with ri? Why online docs? Can't we show simliar page but locally using ri --server and opening related page (for Array#join - http://localhost:8214/ruby/Array.html#method-i-join)?

RI output is often poorly formatted (compared to the corresponding HTML). I'm aware of the HTML online docs, but not of whatever comes from ri --server. If that's available, so much the better!

@BurdetteLamar
Copy link
Member Author

I'll look into building a gem that would do this work without the user's needing nokogiri.

@simi
Copy link

simi commented Nov 25, 2024

@BurdetteLamar I think parsing of HTML will be too brittle, since any change in rdoc template will potentially break the parsing. Could be ri used in the background and once final target is located like method or class, run ri --server and open given page? I'm still not sure about the user experience, since the ri --server will be kept running around. 🤔

@BurdetteLamar
Copy link
Member Author

@BurdetteLamar I think parsing of HTML will be too brittle, since any change in rdoc template will potentially break the parsing. Could be ri used in the background and once final target is located like method or class, run ri --server and open given page? I'm still not sure about the user experience, since the ri --server will be kept running around. 🤔

I think @st0012's suggestion (about a gem) avoids the problem altogether.

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

Successfully merging this pull request may close these issues.

3 participants