Sublime Text Build 3101
forum.sublimetext.com
forum.sublimetext.com
Just because Sublime's developer isn't updating it as much as he used to doesn't mean anything. What more could you want? The community hasn't stopped with plugin development which is what really counts.
This just reminds me of the consumer software mindset where a new version needs to come out every year, just for the sake of it. There's nothing wrong with using 'old' software that just works.
https://en.m.wikipedia.org/wiki/Exponential_growth
Note, I own Sublime and still use it. However, I do see great value in the Atom project. Developers shouldn't fall in love with an editor. Key bindings perhaps. The ideal editor would let me turn it into vim or Emacs, for example.
You mean like vim-mode is already existing in every editor worth to be called editor?
(Also some of us used vi too, and that didn't have all the stuff vim comes with either).
Your projection also implies that programmers of the future won't also produce exponentially slower code. I have doubts about that, considering how unresponsive programs these days are, compared to their counterparts of two decades ago (when most programmers actually cared about performance).
First, there are no more free "Moore's Law pushes". There haven't been any to write home about for at least 2-3 years. It's now all about multicore (which is also not exactly the best thing for a JS based editor to benefit from).
Another issue is that JS performance has already reached most of the optimizations out there. With the JIT-based JS engines there has been a 100x or more speedup from early JS to circa 2010 or so. Not it's at best some 20%-30% speedup year over year, and that only in some narrow cases. Even webassemply (when that lands as a viable option) is not expected to change that much.
As for the larger developer community, ST already has a huge development community for plugins -- which is where most of the action happens. And sometimes a talented programmer with a strong opinion can be better than "design by comitee".
That said, I find Atom to be a nicely designed editor which would have a great potential, if only it wasn't burdened with a crappy architecture and runtime choices. It might not even be JS fault, as Microsofts VS Code seems to do much better.
And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As for concurrency not being applicable, that might be true for some tasks but I can easily imagine scenarios where is would help greatly. Multiple buffers and files. Replace and search for example. Indexing, concurrent garbage collectors, ...
So, in your scenario, if cpu's only become 10x faster and we get 60 CPUs, we won't be able to make a better editor?
The "transistor count" version of Moore's Law has been saved by multiple cores. The speed version hasn't been true for single core performance for years.
> You are asking us to believe the recent past means that we will not get more single cpu performance increases over the next 10-20 years.*
Moore's law is put in specific time terms -- transistors/power(speed) should double every 18 months. So if this hasn't been the case for the recent 2-3 years, then Moore's Law is already broken -- no belief required. The fact that it's very possible we'll might see another CPU speed breakthrough in, say, 2022 or 2028 or 2050 doesn't change that -- as Moore's Law talks about sustained improvements over 18 month periods.
Besides, few in the industry disagree that the Moore Law is pretty much over. That's a great motive behind all the talk of optimizing multicore performance, functional techniques etc.
>And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As already said, this 20-30% is "at best" and covers specific benchmarks and uses, not general speed. And nobody said this is sustainable long term either. After a JIT engine reaches a specific point of sophistication, there are few things that one can add to make it even faster.
>Next month, the worldwide semiconductor industry will formally acknowledge what has become increasingly obvious to everyone involved: Moore's law, the principle that has powered the information-technology revolution since the 1960s, is nearing its end.
http://www.nature.com/news/the-chips-are-down-for-moore-s-la...
And this is why I'm on ST2
Printing.
I'm not the only one to feel this way. https://www.google.com/search?q=sublime+text+printing
Atom users, too: https://discuss.atom.io/t/printing-support/760/8
Granted I would expected it to be slower using an interpreted language and all but other than opening large files the only thing noticeably slower to me is start-up. That's it. The plug-in ecosystem got me to permanently switch to Atom and it's very fast. I also haven't noticed any battery issues yet as I still will frequently use my MacBook for sometimes most of a day before needing to charge.
I'm not sure if you were speaking from experience with Atom or just approximating but it's surprisingly good. I know I was extremely skeptical to the point of calling it a dumb idea to write an editor in the way they did but after they dumped react I don't notice any slowdowns.
That's a big pain point, if you switch between windows (e.g. browsers - including some tabs/incognito for testing etc.). After having used eclipse when I moved to ST 3/4 years ago. I realized what I was missing. Faster start time and switching is a must. I normally have 3/4 projects (i.e ST sessions open). And just using key board (ctrl-tab) switch between them, and its almost instantaneous.
I typically use it for coding Go, bit of C++ and web UI (javascript etc).
The fast feel is so good, that now, I think even if I need to start a Java project, I will try ST with some appropriate plugins.
I typically have 4-5 Atom windows open all with multiple files open and each has always opened instantly when switching.
Have not used Atom. Great for you, if you like it.
My point being, when I started to use ST (which has been coded in C++). It dawned on me, that most editors not coded in C/C++ (or coded in Java, which are the ones I used) are slow, mainly because of lots of extra memory usage. Using ST also brought back the memories of fast and responsive Vi(m) earlier. I recalled, even MS Visual C++ (which I believe is done in either C or C++), which I used before eclipse/etc was quite fast. Hence my submission. So now, I don't think I am going to like using a coding editor, which is done in any garbage collected language (basically any non C/C++ language). As a side note, when I tried to use the DartEditor for coding in Dart, after having tasted ST, I was thinking why did Dart team not make a simple ST plugin instead? I believe an editor could make a difference in adoption of a new language. In love with ST.
Granted, I typically use Sublime in a way that others probably do not...more for manipulating / viewing data than actual coding. Outside of HTML, JS & CSS, I tend to use IDEs for development (VS for C#, XCode for ObjC and Jetbrains for most everything else). Maybe Atom isn't meant for that type of use and it much more suited for use as something akin to an IDE.
All that being said, I have found nothing that compares to Sublime for simple data viewing / manipulation (regex)...it seems to have no issues with 100+ MB files where as I don't even know if Atom could open something that large.
Since I only use Atom to write code I would consider anything over, say, 200kb a large file. Unless it's a log file I never open anything larger than that in Atom. A few MB usually isn't too bad but once I hit around 5MB it gets to be just too slow.
I use sublime for browsing log files :)
Javascript isn't interpreted, it is dynamically typed, but there is a compilation process before any JS code even executes.
The plugin system is great. But updating, searching, parsing, is very slow. Have you tried displaying the keybindings? It takes forever.
While I love Atom for small projects, its slowness is what drives me away for large projects.
One great thing that came out of it was Electron though, neat piece of software.
Note: I run it on the beefiest 17" mid 2015 Macbook Pro.
Being interpreted and dynamically typed are not mutually exclusive. Regardless I'm not going to get into a pedantic argument about what is or isn't an interpreted language because it's ridiculous. If you feel strongly about JavaScript not being an interpreted language, as per your personal definition of interpreted languages, then feel free to update the wikipedia article (https://en.wikipedia.org/wiki/Interpreted_language).
> The plugin system is great. But updating, searching, parsing, is very slow.
I haven't noticed. By the time I get to the point of needing a search function over a project (because in file is instant) it's not the fastest operation in any editor.
> Have you tried displaying the keybindings? It takes forever.
Yeah though I've never noticed any slow down in doing so (seems to open in less than a second every time I try it on my MacBook Air). Regardless keybindings is something I'd open once every 3 months-ish; so it could take 20 minutes to open for all I care as long as the editor itself is fast and improves my productivity, which at the moment it does (I previously used Sublime).
I move to whatever editor makes me more productive. I have no loyalty here. I tried Visual Studio Code which was pretty nice but I'm too used to tabs and had to move back to Atom.
Yeah I've opened maybe one or two files like that before. I honestly can't remember if there was an issue or not but like I said I would be shocked if I ever needed to open a file that's bigger than, say, 200kb in Atom. If I need to open a big file that's, say, logs or contains base64 encoded stuff in it then I use Sublime. Atom just isn't a good fit for opening large files.
Right tool for the job and all :)
That's why I use TextMate ;) Honestly, it's got a great UX and is native for OSX. But hey, use whatever you enjoy.
Thats a bit over exaggerated. As fine for me. Maybe I have a faster laptop
Switching to Atom a few months ago let me get things linting errors displayed inline [1]. Sublime plugins have very limited ability to tweak the editor contents.
There's also a neat Git plugin that turns Git's textual conflict markers into live markers allowing you pick which side to use. It also displays a list of pending project-wide conflicts while you're working — also not something Sublime plugins can do.
The Markdown Preview package is very nice. It displays a preview window inside Atom. Sublime can't do this because of the API.
Atom has a bunch of Go packages that autoformat on save, provide "intelligent" autocompletion (e.g. type a variable and a dot and it will suggest methods callable on the variable), lint/syntax check, and so on. (In particular, Atom's autocompletion mechanism is extensible; plugins can provide completions based on context. Sublime's autocompleter is hardwired, I believe.) There are some Go packages for Sublime, but they never worked properly for me. The ones for Atom are quite polished and just work.
Sublime plugins can't modify the file sidebar. With Atom, I can have the sidebar colorized based on Git status, for example.
The color-picker package is great — when editing CSS you can get a little color picker popup for color codes. Again, not possible in Sublime.
In short: Sublime has a very limited plugin API that supports very little side from editing text. Atom's API opens up a ton of possibilities that simply can't be done in Sublime.
There's no way to know 'everyone' is really using ST3 beta except if you learn it from a social network.
Yes, if I go to a website for a product I haven't used before, and there's a big download link for X.0 version, and a link somewhere else on some other page for x+1.0.beta, I'm going to download the X.0 even if I _do_ find that other page.
A social network, tons of posts and articles on the subject on blogs and web outlets, Hacker News (which has covered the editor several times in the past), plus the official forums.
If it's a tool you use everyday for hours on end (which is what programmers do with their editor), then you can go out and read a few things about that. People spend hours reading on their favorite shows, car models, NFL games, movies etc -- and those are just hobbies, whereas this is a professional tool.
If it is production quality as everyone is telling me, then why not removing that "beta" flag?
Back when it was hot (some of you are probably too young to remember this) I used jEdit. It is still around and gets some maintenance updates from time to time (http://www.jedit.org/), but the plugin ecosystem has languished so you better be ready to roll your own.
With Vim and Emacs (Vim for me) I can trust it to go anywhere I want to be. If I'm ssh-ing into a Redhat 5 production server needing to do an emergency fix at 3 in the am Vim is there for me.
And when I need syntax support or any plugin under the sun, that is available as well. Vim is also blazingly fast compared to Atom (the latest fad) which is sluggish by comparison. Sublime seems to be falling into that sunsetting stage the same as jEdit
Just my 2 cents.
> Sublime seems to be falling into that sunsetting stage the same as jEdit
1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead.
2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins.
3) Stick with a tool that you can have a level of faith will still be well supported for the next 20 years.
If anything, vim is the most unique editor with the most unique "paradigm" I've ever really had much experience with. Atom, Sublime and Emacs all seem pretty much the same in terms of how you interact with them.
Pretty sure saint ignucius will damn you to proprietary software hell for dissing on the One True Editor (tm).
Parent is saying that vim is a 70's paradigm and people not stuck in the past enjoy the modern paradigm that sublime follows.
Production servers usually have no vim plugins. Basic vim editing is good enough to get by if you're just looking at logs.
In my workplace and I guess it's pretty standard these days (in Linux shops at least) where the code repository resides on a server in a data center and not locally on your laptop/desktop.
Here are the issues with this development work flow:
- There are a lot of hurdles to go through to install all the vim plugins (no root access, security of plugins etc.)
- Which plugin manager to use (Vundle, pathogen or some variant??). Why isn't there a standard for this after all these years?
- Unreadable .vimrc file with all sorts of key bindings (Yes I know it's "write once use everywhere", it still is unreadable a few months down the line)
- In my experience, using vim on a mounted drive with the plugins I need (git,ctrl-p,ctags,cscope,nerd tree and a few others) is slower as compared to Sublime Text.
> 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins.
https://packagecontrol.io/stats
I don't think these are low numbers by any means.
I'm not a vim basher, I just don't prefer working with it.
There's reasons other than staying power to use an application. If I only used applications that I expect to be around forever I'd be paralyzed and unable to make a decision a lot of the time.
My dream editor is Sublime3 with an extensible UI layer for plugins in HTML/JS.
This is a funny myth.
Now to some facts:
1. It’s the Applet part that has a bad security record. Not standalone Applications.
2. Java GUI apps use less resources, are less laggy, and more native than any node.JS app out there. jEdit is not an exception.
It’s crazy to see people hype Atom for being node-webkit, extensible, etc, but complain about Java apps for "bundles a whole runtime" (while node-webkit bundles a whole browser), for "so slow and laggy" (but faster than node-webkit), for "looks not native" (but more than node-webkit)
I can't remember any instances where IntelliJ was "laggy" except during processes that inherently take time for larger code bases (indexing, etc.).
Yes off topic; sublime rocks! :)
Incidentally, I have used Atom and while I found it to be too slow and lacking features, I'm quite pleased it was made since it spawned the Electron project which is pretty awesome.
https://github.com/atom/electron
"Build cross platform desktop apps with web technologies http://electron.atom.io"
It's my opinion that Electron is a terrible idea.
It's very fast, handles huge files/projects and has plugins and extensions for a wide range of tasks.
The only downside is that the developer retains complete control and updates are few and far between. It would be great if the project could become more open and we could see more focused development on it.
Recently, I found its old main author (Slava Pestov) again on the swift-evolution mailing list - this time with an @apple.com address.
That said, I still support Sublime and would still even buy the upgrade to the new version if it ever comes out.
Its clear that Sublime is no longer being developed as a priority like it used to.
I have been using atom now full time for 3 weeks and gave it another chance as I love a lot of the plugins it has and the community and I am very impressed.
Regarding its slowness it has improved a lot. The only complaint I have with its speed compared to a native app like sublime is that it is slow in starting. This doesn't affect me much as when I am working on a project I leave it open all the time anyway :-)
Give it a try and get some of the useful plugins and you will never look back.
It still somehow manages to feel faster than many other editors.
EDIT: Do I really need to say /s ?
With emacs and vim around, I'd argue that text editors is a solved problem, if there ever was one. It is very hard to match emacs in terms of useful features or adaptability. Granted, the learning curve has a reputation for being steep, and elisp could need a facelift, but I think addressing these problems would provide much more value than reinventing the wheel with another shiny editor.
A piece of software like a programming editor, which until now leaves a lot to be desired, even in the most popular implementations (Vim, Emacs, ST, Atom, etc), sure needs constant reinvention and refinement until someone finally gets it right.
Atom would be close to that if it was not fucking based on web technologies. ST3 would be that if it was open source (so the APIs/internals could be improved faster). Emacs would be that if it wasn't based on a 30+ year old UI model and elisp. Vim would be that if it was more extensible and not 100% focused on the CLI experience.
Also, your underlying point is practically offensive to the hacker mindset. Though there is nearly a cult-like devotion to the editing tools of yore, the devotion is not universal.
I've been using Atom for a couple of weeks now, mainly for a few Laravel applications. I use the git-hide package to remove the ".git", "node_modules" and "vendor" directories from the tree view which does seem to have a nice effect on speed.
That said, here are the issues I face:
- I frequently find that I type too quickly for the editor to pick up the keys and I end up missing off the beginning of some lines.
- I still use Sublime text daily for quickly opening a file, rather than waiting for a new Atom instance to open.
- PHP support is awful. Auto complete for class names in any used packages is something that I sorely miss from the Sublime plugin I use.
- Start-up time still takes a few seconds which means I only use it for projects.
- Listing of installed and discovery of packages is _so_ slow. Sometimes I just don't bother installing a package anymore because it takes at least 10 seconds to show me what I have installed or search for one.
Regardless of me using Atom, I'm still loving the updates to Sublime and continue to moderate the forums, knowing that Jon will deliver :)
That's not to say that it doesn't have its own problems. One massive pain-point: I was assisting with a getting a complex build system working a few months back. The VSCode build integration is scenario-driven garbage. Because I deviated from the most basic of scenarios I had to resort to all manner of nasty hacks to avoid having contributors open a CLI.
I feel it'll never be a sensible choice until people no longer have to type sentences like this.
I may be wrong, so please let me know :)
"tree-view":
hideIgnoredNames: true
hideVcsIgnoredFiles: true
I just wish Node-based editors were as nimble as ST.
ST3 is a great editor. My biggest problem with the recent pause in development is that I have to install a plugin to get Rust syntax highlighting.
Atom is fine for many people's usage of it, and it does some interesting things. It is not without merit. But until issues like this go away, I can't consider it. I regularly need to work with text files several hundred megabytes large. Atom cannot handle this usage. And before you say "Well, you're deliberately being difficult"... I am either taking a quick look at big csv files or automatically generated XML files that store configuration information for some of the systems I work on. A 120 MB XML config file isn't unusual.
Is there any plugin/editor combination that still does C completion like SublimeClang used to do?
[1] http://limetext.org [2] https://github.com/quarnster/SublimeClang
As a moderator of the forum, I try my best to keep on top of it. The old forum didn't have mail notifications or a decent spam blocker, so it was a lot of manual work.
Very customizable, very nice font rendering, healthy plugin ecosystem and tons of themes, lots of shortcuts and features, GPL v2 license.
I use this at work and home. I love vim, but I haven't mastered it more than I have jEdit.
I am taking a shot in the dark but I'm guessing the lack of popularity is due to it being dependent on the jvm. It's a non-issue for me.
It seems to me that Sublime lost a lot of community support due to the very long development time of version 3.
I honestly think Jon Skinner could just release the next version as 3.0 and few people would mind since most people treat the current beta as an RC anyway.
But if you already have a license key for 2, there's no risk, download 3 and see if it accepts your existing license key -- I think it might.
I have no idea why 3 is still called 'beta'.
It does. While ST3 is on beta, you can use your ST2 license.
>>Thanks for trying out Sublime Text 3!
Sublime Text 3 is a paid upgrade from Sublime Text 2, and an upgrade will be required for use when 3.0 is released.
Until then, please enjoy Sublime Text 3 Beta.
If you have a Sublime 2 license, you will have to pay to upgrade to 3 once it is out.
Those names are arbitrary BS.
ST3 hasn't felt like "beta" software for 2+ years.
If he had released it as ST3 2-3 years ago, nothing would have changed. It's been release quality for ages.
Given the very slow and infrequent development and the fact that its just a text editor (albeit a fancy one), i really can't justify the price.
I would consider buying if it was receiving regular updates (bug fixes, new features, etc) and had a bit of certainty with its future. But really, if it was priced around $20, i would have bought it ages ago - and if it hadn't then, I'd buy it now.
Do you use Sublime for work? If so, you should pay for it. Any other excuse is just you, being cheap. $70 is nothing for it offers.
Panic's Coda is priced similarly, but it also offers a lot of web-dev targeted features that other editors either don't provide or only provide less user-friendly plugins for
When you strip out plugins made by someone who isn't getting a cut of that $70, what are the tangible features Sublime has over the glut of free editors out there?
For something I'm going to have my face in for hours each day, every day, $70 seems pretty reasonable. (Partially playing devil's advocate here, as I use vim much more than Sublime)
I want to buy another license.
Thanks.