Sublime Text packages are on GitHub
github.com
github.com
- XML for snippets (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%...)
- JSON for 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/In...)
Of course each one has a reason to be that way, but it must be really annoying to maintain.
One step at a time!
"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
You can parse any JSON file using a YAML parser.
Example: using PyYAML to parse the JSON file from above:
>> import yaml
>> val = yaml.load('{"extensions": ["cpp", "cc", "cxx", "c++", "h", "hpp",
"hxx", "h++", "inl", "ipp"]}')
>> print val
{'extensions': ['cpp', 'cc', 'cxx', 'c++', 'h', 'hpp', 'hxx', 'h++', 'inl', 'ipp']}That said, I think http://json5.org/ is a decent middle term.
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...
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!
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.
[0]: http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/
Happy TextMate 2 user here.
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.
It's pretty simple: if the software is unique and offers good enough utility, people will jump on it. If it's open sourced as abandonware, it will probably remain abandonware.
But surely the odds of a project's long-term viability [i]increase[/i] if the community has the option of continuing the project, right? Clearly, if the project is [i]not[/i] open-sourced, then its odds of outliving its original author's interest are obviously stuck at 0%.
I agree with this, but not the following:
> Clearly, if the project is not open-sourced, then its odds of outliving its original author's interest are obviously stuck at 0%.
Because, while the author's interest flagging doesn't necessarily mean a closed-source project is dead, the author could transfer it (open-sourcing could be considered an example, but it could also be sold when they tire of it.)
But with closed source, there is a risk that a time will come, either through neglect or active decision, where development will stop and others will be legally denied the right to take up the maintenance of the system, whereas with open source, the right of interested outside parties to take over is, insofar as this is possible, guaranteed.
*this will be italics*
this will be italics
Obviously, some folks prefer Sublime. But I'd be a lot more interested if it was open source.
I, on the other hand paid for ST2, and have been using ST3 since the first dev builds. Never had any problem, except some small glitch which was fixed in an update 1 or 2 days ago.
UPDATE: On OS X (always with latest stable OS X release), and using SublimeLinter (Python, PHP, JS), GoSublime, Vintageous, a plugin that shows repo changes next to line numbers, and several other plugs. YMMV in other platforms / plugins.
Particularly, with Sublime, I don't think it being closed source is a particular source of resentment for many people, given how stable it is. That said, given the choice between a stagnant development cycle, and an open source ST, I think most people would prefer an open source ST.
To JPS credit though, he's removed any doubt over the last few months that he wants to continue active development for ST.
But the 3dev channel is getting pretty steady updates now.
Lots of open source projects have 1 or 2 people doing 90% of the work, and when they lose interest (or find the next thing to carea about) they die.
With a closed source project, that's not the case.
So, instead of open sourcing, I think these should happen:
1. He should get partners who can take care of Sublime Text if he isn't able to do it himself.
2. If Sublime Text is about to become abandonware, then it would be better to sell it to another small company, which could carry on developing it.
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.
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.
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.
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.
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.
> The web platform simply has had more optimizations and
> standardization work put into it than any other interface
> technology out there today.
Why dismiss the two most popular alternatives?
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%20Cu...
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/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.
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.
Just because something could stop being maintained, doesn't mean it instantly becomes worthless.
I don't know, maybe I'm missing something?
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.
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.
Citation needed. All I hear about Atom is that people are giving up on it.
My team just voluntarily switched over from Sublime and no regrets so far.
Uh who? About every other editor and IDE under the sun is leagues ahead of Atom. Honestly an editor based around a freaking browser is already too heavy for usage. No, I don't want to use a browser engine to run my editing environment, and a ton of "big names" are not picking up Atom at all.
Going to need to see some citations, not downvotes Hacker News. I don't care if it's the "hip new editor", being made by GitHub is not enough.
Electron is a souped up Chromium Embedded Framework, patched to make it easier to develop desktop applications. Atom is built on top of that.
So, Visual Studio Code only uses the "low level" components from the Atom project, but it doesn't use Atom itself (unlike Nuclide which is, instead, a set of Atom plugins).
One year ago, open sourcing ST could have prevented Atom from ever taking off, but now it's not going to change much.
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).
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.
If Linux remained the sole project of Linus, it would be nowhere near as effective as it is being out in the open, so to speak.
There are plenty examples of excellent open source software, so I fail to see your argument on this. Proprietary ≠ better that open source.
There are plenty of great open source text editors, but Sublime happens to be leading the pack. It just so happens to be proprietary. I don't think that this is the sole reason for its success. The coder behind the project is evidently extremely gifted, he values his time and you're right, it is his choice to decide the license. I'm merely making the point that if Sublime Text was open sourced, it needn't spell the end of the line. I dare say it could pocket Jon a tidy sum, if it were kickstarter'd for say... £5,000,000? I know there are a LOT of coders out there who would splash out, in order to make this happen.
It's pretty much donationware as it stands, and it could still continue to use this method as a source of income, even if the license became permissive.
I think one of the main differences between Atom and Sublime is performance, and that is largely down to the technology stacks in use.
In his mind, he may be thinking "crowdsourcing? Why would I give you my baby for $20k"
If I were in his shoes, I wouldn't in my wildest dreams expect that someone asking me about kickstarter would be in talking about the 7 figure range.
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?
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.
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?
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.
I wanted to show that this has been here "for a while".
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.
Hit by a bus insurance if you will :P
Anyone know of any ongoing efforts in this area?