Have you ever been in the middle of writing a code comment and find yourself needing to switch context for a single minute? When you returned to the diff, did you find that your comment disappeared while you were in the middle of writing it?
In the latest release of GitHub for Visual Studio, we added the ability to save drafts of comments. As they are written, comment drafts are saved to a SQLite database and displayed when a user comes back to them later. Now, in-progress comments will never be lost again.
When reviewing a pull request, it’s common to write inline comments in the file diffs. Sometimes it’s necessary to switch back and forth between files (and other views) within Visual Studio. Now the diff can be closed and reopened and the in-progress comment is restored right where you left it.
After reviewing a pull request, it’s time to submit your review. From this view, you can navigate away and come back to the summary later so you can easily complete your review.
For creating a pull request, you can close the Create Pull Request form and return to it later—the title and description are filled out just as you left them. Even better, Visual Studio can be restarted and the content will be restored.
This is the latest feature we have added as we continue to build out our pull request workflow. Download the latest version of GitHub for Visual Studio and try it out.
Text editors like Atom have many features that make code easier to read and write—syntax highlighting and code folding are two of the most important examples. For decades, all major text editors have implemented these kinds of features based on a very crude understanding of code, obtained by searching for simple, regular expression patterns. This approach has severely limited how helpful text editors can be.
At GitHub, we want to explore new ways of making programming intuitive and delightful, so we’ve developed a parsing system called Tree-sitter that will serve as a new foundation for code analysis in Atom. Tree-sitter makes it possible for Atom to parse your code while you type—maintaining a syntax tree at all times that precisely describes the structure of your code. We’ve enabled the new system by default in Atom, bringing a number of improvements.
Atom’s syntax highlighting is now based on the syntax trees provided by Tree-sitter. This lets us use color to outline your code’s structure more clearly than before. Notice the consistency with which fields, functions, keywords, types, and variables are highlighted across a variety of languages:
In most text editors, code folding is based on indentation: lines with greater indentation are considered to be nested more deeply than lines with less indentation. But this doesn’t always match the structure of our code and can make code folding useless in some files. With Tree-sitter, Atom folds code based on its syntax, which allows folding to work as expected, even for code like this:
Atom also uses syntax trees as the basis for two new editing commands:
Select Larger Syntax Node and
Select Smaller Syntax Node, bound to Alt+Up and Alt+Down. These commands can make many editing tasks more efficient and fun, especially when used in combination with multiple cursors.
Parsing an entire source file can be time-consuming. This is why most IDEs wait to parse your code until you stop typing for a moment, and there is often a delay before syntax highlighting updates. We want to avoid these delays, so we designed Tree-sitter to parse your code incrementally: it keeps the syntax tree up to date as you edit your code without ever having to re-parse the entire file from scratch.
If you write code and you’re interested in trying our new system, give the new version of Atom a try. We’d love to hear your feedback—tweet us at @AtomEditor or if you’ve run into a bug, open an issue.
In early September, we released a new extension to the Visual Studio Marketplace that supports GitHub pull requests. On October 17, day two of GitHub Universe, we’ll share the stage with the Visual Studio Code Team at Microsoft to give you updates and insight into how we are building the extension during our talk Cross Company Collaboration: Extending GitHub to a New IDE.
We design GitHub for developer experience—so you can effectively collaborate and build great software. To bring you a user-friendly experience that invites novice and seasoned developers alike, it’s important we identify new opportunities. We’ve been working since 2015 to provide a GitHub experience that meets you where you spend the majority of your time: in your editor.
As .NET developers writing in Visual Studio, we recognized a large gap in the ability to collaborate in this environment. In 2015, we brought all Visual Studio developers an extension that supports GitHub.com and GitHub Enterprise engagements within the editor. And today, you can complete an entire pull request review without ever leaving Visual Studio.
Not a .NET developer on Windows? No problem! We also support a first class Git and GitHub experience for Atom developers. Access basic Git operations like staging, commiting, and syncing, alongside more complex collaboration with the recently-released pull request experience.
Unity game developers can now use Git within Unity for the first time to clone and sync with GitHub.com and lock files, including large assets that game developers often have in their projects.
In Winter 2017 we started planning our integration with VS Code after seeing how it influenced developers around the world. With a basic pull request experience in both Visual Studio and Atom, we knew we wanted to start with that level of collaboration.
In Spring 2018, we reached out to the VS Code Team and discovered that, since they were building VS Code on GitHub, they felt they were missing that collaboration piece in their editor.
VS Code developers now have the first iteration of a pull request review experience within VS Code. With a small group of people, we launched the public preview of the GitHub Pull Request Extension in September 2018.
This new extension gives developers the ability to:
Thanks to Kenneth Auchenberg (Microsoft), Rachel Macfarlane (Microsoft), Kai Maetzel (Microsoft), Peng Lyu (Microsoft), Sarah Guthals (GitHub), Andreia Gaita (GitHub), and Ashi Krishnan (GitHub) for your continued work on this extension. :sparkles:
Want to learn more? Join us at GitHub Universe 2018 on October 17 at 10:15am. We’ll demo the extension for you, give you an update on what we’re releasing next, and show you how you can contribute. If you can’t make it to San Francisco in time, tune into the livestream on githubuniverse.com.
As always, you can reach out to the Editor Tools Team by tweeting at (@githubvscode) or joining the conversation in our open source repository. And if you’d like to participate in usability studies around our extension, we invite you to fill out a short survey.
In our latest release of GitHub for Visual Studio, we introduced a new clone dialog that improves the load time of the repository list using GraphQL. There are also separate tabs to clone repositories from GitHub and GitHub Enterprise and an additional option to clone from a URL.
The first way to clone a repository is using the “GitHub.com” or “GitHub Enterprise” tabs and selecting a repository from the list.
There’s also the option to use the “Filter” field to narrow down the list of repositories instead of scrolling down the full list.
The second way to clone a repository is to enter either a full URL or the username and repository names. This is necessary when you want to clone a public repository which you (or one of your organizations) don’t own.
We’ve also updated the default clone path. Previously, we would just clone to the default clone path (found under
Team Explorer > Settings > Global Settings > Default Repository Location). Now, you’ll find that the owner and repository name are appended to your default clone path, adding more structure and organization to your local repositories.
We’ve also started to localize GitHub for Visual Studio to give more users a first-class experience when developing with GitHub. We first focused on translating the extension to Chinese.
Figuring out the best practices for localizing an extension has been a learning process. Thanks to @maikebing for providing both simplified and traditional Chinese translations and to @grokys, @jcansdale, and @stanleygoldman for learning how to use Crowdin, the platform supporting our internationalization, and understanding how our extension can support multiple languages successfully.
We’re excited to do more localization in the future for other languages. To see our progress or get involved, check out the issue.
Thanks to @jcansdale, we’re able to learn through metrics whether our changes are supporting a more effective workflow for users. We’re also currently conducting usability studies for a new feature that we’re building and looking for participants to sign up. If you would like to participate in our 30-minute study, fill out this short survey.
There’s a new way to view and interact with new pull requests in Atom through the GitHub package!
First, we’ve added a pull request list view. Now you can see the most recent pull requests in the GitHub tab Ctrl+8 with information such as:
When you click on a pull request, you’ll see a view similar to the conversation view on GitHub.com, and can quickly check out the PR with the click of a button!
The top of the view contains the most important information:
After this information, you will find the same conversation view you would see on GitHub.com. Sometimes, it may be something as simple as the list of commits and other times it might be an entire conversation.
We’ve also added some user experience enhancements, such as enabling the hover card functionality in @mentions and references to other issues and pull requests:
In addition to seeing more information about your existing pull requests, you can also open a new pull request directly from Atom.
Starting from master, you will see a new message in the GitHub pane providing you with information on what you might want to do next, such as checking out an existing branch or creating a new branch. If you create a new branch, you will be prompted to start making changes to your branch. Finally, if you make changes, stage them, and commit to your branch, you will be invited to publish your branch and create a pull request with those changes:
Clicking Publish + open a new pull request will launch your browser at the draft of your pull request on GitHub.com. There, you can add an extensive description, reviewers, labels, and more. Visit https://github.atom.io/ for more information on the GitHub panel in Atom.
We also care about making the experience consistent with GitHub.com. You might notice that commit messages in Atom now support emoji! :sparkles: to @annthurium for making committing in Atom a bit more entertaining:
We’re excited about the new experiences we’re bringing to the Atom community and looking forward to continuing to improve our package. You might have seen in a recent blog post that we’re working on improving our understanding of who you are, how you write code, and how you collaborate with your team. This involves usability studies, as well as a large project that @annthurium and @jasonrudolph have been working on to improve our metric gathering. Read about the details of Telemetry on the Atom Blog.
We have integrated Telemetry into our GitHub package for Atom so that we can better understand what features are useful—and which are being left undiscovered. We invite you to revisit your opt-in decision on metrics if you’re interested in helping us improve our package by sending metrics through our secure GitHub data pipeline. Just open your Atom Preferences and choose Allow limited anonymous usage states, exception, and crash reporting.