11 ms·

Sublime Text packages are on GitHub

194 points by kolev 11y ago

iaw 11y ago
Whenever I've used Sublime Text I've had great experiences with everything except trying to customize/setup my own packages. I think this is an excellent step in the direction of making Sublime Text a more out-of-the-box solution.
sergiotapia 11y ago
Is this a sign of Sublime Text inching it's way towards open source? If Sublime Text went full on open-source would it decimate Atom? I'd like to think so. I just had to move back to Sublime for the third time because Atom would choke on a 400 line Ruby file. I was using vanilla Atom with RuboCop and it's linter, and stutter-city. Should the owner decide to open source Sublime Text, it would instantly put it with the likes of Vim and Emacs in my opinion.
- Old_Thrashbarg 11y ago
  Yeah, the only thing holding me back from trying out Sublime Text is that I don't want to invest time learning proprietary software when there's good open-source alternatives.
  - Cthulhu_ 11y ago
    But are there good open source alternatives? Besides Vim and Emacs, I mean, which seems to be what ST is most often compared to. Atom appears similar in features and whatnot, but it's still struggling heavily with performance issues, and mainly because they decided to use an incredibly complicated stack - html/js. Square peg / round hole approach.
    - rezistik 11y ago
      I'd switch to sublime in a heart beat and pay twice what he wants now if it had a similar package manager to Atom. That to me is the biggest draw. I often try to pick sublime back up, but when I go to install packages I find I have to mess with too many configuration files and searching the third party package manager kind of sucks. It's faster though so I keep trying before getting frustrated and going back to the land of easy wins.
    - lewisl9029 11y ago
      > performance issues, and mainly because they decided to use an incredibly complicated stack - html/js This sentiment, that Atom is not performant because it's built on web technologies, gets repeated a lot, but it's provably false. Light Table and VS Code both use the exact same HTML/CSS/JS stack on top of Electron. Both are much more performant than Atom. Whatever performance issues plaguing Atom are more likely caused by flawed architecture and/or lack of optimization. The underlying web technologies it's built on have been demonstrated to be capable of delivering highly performant text editors.
      - strmpnk 11y ago
        I'm not going to claim that you can't make performant editors with web tech but recent snapshots of Light Table and VC Code are not all that fast for me for files that get beyond a hundred lines or so. Same with Atom. It seems to usually be the syntax highlighting engines on first load of a file, or if you're moving code around, a simple cut and paste will show this too. I'd happily turn off highlighting since I find it distracting 99% of the time but ironically these editors don't allow that. Some of the editors make highlighting async but it makes it even more obvious when interacting with the view. There's a distinct pop-in then style effect that often happens. Now the question: Why is highlighting slow? It seems like a lot of these editors still run lots of logic including highlighting i the UI thread still. Web workers could potentially help but of course there are still limits to how values are exchanged with the UI so it's likely non-trivial work. So, remind me again why it's an advantage to use a browser engine for this application? Portability is about the only thing I can think of but that hasn't stopped Sublime Text obviously.
        lewisl9029 11y ago
        I just did a quick, unscientific test using a 3.5 MB bundled (but not minimized) .js file. Sublime 3 results: Opening the file took 13 seconds, of which only for the first 5 seconds the editor interface was unresponsive. Syntax highlighting was available throughout the entire file immediately after opening. As an additional test, I tried doing a select all, cut and paste of the entire 3.5 MB source. The paste took 6 seconds. The editor interface was unresponsive during the entire time. Syntax highlighting became available immediately after the paste completed. VS Code results: File opened in 7 seconds. The interface was fully responsive for the entirety of this duration. Syntax highlighting took an additional split second, but this did not affect responsiveness either. Cut and paste completed almost immediately, but syntax highlighting did not become available for another 7 seconds, but responsiveness is once again completely unaffected during the entire process. So it looks like in terms of pure syntax highlighting speed, the two are rather evenly matched. However, it would appear that VS Code has an edge over Sublime 3 in both initial loading speed as well as in terms of UI responsiveness. As for your question: > So, remind me again why it's an advantage to use a browser engine for this application? My own answer would be that it's simply the most accessible way to build cross platform applications. The web platform simply has had more optimizations and standardization work put into it than any other interface technology out there today. It also happens to have a very simple model for concurrency that is very well suited for event-based UIs: the single UI thread with message passing through web workers. While it's true that the traditional, free-for-all multi-threading based concurrency model is more powerful, it also presents a much heavier cognitive load on the developer and is notoriously error prone to implement. It was probably a much simpler task to implement Web Workers in VS Code than it would have been to architect Sublime 3 into a fully multi-threaded application on all the platforms that it must support, in order to have the UI be fully responsive during intensive tasks like in VS Code.
    - PantaloonFlames 11y ago
      > But are there good open source alternatives? Besides Vim and Emacs, I mean, Why dismiss the two most popular alternatives?
      - oldmanjay 11y ago
        The culture around both of those editors is offputting. There are way too many people who substitute an emotional attachment to their esoteric tool interface for an actual reason to use something, and then they evangelize. It's basically religious.
        infodroid 11y ago
        Perhaps it appears that way to outsiders. But I have found that within editor communities the culture is mostly about getting things done. Besides, why should the emotional attachment of some users reflect badly on the community as a whole? For example this study argues that devoted fans of the Apple Macintosh appear to be like members of a religious cult [1]. But is that a good reason for someone to avoid Apple products? And so what is different about editors? [1] http://gulnurtumbat.com/GulnurTumbat/Research_files/The%20Cult%20of%20Mac.pdf http://gulnurtumbat.com/GulnurTumbat/Research_files/The%20Cu...
        lrvick 11y ago
        Using a tool only due to emotional attachment is bad engineering, but so is -not- using a tool because some are emotionally attached to it. Choose or discard tools based on their utility and merits. As engineers we don't have the luxury of ignoring an entire path of tool evaluation simply because a many people are annoyingly vocal about the value they see in it. I use vim because I like the keybindings, speed, the ability to use it on any of the hundreds of systems I work on, across many different operating systems be it remote over ssh or locally. I need the ability to easily fix/modify it to meet my specific workflow needs and share my configuration across all my systems. (Example: https://raw.githubusercontent.com/lrvick/dotvim/master/screenshot.png https://raw.githubusercontent.com/lrvick/dotvim/master/scree... ) Being open source I know I can always use this tool how I like and port it to any future platform I care about. Closed source GUI-only editors only work for a very limited number of use cases, and only for a period of time that the current maintainers feel like maintaining them. Vim and Emacs will remain maintained so long as there are enough people using them that care to port and patch. 20+ years is a good track record and thousands of contributors have come and gone over that time. If the (single) author of Sublime gets hit by a bus in a few years, the chance of it ever being ported to a future version of the operating system you are currently using is now nonexistant. Worse, the years of you becoming efficient with that tool will now be for nothing. Closed source is fine for entertainment, but when it comes to anything you rely on and are going to spend a lot of your time investing in... you should always have the control to take over the codebase yourself if needed.
    - framp 11y ago
      Kate is a great editor. It used to be better in the past, nowadays there are some random bugs popping up from version to version. Actually it was working best with KDE 3.x, KDE 4.x introduced performance problems, KDE 5.x fixed some and added more bugs. Minor stuff anyway and YMMV.
  - jbrooksuk 11y ago
    I genuinely don't get this argument. If it was that, if Sublime were to cease updates everything stopped, I'd get it - but in the 4/5 years that I've been using it, I've only ever once had an issue (with a dev build) that stopped me from working. I just downgraded. Just because something could stop being maintained, doesn't mean it instantly becomes worthless. I don't know, maybe I'm missing something?
    - mikekchar 11y ago
      I don't know you, so it's hard to tell, but it's possible you are missing something. An editor is an integral part of a programmer. You don't want to be thinking about the editor when you edit. You want to have a thought and have it appear in your editor. Very good editors have a crazy number of features. Many of these features cover small corner cases that only show up once in a while. A programmer who really knows their editor can use all of these features without thinking about them. It can save you an hour when you really, really need that hour. It can also save you brain cycles when you really, really need brain cycles. Switching editors is not impossible (I've done it twice in 30 years, though I'm moving my way back to my original editor, emacs). If you are a real expert in your editor you will lose productivity for however long it takes you to acquire the equivalent features of your original editor. My experience is that it takes months, if not years to get really, really good -- depending on how much time you have to fiddle with your editor. Choosing an open source editor that works on a variety of different platforms and is supported by a large community of people gives you insurance that you won't have to change editors unless you have some really compelling reason to do so. If Sublime were stop being maintained, sure you could continue to use it for a few years, but would you (could you) be using it 10 years from now? That seems unlikely without an active community making builds for the new platforms you are going to be working on. I know a lot of the younger people I work with don't understand the benefits of learning your editor to the extent I'm talking about, so they don't understand the cost of switching. Pair programming with someone who is a true expert with their editor can be very illuminating.
