> With these latest changes, Sublime Text 3 is almost
> 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).
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.
The fact that it is a pseudo-free piece of software is one of the biggest reasons for its success (apart from its blazing speed and the rugged, minimalist engineering aesthetic). People just get used to the occasional nag screen as a sort of background noise.
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 have a license too but as I'm moving between workstations and sometimes between accounts even on the same machine, I don't always paste the license in, because it would be extra effort to dig it up and copy-paste it...
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. :)
It's probably not that they don't have $70, but that they don't have time and it's easier not to bother. Buying software at big companies can be a pain.
Sorry, I must disagree. For 70 bucks you get developers who hardly fix bugs, who don't listen to users (I posted a few feature requests in their site and was banned) and with a crazy architecture (try and change the highlight colour of brackets in BracketHighlighter and see what I mean). They are worse than Microsoft. Screw them.
It was great when it came out, but now Atom is better.
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.
I wish the Sublime Text people open sourced their code. I'd buy it from them in that event and I'd finally have a text editor to recommend. Atom, VS code, and anything else is completely blown out of the water by ST. There's a reason it's still around and it's because ST is the only thing that can even think of doing what sublime text can do.
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.
Actually the only thing that keeps me from switching back to ST3 is Atoms first class support for `.gitignore` and excluding files from the quick open menu.
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.
Create a Sublime project. You can have project settings to ignore file and folder patterns. I set this up at the same time I create a .gitignore file for a repo.
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.
This is my exact issue! That's what keeps me coming back to Atom even though Sublime is much, much faster. The last package I saw tackle this required you to make a project -- which I just never do in Sublime.
I second that, along with .gitignore handling I also terribly miss having new and changed files (in git) highlighted in the sidebar, which Atom has out of the box. They have a lot of feature requests for that, since their sidebar API doesn't even allow package developers to add it, and just like your case, it's the only feature keeping me from going back.
I really, really wish it was open source. I understand why it isn't, but with its main competitors being Atom and VSCode, it's hard to warrant using a closed source text editor even if it's so much faster and I'm used to it.
When I first started using Sublime, I disliked the occasional popups, and thought I'd just keep using it without paying $70 for a text editor?!?!
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).
I'm surprised so many people here are using Sublime to edit >100 MB files. Yes, it handles them (as long as the lines aren't too long), but it always has to load the entire file before displaying the first line. Aren't there some editors that don't have to do that?
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.
> Also new in 3124 is Show Definition, which will show where a symbol is defined when hovering over it with the mouse. This makes use of the new on_hover API, and can be controlled via the show_definitions setting:
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!
It's similar to Goto Definition (F12). It's based on parsing according to the syntax definition (which only does line by line contextual parsing) so kinda like ctags. In practice it works better than the painfully slow "smart" and often non-existent* symbol navigation in IDEs (although QtCreator is very good in this regard).
A number of people expressed the need to edit large files. For the development of my own editor[0] I would be interested to know what kind of usage patterns most often occur. What are the most important operations? Do you search for some (regex) pattern? Do you go to some specific line n? Do you copy/paste large portions of the file around? Do you often edit binary files? If so what types and what kind of changes do you perform?
1) Going to a specific location (e.g. a location that shows up in some error log about processing that data file) and eyeballing it. Being able to go to a specific location is sometimes important (e.g. row 12873, character 233). Syntax highlight is important, it sometimes makes obvious something that's subtly malformed. Syntax highlight that doesn't take an eternity for large files is a hard issue.
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.
I'm a bit hesitant to burden you with feature suggestions - sidetracking the developer(s) can easily kill many small projects. But I'd like to mention a feature I would find compellingly useful that I have yet to see in "modern" editors. Possibly this could be a distinguishing feature that gives you a niche!
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.
My complaint is actually not with ST3, but with Package Control. I have to maintain my user preferences in git because PC rewrites them and resets the theme every time it updates. (I run the Material Design theme)
sublime is by far my favorite editor. fast and lots of plugins. specially if you work with big files. i sometimes need to work with files larger than 150MB and it takes few seconds to open. atom crushes and can't even open the files.
Agree. The number of times a year I need to open a a crazy large file in reality, is fairly small. But I love that when I do, my tool of choice works perfectly with these files and I don't need to bust out a specialty text editor.
I'm an UltraEdit user. I have tried Sublime Text because of all the nice comments, but I don't see it. Can somebody that also uses or used to use UE tell me what I'm missing?
Here comes a piece of history.
I replied this to my Sublime Text 2 purchase confirmation email I got from Jon Skinner on 2011/08/30:
> 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...
On Mac I use TextWrangler for quick editing and VS Code as the IDE. I never need to open super large files so after reading this discussion I tried to open a 177MB text file in TextWrangler and it opened quickly and was editable. Searching within the file was also super fast.
The addition of Phantoms [1] is the killer feature in this release for me. This will allow embedding custom HTML [2] inline in the editor, which is something I've been dreaming of - the power of Atom's nice plugin UIs with no compromise in speed!
[+] [-] guessmyname|9 years ago|reply
> 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.
[1] https://github.com/SublimeTextIssues/Core/issues
[+] [-] mastazi|9 years ago|reply
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).
[+] [-] mstade|9 years ago|reply
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.
[+] [-] jasim|9 years ago|reply
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.
[+] [-] onetom|9 years ago|reply
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. :)
[+] [-] lawnchair_larry|9 years ago|reply
[+] [-] petters|9 years ago|reply
[+] [-] draw_down|9 years ago|reply
[+] [-] travisty|9 years ago|reply
[deleted]
[+] [-] gotofritz|9 years ago|reply
It was great when it came out, but now Atom is better.
[+] [-] spdustin|9 years ago|reply
> 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.
[0]: https://www.sublimetext.com/3
[+] [-] derefr|9 years ago|reply
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.
[+] [-] wbond|9 years ago|reply
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.
[+] [-] connorshea|9 years ago|reply
[+] [-] amorphid|9 years ago|reply
[+] [-] skybrian|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
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.
[+] [-] wkirby|9 years ago|reply
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.
[+] [-] teddyc|9 years ago|reply
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.
https://www.sublimetext.com/docs/3/projects.html
[+] [-] drhayes9|9 years ago|reply
[+] [-] MatekCopatek|9 years ago|reply
[+] [-] connorshea|9 years ago|reply
[+] [-] statictype|9 years ago|reply
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.
[+] [-] octref|9 years ago|reply
[0]: https://github.com/Microsoft/vscode/issues/12163
[+] [-] ricardobeat|9 years ago|reply
[+] [-] supergetting|9 years ago|reply
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).
[+] [-] modeless|9 years ago|reply
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.
[+] [-] fake-name|9 years ago|reply
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?
[+] [-] PavlovsCat|9 years ago|reply
http://www.ultraedit.com/
ST is neat. UE is heavy duty.
[+] [-] watmough|9 years ago|reply
Of course I may do anyway. I like to support small software producers.
[+] [-] Manishearth|9 years ago|reply
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!
[+] [-] sunnyps|9 years ago|reply
* for large projects
[+] [-] martanne|9 years ago|reply
[0] https://github.com/martanne/vis
[+] [-] PeterisP|9 years ago|reply
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.
[+] [-] Elrac|9 years ago|reply
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.
[+] [-] mangeletti|9 years ago|reply
In order to truly clear your history (files open, last searches, etc.), I have to maintain a script with the following:
Other than that, see https://news.ycombinator.com/item?id=12553515[+] [-] slowmovintarget|9 years ago|reply
[+] [-] sagivo|9 years ago|reply
[+] [-] traduz|9 years ago|reply
[+] [-] CameronBanga|9 years ago|reply
[+] [-] TsomArp|9 years ago|reply
[+] [-] onetom|9 years ago|reply
> 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...
[+] [-] putlake|9 years ago|reply
[+] [-] jayflux|9 years ago|reply
[+] [-] woodruffw|9 years ago|reply
I've moved between maybe half a dozen editors over the past half-decade, but I always end up coming back to Sublime.
[+] [-] ricardobeat|9 years ago|reply
[1] https://www.sublimetext.com/docs/3/api_reference.html#sublim...
[2] https://www.sublimetext.com/docs/3/minihtml.html
[+] [-] 0xmohit|9 years ago|reply
[0] https://github.com/SublimeTextIssues/Core/issues/1387
[+] [-] wbond|9 years ago|reply
[+] [-] Egidius|9 years ago|reply