Sublime Text packages are on GitHub(github.com)
github.com
Sublime Text packages are on GitHub
https://github.com/sublimehq/Packages
102 comments
YAML is a superset of JSON, so those might be processed by the same parser.
That's an error prone way of doing things. People will start putting yaml in their json. Better to just call it yaml then.
Well, the file doesn't actually say what format it's in; from what I can tell, the previous poster just assumed it was JSON from the syntax.
That’s not true; YAML is completely seperate.
No, it's not. See my post downstream. Every JSON file is a valid YAML file.
Example: using PyYAML to parse the JSON file from above:
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']}Wow, interesting. Why do people use YAML syntax then? I find JSON much simpler, less ambiguous. Much prefer JSON for configuration over YAML.
Mostly, I'd say people who prefer YAML-specific syntax (myself included) think it's generally more readable and easier to write. It's also easier to keep clean commits (no trailing comma issue).
That said, I think http://json5.org/ is a decent middle term.
That said, I think http://json5.org/ is a decent middle term.
Correct. YAML and JSON can be parsed into the same tree structure but are completely separate syntaxes.
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
You can parse any JSON file using a YAML parser.
"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.
I … OK, I recind my earlier statement! TIL :)
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!
One step at a time!
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...
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...
I was a dedicated st2 user that left because of package instability. My windows setups sudden wouldn't be able to open and segfault iirc after package updates. I wanted answers but the forums had none, so it was back to ides.
Speaking of which, one of the ST improvements I keep waiting for is a decent forum. One of the best things about ST is the community, but ST's official forum sucks. It doesn't send email notifications because JPS doesn't want to manage email servers. How can he be so cheap? Pay the Discourse folks for a great hosted forum and be done with it!
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!
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!
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.
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.
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.
Perhaps the advent of Atom lit the fire under JPS.
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...
I think people started really pushing for an open source ST when JPS kind of disappeared for a year and a half. While he pushed out a few bug fixes[0], you can also see he only pushed out one ST3 update during 2014. Because of this, I think the community was particularly worried about ST development halting, and people started calling for ST to be open sourced because of that.
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.
[0] http://www.sublimetext.com/3
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.
[0] http://www.sublimetext.com/3
Yeah, I was one of those who was frustrated that I bought a ST2 license, then a 3 license in beta, only to see ... (nearly) nothing.
But the 3dev channel is getting pretty steady updates now.
But the 3dev channel is getting pretty steady updates now.
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/
[0]: http://blog.fogus.me/2013/08/12/marginalia-has-a-new-home/
>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.
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.
Projects can still be abandoned even if they're open source, yes.
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%.
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%.
> But surely the odds of a project's long-term viability increase if the community has the option of continuing the project, right?
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.
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.
markdown uses words wrapped in single asterisks for italics. You're using bbcode.
this will be italics
*this will be italics*
this will be italics
Hacker News does not support markdown. It supports just italics with asterisks, blank lines for paragraphs, code blocks by indenting with two spaces (while markdown uses 4), and auto-linking URLs. https://news.ycombinator.com/formatdoc
We've also seen it hugely succeed time and again, with software like Open Office and Blender, and the vast cottage communities set up around open sourced video game engines.
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.
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.
Worked out for Blender. Depends on community I giess.
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.
Sure about that?
https://github.com/textmate/textmate/commits/master
Happy TextMate 2 user here.
Happy TextMate 2 user here.
Speaking only for myself, I'm not comparing it to random/theoretical OS projects. I'm comparing it to emacs. Sublime is beautiful, but emacs is a lot more likely to survive, and historically, emacs upgrades have broken fewer things. There are also more packages and more available information on how to build things that aren't available. Configuring packages in Sublime wasn't that great.
Obviously, some folks prefer Sublime. But I'd be a lot more interested if it was open source.
Obviously, some folks prefer Sublime. But I'd be a lot more interested if it was open source.
Same here. I switched from Emacs to Sublime, but moved back a couple of months ago. I used my Sublime setup as inspiration for making Emacs as pretty, and now love it even more than I did before.
I agree with you a hundred percent. I paid for ST2, and waited for ST3 to get out of beta for ages. After seeing the project halt for a year I made the jump to Emacs. And I can't be happier, I'm able to use the same editor in three different platforms and use the same init.el for all of them. Also I'm able to edit files in a remote server without having to replicate the files locally as ST does.
>I paid for ST2, and waited for ST3 to get out of beta for ages.
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.
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.
Same here, I am on a dev channel for God knows how many months if not years already, never had a problem so far.
I would have liked to have had a chance at fixing the bug in Sublime that annoyed me daily for ~2 years. It went unacknowledged in the "bug tracker" (a phpBB full of threads no one reads, and bot spam about pay-per-view television).
I think it would be a security concern for a lot of people/companies to trust their source code to a closed-source binary from a relatively untrusted, unknown company.
I think the open source obsession is a bit sad. Open sourcing would mean an end to another entrepreneur and indie developer.
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.
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.
Let's say you were working on a plugin and spent I don't know how many thousands of man-hours developing it. Now let's say that the creator of ST was hit by a car. You would be fucked.
Fucked? You would keep using ST as it is until it would no longer run on the current version of the OS. The product wouldn't stop working the day the author quit working on it.
Whereas if the lead developer of Emacs was hit by a car?
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.
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 an open source project, a sufficiently interested third-party has at least the legal right to pick up development of the code base that their work depends on (or to pay the developer of their choice to do so.)
With a closed source project, that's not the case.
With a closed source project, that's not the case.
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.
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.
>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?
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?
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.
Couldn't they just do it in C++ though?
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!
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.
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.
> 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.
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.
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.
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.
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.
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.
I just opened a 2.8 MiB file in ST3-dev (JS, using babel syntax def) and it opened sub 1 second. I think it must be the dev branch that has this sort of performance boost? Give it a shot.
It's probably just due to a difference in sheer processor power (I should have mentioned these tests were done on a lowly Core M ultrabook).
That makes sense. Still, it's good to know VS Code can load a file that size. It seems like the nicer of the web-tech based editors that I've toyed with.
> But are there good open source alternatives? Besides Vim and Emacs, I mean,
Why dismiss the two most popular alternatives?
Why dismiss the two most popular alternatives?
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.
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/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.
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.
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%20Cu...
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'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.
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.
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.
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.
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?
Just because something could stop being maintained, doesn't mean it instantly becomes worthless.
I don't know, maybe I'm missing something?
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.
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.
> 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.
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.
> and is starting to be adopted by some big names
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.
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.
I don't know if 'adopted' is the right word, but it and its underlying platform or whatever are being used by Microsoft, Facebook and Slack among others
Microsoft's Visual Studio Code & Facebook's Nuclide are two that come to mind.
Visual Studio Code is based on Electron, not Atom. The editor component is Microsoft's and based on Monaco, the editor used in Visual Studio Online.
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).
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).
Yeah, Atom already has hundreds of thousands of active users and moved ahead in terms of features and UI.
One year ago, open sourcing ST could have prevented Atom from ever taking off, but now it's not going to change much.
One year ago, open sourcing ST could have prevented Atom from ever taking off, but now it's not going to change much.
> is starting to be adopted by some big names
Citation needed. All I hear about Atom is that people are giving up on it.
Citation needed. All I hear about Atom is that people are giving up on it.
Facebook's tool built ontop of Atom: Nuclide[0].
[0] http://nuclide.io/
[0] http://nuclide.io/
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.
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).
With the recent 1.0 release that got a lot of attention, I imagine the adoption curve has gone up.
My team just voluntarily switched over from Sublime and no regrets so far.
My team just voluntarily switched over from Sublime and no regrets so far.
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).
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).
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.
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.
Literally, the difference between open source and proprietary is the license... nothing more.
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.
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.
Well, how did you approach him? Did you ask him what kind of monetary figure it would take for him to consider open sourcing it? Or did you just ask him if he'd open source it for a crowdfunding effort?
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.
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 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
Indeed, an open source license does not ensure a better quality of product, and nor does a proprietary one. Free/Libre Open source software gives users various freedoms, which many people like (myself included). It also opens the door to a wide community of hackers, to help improve upon and speed up development.
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.
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.
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.
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.
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.
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.
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.
And religious wars over which is the better editor will likely still be ongoing...
In practice those are over, just a stale joke people keep repeating.
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...
I posted this 15 days ago (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?
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?
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.
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.
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".
I wanted to show that this has been here "for a while".
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.
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.
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.
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
Hit by a bus insurance if you will :P
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.
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.
Hopefully this results in improved syntax highlighting for Ruby.
Anyone know of any ongoing efforts in this area?
Anyone know of any ongoing efforts in this area?
Well it's been opened up. Why not help contribute yourself?
- 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.