meaghanlewis
In the latest GitHub for Atom release, we’re introducing two new features that will improve your commit experience.
Previously, DOM elements were rendered for every line of each diff, which meant a lot of work for React and the DOM to process. This led to rendered diffs being limited to less than 32k bytes, resulting in the inability to load large or multiple diffs.
Now diffs are rendered using Atom’s TextBuffer. The text buffer’s most important benefits are improved performance when loading large diffs and the ability to render multiple diffs. A few other perks include keyboard bindings to use Atom shortcuts with the ability to navigate around diffs, as well as copy and pasting code from a diff.
Rendering diffs with TextBuffer makes it easier to review and edit code from within a diff view whether you’re making changes now or in the future. TextBuffer provides options, such as:
Now you can use the option to “See All Staged Changes” before you commit, opening diffs of all staged changes in one pane. Seeing all changes at once makes it easier to double-check your work and write a meaningful commit message about your changes. Commit preview uses the new and improved diff rendering to render multi-file diffs.
While building out this feature, user research sessions gave us informed data to make (and finalize) changes to the design, color, and text of the button. This feedback helped us feel confident that the updates created a more intuitive workflow and led to a more polished diff view with a cleaner look.
User experience is important. Our goal is to make it easy to write, review, and collaborate on code within Atom. We have plenty of updates in store, but look out for upcoming improvements to pull request reviews.
If you have feedback about what we’ve worked on—or ideas for what you’d like to see in the pull request workflow—reach out to us in the Atom repository. We’re always looking for participants for our ongoing usability studies.
meaghanlewis
The GitHub Pull Requests extension in VS Code allows you to manage your pull requests directly from your IDE. Over the past months the team has added even more enhancements to pull request functionality. Using the latest version, you can now create pull requests, leave suggested edits as a comment, and view status checks for each pull request.
To create pull requests in VS Code, hover over the GitHub Pull Requests title and click the + sign. Choose the target branch for the pull request, press enter, and relax—you’ve opened your pull request.
Provide suggested code edits and leave them as comments with a diff that shows the current code alongside your suggested changes. The suggestions can easily be applied by selecting Apply Patch to commit the new patch of code.
You also have the option to stage all suggested changes when changes have not yet been staged.
Once you create a pull request, status checks will appear in the description. You can now view the progress of each check that was integrated: passing, failing, and in-progress.
Visit the VS Code Pull Requests Repository to view release notes and download the latest release package. Don’t forget, you can always install or update the latest version directly from inside of VS Code.
meaghanlewis
In the latest release of GitHub for Visual Studio, the Editor Tools team has improved the pull request experience with check runs and annotations. Seeing annotations inline for a check run when reviewing a pull request provides the reviewer with more information in order to perform a more thorough review of their code.
The GitHub for Visual Studio team worked on a release to provide you with more information when reviewing pull requests. This past August, @stanleygoldman implemented checks and statuses so that pull requests show a status of pending, passing, or failing for each check. Taking it a step further, checks can be configured to run against changed files in a pull request to provide annotations and show details about the code including errors, warnings, and general information.
When a check run application is configured for a repository, annotations appear on each pull request if a certain condition is met. Looking at the list of changed files, it’s easy to see which files have annotations. Here’s an example where the indicator is beside the file name (represented by a symbol), and the number of annotations is linked.
When you click on the link, the file opens for you to view more details about the annotations. In the margin of the diff, lines with check run annotations are identified with a different color: red for errors, yellow for warnings, and blue for information.
When inline comments are on the same line as an annotation, two separate indicators appear: a diamond symbol for the annotations and a circle for comments. When clicking on the marker, both the annotation and comment are displayed.
GitHub applications can be integrated with checks to list annotations about lines of code that have been changed in pull requests. Here are a few awesome GitHub applications that can show annotations through check runs:
Build Cross Check creates checks and surfaces warnings, errors, and additional information.
Yamburger finds syntax errors in YAML files changed in pull requests.
Kubevalidator validates Kubernetes YAML files changed in GitHub Pull requests against a community-maintained set of schemas using kubeval.
Prosebot listens for changes to Markdown files and runs various checks against them to provide feedback on English spelling, prose, and inclusive verbiage.
Linter-Alex ensures your writing is sensitive and considerate before you merge your pull requests.
You can use existing GitHub applications to provide code annotations, or you can build your own. This option provides the flexibility to choose the exact annotations you want to show in your project.
Try the new check run annotations feature, and let us know what you think!
If you’re curious see what else we worked on, check out the latest release notes. As always, you can reach out to us in our repository or on Twitter.
billygriffin
Since launching the new GitHub Desktop in 2017, we’ve focused on improving collaboration in the app, laying the foundation how you can work with Desktop today.
Today, we’re releasing GitHub Desktop 1.5, representing a culmination of the work we’ve been doing this past year. This release completes the merge collaboration cycle by providing a way to initiate a merge in the branch dropdown, guiding you through resolving merge conflicts, and informing you when a merge is complete. It also includes our first step toward improving onboarding onto GitHub Desktop with the option to clone and add new repositories in the repository dropdown.
With today’s GitHub Desktop release, you can merge with confidence knowing that even if conflicts occur, we’ll help you through it so you can keep shipping. Merge conflicts can be intimidating for new developers, especially those working in teams. In our usability tests, the audible “NOOOOO” when encountering a conflict became predictable.
In our previous release, we reduced some of that anxiety by informing you whether or not you would encounter merge conflicts before merging, but you still needed to actually resolve the conflicts on your own. With more than 10 percent of all merges in the app resulting in merge conflicts, we knew we could do better. And with GitHub Desktop 1.5, you’re no longer on your own. The app will now inform you which files have conflicts, route you to your preferred editor to resolve them, list the conflicts that you still need to address, and show you when everything is resolved and ready to merge.
As we’ve released features related to merging over the past several months, we’ve also had an opportunity to listen to lots of users. We care about your feedback, and this release incorporates several changes based on what we’ve learned from you. With GitHub Desktop 1.5, you can now initiate a merge from the branch dropdown, and you’ll receive feedback in the app to let you know when a merge is completed successfully.
We’ve also seen that the core function of adding a repository to Desktop has been difficult to find and use. We solved this by adding a simple way to create, add, or clone a repository right from the repository dropdown.
These changes are subtle, but together they represent our commitment to listen and learn from people using Desktop every day. We conduct user interviews and usability testing on a regular basis—if you’d like to participate and help make Desktop even more useful, please sign up.
Finally, we want to call out that this release is the first time we’ve shipped a feature iteration built almost entirely by community contributors outside of GitHub. The improved merge flow was a combined effort from @JQuinnie and @bruncun, and there were more than 30 merged pull requests from the community since our last release.
We continue to be blown away by the community that has grown around GitHub Desktop as an open source product. There were more community pull requests merged in September and October than in any previous months, and there’s no sign of slowing down. We’re grateful for the community’s participation in improving GitHub Desktop, and if you feel inspired to build something awesome together, we’d love to see you in our open source repository.
maxbrunsfeld
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.
Currently, we use Tree-sitter to parse 11 languages: Bash, C, C++, ERB, EJS, Go, HTML, JavaScript, Python, Ruby, and TypeScript. And we’ve added Rust support on our Beta channel. If you’d like to help us bring the power of Tree-sitter to more languages, check out the Tree-sitter documentation and the grammar page of the Atom Flight Manual.
Want to know more about Tree-sitter? Check out this talk from this year’s StrangeLoop conference.
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.
