Sublime Text 3 Build 3124
sublimetext.com
sublimetext.com
> ready to graduate out of beta, and into a 3.0 version.
Wow, Finally! I have been using ST3 for several years (wow, years) and always wondered what is keeping the developer from labeling that version as stable. From all the issues reported here [1] I have never encountered one while using the editor for pretty much all my work. Those $70 are definitely worth every penny. Sometimes I cringe from videos featuring ST while using a non-registered license, this week it happened with a course from Google engineers via Udacity, Google engineers!!! As if they don't have miserable $70 to buy a license, I assumed they were in a rush and didn't have time to set the license which I hope they bought.
Anyway, thanks for all the hard work Jon, and recently Will.
Same here, buying an ST license is probably the single best SW-related purchase that I've ever done. ST3 works so flawlessly, it's just ironic that it's still technically a beta version. It is actually much less buggy than many "final version" competitors ;-)
On a side note, it is notable how, despite being a closed-source program, ST was able to generate a large ecosystem of open-source plugins; that is not something that happens every day (Jeskola Buzz comes to mind as a similar case: also closed source and with a large open-source plugins ecosystem, but I'm not sure how many people on HN are familiar with tracker-style music software, LOL).
Even still, TextMate is a substantially more carefully designed tool. My impression is that the Sublime programmer didn’t really understand the underlying philosophy behind many of the features he cloned, and kind of screwed up a bunch of the subtler details. (This isn’t really surprising; I’d say it pretty much always happens when anyone just copies something that exists; they seldom perfectly understand the context or ideas of the original creator, so the copy is always at least a bit degraded/distorted, with less clarity of vision.)
Sublime does have the advantage of working on more platforms though.
Copying or not, "badly designed" or not, in the end Sublime Text is blazing fast even on a big files, extensible with the help of Package Control and has some native features (like multiple cursors) that make the difference.
Do people still actually use TextMate? Judging by their website [1], for example the screenshots taken under an ancient version of OS X, I thought it'd been abandoned years ago. The last post on the blog is in October 2014.
It's constantly being updated.
Also, when Sublime Text has a reasonable amount of popularity within Google, they could just purchase a site license for N users.
It was great when it came out, but now Atom is better.
However great Atom is though, it's unbelievably slow and nearly unusable because of that. Unfortunately, I haven't been able to find a better alternative since.
>buggy software and the unresponsive devs
I mainly use VS Code for that reason. It does feel a bit more polished and Atom is missing some much requested features, most notably a list of open files in the sidebar (the plugins that offer this are all terrible).
And why should you need that kind of machine to do text-editing?
If a text editor can't open a big file unless you are on a beast of a machine, it isn't a very good text editor.
When you regularly work on such files, Atom is the wrong tool for the job. For regular programming however, I'd argue it's far better than Sublime Text by now.
Have you given emacs a shot? While once upon a time it was derided as eight megabytes and constantly swapping, it's extremely fast after forty years of Moore's Law.
It's cross-platform: if you run an OS, odds are emacs runs on it. It runs in both the terminal (convenient for remote sessions) and in the X/Cocoa/Windows GUIs.
It has modes for just about every programming language in use, and then some.
It has a plethora of keybindings for dealing with code semantically, e.g. navigation by expressions or blocks. If you prefer, it also has vi keybindings.
It's extraordinarily extensible, so much so that web browsers (three that I can think of), mail readers, news readers, process browsers and shells have been implemented in it.
Indeed, for many people emacs can become more of an OS than their OS.
It's pretty awesome.
I just recently looked at my old .emacs file to discover that the majority of code in there was to get the features that come out of the box with Atom. Of course Emacs does allow you to configure and program way more than Atom, but the downside is that you have to do it because the defaults come from computer history museum - it's great fun though if you like to learn about the history of the field.
I've been pleasantly surprised just how easy it is to extend Atom. It invites you to configure it, with very approachable docs and built-in tooling, but it doesn't force you to.
I've been using the beta of ST2 for years and the dev of ST3 for years after that, and have seen hardly ANY bugs. (on OS X). I use with it SublimeLinter (Python, JS, PHP), a Shell linter plugin, GoSublime, JSONFormatter, Vintageous, and a few other plugins.
>who don't listen to users (I posted a few feature requests in their site and was banned)
Maybe it was the tone that got you banned? The forum is chock-full of feature requests. I've posted some and didn't get banned. Whether they are implemented or not depends on the roadmap and their popularity/feasibility. Obviously not all will be.
>and with a crazy architecture (try and change the highlight colour of brackets in BracketHighlighter and see what I mean).
BracketHighlighter is a third party plugin, so nothing to prove some ST3's supposed "crazy architecture".
>It was great when it came out, but now Atom is better.
Atom was, is, and due to its architecture, will always be, slow. It has been slow every time I've tried it, and it's the common complaint of every Atom user whenever Atom is on HN.
> BracketHighlighter is a third party plugin, so nothing to prove some ST3's supposed "crazy architecture". BracketHighlighter is forced to do things in a certain ways by ST3's crazy architectura.
https://github.com/facelessuser/BracketHighlighter
And is it crazy overall, or just when it comes to handling brackets from a plugin, in which case, it might just be a corner case that was not originally catered for?
Highlight colors should be the responsibility of highlight themes, and users should be able to change them by changing the theme they use or adjusting it to their taste, not by ...hacking into a plugin that hardcodes them.
At best you could argue that the plugin could be allowed to hardcode a color, and themes could optionally override it -- but even that breaks separation of concerns.
Even if it was crazy (which it is not) it's a tiny part of ST (just how the syntax highlighting works), and wouldn't be proof of any general "crazy architecture" of the editor.
I'm hopelessly tied to IntelliJ's amazing IDEs for any sort of programming, but Sublime is my EDIT.COM for all other writing, especially note-keeping. I used it in that capacity for around a year, guiltily enduring the nag-screen, before I got around to buying it. This free-but-nag approach (not Nagware - too negative) was unusual for the times, but it reminded me of the Shareware days when successful software like PKZip spread virally, but extracted commercial value only when the users felt like it.
I think the demise (in terms of active development) of TextMate should not be understated as a factor in ST's success. At the time Sublime Text 2 came out, a lot of TextMate users were frustrated with the lack of progress on TextMate and hopped on the ST bandwagon.
Ironically, ST had the same fate for a while. But it's good to see that there is some movement again.
I've said it before, and I'll say it again – the fact that ST saves buffers no matter what has saved my butt so many times I can't even count. The effort it would've taken to restore the lost data had those buffers not been stored would've costed way more than $70 every time. Even if ST was worse in every possible way than other editors (and it's not,) I'd still pay money for this (and I did.)
I don't know if my license will stop working when ST3 comes out of beta (I think I bought it for ST2, but it was so long ago at this point I don't even know) but if it does I'll happily shell out another $70. ST is one of the few tools I use that never, ever caused me any grief. Not once. It just works, works really well, and does all I need it to do.
I bought it on day one when I discovered that Sublime supports Windows, Linux & Mac.
I wanted a "modern editor" after vim, which works the same way across platforms, easy to install and configure, supports proportional fonts and does save on focus lost, yet still neither a memory hog nor a snail.
I never would have paid just for getting rid of the nag screen, but I was so impressed with its quality, I just had to express my gratitude by paying. :)
> Minor improvements to file load times
I didn't even realize there was room to squeeze out more performance here. Sublime Text is wicked-fast opening pretty much everything I throw at it.
Sublime Text is my go to text editor for files over 10MB, and it can get a little slow loading anything over 1GB. It's awesome to know that it'll be a little faster when I get into work tomorrow.
Being able to jump to the definition of a function, even when contained in a source file that is 200k lines can be handy.
I spend a lot of time less-ing around in log files, but then every once in a while I need or at least want the full power of an editor to act on those files. Be it converting one kind of line delimiter to another so I can visually understand the structure of strange messages, excerpting blocks of the log to files,... lots of things I can do easily in vim (and probably could do in ST if I had ST in my environment) and not nearly so convenient otherwise.
I routinely edit text files that are hundreds of megabytes, and sometimes over a gig. These are usually transcripts from chip simulations, where I'm tracking down where something went wrong.
Most often I do this in emacs, and sometimes vim. They both do fine with it, although emacs used to warn about files over a certain limit. It has always done fine with them in practice.
That said, I will happily shell out for any future paid releases. I live in this editor. It's my primary code editing and note-taking tool.
If Sublime is going to acknowledge Package Control, why not just ship with it? I'm sure the Package Control folks would be glad to move their repo upstream.
Part of the reason is allowing it to have a different release cadence, but also to not default to making outbound network connections without a user opting in.
Good work to the people behind it, it's an amazing feat no doubt. Just please consider making it free software for all of us who care about that just a bit. Amazing work none the less.
If you continue to use the evaluation copy after you're done evaluating it, nobody's going to stop you, but it is a little dishonest.
If you're an amateur (in the literal sense, not as an insult), then you might be more inclined to pirate it. I guess the developers are savvy enough to realise this, and just put a nag-screen in instead.
Bottom line, some people have the luxury of having such well-paid jobs that open source is a real possibility nowadays. But ST is likely someone's income/living, and shafting the devs isn't cool at all. If you're not happy with this, you can always make another editor, but it turns out to be fairly hard to do (see Atom).
There is no separate shareware version. What makes Sublime unique is that it never stops working; it's evaluation period is open, and treats the user as an adult to do the right and legal thing.
I do get mad when people don't give them money since I really appreciate the model.
It's great that Sublime doesn't have strong DRM, but using the free version indefinitely is just as wrong as using a cracked version of Photoshop, IMHO.
I do care about my fellow developer who wrote ST and seems a nice guy, which is a reason to pay... So maybe I'm not a sociopath after all.
And as someone running a business, it is a significant and unnecessary liability to use pirated or unlicensed software.
I doubt donations would be even half of what his creator is getting now.
$70 dollars is already pretty ok, considering I was paying above 150 with student discount on the mid-90 for software tools.
Why this urge to get stuff for free, yet wanting to sell own work.
And yes, I do donnate to all FOSS projects relevant to my work, as if I had bought a license.
>> Just please consider making it free software for all of us
I took that to mean the OP wanted it to be "free as in freedom" not "free as in beer".
For instance, if Apple decided today "Hey why not just make OSX a set of applications, a window manager, and a desktop environment for Linux and make it free software." I'd pay for it. I'd pay the 100 bucks because no one really does UX better then Apple.
While it's true you can charge for your OSS product, all OSS licenses allow the recipient to distribute the source code (and the built binaries) at no cost. So, OSS does imply free, even if it doesn't mandate it.
I know there are many people who will obey the license, but would not donate. If you dual license it (commerical and GPL), they'd just accept the GPL "deal". So it still makes sense to not have a GPL option business wise.
But what about, instead of open source, they make it "source open" or "source available"? Here is the source, you may not use it unless I die. Or you may use it, but not sell it. Or you must contribute changes back if you release a changed version...
They have no big trade secrets in the source. They already rely on the fact that customers obey licenses that they materially don't have to. So I believe they have nothing to lose by making the source available.
I would prefer to acknowledge on-going development costs and pay those for a continually-developed, high-quality editor.
I think he should at least put a demo time limit on using Sublime Unregistered. It's established enough now, and the extra revenue could help speed up development. There are a few things that Atom does in a nicer way, like package management.
But Atom doesn't feel nice because of the speed issues, for me.
I doubt it would be a very good move for the author.
I'm pretty certain that both emacs & vim can do anything Sublime Text can do, but I'm open to being shown otherwise.
Keyboard commands aren't the reason I want Sublime Text. I want it for the amazing plugins that support a load of features as well as having a graphical user interface.
There's a reason people have spent so many years using it.
For example, if there is already a selection, right click in Emacs extends it much like pressing a shift-arrow key does in a typical GUI. (Most modern GUIs will of course pop up a contextual menu in that situation.)
Similar to the keyboard-driven part, as much as possible of the GUI part of Emacs is implemented in Lisp, so it seems to me (as someone who has modified his copy of Emacs to pop up a contextual menu on right click) that it would be fairly easy to write a GUI for Emacs that adheres much more closely to modern conventions than the GUI that comes with Emacs does, but the only project I know of that has tried to do so is the Aquamacs project.
I know there's a package that claims to update the file ignore pattern to match the open project, but it really doesn't work well at all.
Then I have a short bash alias `lime` that takes the place of `subl`: https://gist.github.com/imjared/db14e2c92df864ae048e1d2a94d0...
The benefit seems to be that it _isn't_ synced with my .gitignore so I never have to worry about accidentally committing a .env or similar. I can toggle files and folders on and off as I need to.
Whenever you re-open a project, it re-opens every tab you had when you closed the project, which is really nice. Even unsaved files are restored.
Sublime is a better editor for my purposes. It runs everywhere. I use it. Done.
My rule of thumb is:
If I'm on a server via SSH, it's Vim. Otherwise, it's Sublime.
That said, decent for the day to day. If you're hitting moving target servers, docker, etc, you still need to have some basic vim or emacs or nano knowledge.
The only problem with this setup is that sshfs is bad at recovering from network errors. If someone made a version of sshfs that could automatically reconnect after an interruption then this setup would be practically indistinguishable from working locally, even on moderately high latency connections.
Is that just so there aren't a million different free versions out there so he can, deservedly, make a living off of his product, or something else?
The only thing that keeps VSCode on it is the great support for Rust.
The day Rust IDEs get feature parity with VSCode plugins, it is out.
The same can be said about steep learning curve for VIM/Emacs. What's the reason for Atom/VSCode if Emacs/VIM can do it much better / faster. Even opening large files on Emacs is flawless with vlf.
Atom provides this - it also provides arbitrary html in the editor itself which is cool but also what makes it slow.
I just want it for the supplementary panels that show build outputs, documentation or other contextual information.
That's enough to let me customize it for our team's usage.
But I HAD to buy the thing! Not because I wanted to avoid the annoying popup, but because of everything we know about Sublime today; performance, simplicity and intuitiveness of the UI, packaging system, etc.
The article mentions that they're coming out of beta in the near future! nice! and I just noticed they're already mentioning sublime text version 4 (under sales FAQ page).
On a related note, large files are often binary. I appreciate that Sublime can display binary files but it's pretty bare bones, and there's no editing support. I'd love to see what Sublime HQ could do if they worked on binary editing support for a couple of milestones. For example, the ability to locate and edit strings in binary files would be cool, as would a basic hex editor.
Of course I may do anyway. I like to support small software producers.
https://github.com/facelessuser/HexViewer
I've used it, and it's quite nice, but I don't know how it'd handle large files. Maybe take a look?
ST is neat. UE is heavy duty.
How is it to use?
Depends on how you configure it, it can be a lot of things. The UI is pretty amazing, but I don't have the knowledge or time to do it justice in the least, sorry :)
To be perfectly honest, the first time I finally tried it after hearing so much about it for so long, Sublime Text kind of disappointed me. You can't even print out of the box -- waitwhat? It does other cool things, true, and there is room for more than one text editor, text files are awesome that way. But still, I felt a bit like when everybody was going nuts over Firefox because they didn't know about Opera. I love Mozilla (a lot) and harbour no ill will towards Sublime Text, but god damnit, software isn't as tight as it used to be. I don't know anything about anything and even I can tell.
Is this just an API hook which a plugin can add a definition resolver to, or does this automatically find definitions for all builtin languages? If the latter, this is super cool!
If the former, I'm going to try and update https://packagecontrol.io/packages/YcmdCompletion for this
-----
Edit: omg works out of the box. Seems to be a simple grep-based thing (so it lists all definitions of the same name), but that's still quite useful!
* for large projects
Although I'm not sure how IDEs for other languages deal with humongous projects (~ millions of LOC).
Then, because in e.g. Java the fully qualified name of a type is forced to have a direct relationship to the directory structure¹, the IDE can just look up the .class file in which the type was defined. If the .class file doesn't exist or is outdated, the IDE recompiles but it only needs to do this once and then it can cache it. This .class file itself is a small file of JVM bytecode that allows very fast lookup of all its methods and attributes and whatnot.
This means that it's not a search at all - it's only a lookup (look up name of identifier, determine file location, look up definition), and project size hardly matters.
I often wonder whether they realized how easy they were making things for IDE builders when the Java team invented this stuff 20 years ago. If not, it's a pretty lucky hit and it works great. .NET, even with the benefit of Java-hindsight, didn't do this as well. Assemblies are nice but they make lookup and recompilation a bit more messy.
¹) nitpickers will complain about .jar files and the classpath, but you can look up once which types are in which directory or .jar, cache that, and you're done.
Don't tend to copy large portions of files around, but goto-line is used fairly often and some kind of programatic interface (REPL-style) would also be good, similar to the Sublime console.
Plugins are also important for the long-tail features that are very niche.
...but... speed and lightness is also very important.... so don't use JS/CSS/HTML... please.
2) regex search/replace - interactive grep/sed.
3) Very large edits - e.g., find a specific location and remove all data entries before that so that the problematic entry now would be the first one; essentially cutting away half of a very large file.
4) Do note that you might have very, very large lines - it's not that uncommon to have the whole file in a single line, e.g. non-pretty-printed json data. Some editors work well with large files but simply die if there's a line with a million characters.
Many years ago, one compelling feature about Lugaru's emacs-family Epsilon (recently discussed here on HN) was the fact that you could quickly load _any_ file, with maximum sizes several times the available system memory, and completely regardless of text structure. You could load a fat binary, e.g. WORD.EXE, edit character strings in it, save it, and if you carefully avoided changing sizes and offsets, have a still-working .EXE program.
This is of course a slightly off-the-wall use case for a text editor, but if you happen to need that kind of thing you'll be really grateful if you have an editor that can do it.
Yes syntax highlighting for large files is a hard issue. I'm not really aware of an accurate an high speed solution supporting editing operations in huge files.
In principle the underlying data structure used by vis supports all modifications with linear complexity in the number of editing operations since file load. This is independent of the file structure (i.e. single line files should be well supported). However the frontend code hasn't yet been optimized so in practice there might be some problems.
Unless one specifies the blackhole register when deleting large parts of a file this will create an in memory copy (to enable later pasting at a different location). Better would be to keep a reference to the existing immutable text region.
Open a medium sized file in some format (CSV for example)
Select all
Change the selection to individual selections, one per line.
Edit in parallel, doing the same edit to all lines.
When the file is not that big, this sequence of actions is amazingly fast in ST.
IBM's mainframe editor ISPF allowed you to select a set of lines, usually based on a search (including negative search, i.e. lines _not_ containing the search data), then to manipulate the set of lines thus selected (manually removing lines, adding lines or reversing the selection) and then performing other operations, such as global search and replace, or sorting, or indenting or whatever, on that set of lines while ignoring all other text in the file.
I occasionally run into tasks where I would love to have this functionality available.
x g/foo
x v/foo
I was more interested in common editing tasks for huge files which according to this thread a lot of people perform using sublime text.
In order to truly clear your history (files open, last searches, etc.), I have to maintain a script with the following:
find ~ -name *.sublime-workspace -delete
rm ~/Library/Application\ Support/Sublime\ Text\ 3/Local/Session.sublime_session
> hi jon, > > my salary was reduced by 30% just yesterday, but when i woke up today, > they 1st thing i did was purchasing sublime. it's that fucking awesome! > i wish it would be open source, so people could learn from it... > but, hey, i doubt many open source developers could contribute quality > code to it.. :) > > if u could implement the elastic tab stop feature (which has some reference > implementation on the nickgravgaard.com/elastictabstops/ site), then i > would be happy to pay another 60bucks for it. > actually, u could sell separate license for the version which has this > feature... > i know it would be quite elitist, but it worked well with the black macbooks > back then...
I've moved between maybe half a dozen editors over the past half-decade, but I always end up coming back to Sublime.
[1] https://www.sublimetext.com/docs/3/api_reference.html#sublim...
Anyone have a guess as to why this happens? It causes me headaches using R as well.
> Settings now open in a new window, with the default and user settings side-by-side
- no engagement with the developers. For $70 I expect to be able to file bug reports and maybe some feature requests. Without being banned.
- multi file search is ridiculously poor. I can't save search patterns, the long text box with all the file patterns is hard to navigate (on OS X if you put the cursor at the end it starts scrolling), but most of all the result pane doesn't stick as it used to. I have to search again every time I click on a file from the results then close it.
- copy and paste is STILL buggy on OS X. Sometimes you paste a string and it puts it in the line above the one where you have your cursor.
- package control is not included. It's just common sense
- the scrollbars are invisible on OS X. I don't want a minimap, it used too much space and adds too much noise
- I use BracketHighlighter. Every time I want to customise the highlight colour it's a royal pain in the neck because of ST3's crazy architecture
I'd much rather use atom these days.
2) My only gripe is that it can block the UI.
3) Not experienced.
4) Would be nice, but not a deal-breaker.
5) That's how scrollbars work on macos. You can change it with "overlay_scroll_bars": "disabled". Minimap can also be disabled via View > Hide Minimap.
6) No idea.
7) Who is stopping you?
WRT Scrollbars: `"overlay_scroll_bars": "enabled"` should do the trick.
I can't help with many of the others, I'm afraid - not that it really matters, as I'm sure you're fine with whatever your current solution is.
Did you even click the link? This is an update changelog...
Having said that, while competitors have popped up like Visual Studio Code which is pretty darn good, Sublime was one of the first text editors that I used years ago when the landscape was primarily dominated by Dreamweaver and TextMate. It was a step-up from Notepad++ which many open source lovers used, but lacked the finesse that ST brought to the table. When it comes to opening large files, especially large SQL dumps >1gb, Sublime Text is still the king in my opinion. I still occasionally need to do a find and replace on a large file and nothing beats Sublime Text (except maybe command line editors like Vi/Vim, which I can't use).
I primarily focus on front-end development nowadays, so I primarily use Webstorm, but if I need to write some Markdown, edit some PHP/Python or edit large files, Sublime is still my go-to. Such a shame people think you need to update something every day to keep using it, ST has been incredibly stable for years now. Even ST3 which was in beta for years has been quite stable.
They haven't exactly been keeping to a regular update schedule.
So not hard to blame people for wondering if it was abandoned or not.
I used ST2/3 daily for a few years before switching to Webstorm, Atom, and then to VSCode :)
The cadence of updates in Atom/VSCode far outpaces that of ST, making it easy to forget that the latter exists.