- jastanton 11y ago
  > decimate Atom I don't think so. Keep in mind that Atom is used internally at Github, and is starting to be adopted by some big names. Things like that don't get chocked out by the competition. I'm not sure how much funding it'll loose internally if they aren't the #1 but I don't think it'll effect them as much as if Sublime Texts competitor got it's funding from sales for instance.
  - makeitsuckless 11y ago
    > is starting to be adopted by some big names Citation needed. All I hear about Atom is that people are giving up on it.
    - kyrra 11y ago
      Facebook's tool built ontop of Atom: Nuclide[0]. [0] http://nuclide.io/ http://nuclide.io/
      - digikata 11y ago
        Not to criticize the tools themselves here (Atom or Nuclide), but the process of building an enhanced X over some large base application code didn't work out well for a lot of Eclipse tools. Or at least my experience is with working with lots of Eclipse + "x" on top environments which were integrated once, then rarely touched the base Eclipse again... leading to lots of inconsistent annoyances between Eclipse/tool instances.
        kyrra 11y ago
        As an eclipse user for far to long, I understand the pain. I'd prefer if more languages/frameworks went the Golang approach and provided generic tools that can then be integrated into various editors to provide things like auto-complete and context support (oracle).
    - quonn 11y ago
      Microsoft's "Visual Studio Code".
