When I open CRANsearcher at the RStudio command prompt or via Add-Ins, I cannot type text in the search box and that box is partially concealed by "Column visibility". Might this be a Windows issue? Have others who run RStudio in Windows had success with CRANsearcher? It's also possible this is related to work computer browser restrictions.

Would it be reasonable to extend the searched text to include function documentation and vignettes (possibly as an option)? I have made a couple of searches recently where the serach terms only occurred in the function documentation - so i could find the package via Google, but not CRANsearcher.

Quite perfect as it is, I think if the search bar could be frozen so we could always see it. A great work it is, even it has not been updated for years.

I get this error when launching CRANsearcher from RStudio 1.0.143 on macOS Sierra 10.12.5:

CRANsearcher:::CRANsearcher()

Listening on http://127.0.0.1:3275
Warning: Error in url: URL scheme unsupported by this method
Stack trace (innermost first):
51: url
50: getPackages
49: eval
48: eval
47: %>%
46:
45: do.call
44: server
3: shiny::runApp
2: runGadget
1: CRANsearcher:::CRANsearcher
Error in url(description, "rb") : URL scheme unsupported by this method

Please change the date format for the CRAN "as of" date at the bottom of the CRANsearcher dialogue to ISO (matching the format of the last release dates. The current format is only used in one country in the world.

Thanks (and CRANsearcher is great!)

When you use multiple search terms (say X, Y, and Z) the search summary at the bottom of the CRANsearcher pane will say something like:

There are n1 packages related to 'X' on CRAN (as of 09/23/17). There are n2 packages related to 'Y' on CRAN (as of 09/23/17). There are n3 packages related to 'Z' on CRAN (as of 09/23/17).

Presumably CRAN is accessed for all search terms on the same date, so it is redundant to repeat the date for each search term. How about reordering to something like:

On CRAN at 09/23/17, there are: n1 packages related to 'X'; n2 packages related to 'Y'; n3 packages related to 'Z'.

In my workflow, I usually search packages via CRANsearcher, and then execute a comparison with packagemetrics package (number of downloads, tidyverse friendly......)
To that purpose (and I suppose many) would be very useful to donwload data after search.

I think the ability to export a data frame in the workspace that corresponds to the filtered results would be a welcome feature. Often times I will use the add-in to explore what packages are related to a certain technique or field, and want to save a record of the results so I can discuss further with colleagues or do some additional analysis of the packages identified. I'd be glad to submit a PR if this sounds like a worthwhile feature to you.

Blue row selection overshadows hyperlink text. Either choose a different background color or change hyperlink text.

If you search with multiple search terms, the results are the intersection of the sets of packages corresponding to each search term. That is, the terms are ANDed together. The summary counts at the bottom of the panel are the counts of the search terms *within the intersection rather than within CRAN.

For example:

principal ==> There are 134 packages related to 'principal' on CRAN

component ==> There are 353 packages related to 'component' on CRAN

principal component ==> There are 104 packages related to 'principal component' on CRAN

principal, component ==> There are 113 packages related to 'principal' on CRAN. There are 113 packages related to 'component' on CRAN.

principal, component, breakfast ==> There are 0 packages related to 'principal' on CRAN. There are 0 packages related to 'component' on CRAN. There are 0 packages related to 'breakfast' on CRAN.

Because the search terms are ANDed and the search term counts are with in the intersection, the counts must always be identical for each of the search terms and equal to the number of results returned.

It would be more helpful if the search term counts were counts within CRAN rather than within the intersection. This would help in modifying the query - especially when the query returns zero results.

Also, the wording "on CRAN" is misleading because the count relates to the intersection rather than all of CRAN.