Apart from the fixes, there's also some changes to the tab rendering, which is comprised of two items:

Spacing is used more effectively now. The label is able to nestle up closer to the close button, and both the label and button will move towards the edge of the tab to avoid clipping the label. The whitespace on the left and right edges of the tab will be balanced now, too.

Labels are faded out now, rather than elided. While eliding can show more information at times, by hiding the unimportant parts of file names, it often loses out by dedicating too much space to showing elipses. This change is more experimental than the above one, but I'm happy with it so far.

Something I've noticed in the last two builds is when I select the text in a view and try to extend the selection past the first visible line (with the mouse, holding down the button), Sublime will scroll about 4 lines up but then no more. If you are trying to select text that spans more than one visible screen pages then this bug can be quite annoying...

If you want two more ideas for making tabs more efficient: (Just ideas)1. Instead of showing a circle/dot for modified but unsaved files, make the top pixel or two of the tab a different color, so the tab has like a white top border instead of the dot.2. Instead of always showing the close button, only show it on mouseover. It's ok if the button overlaps the text on mouseover probably, but both of those would save a little room.

Still getting some cursor oddities (Linux, Arch, x86_64). Basically as soon as my cursor turns into the text cursor, it gets stuck as that everywhere else besides file menu buttons (file, edit, etc.), the minimap, and the line number gutters. Everywhere else, the entire tab bar, status bar, empty parts of the file menu all keep the text cursor.

Still getting some cursor oddities (Linux, Arch, x86_64). Basically as soon as my cursor turns into the text cursor, it gets stuck as that everywhere else besides file menu buttons (file, edit, etc.), the minimap, and the line number gutters. Everywhere else, the entire tab bar, status bar, empty parts of the file menu all keep the text cursor.

What appears to be happening is that the selection is only relative to the original mouse position. So if you start a selection by clicking and holding the mouse, then use the middle wheel to scroll the document, the then move the mouse up a couple of lines, the original selection becomes two lines rather then the two lines you moved PLUS the amount you scrolled.

The same kinda thing happens when you get to the top and bottom of the editor area. You can move the mouse outside of the window and the respective number of lines gets selected, but no more. The text buffer doesn't 'autoscroll' with the mouse, instead it ignores the fact that you've gone outside and selects the lines as it normally would, up until the limits of the monitor's height. The problem is that it appears that the buffer's autoscrolling but then stopping doing so, but what's actually happening is that the newly selected lines (which were out of view) are being scrolled into view as they are added to the selection. This is normal (and good) but obviously the 'autoscroll buffer as mouse leaves visible area in the context of a selection' seems to have been disabled.

I wonder if it's because of the changes that may have been required in order to accommodate directwrite (even if directwrite is not actually enabled), but that's only speculation.

Great product by the way, there are a few niggles, but there are so many great points about this editor, and you're never going to be able to please everyone, so keep up the good work.

(Also, +1 on the text cursor issue - my specific issue here is not the minimap or any other UI element except inactive tabs. They still have an I-beam cursor when you hover over them. Interestingly, the active tab does not, just inactive ones. But this is a very minor complaint compared to above. Also introduced in 2081 I think.)