- neuromute 11y ago
  I emailed SublimeText offices a long time ago to push the concept of crowdsourcing the open sourcing of the project. It was blown out of the water. I should imagine that even if they set a high goal, they'd do pretty well out of it. I'd happily pay a premium price to see the source released permissively (free software approved, ideally).
  - wbond 11y ago
    It seems to me a pretty realistic estimate that Jon is doing rather well off of Sublime Text nowadays. However, he's been working on it for over 8 years. I've gotten the impression that some of the early times were very lean and he took on contracts to keep it going. So why should he give up the resources that he justly earned? He worked his butt off, likely made lots of personal sacrifices, and now he should open source it once he's built a solid product that lots of people love? Ok, so let's say you don't buy the angle that he deserves the success he's had. Do you think Sublime Text's success is a coincidence? Jon is a single engineer who's built pretty much every aspect of it, from a custom cross-platform UI that doesn't suck, to a custom editor control, more recently a parallel custom regex engine to make syntax highlighting faster and more robust. He's taken performance seriously from day one. By contrast, Atom started development in 2008 and had a team of engineers working on it. It has more community involvement and bells and whistles, but still seems a bit behind in performance. I would argue that Jon and his priorities and decisions are one of the biggest reasons Sublime Text has been successful. Would open sourcing it help Jon keep up the focus and insight he has shown in the past? Or, would it likely take up a large amount of his time? I don't have an insight that anyone else doesn't have. And I could be completely wrong, but I feel like if open source would ensure a better product, Lime would have taken off. Or there would be other, strong, cross-platform text editors written in desktop technologies.
    - asddubs 11y ago
      I don't think open source ensures a better product. I think open source can make a good project better, but you still need competent leadership
- coldtea 11y ago
  >I just had to move back to Sublime for the third time because Atom would choke on a 400 line Ruby file. I was using vanilla Atom with RuboCop and it's linter, and stutter-city. I just can't understand why people would even use a JS based text editor and expect it to perform. It will never happen. And it's not because of JS (which can have decent speed), it's mostly the HTML/DOM part. If you don't like ST3 there's Emacs, Vim, TM2, Idea, and tons of other options. Atom, why?
  - michaelwww 11y ago
    Facebook is throwing it's weight behind Atom. They are not forking Atom, but rather contributing their improvements back to Atom. They are developing their Nuclide IDE with Atom packages. Atom is still young, but has a bright future. Free and open source is very attractive for lots of us.
    - swah 11y ago
      Couldn't they just do it in C++ though?
  - copperx 11y ago
    Agreed. The HTML/DOM part makes absolutely no sense. You're trying to render text, not a webpage. Just make the GUI native or use Qt!
- daemonza 11y ago
  I tried Atom when it came out, it was painfully slow...on a whim I tried it a couple of weeks ago to test the go-plus package for go development and, and I was pleasantly surprised how much performance improved, personally when both editors are open, I don't see a speed difference anymore. If you have not tried Atom recently, give it a go.
  - statictype 11y ago
    I still find it fairly slow but I'm going to try and use it as much as possible, anyway. I like the core principle it's built on (completely hackable as everything is built on a scripting layer) which makes it more potentially powerful than Sublime, even if its slower now.
alexggordon 11y ago
Here's the ST forum announcement[0] from June 16th. This is a good step in the right direction for ST. It seems that JPS is increasingly relying on the open source community for ST development, which could lead to some awesome developments in the future. I think it would be even more awesome if JPS open sourced the ST Package API. I think that could really improve the state of package development in the future, and is one of the areas that I think is still hurting the growth of ST. [0] http://www.sublimetext.com/forum/viewtopic.php?f=2&t=18787&p=69229#p69229 http://www.sublimetext.com/forum/viewtopic.php?f=2&t=18787&p...
- zzleeper 11y ago
  Your comment was the most informative and yet it's the second least upvoted. Syntax files are those things that get really annoying if buggy and are really easy to fix (compared to adding features to the C++ codebase). The fact that they are YAML files makes it even better. Also hope to see more stuff opening up!
- wbond 11y ago
  Part of the reason I think this happened is because ST just switched to a custom syntax format that compliments the new parallel regex engine. Before Jon could work with the open-source Textmate language definitions. By mass converting them and open-sourcing them, the community can help keep them up-to-date, and Jon can provide the improved performance of the new syntax engine.
  - alexggordon 11y ago
    Exactly my point. I'm just excited because It seems to me that this is the first time JPS has open sourced something directly to the ST community, with the idea that they will continue to develop and maintain it. I'd really like to see more of that happen, and I think there's a huge desire to help with future development of ST.
  - hatmatrix 11y ago
    Perhaps the advent of Atom lit the fire under JPS.
