Do you have an idea for making RStudio better? We'd love to hear about it! Here are some tips from the product team on writing good feature requests.

Your first job when filing a feature request is to make sure that it isn't already filed. We get feature requests every day, so there's a reasonable chance that someone else has had the same idea; just search our issue list! Feature requests are marked with the enhancement tag. Here are our most popular requests:

Open RStudio Feature Requests

If you find that someone else has already filed the feature request, don't just move on! Instead, help us know that you're interested, too:

1. Add a thumbs-up to the feature request to vote for it. This helps the request become more visible to the team.
2. Optionally add a comment with any insight and background you have that isn't already part of the conversation.

A good feature request describes the context in which the feature will be used. It's easy to forget to write about context because you already know it so well that it seems obvious! Just like any tool, though, the best improvements are made with a deep understanding of how it's used.

Add an option to beep whenever the letter Q is emitted.

I regularly use the doneQuickR package, which emits the letter Q when a task is done. I'd like RStudio to notify me when the Q is emitted so I know my task is done. A beep would be perfect because I'm usually working across the office while it runs.

Most feature requests only describe solutions -- that is, a specific product improvement.

Make your feature request better by describing the problem you are facing, and only then proposing the feature request as one solution to that problem. You might find that the product team (or another RStudio user) proposes a different solution you hadn't thought of.

Make it so scrolling with the mouse wheel is twice as fast when I hold down Ctrl.

I often add code to the bottom of the file, then scroll to the top to update a revision date. That takes a long time because my files are sometimes thousands of lines long. I'd like to be able to scroll faster, and in my second favorite program I can do that by holding down Ctrl while I scroll.

Is there already software that has the behavior you're interested in? What is it, and how does it work?

Can you give a concrete example of how you'd use the feature? A relevant code sample?

What other ways did you try to solve your problem?

Are there any relevant existing standards or conventions?

Can you draw a picture of what you're imagining?

You get the idea!

There's no need to decorate the title of your issue with words like Enhancement or Request. Use your feature request's title to state it as simply and clearly as possible, with ordinary casing. This will help other people find it when they're looking to contribute.

[ENHANCEMENT] Too Hard to Scroll on WINDOWS RStudio Desktop 1.1.442, Need More Scrollbar Space

Increase scrollbar width on Windows

Title: Add support for custom RStudio color schemes based on .tmtheme files

I'm a partially color-blind user of RStudio. I have a hard time seeing the difference between the color for variables and the color for functions in almost all the color schemes that RStudio uses. This makes it more difficult to write code.

I've already developed a number of color-blind friendly editor themes in the TextMade .tmtheme format (link to spec). You can see my color schemes here:

• Theme 1 (link)
• Theme 2 (link)
• Theme 3 (link)

However, I can't use these in RStudio since it doesn't offer a way to use custom colorschemes. It'd be great to be able to use these .tmtheme color themes in RStudio.

As an example, I really like the way my second favorite program, Mark's Editor, handles these: I drop the .tmtheme file into a special folder in my home directory and it just shows up as an option in the preferences pane.

Thanks for a great product!

Notice how this feature request:

• Is simple and to the point
• Describes the problem being solved
• Proposes a specific solution
• Gives context around how and why the solution will be used
• Links to relevant examples of context and existing work

It should go without saying, but unfortunately it doesn't: don't file a feature request as if it were a bug. It might feel like a missing feature "breaks" the product for your use case, but that doesn't make it a bug!

It's also not helpful to add comments such as "it's shameful that this request has been ignored" or "it's been years, why hasn't this been implemented yet?". Most people who are reading this use RStudio for free, and RStudio has a small core dev team. We care very much about our community and we probably love your idea, but we can only do so many features in each release while keeping quality and stability high. Help us focus on the very best ones by writing great requests!

There's no better way to get your feature request implemented than to do so yourself. RStudio is primarily written by a core team, but we frequently take pull requests from the community; see our CONTRIBUTING guide for details.

We also have an extensive Beginner's Guide to Writing RStudio IDE Features to get you started, and you'll find that we're happy to help if you get stuck.

If you find all this daunting, or only have a fuzzy idea of what you're after, you might try posting on the RStudio community forum to collect ideas and feedback from other RStudio users. You can find the IDE section of the community forum here:

RStudio IDE Community Forum

Many of the best parts of RStudio started out as ideas from the user community, and we're very grateful for each one. Thanks so much for taking the time to write up a thoughtful feature request.