Sublime Merge Build 2047
Today we're releasing the first Sublime Merge build of the year - Build 2047! This build brings plenty of new features and enhancements.
Continue reading the full post for more details.
Today we're releasing the first Sublime Merge build of the year - Build 2047! This build brings plenty of new features and enhancements.
Continue reading the full post for more details.
From the first release of Sublime Merge, we talked about the simple joy of software that ‘gets it really right’. For our team it means going beyond the minimum, making software as good as it can be, and paying attention to the details.
It’s been almost two years since Sublime Merge was launched, and our focus hasn’t changed. Our aim for the newest update was to ‘get it really right’ when it comes to flexibility and customization.
Our community uses Sublime Merge in many different ways; from reviewing commits on a tablet, to writing thousands of lines of code on a desktop computer.
The latest version of Sublime Merge is packed full of upgrades, but we want to highlight some of the ways we’re giving you flexibility in the way you work. We’ve included the full list of changes at the bottom of this post (spoiler: there’s a lot)
To get started straight away, visit the download page.
As developers, we know that windows can be cumbersome. We want to give you the tools you need to focus on your work, not on managing windows.
The new update provides the flexibility to view all your projects in one window.
Repository Level Tabs
We’ve re-worked the commit UI to support different workflows.
You can now configure the commit message position, and toggle between individual files using file tabs. You’ll also notice the new file stats.
Upgraded Commit UI
With the wide variety of displays available today, it’s important to have a flexible layout that works for you.
Starting today, you can simply select the layout that fits your set up.
Whether you’re on your 4K desktop screen, your work laptop, or even a tablet, we’ve got you covered.
Flexible Layouts
We're excited to announce support for hardware acceleration in Sublime Merge. Powered by OpenGL, this will deliver significant rendering performance improvements on all platforms. It is enabled by default on MacOS, and can be controlled via the advanced section of the preferences.
Many of us use Sublime Merge to manage and share our work, but some of us also use it to review work. File tabs have improved this process significantly, but there’s more work to do. Keep your eyes out for multiple improvements focused on improving your ability to review.
If you’re using Git, chances are you’re working with images too. Just like code, it’s important to see what’s changed when modifying image files. We want to make reviewing image changes as seamless as reviewing code changes.
It’s incredible to see what the community has built using the plugin system for Sublime Text. The plugin system offers the power and flexibility needed to truly personalize your experience. We know this is an important part of software that gets it really right, so we’ll be bringing it to Sublime Merge.
We’ve got big plans for the Sublime Merge team, and we’re full steam ahead! Our team is growing, and we’d like to welcome our new developer, David! You can thank him for features such as commit stats, the new console, and some great performance improvements in Sublime Merge.
Hello hello, I’m David, one of the software engineers at Sublime HQ.
I’m usually the quiet guy that enjoys making silly jokes whenever I’m given the chance.
As a programmer, I enjoy learning how to make traditional software, and writing clean compact code.
In my own time I’ve been learning how to draw digitally.
As always, we’re excited to hear your thoughts. We’ll be on the forum listening to any feedback. We also have an official bug tracker, where you can share your ideas for features.
We know times are tough on a global scale at the moment, and our thoughts are with all of you. We’d like to take this time to thank you for your feedback and participation, whether it be on the forums or the Discord server. Through this, you have guided Sublime Merge to where it is today. We’re excited to continue delivering the best Git experience to you.
When we implemented the git portion of Sublime Merge, we chose to use mmap
for reading git object files. This turned out to be considerably more difficult than we had first thought. Using mmap
in desktop applications has some serious caveats, and here's why:
You can follow along with the example project here.
Say you were reading some binary format, data you need throughout some application. You take the easiest approach and use a simple read
to get the full contents of the file. You release your software and someone comes along and says: "I need to parse this 3GB file, but I only have 2GB of memory. Could you make it so that you're not using so much memory?". Of course you want to help them, so you do some searching and come to the conclusion that memory mapping is the perfect solution to this problem.
Memory mapped files work by mapping the full file into a virtual address space and then using page faults to determine which chunks to load into physical memory. In essence it allows you to access the file as if you had read the whole thing into memory, without actually doing so. Crucially it requires only a small change to the codebase:
And with that, you've fixed the memory usage issue. You've fixed the bug, people are happy and all is well until you get another support ticket. Your program is crashing with a SIGBUS.
SIGBUS (bus error) is a signal that happens when you try to access memory that has not been physically mapped. This is different to a SIGSEGV (segmentation fault) in that a segfault happens when an address is invalid, while a bus error means the address is valid but we failed to read/write.
As it turns out, the ticket comes from someone using a networked drive. Their network happened to disconnect while your memory mapped file was open, and since the file no longer existed the OS couldn't load it into ram for you and gave you a SIGBUS instead.
Because the OS is loading the file on demand, you now have this wonderful issue where any arbitrary read from an address into the memory mapped file can and will fail at some point.
Luckily on POSIX systems we have signal handlers, and SIGBUS is a signal we can handle. All you need to do is register a signal handler for SIGBUS when the program starts and jump back to our code to handle failures there.
Sadly our code actually has some edge cases we should consider:
Signal handlers are global, but signals themselves are per-thread. So you need to make sure you're not messing with any other threads by making all our data thread local. Let's also add some robustness by making sure we've called setjmp
before longjmp
.
Using setjmp
and longjmp
ing from a signal handler is actually unsafe. It seems to cause undefined behaviour, especially on MacOS. Instead we must use sigsetjmp
and siglongjmp
. Since we're jumping out of a signal handler, we need that signal handler to not block any future signals, so we must also pass SA_NODEFER
to sigaction
.
This is starting to get quite complicated, especially if you were to have multiple places where a SIGBUS could happen. Let's factor things out into functions to make the logic a little cleaner.
There, now you just need to remember to always call install_signal_handlers
for every application, and wrap all file
accesses with safe_mmap_try
. Annoying, but manageable. So now you've covered POSIX systems, but what about Windows?
Windows doesn't have mmap
, but it does have MapViewOfFile
. Both of these implement memory mapped files, but there's one important difference: Windows keeps a lock on the file, not allowing it to be deleted. Even with the Windows flag FILE_SHARE_DELETE
deletion does not work. This is an issue when we expect another application to delete files from under us, such as git garbage collection.
One way around this with the windows API is to essentially disable the system file cache entirely, which just makes everything absurdly slow. The way Sublime Merge handles this is by releasing the memory mapped file on idle. Its not a pretty solution, but it works.
Windows also does not have a SIGBUS signal, but you can trivially use structured exception handling in safe_mmap_try
instead:
Now all is well, your application functions on Windows. But then you decide that you would like some crash reporting, to make it easier to identify issues in the future. So you add Google Breakpad, but unbeknownst to you you've just broken Linux and MacOS again…
The problem with using signal handlers is that they're global, across threads and libraries. If you have or have added a library like Breakpad that uses signals internally you're going to break your previously safe memory mapping.
Breakpad registers signal handlers at initialization time on Linux, including one for SIGBUS. These signal handlers override each other, so installation order is important. There is not a nice solution to these types of situations: You can't simply set and reset the signal handler in safe_mmap_try
as that would break multithreaded applications. At Sublime HQ our solution was to turn an unhandled SIGBUS in our signal handler into a SIGSEGV. Not particularly elegant but it's a reasonable compromise.
On MacOS things get a little more complicated. XNU, the MacOS kernel, is based on Mach, one of the earliest microkernels. Instead of signals, Mach has an asynchronous, message based exception handling mechanism. For compatibility reasons signals are also supported, with Mach exceptions taking priority. If a library such as Breakpad registers for Mach exception messages, and handles those, it will prevent signals from being fired. This is of course at odds with our signal handling. The only workaround we've found so far involves patching Breakpad to not handle SIGBUS.
3rd party libraries are a problem because signals are global state accessible from everywhere. The only available solutions to this are unsatisfying workarounds.
Memory mapping may not use physical memory, but it does require virtual address space. On 32bit platforms your address space is ~4GB. So while your application may not use 4GB of memory, it will run out of address space if you try to memory map a too large file. This has the same result as being out of memory.
Sadly this doesn't have a workaround like the other issues, it is a hard limitation of how memory mapping works. You can now either rewrite the codebase to not memory map the whole file, live with crashes on 32bit systems or not support 32bit.
With Sublime Merge and Sublime Text 3.2 we took the "no 32bit support" route. Sublime Merge does not have a 32bit build available and Sublime Text disables git integration on 32bit versions.
I mentioned before that you can rewrite your code to not use memory mapping. Instead of passing around a long lived pointer into a memory mapped file all around the codebase, you can use functions such as pread
to copy only the portions of the file that you require into memory. This is less elegant initially than using mmap
, but it avoids all the problems you're otherwise going to have.
Through some quick benchmarks for the way Sublime Merge reads git object files, pread
was around ⅔ as fast as mmap
on linux. In hindsight it's difficult to justify using mmap
over pread
, but now the beast has been tamed and there's little reason to change any more.
If you think we've missed something or made a mistake, please leave us a message on the forums. We hope this helps some of you in your future endeavours. If you haven't already, check out our git client Sublime Merge.
The past year has been busy here at Sublime HQ. We've grown our engineering team, shipped Sublime Text 3.1 and released our second product, Sublime Merge. If you use Git and like the ethos of Sublime Text, we think you'll love it.
Today we're pushing out Sublime Text 3.2, which builds off of a bunch of work we've done in Sublime Merge. This includes: first-class Git integration, incremental diffing, new theme functionality and block caret support. Beyond that is a slew of other enhancements, stability improvements and performance gains. See the full changelog below for details.
Sublime Text 3.2 is available from the Download page.
Git status badges in the side bar and incremental diff markers in the gutter
Sublime Merge, our Git Client and Merge Tool, is out now with improvements to the Merge Tool, Tree viewing, and Clone dialog. See the full post for more details.
Sublime Text 3.2 will be coming very soon now, featuring Git integration and more.
Sublime HQ's Git Client, Sublime Merge, is out now with Interactive Rebase, a new Contents View, and Word Wrap - see the full post for more details.
While we continue to add more features and polish to the default Sublime Merge experience, we know that developers love the ability to tweak their tools. Sublime Merge is built on the same foundation as Sublime Text, so you can tweak key bindings, menus, command palette entries, and even the look and feel of the UI.
To assist, we’ve just rolled out a number of pages of documentation for users who wish to customize Sublime Merge to look and function a little differently. In addition, we’ve added a new documentation section for the dev builds of Sublime Text. It covers all of the features we added during the development of Sublime Merge.
Sublime Merge Build 1070 is out now with Commit Folding - see the full post for more details.
Just a quick post about what we're going to be adding to Sublime Merge. This isn't a comprehensive list, but it should give an indication of what we're focusing on right now.
We'll also be getting a new Sublime Text Dev Build out this week, rolling in all the updates from Sublime Merge, including the updated theming system and Mojave support.
(You can download Sublime Merge from https://www.sublimemerge.com/download)
There's a company that makes photography accessories, called Really Right Stuff. They make lovely equipment, but what I really like is the name. It embodies the idea of building something that goes beyond the minimum: making it as good as it can be, paying attention to the details, and getting it really right.
When it comes to software, getting it really right goes beyond functionality. The feel, aesthetics, and performance all have to be there.
There's a real pleasure using software that gets it really right, as a lot of the time, it doesn't. We're all too familiar with clunky layouts, unresponsive buttons, choppy scrolling, tedious splash screens, and flickering on every interaction.
After typing git add -p in the terminal one too many times, I thought to myself: we've got some pretty great tech in Sublime Text. What if we used it to build a Git client? Could we make it fast? Could we make it buttery smooth, without flickering or blocking? Could we make something that's really, really right?
Today, I'd like to introduce Sublime Merge.
It combines the UI engine of Sublime Text, with a from-scratch implementation of Git*.
The result is, to us at least, something pretty special.
Sublime Merge - Commit Dialog
You can download Sublime Merge, and try it for yourself - there's no time limit, no accounts, no metrics, and no tracking. The evaluation version is fully functional, but is restricted to the light theme only. Individual purchases are buy once, use forever, with 3 years of updates included in the purchase. Business licenses are available on a subscription basis. Sublime Merge runs on Windows, Mac and Linux.
It's still early days for Sublime Merge - it has only been used by us and our small team of beta testers so far. We'd love to hear what you think. We'll be on the Forums listening to any feedback - let us know how you get on with it!
* We have a custom implementation of Git for reading repositories, which drives a lot of our high performance functionality. However we defer to Git itself for operations that mutate the repository (Staging, Committing, Checking out branches, etc).