usaphp 11y ago
Can someone explain me why is everybody so obsessed about sublime not being open source? Being an open source software gives no guarantee that it wont be abandoned one day, and if there is something else better even not open source out there everybody (mostly) will forget about an inferior open source project and use the premium software with better features instead, it happened when sublime text was released and won our hearts, so I don't see how can it becoming open source stop a new premium and better product beat it just like it beat others before...
- ffreire 11y ago
  I believe the argument for open source is that the community can continue to maintain the software long past when the creator stops (for whatever reason). Responsible maintainers will often seek new developers from the community to take charge (as is the case with marginalia[0], the first project that came to mind). Of course this isn't the only reason why folks want ST to be open source, but I believe this addresses your point about abandoning closed source software. [0]: http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/ http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/
  - jbverschoor 11y ago
    Well. textmate was also closed source, abandoned and opensoured... Didn't do any good. I'm very happy with ST and hope other people will also buy a license.
    - biftek 11y ago
      Sure about that? https://github.com/textmate/textmate/commits/master https://github.com/textmate/textmate/commits/master Happy TextMate 2 user here.
  - coldtea 11y ago
    >I believe the argument for open source is that the community can continue to maintain the software long past when the creator stops We've seen this fail to be so in practice time and again, if not for the software entirely (which also happens), then for less popular ports, like for OS X and Windows.
0942v8653 11y ago
I can't help but think it's funny that Sublime Text uses - XML for snippets (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/forv.sublime-snippet https://github.com/sublimehq/Packages/blob/master/C%2B%2B/fo...) - YAML for syntax files (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%2B%2B.sublime-syntax https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%...) - JSON for settings (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%2B%2B.sublime-settings https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%...) - and plist for TextMate compatibility (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/Indentation%20Rules.tmPreferences https://github.com/sublimehq/Packages/blob/master/C%2B%2B/In...) Of course each one has a reason to be that way, but it must be really annoying to maintain.
- jbrooksuk 11y ago
  Oh it is. I imagine that Jon has plans to consolidate this mess, but it'd take a while to update the thousands of packages being maintained. One step at a time!
- icebraining 11y ago
  YAML is a superset of JSON, so those might be processed by the same parser.
  - robin_reala 11y ago
    That’s not true; YAML is completely seperate.
    - bjacobel 11y ago
      Correct. YAML and JSON can be parsed into the same tree structure but are completely separate syntaxes.
      - icebraining 11y ago
        No, they aren't. From the YAML site [emphasis mine]: "YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model. This is also the case in practice; every JSON file is also a valid YAML file." http://yaml.org/spec/1.2/spec.html#id2759572 http://yaml.org/spec/1.2/spec.html#id2759572 You can parse any JSON file using a YAML parser.
koblas 11y ago
Just for humor reference, 20 years from now there will be thousands of text editors that will have come and gone. But, emacs and vi will still be cranking out code everyday.
- krampian 11y ago
  And religious wars over which is the better editor will likely still be ongoing...
  - shpx 11y ago
    In practice those are over, just a stale joke people keep repeating.
    - nzp 11y ago
      It was always kind of a ha-ha-only-serious joke. I'm amazed to read some people here take the "wars" seriously enough to make it an argument to not use either. Like some weird cultural misunderstanding. Hipster kids these days...
jbrooksuk 11y ago
I posted this 15 days ago (https://news.ycombinator.com/item?id=9724047 https://news.ycombinator.com/item?id=9724047) - forum announcement may have been linked somewhere too? Edit: I don't understand the down votes. This happened a while back, nothing has changed except the open source packages made it into a release - which was due anyway?
- asdgb1234df 11y ago
  You were downvoted because your comment added nothing to the conversation, and came off as sour grapes. (You may not have intended it to sound so, but I read this as, "I submit essentially the same material 15 days ago but nobody gave me karma for it. waaa"). The HN karma system is the elephant in the room. Everyone knows it affects behavior, but you're supposed to pretend like it isn't there.
  - jbrooksuk 11y ago
    Ok, I can see that - amongst a group of kids. I don't care for karma. I wanted to show that this has been here "for a while".
    - asdgb1234df 11y ago
      Haha fair enough. This may be completely non sequitur, but my my life significantly improved when I stopped trying to denigrate other people in order to defend my own hurt feelings. Outside of the fact that you were the one who posted it earlier, it seems unlikely that you were bothered by the previous posting. I haven't seen you on other reposts on HN saying the same thing. Therefore I am led to conclude that it's not the reposting, but the lack of credit, that upset you. And if you're really bothered about reposting, on this internet, it's going to be a repetitive experience for you. Also, if you question your downvotes on HN, you'll get more downvotes and engage in less conversations from which you can learn.
- kolev 11y ago
  Sorry, I didn't see this earlier although I frequent the new links. I suggest posting stuff like this between 9AM and noon PST as popularity highly depends on the timing as well.
camhenlin 11y ago
I found the Sublime package repo pretty helpful today, after the Sublime update, where the syntax coloring was changed without warning. Luckily all of the old color was in the first commit to the repo.
forrestthewoods 11y ago
I wonder how much money it'd take to buy out Sublime Text and open source it. I wonder how much money has been spent developing Atom so far.
fweespeech 11y ago
Honestly, the one thing I want more than this from ST is a promise that in the event of loss of interest or catastrophe, ST3 will be open sourced. Hit by a bus insurance if you will :P
mbell 11y ago
Hopefully this results in improved syntax highlighting for Ruby. Anyone know of any ongoing efforts in this area?
- leetNightshade 11y ago
  Well it's been opened up. Why not help contribute yourself?

194 points by kolev 11y ago

iaw 11y ago

Whenever I've used Sublime Text I've had great experiences with everything except trying to customize/setup my own packages. I think this is an excellent step in the direction of making Sublime Text a more out-of-the-box solution.

sergiotapia 11y ago

Is this a sign of Sublime Text inching it's way towards open source? If Sublime Text went full on open-source would it decimate Atom? I'd like to think so. I just had to move back to Sublime for the third time because Atom would choke on a 400 line Ruby file. I was using vanilla Atom with RuboCop and it's linter, and stutter-city. Should the owner decide to open source Sublime Text, it would instantly put it with the likes of Vim and Emacs in my opinion.

Old_Thrashbarg 11y ago
Yeah, the only thing holding me back from trying out Sublime Text is that I don't want to invest time learning proprietary software when there's good open-source alternatives.
- Cthulhu_ 11y ago
  But are there good open source alternatives? Besides Vim and Emacs, I mean, which seems to be what ST is most often compared to. Atom appears similar in features and whatnot, but it's still struggling heavily with performance issues, and mainly because they decided to use an incredibly complicated stack - html/js. Square peg / round hole approach.
  - rezistik 11y ago
    I'd switch to sublime in a heart beat and pay twice what he wants now if it had a similar package manager to Atom. That to me is the biggest draw. I often try to pick sublime back up, but when I go to install packages I find I have to mess with too many configuration files and searching the third party package manager kind of sucks. It's faster though so I keep trying before getting frustrated and going back to the land of easy wins.
  - lewisl9029 11y ago
    > performance issues, and mainly because they decided to use an incredibly complicated stack - html/js This sentiment, that Atom is not performant because it's built on web technologies, gets repeated a lot, but it's provably false. Light Table and VS Code both use the exact same HTML/CSS/JS stack on top of Electron. Both are much more performant than Atom. Whatever performance issues plaguing Atom are more likely caused by flawed architecture and/or lack of optimization. The underlying web technologies it's built on have been demonstrated to be capable of delivering highly performant text editors.
    - strmpnk 11y ago
      I'm not going to claim that you can't make performant editors with web tech but recent snapshots of Light Table and VC Code are not all that fast for me for files that get beyond a hundred lines or so. Same with Atom. It seems to usually be the syntax highlighting engines on first load of a file, or if you're moving code around, a simple cut and paste will show this too. I'd happily turn off highlighting since I find it distracting 99% of the time but ironically these editors don't allow that. Some of the editors make highlighting async but it makes it even more obvious when interacting with the view. There's a distinct pop-in then style effect that often happens. Now the question: Why is highlighting slow? It seems like a lot of these editors still run lots of logic including highlighting i the UI thread still. Web workers could potentially help but of course there are still limits to how values are exchanged with the UI so it's likely non-trivial work. So, remind me again why it's an advantage to use a browser engine for this application? Portability is about the only thing I can think of but that hasn't stopped Sublime Text obviously.
      - lewisl9029 11y ago
        I just did a quick, unscientific test using a 3.5 MB bundled (but not minimized) .js file. Sublime 3 results: Opening the file took 13 seconds, of which only for the first 5 seconds the editor interface was unresponsive. Syntax highlighting was available throughout the entire file immediately after opening. As an additional test, I tried doing a select all, cut and paste of the entire 3.5 MB source. The paste took 6 seconds. The editor interface was unresponsive during the entire time. Syntax highlighting became available immediately after the paste completed. VS Code results: File opened in 7 seconds. The interface was fully responsive for the entirety of this duration. Syntax highlighting took an additional split second, but this did not affect responsiveness either. Cut and paste completed almost immediately, but syntax highlighting did not become available for another 7 seconds, but responsiveness is once again completely unaffected during the entire process. So it looks like in terms of pure syntax highlighting speed, the two are rather evenly matched. However, it would appear that VS Code has an edge over Sublime 3 in both initial loading speed as well as in terms of UI responsiveness. As for your question: > So, remind me again why it's an advantage to use a browser engine for this application? My own answer would be that it's simply the most accessible way to build cross platform applications. The web platform simply has had more optimizations and standardization work put into it than any other interface technology out there today. It also happens to have a very simple model for concurrency that is very well suited for event-based UIs: the single UI thread with message passing through web workers. While it's true that the traditional, free-for-all multi-threading based concurrency model is more powerful, it also presents a much heavier cognitive load on the developer and is notoriously error prone to implement. It was probably a much simpler task to implement Web Workers in VS Code than it would have been to architect Sublime 3 into a fully multi-threaded application on all the platforms that it must support, in order to have the UI be fully responsive during intensive tasks like in VS Code.
  - PantaloonFlames 11y ago
    > But are there good open source alternatives? Besides Vim and Emacs, I mean, Why dismiss the two most popular alternatives?
    - oldmanjay 11y ago
      The culture around both of those editors is offputting. There are way too many people who substitute an emotional attachment to their esoteric tool interface for an actual reason to use something, and then they evangelize. It's basically religious.
      - infodroid 11y ago
        Perhaps it appears that way to outsiders. But I have found that within editor communities the culture is mostly about getting things done. Besides, why should the emotional attachment of some users reflect badly on the community as a whole? For example this study argues that devoted fans of the Apple Macintosh appear to be like members of a religious cult [1]. But is that a good reason for someone to avoid Apple products? And so what is different about editors? [1] http://gulnurtumbat.com/GulnurTumbat/Research_files/The%20Cult%20of%20Mac.pdf http://gulnurtumbat.com/GulnurTumbat/Research_files/The%20Cu...
      - lrvick 11y ago
        Using a tool only due to emotional attachment is bad engineering, but so is -not- using a tool because some are emotionally attached to it. Choose or discard tools based on their utility and merits. As engineers we don't have the luxury of ignoring an entire path of tool evaluation simply because a many people are annoyingly vocal about the value they see in it. I use vim because I like the keybindings, speed, the ability to use it on any of the hundreds of systems I work on, across many different operating systems be it remote over ssh or locally. I need the ability to easily fix/modify it to meet my specific workflow needs and share my configuration across all my systems. (Example: https://raw.githubusercontent.com/lrvick/dotvim/master/screenshot.png https://raw.githubusercontent.com/lrvick/dotvim/master/scree... ) Being open source I know I can always use this tool how I like and port it to any future platform I care about. Closed source GUI-only editors only work for a very limited number of use cases, and only for a period of time that the current maintainers feel like maintaining them. Vim and Emacs will remain maintained so long as there are enough people using them that care to port and patch. 20+ years is a good track record and thousands of contributors have come and gone over that time. If the (single) author of Sublime gets hit by a bus in a few years, the chance of it ever being ported to a future version of the operating system you are currently using is now nonexistant. Worse, the years of you becoming efficient with that tool will now be for nothing. Closed source is fine for entertainment, but when it comes to anything you rely on and are going to spend a lot of your time investing in... you should always have the control to take over the codebase yourself if needed.
  - framp 11y ago
    Kate is a great editor. It used to be better in the past, nowadays there are some random bugs popping up from version to version. Actually it was working best with KDE 3.x, KDE 4.x introduced performance problems, KDE 5.x fixed some and added more bugs. Minor stuff anyway and YMMV.
- jbrooksuk 11y ago
  I genuinely don't get this argument. If it was that, if Sublime were to cease updates everything stopped, I'd get it - but in the 4/5 years that I've been using it, I've only ever once had an issue (with a dev build) that stopped me from working. I just downgraded. Just because something could stop being maintained, doesn't mean it instantly becomes worthless. I don't know, maybe I'm missing something?
  - mikekchar 11y ago
    I don't know you, so it's hard to tell, but it's possible you are missing something. An editor is an integral part of a programmer. You don't want to be thinking about the editor when you edit. You want to have a thought and have it appear in your editor. Very good editors have a crazy number of features. Many of these features cover small corner cases that only show up once in a while. A programmer who really knows their editor can use all of these features without thinking about them. It can save you an hour when you really, really need that hour. It can also save you brain cycles when you really, really need brain cycles. Switching editors is not impossible (I've done it twice in 30 years, though I'm moving my way back to my original editor, emacs). If you are a real expert in your editor you will lose productivity for however long it takes you to acquire the equivalent features of your original editor. My experience is that it takes months, if not years to get really, really good -- depending on how much time you have to fiddle with your editor. Choosing an open source editor that works on a variety of different platforms and is supported by a large community of people gives you insurance that you won't have to change editors unless you have some really compelling reason to do so. If Sublime were stop being maintained, sure you could continue to use it for a few years, but would you (could you) be using it 10 years from now? That seems unlikely without an active community making builds for the new platforms you are going to be working on. I know a lot of the younger people I work with don't understand the benefits of learning your editor to the extent I'm talking about, so they don't understand the cost of switching. Pair programming with someone who is a true expert with their editor can be very illuminating.
jastanton 11y ago
> decimate Atom I don't think so. Keep in mind that Atom is used internally at Github, and is starting to be adopted by some big names. Things like that don't get chocked out by the competition. I'm not sure how much funding it'll loose internally if they aren't the #1 but I don't think it'll effect them as much as if Sublime Texts competitor got it's funding from sales for instance.
- makeitsuckless 11y ago
  > is starting to be adopted by some big names Citation needed. All I hear about Atom is that people are giving up on it.
  - kyrra 11y ago
    Facebook's tool built ontop of Atom: Nuclide[0]. [0] http://nuclide.io/ http://nuclide.io/
    - digikata 11y ago
      Not to criticize the tools themselves here (Atom or Nuclide), but the process of building an enhanced X over some large base application code didn't work out well for a lot of Eclipse tools. Or at least my experience is with working with lots of Eclipse + "x" on top environments which were integrated once, then rarely touched the base Eclipse again... leading to lots of inconsistent annoyances between Eclipse/tool instances.
      - kyrra 11y ago
        As an eclipse user for far to long, I understand the pain. I'd prefer if more languages/frameworks went the Golang approach and provided generic tools that can then be integrated into various editors to provide things like auto-complete and context support (oracle).
  - quonn 11y ago
    Microsoft's "Visual Studio Code".
neuromute 11y ago
I emailed SublimeText offices a long time ago to push the concept of crowdsourcing the open sourcing of the project. It was blown out of the water. I should imagine that even if they set a high goal, they'd do pretty well out of it. I'd happily pay a premium price to see the source released permissively (free software approved, ideally).
- wbond 11y ago
  It seems to me a pretty realistic estimate that Jon is doing rather well off of Sublime Text nowadays. However, he's been working on it for over 8 years. I've gotten the impression that some of the early times were very lean and he took on contracts to keep it going. So why should he give up the resources that he justly earned? He worked his butt off, likely made lots of personal sacrifices, and now he should open source it once he's built a solid product that lots of people love? Ok, so let's say you don't buy the angle that he deserves the success he's had. Do you think Sublime Text's success is a coincidence? Jon is a single engineer who's built pretty much every aspect of it, from a custom cross-platform UI that doesn't suck, to a custom editor control, more recently a parallel custom regex engine to make syntax highlighting faster and more robust. He's taken performance seriously from day one. By contrast, Atom started development in 2008 and had a team of engineers working on it. It has more community involvement and bells and whistles, but still seems a bit behind in performance. I would argue that Jon and his priorities and decisions are one of the biggest reasons Sublime Text has been successful. Would open sourcing it help Jon keep up the focus and insight he has shown in the past? Or, would it likely take up a large amount of his time? I don't have an insight that anyone else doesn't have. And I could be completely wrong, but I feel like if open source would ensure a better product, Lime would have taken off. Or there would be other, strong, cross-platform text editors written in desktop technologies.
  - asddubs 11y ago
    I don't think open source ensures a better product. I think open source can make a good project better, but you still need competent leadership
coldtea 11y ago
>I just had to move back to Sublime for the third time because Atom would choke on a 400 line Ruby file. I was using vanilla Atom with RuboCop and it's linter, and stutter-city. I just can't understand why people would even use a JS based text editor and expect it to perform. It will never happen. And it's not because of JS (which can have decent speed), it's mostly the HTML/DOM part. If you don't like ST3 there's Emacs, Vim, TM2, Idea, and tons of other options. Atom, why?
- michaelwww 11y ago
  Facebook is throwing it's weight behind Atom. They are not forking Atom, but rather contributing their improvements back to Atom. They are developing their Nuclide IDE with Atom packages. Atom is still young, but has a bright future. Free and open source is very attractive for lots of us.
  - swah 11y ago
    Couldn't they just do it in C++ though?
- copperx 11y ago
  Agreed. The HTML/DOM part makes absolutely no sense. You're trying to render text, not a webpage. Just make the GUI native or use Qt!
daemonza 11y ago
I tried Atom when it came out, it was painfully slow...on a whim I tried it a couple of weeks ago to test the go-plus package for go development and, and I was pleasantly surprised how much performance improved, personally when both editors are open, I don't see a speed difference anymore. If you have not tried Atom recently, give it a go.
- statictype 11y ago
  I still find it fairly slow but I'm going to try and use it as much as possible, anyway. I like the core principle it's built on (completely hackable as everything is built on a scripting layer) which makes it more potentially powerful than Sublime, even if its slower now.

alexggordon 11y ago

Here's the ST forum announcement[0] from June 16th. This is a good step in the right direction for ST. It seems that JPS is increasingly relying on the open source community for ST development, which could lead to some awesome developments in the future. I think it would be even more awesome if JPS open sourced the ST Package API. I think that could really improve the state of package development in the future, and is one of the areas that I think is still hurting the growth of ST. [0] http://www.sublimetext.com/forum/viewtopic.php?f=2&t=18787&p=69229#p69229 http://www.sublimetext.com/forum/viewtopic.php?f=2&t=18787&p...

zzleeper 11y ago
Your comment was the most informative and yet it's the second least upvoted. Syntax files are those things that get really annoying if buggy and are really easy to fix (compared to adding features to the C++ codebase). The fact that they are YAML files makes it even better. Also hope to see more stuff opening up!
wbond 11y ago
Part of the reason I think this happened is because ST just switched to a custom syntax format that compliments the new parallel regex engine. Before Jon could work with the open-source Textmate language definitions. By mass converting them and open-sourcing them, the community can help keep them up-to-date, and Jon can provide the improved performance of the new syntax engine.
- alexggordon 11y ago
  Exactly my point. I'm just excited because It seems to me that this is the first time JPS has open sourced something directly to the ST community, with the idea that they will continue to develop and maintain it. I'd really like to see more of that happen, and I think there's a huge desire to help with future development of ST.
- hatmatrix 11y ago
  Perhaps the advent of Atom lit the fire under JPS.

usaphp 11y ago

Can someone explain me why is everybody so obsessed about sublime not being open source? Being an open source software gives no guarantee that it wont be abandoned one day, and if there is something else better even not open source out there everybody (mostly) will forget about an inferior open source project and use the premium software with better features instead, it happened when sublime text was released and won our hearts, so I don't see how can it becoming open source stop a new premium and better product beat it just like it beat others before...

ffreire 11y ago
I believe the argument for open source is that the community can continue to maintain the software long past when the creator stops (for whatever reason). Responsible maintainers will often seek new developers from the community to take charge (as is the case with marginalia[0], the first project that came to mind). Of course this isn't the only reason why folks want ST to be open source, but I believe this addresses your point about abandoning closed source software. [0]: http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/ http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/
- jbverschoor 11y ago
  Well. textmate was also closed source, abandoned and opensoured... Didn't do any good. I'm very happy with ST and hope other people will also buy a license.
  - biftek 11y ago
    Sure about that? https://github.com/textmate/textmate/commits/master https://github.com/textmate/textmate/commits/master Happy TextMate 2 user here.
- coldtea 11y ago
  >I believe the argument for open source is that the community can continue to maintain the software long past when the creator stops We've seen this fail to be so in practice time and again, if not for the software entirely (which also happens), then for less popular ports, like for OS X and Windows.

0942v8653 11y ago

I can't help but think it's funny that Sublime Text uses - XML for snippets (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/forv.sublime-snippet https://github.com/sublimehq/Packages/blob/master/C%2B%2B/fo...) - YAML for syntax files (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%2B%2B.sublime-syntax https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%...) - JSON for settings (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%2B%2B.sublime-settings https://github.com/sublimehq/Packages/blob/master/C%2B%2B/C%...) - and plist for TextMate compatibility (https://github.com/sublimehq/Packages/blob/master/C%2B%2B/Indentation%20Rules.tmPreferences https://github.com/sublimehq/Packages/blob/master/C%2B%2B/In...) Of course each one has a reason to be that way, but it must be really annoying to maintain.

jbrooksuk 11y ago
Oh it is. I imagine that Jon has plans to consolidate this mess, but it'd take a while to update the thousands of packages being maintained. One step at a time!
icebraining 11y ago
YAML is a superset of JSON, so those might be processed by the same parser.
- robin_reala 11y ago
  That’s not true; YAML is completely seperate.
  - bjacobel 11y ago
    Correct. YAML and JSON can be parsed into the same tree structure but are completely separate syntaxes.
    - icebraining 11y ago
      No, they aren't. From the YAML site [emphasis mine]: "YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model. This is also the case in practice; every JSON file is also a valid YAML file." http://yaml.org/spec/1.2/spec.html#id2759572 http://yaml.org/spec/1.2/spec.html#id2759572 You can parse any JSON file using a YAML parser.

koblas 11y ago

Just for humor reference, 20 years from now there will be thousands of text editors that will have come and gone. But, emacs and vi will still be cranking out code everyday.

krampian 11y ago
And religious wars over which is the better editor will likely still be ongoing...
- shpx 11y ago
  In practice those are over, just a stale joke people keep repeating.
  - nzp 11y ago
    It was always kind of a ha-ha-only-serious joke. I'm amazed to read some people here take the "wars" seriously enough to make it an argument to not use either. Like some weird cultural misunderstanding. Hipster kids these days...

jbrooksuk 11y ago

I posted this 15 days ago (https://news.ycombinator.com/item?id=9724047 https://news.ycombinator.com/item?id=9724047) - forum announcement may have been linked somewhere too? Edit: I don't understand the down votes. This happened a while back, nothing has changed except the open source packages made it into a release - which was due anyway?

asdgb1234df 11y ago
You were downvoted because your comment added nothing to the conversation, and came off as sour grapes. (You may not have intended it to sound so, but I read this as, "I submit essentially the same material 15 days ago but nobody gave me karma for it. waaa"). The HN karma system is the elephant in the room. Everyone knows it affects behavior, but you're supposed to pretend like it isn't there.
- jbrooksuk 11y ago
  Ok, I can see that - amongst a group of kids. I don't care for karma. I wanted to show that this has been here "for a while".
  - asdgb1234df 11y ago
    Haha fair enough. This may be completely non sequitur, but my my life significantly improved when I stopped trying to denigrate other people in order to defend my own hurt feelings. Outside of the fact that you were the one who posted it earlier, it seems unlikely that you were bothered by the previous posting. I haven't seen you on other reposts on HN saying the same thing. Therefore I am led to conclude that it's not the reposting, but the lack of credit, that upset you. And if you're really bothered about reposting, on this internet, it's going to be a repetitive experience for you. Also, if you question your downvotes on HN, you'll get more downvotes and engage in less conversations from which you can learn.
kolev 11y ago
Sorry, I didn't see this earlier although I frequent the new links. I suggest posting stuff like this between 9AM and noon PST as popularity highly depends on the timing as well.

camhenlin 11y ago

I found the Sublime package repo pretty helpful today, after the Sublime update, where the syntax coloring was changed without warning. Luckily all of the old color was in the first commit to the repo.

forrestthewoods 11y ago

I wonder how much money it'd take to buy out Sublime Text and open source it. I wonder how much money has been spent developing Atom so far.

fweespeech 11y ago

Honestly, the one thing I want more than this from ST is a promise that in the event of loss of interest or catastrophe, ST3 will be open sourced. Hit by a bus insurance if you will :P

mbell 11y ago

Hopefully this results in improved syntax highlighting for Ruby. Anyone know of any ongoing efforts in this area?

leetNightshade 11y ago
Well it's been opened up. Why not help contribute yourself?