Wow, surprised to see everyone bickering as opposed to giving praise. Just because the author doesn't want you to log issues doesn't mean the project is any less open source... The code is there, if you have a problem fork and submit a pull request. The author is merely stating the fact he can't fix issues by himself and if you find an issue and can help, you should submit a fix.
Calm down people and learn to say thank you every once and a while. This is seriously cool, it's written in Go (which HN has a raging hard on for), what's not to love about this? I'm grateful someone took the time to get this far, now lets take it further.
It takes a lot of effort to get something like this out. Just think of all the things the author could've done with time invested in this. And to make it open source and donate it to the world is just crazy. Props to the author. The naysayers ought to suck it up unless they've poured their free time in an open source project like this.
That's exactly it. It's like being invited to an expensive restaurant and getting a five course dinner for free including drinks and then complaining that the dinner wasn't good enough. It was a free dinner!
Most people don't care to give back to open source, they just want to have something to fix their problem... I am disabling issues from my projects starting today. I think this is a brilliant way to make people realize that work has to get done and if they don't want to do it, they have to as someone personally to do it and it's really a favor! I love it.
Most people don't care to fix Wikipedia articles either. But I really appreciate the people who do. Turning off the discussions behind those pages would be a terrible disservice to the people who do contribute.
Likewise, turning off issues makes it much more difficult for us contributors. You can't search issues to see who's working on what, get advice or guidance from the community for nontrivial fixes, and otherwise have high-level conversations before even touching the code.
For those who just open issues, it's not always about laziness. Sometimes, you just don't have that much invested in a particular project. Personally, I still open issues to projects I use infrequently. I can't justify diving deep into a new codebase, reading their style guide, debugging, fixing the broken code, double-checking my fix, adding the proper tests, and documenting it in every case, but I'd be happy to spend the 5 min to search the issues and post a new one if necessary.
I really appreciate the stance you're taking with issues and pull requests. It takes balls to get a project out there, and being upfront about what you're going to accept as contributions is great. Not only because you demonstrate honesty and make things clear, but also because it is a good way not to lose your time.
I doubt I'm going to leave Vim anyways, but I really wanted to share my opinion on this point.
Thanks a lot for doing this project! I have been hoping for an open-source alternative for ST for a while.
As a side note, could you clarify the build section where it says we need to modify cgo.go? I'm not exactly sure what to do there. I'm using Ubuntu 13.10.
Haven't gotten this to run yet because my copy of Python does not meet the criteria he listed in the Readme (`Python 3 must be compiled without sigaltstack enabled.`)
However I got it to build on Arch Linux.
First of all: modifying `cgo.go` didn't work for me. Not sure why: but it's included to late in the build process, `abstract.go` bombs out on the compilation.
These flags worked for me just fine on Arch Linux:
`// #cgo pkg-config: libffi python-3.3`
That's assuming you have `.pc` files for libffi and python on your system. (Which might not be the case if you're building it from scratch.)
> Because I'm just a single person and I don't want to offer up my spare time doing support or dealing with feature requests that I don't care about myself [...]
Sort of defeats the point of open source, no? Sublime Text's author could argue a similar case about keeping it closed source himself.
The rest of the same paragraph that you skipped is:
> If you want a feature implemented or a bug fixed, fork it and implement it yourself and submit a pull request when you're happy with the implementation.
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back. Not being able to request features for free doesn't make it against the "spirit of open source".
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back
while I agree this is at least one of the points of open source, it's also one of the reasons it's pretty hard to get someone who is either not a developper or doesn't have time to play with the source to turn from the commercial to the open source side. In my experience users out there want something that Just Works, or will be fixed within a reasonable time. If they read something like this, they go all like "wtf is this mentality, I'll just buy something instead"
Paying money for software (open or not) is not something immoral, in fact, to me it is the way it should be for most cases.
Also, Open Source should be important to developers. Aren't you a developer? Then be prepared to pay if you want something that's not implemented already. Not being able to program is the illiteracy of this century.
Not being able to program is the illiteracy of this century.
I'm getting pretty tired of hearing this. It isn't the case at all. Not knowing how to use a computer is `the illiteracy of this century', but claiming not knowing how to program is illiteracy is like claiming not knowing how to play piano makes you tone-deaf.
Completely agree. I AM a developer, and I still would have no idea how to help 90% of the projects that I use as dependencies. Each developer has their own area of expertise, and it is completely unreasonable to expect everyone to be able to fix everything they use without an ungodly amount of effort. Sure, I know how to code, but if my graphics driver has a bug, someone telling me "hey it's open source, why don't you fix it?" seems like a completely disingenuous response to me.
But musical literacy does require that you produce music on some instrument or with your voice, and it is rare that any level of musical training would advance very far without a basic understanding of how to use a piano to pick out some notes for reference. You could decide to learn music without ever learning the piano, but you would have to take great pains to avoid it.
Being able to use a computer but having no understanding of how to program it is like being able to operate a record player. Certainly, some people can do masterful work operating a record player -- to the point of an art. You may even learn to operate it in such a way that you could express your own musical ideas. But learning how to operate a record player does not make you musically literate.
I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
I agree with you, actually. I just wanted to cover my bases in the event that there's some composer out there who never played an instrument in their life that I'm unaware of.
> I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
Totally agree. I actually got an Arduino starter kit for my little sister's birthday for this very reason. It's over her head at this point, but I remember LEGO Mindstorms being over my head when I was her age, yet still being fascinated with it.
Not being able to program is the illiteracy of this century.
While I agree with this sentiment, I think it's patently false. The vast majority of people have a hard enough time using Word or Excel, let alone being able to understand programming concepts or actually being able to program!
I have a hard time using word because it always tries to fight what I am trying to do. It is a complicated piece of software that requires quite a bit of time investment to actually understand how everything works.
In my experience with my other open sourced stuff on Github, others fixing stuff is very rare. Having issues enabled quickly turns into users demanding fixes and no amount of asking for others to chime in aiding with pull requests actually result in pull requests.
IIRC most pull requests come either out of the blue for something new no one has requested before, or they don't come at all until I explicitly say "I'm not going to fix this" and close the issue.
I've had several bugs fixed in quite a few of my open source projects. Even bugs I've posted on my own projects. And they have only a fraction of the attention yours does.
Why not open the issues up and see if it works out? If anything, you can close them if it's becoming a burden.
In any case, thanks for open-sourcing this project.
Then they can fork it and allow people to post issues on their fork... but this does get me to thinking about how many people even involved in the FOSS world don't understand it very well. Perhaps I am the one wrong here.
I suppose, but then you also need to remember no software is bug free (especially not new software). Maintenance is not a step of software development you can just gloss over.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
That's true. But if few more developers start issuing pull requests, then the maintenance team could arise out of that, and project would eventually start to also accept bug reports and feature requests. But in this phase, it's obviously that in this time frame the goal of the main and only developer is to get to the point that he has something that "works for him" and has a solid foundation he likes before making it usable to others.
So yes, it's perfectly in the spirit of open source. And no, it's not (yet) production ready for general (non Go coder) audience.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
The benefit of free software (open source plus the freedom to modify and distribute) is that you don't have to do this. You can fix the bug yourself and continue on your merry way. There are many, many stories of companies/people that lost thousands (or sometimes millions) of dollars just because they depended on a piece of proprietary software that became unsupported (for whatever reason) and there was nothing they could do about it.
You could contact the dev and have a discussion with him! If the dev doesn't want it to be a feature in his software, you can post your changes as a plugin/add-on. Effort spent on improving a software rarely goes wasted.
> Effort spent on improving a software rarely goes wasted.
Rarely wasted? Have you seen how many open issues and pull requests on github just languish there forever by unconcerned maintainers? Or projects with a million forks because the maintainer has moved on?
Stating up front that you're not going to even entertain bug reports definitely has an impact on those wishing to improve the software and contribute back. For one, it precludes an entire class of supporters (users who report bugs) from even helping out at all.
For this project in particular in its current state, I don't need people pointing out where it's broken. I know that it's broken and close to useless in fact and that there's a huge list of things to fix, implement or improve.
So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
It is absolutely your choice to have issues or not and as you describe the current project status it is almost certainly the right choice for the moment.
If you intend to the issues up when you reach another state (e.g. widely usable) then indicating that the not accepting issues is a temporary state would be good. I completely understand not wanting issues raised when you already have dozens of things that you know that you need to do already.
From a user point of view the issues list is something I often look at before even using a project to see the activity, scale of the current problems people are having. I also find it a useful source of answers/workarounds. That doesn't mean that you can't be decisive about what issues you choose to work on (from a user perspective a clear response of "no time to work on this issue, send a PR if you sort it" is better than silence).
If you file the issues yourself, you can show to everyone else that you're working on them. That's exactly the kind of communication ST is lacking. Plus, you'll learn about bugs you didnt encounter, so they can be fixed (by you or others) before you have to hit them yourself.
Give the guy a chance to write a functioning editor first. I'm sure he'll reconsider opening up the issue tracker after the thing is actually useful, and maybe has a few more contributors to share the load.
No one is entitled to anything with open source, not even support or a bug tracker. The author is trying to provide an open source alternative to a closed source product controlled by an uncommunicative company. He deserves support and help, not people telling him what to do.
Try walking a mile on his shoes. Bug triaging is a burdensome task. It is perfectly understandable that, for a one man team working in an incomplete software, his decision is to focus 100% in development of his vision.
Or are you volunteering to do the bug triage part?
You're exactly right. I've heard a lot of developers burn out over the sheer amount of work github generates, let alone the amount of entitlement people feel to your labor once you publish your code. If we want to do social coding, we need to be sociable about it.
On various open source projects I have been running, people have requested that I implement this or that feature of zero interest to me. Most are presented as suggestions but some are rude and demanding. I have never understood this mindset. The fact that I am sharing code that I wrote means that I am now obligated to offer support and implement stuff that I don't care about?
The way I see it, the "point" of open source is just that: the source code is open -- for you to see, use and modify if you like. The author is free to do what they want with their time.
This is what professional support contracts are for. If someone really wants something implemented that is of no use to anyone else, then they should pay for it.
Not everybody wants to make a career out of their side project. Just because you offer me money, doesn't mean I should be obligated to take it. (By all means, offer the money to somebody else, just leave me out of it.)
I'm ok with that. What I'm not ok with is when people use open source as an excuse for mediocrity. Many times you do hear "It's open source, I'm doing this for free, just fork it!" when it probably should be "It's a hobby project, it probably won't go anywhere and the code wasn't really made to be used by someone else, but if you can find something useful you're free to use it". There are a lot of active open source projects out there that spend a lot of time maintaining their project and I think it's kind of "meh" to undermine the positive things they've been working for.
I have absolutely 0 problem with this, as long as a disclaimer is listed like the OP did. I honestly think this is the right way to do it. Imagine though if apache had some major security flaw uncovered tomorrow and the maintainers said, "This is just an open source project. You are free to look into the issue and fix it yourself if you want. We will merge the pull request when we get around to it.". Managing expectations is-- as usual-- everything.
You might need to point those people to an open source FAQ stating that you do in fact have a day job and that you cannot find time to support changes you do not care for unless you are getting paid to do so and that if the person wishes they can hire someone to fork the code and implement it themselves and you will be happy to take the pull request
I think the author makes a point here, he is making it Open Source so that anyone who wants to tinker with it can. Fixing people "Issues" is not part of the Open Source culture and more of the closed source model, since the whole point of Open Source is so that you can "fix" things yourself without waiting for the vendor. That's why there's "Use at your own risk" everywhere
I applaud his approach, at it demonstrates respect to other developers by explicitly communicating what others can expect of him. Although it's not required, I would hope that all devs who open source a project without any intention of heeding public issue trackers follow suit and proactively clarify that intention.
(Nothing--philosophically or legally--requires anyone to maintain an issue tracker for an open source project. There was a time when open source typically amounted to a tarball on an FTP server, and maybe a -dev list.)
Yes, but those were also the days when it was super painful to contribute to OSS.
The issue tracker can also be used as a roadmap / task manager which is very helpful. The problem isn't the issue tracker. The problem is the developer does not want to maintain everything for everyone. That is perfectly okay so the solution to me is just to communicate that in the project guidelines. To me, not having an issue tracker at all is equivalent to Sublime Text developers dropping off the map for 6 months.
No. You are free to implement the feature yourself and submit a patch to the original author - or fork the project if he doesn't want your patches. That is the point of open source.
That line right there killed any chance of me downloading or trying this. His first three paragraphs cover how he dislikes Sublime Text for some decently noble reasons. Then the first FAQ is about how he is no different. In fact, probably even worse. The idea that he will only work on things 'only he cares about' says this:
Unless I'm you, I wont care about your project either.
I am only trying to help because I like the idea of this project. However, it's the "Patches Welcome" attitude of devs that kills projects. Honestly, after reading this thread and the attitude portrayed, I suspect this project will die with only a handful of users and no maintenance before everyone resorts back to Sublime Text. -- Maybe he doesn't want an active community of users using his software, which is fine. But then why post it on HN?
Exactly. I'm not sure if there are many examples, I can only think of Lua; the authors of Lua don't share their development progress, discussion or version history. They don't take patches but may implement user suggestions. Still, the releases are free and open software.
There's software I'm scared of releasing as open source because I don't want people to have that opinion about it and I know I won't have the resources to properly maintain it. There is software by leading voices in the free software community with much the same rationale -- the LWN website code comes to mind. Meanwhile, Tarsnap releases their code under a non-open-source license, and everyone thinks they're great, underlining the perverse incentives here.
Let's restore a culture where posting a tarball and licensing it and leaving is okay and wonderful, instead of falling short of expectations.
Or if you don't like the dev's approach here, fork the code and turn on issues. I bet if you're more responsive, people will use your fork rather than the original dev's.
While I can understand the sentiment (barely), the way it's written comes off as "F U".
Better might be "I welcome all feature requests but please understand I am one person with a day job. I would be thrilled for anyone to contribute coded features and pull requests.".
I find it a much bigger "F U" to host an issue tracker and completely ignore it (perhaps while you continue development on other features), or worse, close new items out of hand. At least he's taken the time to clarify what can be expected of him. To me, that's a simple show of respect toward the community.
No, it's not a "F U". He created something, he made it available to everyone to download, build, use and extend. On top of all of that, why would he have to apologize to the world because he doesn't want to hear about feature requests from non contributors at this stage of the project.
On ArchLinux Go is pretty massive ~294 MB (compared to the jdk7-openjdk at ~19MB) installed. I, personally, have avoided installing some small programs because they had Go as a dependency, obviously you can compile a binary to resolve this for the editor itself. It seems like quite a bit of work just to generate a screenshot though.
I've heard this argument from people refusing to install packages that depend on haskell too. I don't get it, 294mb is a trivial amount of space nowadays.
If you pull in lots of dependencies, people think "great, now there are a whole bunch of dependencies that I'll need to keep updated, may break my program if they update in the future, may not be available (or available in the appropriate version) on another platform if I switch platforms, etc."
Dependencies have a cost that is more than just size. There's the extra overhead in managing them any time you need to do something beyond the first time installation.
Sure, if dependencies are all appropriately semantically versioned, with proper symbol versioning and sonames in libraries and so on, and you have a proper packaging system which keeps all of those dependencies updated properly, the cognitive overhead is not that high. But people screw these things up all the time; making backwards incompatible changes without incrementing major versions or updating sonames, packaging systems that don't allow you to have two incompatible versions installed at once, etc. And the larger the dependency set, the more likely it is that you'll run into once of these problems.
It's more the fact that honestly, I don't want to take the time... It's easier for me to shell out $70 to Sublime Text knowing that I can see it before I buy it than take the time to download and install all dependencies, build it, then be like "I don't even like this at all..."
I tried to make it clear in my original comment that you wouldn't even need the Go environment if there was just a binary distributed, so I agree with you on that. I also realize that this is in the early stages of the development process and it doesn't necessarily make all that much sense to distribute binaries when it is changing frequently. My point was that it is a lot to download to get a screenshot.
I can't reply to drbawb (I don't know why sometimes HN doesn't give you reply links and it doesn't seem to be in the FAQ). I am not so worried about Qt because there are a lot of programs that use it and overall if you have a lot of programs using it, it should decrease the size of the individual programs.
True, though it does look like this is using `cgo` though (for the Qt support?)
Do those dependencies end up statically linked as well? Otherwise you'll need Qt installed. I don't happen to have it on my system, but I'd imagine Qt is quite large compared to the Go development tools.
Unless you are building these packages from source then they don't have Go as a dependancy as Go creates static binaries.
And if you are building from source then you can just delete the Go package once you've compiled the program, since you are also on Arch that would be a simple: pacman -Rs go
Or even better, submit a PR that builds the project on Travis and dumps the binaries to an S3 bucket. I did this for an experimental pandoc-based ebook, and it worked great:
Indeed. I think I stated that you could just build a binary. This could also be released as a binary package (which is likely what would happen if it gains traction). I mean just to get a screenshot this is quite a bit of downloading. Then every time you want an update you have to do the same thing (in the absence of just downloading a binary).
Chances are good that a maintainer will pick this up and add it to your distro's official repositories in time, meanwhile it's not such a hassle to build from source imo.
You can click the "View the file list for `go`" link at the bottom of the page to see what it's pulling in.
Looks like, regardless of architecture, it has compiled forms of the packages from the standard library for both i386 and amd64 as well as their source form.
i think this is quite early work, we're a little bit off having stable binary issues - i think quarnster is only after feedback from people comfortable with coding :)
Here again we see the pain of trying to sell software to open source enthusiasts: the temptation to destroy the author's livelihood by copying their work is too great. By releasing a clone as open source, the copier gets to bask in the reflected glory of the original work. It's like trying to sell original oil paintings to master forgers. BitKeeper is the canonical example, but there are countless others.
I'm not sure "open source" has anything to do with this. Selling developer tools has always been a big risk even when the more likely scenario was another developer selling a closed source alternative to your tool.
Sublime Text itself was very much "inspired" by TextMate back when both of them were commercial and closed source.
This may be the pain of trying to sell software to developers. There are a lot of "open source enthusiasts" who don't do any more programming than simple shell scripts, and while they appreciate the philosophy of "if the project doesn't have the feature you want you can just add it," in practice they can't just add it. (Unless it can be added through a simple script, which -- ironically in this case -- you can do pretty well with a lot of closed source editors.)
The flip side, of course, is that only a limited number of developers can afford the time to write a full-featured programmers' editor with no expectation of recompense. That's not trivial stuff. There are an awful lot of free editors out there, but most of them end up being relatively feature-limited and, at best, "cult hits." Even getting to that point takes years.
(And, while I hope this won't seem too cynical, the pain points Lime's developer describes as his motivation don't strike me as coming from Sublime Text's status as closed source. They strike me as coming from its status as a one-person project. A one-person open source project is theoretically better than a one-person closed source project, but...)
Damn, isn't it frustrating to see how people are free to compete? Even worse, they're allowed to give away their competing products for free! The gall!
Seriously, though, you do know that there's no such thing as a free lunch, even when it comes to open source, right?
Except he's doing it because there is (to him) an impression that the original software isn't being maintained. So instead of letting a beloved piece of software disappear he cloned it and released it to the world.
The presumption that he's trying to destroy the original developers livelihood is naive at best.
The intention doesn't matter, the effect does. We are talking about risks of doing business with developers (which reimplementation is), not about some abstract morals.
Do you think that Sublime Text is a completely original work, or largely a clone of text editors that came before it? If the latter, then I'm not sure what copying has to do with open source, other than people who are involved with open source give away the copy instead of trying to make a living off of it.
That's why you open-source your software if you're selling to open source enthusiasts. I'd be just as happy to pay for an upgrade to a commercial version as I would be to upgrade from the "free trial" version.
That may be the only way, I agree. But because open source
pricing fails to capture the value of the software, you'll make 100x more writing closed source software for a more respectful industry.
Open source can mean your customers contribute to product development. Thus, "the value of the software" that people pay for does become diminished: it's just having the commercial license on hand, and not having to build from source yourself.
But we're not just a demanding (less respectful, in your terms) industry, we also are one that's willing to support itself - developers do pay to support each other.
His product will only take significant business from ST if it is better. Within reasonable bounds, the price of an editor is not going to be a deciding factor in the professional developer market.
This. If I needed simply a good open source editor, I could use vim or notepad++, and they're free as well; but I pay for ST because it's more useful for me.
This issue reflects the challenge of trying to sell music to people who can pirate the stuff. When the alternative to your product is free and close enough to substitute, the paid product needs to provide enough value to convince the market that it is worthwhile. Here you have a text editor that its audience feels has been abandoned, so it is not providing as much value as an open source alternative.
He should just change the headline since it doesn't really look like a Sublime Text clone anyhow. Just say something like "I'm building a sweet code editor inspired by some of the great editors I've used like TextMate and Sublime Text as well as some ideas I've been thinking about. If you'd like to work on a great new text editor, please join me."
No, he is definitely not creating a 'inspired by' editor, since a major point is compatibility with the existing ST plugins, so it has to be a near-clone to do that.
If Sublime Text development does go off the rails like TextMate 1 did then that'll be my "fool me twice" moment and I'll concede to FOSS tooling advocates.
I love ST. Bought both ST2 and ST3 licenses and never thought it was not worth the money. However, it's getting silent and the maintainer does not really care about taking care of the community. I was hoping that it would not be like TextMate.
But I guess I should not be "hoping" for anything when it's about my text editor.
Vim is mature software and has 20 years history of not going silent. 7.3 has had about 1300 updates published. and they already have 50 updates since 7.4 was released in August.
> If Sublime Text development does go off the rails like TextMate 1 did then that'll be my "fool me twice" momen
At some point I was tempted to buy into ST, but after giving it a go, I just decided that I need a reliable toolchain which doesn't change or disappear at the flick of a switch.
Little speaks reliable as Emacs or vim does.
This new project is open-source, which is definitely an improvement, but I still like the total hackability of emacs.
Alright, I had some real problems building this on Ubuntu.
1. I couldn't compile completion. There is no build.go in the build directory
2. I tried compiling lime anyways, by it required go-qt5 even though the repo page says that's optional.
I really wanted to check this out but I'm not really willing to spend more than the 15 minutes I already did trying to build it.
As a self-proclaimed gopher: this build has taken me far more than 15 minutes, and I'm still struggling with my Python installation.
The main issue here is that very few of these packages follow the proper conventions to work with the `go get` tool.
The author has attempted to version control his third-party deps (something `go get` lacks) in addition to using cgo (to build a C extension for Python).
Plus there's a frontend with a dependency on QT5 (another complicated C-interop library which probably has its own crazy dependency maze).
This is a fairly complex build, but the lack of `go gettable` packages and poor factoring of some packages is definitely making it more complex than it needs to be.
> This is a fork of visualfc's qt4 bindings, and several critical bugs are inherited along the way. Until these bugs are fixed, this package is not recommended for any real use. I don't have any time to actively work on this project, but I'll keep reviewing and merging pull requests.
I guess GUI programming in Go isn't really up to anyplace you can consider 'stable'
It is a different approach to using Qt GUI programming in Go where you use qml to define your UIs and keep the interface surface between Qt and Go fairly small instead of trying to expose the whole of Qt (which is very difficult to do in a maintainable manner because of the C++ API).
The license is LGPLv3 instead of the usual MIT-style Go license but it includes a linking exception that makes it viable for just about any use.
How about instead of writing just an opensource sublime text clone. We sit down as a community and discuss how we can create an even better editor than Sublime Text.
There are some awesome text editors out there that have features I wish were in sublime text but sadly arent.
For example, Rob Pike's acme editor has some really awesome ideas like mouse chording, (contextual right click. middle click command executions, etc), 9p vfs interfaces that allow plugins to be written in any language.
And then there are little experimental editor ideas like Conception with great ideas that are worth checking into.
Sublime Text gets alot of things right, but during my experience using it and using acme. I often find myself wishing there was a way to take both editors and mash them together because using one often makes me miss using the other.
I think it's more of an assumption than anecdotal. Sublimetext is a very expensive piece of software. You have the forever trial thing, but people don't usually want to get hooked up.
And now piece of anecdotal - I don't know a single person around me that uses it.
Can't say I actually use Sublime anymore, although I do know a few people who do, but when put in the perspective of a piece of software you use all day every day it doesn't seem that expensive. Even when many other editors are free.
IMHO, new languages are dominated by people that are not the best, but are on their way, as they will spend an inordinate amount of time learning from the best in older languages out of necessity. The arrogant go devs of today are likely to be the jaded experts of tomorrow, as they will be forced to learn in ways that devs on an established platform rarely must.
That was a BIG BIG disappointment for me. I assume the UI frameworks on Go are not on the same level as would be available for C/C++. Also I suspect portability is an issue.
There's something wrong on the install instructions: completion can't be installed
$ go get code.google.com/p/log4go github.com/quarnster/parser github.com/quarnster/completion github.com/howeyc/fsnotify
package github.com/quarnster/completion
imports github.com/quarnster/completion
imports github.com/quarnster/completion: no Go source files in /home/oscar/go/src/github.com/quarnster/completion
$ go version
go version go1.1.2 linux/amd64
I'm still in the process of building it. (Need to get my C deps straightened out for the python integration.)
The main problem here is that several of these packages (`lime` included) are not "go gettable."
---
Completion:
If you `go get github.com/quarnster/completion` it will error out but `$GOPATH/src/github.com/quarnster/completion` should contain the downloaded source files.
If you go into `$GOPATH/src/github.com/quarnster/completion/build` there's a Makefile you can run (with `make`) that should install the package.
----
Parser:
The `github.com/quarnster/parser` package is also not properly go gettable.
You need to cd into `$GOPATH/src/github.com/quarnster/parser/pegparser` and run `go install` which will put it in `$GOPATH/bin`
(I didn't try, but `go get github.com/quarnster/parser/pegparser` might actually work.)
This package is just poorly factored in my opinion. The root package contains the library code, and the binary is in a sub-package. It really should be the other way around: the root package should build the binary, which would import the library from a sub-package. That or they really should be two completely separate packages in distinct namespaces.
---
QT5:
The `github.com/salviati/go-qt5` library is _also_ not go gettable. However `go get` will download the source to your `$GOPATH` which should be enough for the Makefile to find it.
---
This is a rather frustrating build because so many of these packages don't follow the proper conventions for Go's package management.
I gave up! It fails to build miserably. What's the point of open-sourcing something when you're not open to the community. I mean, do this when it's ready for prime time, provide binaries, and they open-source it so that people can have some confidence in what they're running on their machines.
My main question is... what doesn't Sublime already do? I get that you want a project that's constantly getting new bugfixes and features, but there's not a whole lot that Sublime doesn't do for you as it stands. It's a mature project, most of the kinks have been ironed out. And, whatever functionality doesn't exist for it, YOU CAN BUILD.
There's only one feature that I feel could benfit ST3 right now, and that's the ability to move files from the sidebar.
But even then, I can't hate on the creator because that seems a bit outside the purview of a text editor in the first place (IMO that moves into IDE territory). I'd love it, and Sublime pretty much is my IDE already (what with build commands, project files, source control integration plugins, etc), but ultimately I'm fine with it not being there because I have a perfectly capable file manager open in a window right beside it.
I don't mean to rag on OP, I absolutely support the mentality that if you feel like something is broken you should fix it: however, in this instance I just feel like it ain't broke.
For me, ST is my primary work tool. What I paid for it is completely insignificant compared to what I earn.
Speaking as someone who used Textpad from 1995 until when I discovered SublimeText last year, I love the functionality and keyboard shortcuts that have been built into it. For example, the developer appears to have lifted CTRL+F2 / F2 for bookmarks directly from Textpad, and I'm very happy they did.
I for one am happy for the developer to move at his own pace. It is very solid for my purposes, now using the Ubuntu version having switched from Windows.
It's pretty much free, if you don't mind the nag dialogs. And it's well worth the money - finally, who cares if it's open source? You can build anything you need on top of it. Maybe it doesn't satisfy some lofty "open-source" philosophy, but for practical purposes, who cares?
Learning an editor is an investment in a developers time. Software has to be updated and maintained to work on newer operating systems. With popular open source editors, you're pretty much guaranteed that the software will continue to evolve. Can't say the same about proprietary editors. I think a lot of developers could use an open source editor for their entire career, something highly unlikely to happen if they were using a proprietary one.
I haven't used ST3, but ST2 doesn't build based on shebang lines and won't hide the menubar on Linux. I'm sure there are many issues I've forgotten since moving to vim as well.
I can definitely see the argument that development slowing and a lack of transparency is a problem worth fixing.
An example: it should be almost trivial to offer an ARM build of Sublime Text but the author refuses to do that even though there are 1300+ requests for that:
Just today, I was thinking to my self, my life isn't long enough to get fully comfortable with emacs or vi (and I am sure I am going to get hate mail for even saying that :)) So, it makes me happy to see a new, from the looks of it, powerful, text editor for the terminal!
I don't get why people are so pissed that this guy is refusing to fix bugs in his code or add features. I get it that Open Source is often massy because of this kind of attitude, but then again, you get MORE than you pay for it, don't you. If this proves to be a popular project, I am sure a community can organize around it. Not to mention that this kind of editor would primarily be used by programmers and coders, it's only fair that at least some of the people who use the software for free would get to contribute to it as well.
Vim is not as hard as it seems, the learning curve is kind of steep but nothing too crazy to get the basic things going, it's just a different approach to text editing. Don't get me wrong I would never use it (me, myself!) as a IDE, but as text editor, it's pretty great.
I don't want to start a flamewar about this, I don't find them interesting, I just want to point out that knowing Vim is extremely useful if you're going to be shh'ing into remote machines as it is basically ubiquitous.
I agree that flamewars about editors are not interesting, so I won't say too much, other than:
For SSH'ing, another editor which is (nearly) always there, and which I find convenient, is nano - and it displays its common shortcuts at the bottom, so you don't have to learn anything. I still use nano, even on my mac locally, to edit the odd file quickly in the terminal.
I agree, Vim is nice to know. But to each his own, I like the Sublime Text style editors, and having something like it but in terminal sounds really cool to me. Wonder how it will support multiple cursors, have yet to try it.
i wish quarnster didn't decide to retire his excellent sublimeclang plugin. it's by far the most useful plugin i've come across for sublime (in fact, i've almost come to rely on it), and i fear that his replacement isn't going to be able to do quite as much as clang can. incidentally, the lack of ST updates have meant that i've not ran into any issues with the plugin randomly breaking..!
that said, i'm looking forward to giving this a go, as an open source sublime text would be perfect.
One of the reasons it was retired is the same reason people can't open up issues on lime. Too much demand to fix everything that's broken, and not enough people actually fixing it combined with me not touching much C/C++ code personally.
I do still accept pull requests for it, and if anyone wants to step up as a maintainer I'd happily add them as collaborators after they've submitted a few pull requests.
My plan is to dive into the plugin if/when it breaks. If I can't get it working, I'll probably take that as a single to leave Sublime Text (unless development and interaction with the community has picked up again).
At the moment, SublimeClang working so well is the only thing which is stopping me looking around at other editors (I've tried the grand old vim and emacs before, and never got on well with either of them).
actually, aside from a few UI issues, i don't really have any complaints with sublimeclang, however, if the time comes that it no longer works with a build of ST3, i'll be more than happy to try and make a fix.
While I agree that quarnster is under no obligation to fix issues people have with the code, I think a simple statement to the effect that they will not be fixed would suffice. Not allowing issues and suggesting that people fork the code and set up their own issues neglects the fact that this will probably remain the main repo for the project, and it would be good to have issues in one place even for contributors to discuss.
That's not the editor. That looks like an experiment that sets up an ACE editor with TextMate syntax highlighting. The Lime editor is written mainly in Go.
At one point it was written in javascript. Then in python. Then Go.
I still think a html frontend would be cool, and it's certainly my intent to keep as much of the code in the backend as possible to be able to swap one frontend with another.
On Ubuntu + my AMD card, sublime text just chugs no matter what settings I use or what driver I switch to, so I'm really open to checking out alternatives. I'm even working up the courage to dive into vim.
> I'm even working up the courage to dive into vim.
If you're going to be using something 10 hours a day for who knows how many years, definitely take the time to get to know the best tools, which to me are still Emacs and ... I'll grudgingly admit, Vim.
Interesting how the editor wars seem to have ceased due to the prevalence of other editors. It used to be emacs vs. vim, now it seems to be emacs and vim vs. everyone else. (I completely agree, from the vim side).
I've noticed this too over the past few years that I've been dipping my toes in these waters. I just started learning emacs after working in vim for the past couple of years. Not an attempt to switch so much as to have another tool on my tool belt. Plus I don't want to be handicapped if a pairing opportunity arises.
You could also try emacs. I've used vim for years and switched to emacs recently (well, with the fantastic emacs evil plugin, that emulates all vim keybindings), but coming from Sublime emacs may be easier to get into as it is not modal. Also, it still has a ton of fantastic plugins.
That's a complicated build process, even for someone who already knows his way around Go. It wouldn't hurt to have a few binaries for those who just want to see what it looks like
are you sure fglrx gets loaded properly? i'd give it a go and poke around your Xorg log file, and ensure everything is as expected - any radeon from 2006+ should be able to handle unity and sublime..!
I have to wonder if this is solving a problem that doesn't really exist. So Sublime Text is closed source and production has slowed down... one could argue the latter happens when any big project blows-up to mainstream.
We have TextMate, we have SublimeText we have an endless supply of code editors and IDEs...do we need another just because of "open source"? I can't help this feels like a wasted effort.
Also, after going through the checklist, the app is supposed to support SublimeText and Textmate snippets, colors, bundles, bindings and more. Seems like the dev might have been better off contributing to these projects rather than trying to push yet another code-editor into an already crowded market.
I don't care about what you need or don't need, maybe I enjoy writing code for the sake of writing code. Implementing the rope structure for example was fun, as was figuring out how to go about with the various ST3 compatibility tasks.
What I choose to do on my own spare time is none of your business no matter how much of a waste of time you think it is.
It wasn't my intent to raise a defensive argument from you as I was simply stating my opinion. I know this is your pet project, and you're defensive... but people will have differing opinions and you should get used to dealing with them.
My point (which was perhaps missed?) was that I personally just don't see the value in bringing another text editor into the world especially when you're focused on imitating and supporting others rather than innovating with your own way. If you had created an editor with a new way of doing things, or pushed past existing concepts I wouldn't have thought twice about its value, but all the feature checklist is pretty much "Make this TextMate and Sublime in one" without any real game-changing plans being mentioned.
As to your point about learning new things through projects and enjoying code I don't disagree. My point was simply that you chose to invest your time in an already crowded market and simply reinvented functionality that already existed. I can respect the work, effort and learning that went into the project, I was just musing that it may have been better invested in a project that is a bit more unique and doesn't just reiterate what has already been achieved. That's also why I ended it with </2cents> it was an opinion...
Sounds like you really don't get the value of open source.
> If you had created an editor with a new way of doing things, or pushed past existing concepts I wouldn't have thought twice about its value, but all the feature checklist is pretty much "Make this TextMate and Sublime in one" without any real game-changing plans being mentioned.
That's the entire point; he/she wants to add features to Sublime but can't do so because it's closed source. He/she has to get to parity with Sublime before starting to add stuff, no?
I do see your point that parity much be reached first, and do personally appreciate the open source model for a number of reasons.
Perhaps my viewpoint stems from the description of the project.
The entire opening section talks about how Sublime Text has become slower and less communicative about releases. There's nothing mentioning surpassing the app, missing functionality, or items the developer wants to change. Simply that it's not moving fast enough for the developer of Lime to appreciate, so another must be built.
If there had been a specific statement saying "I want to implement X and Sublime doesn't" or "I want to have an editor do Z and none of the others do" then yes, I would see value in a project that starts off by imitating others. As it stands though, the project describes itself like a recreation of what's already out there without mentioning any intent to build on it.
This strikes me as the typical developer time-sink "I'll build this because I can". Sure it can be fun and educational and maybe help out a handful of people...but the real question that should be asked is "what sets my project apart from the rest". In this case, there's no sign of it aside from using GO and making it open source.
> I personally just don't see the value in bringing another text editor into the world
This isn't really a valid POV. There are many reasons to introduce solutions to problems with existing solutions. Is there any compelling reason not to open-source those solutions? Why does it matter whether there are competitors?
I don't see how it is a crowded market. Apparently Sublime Text is good enough to make a living as a paid-for, closed source piece of software, in spite of the existence of tons of high quality open source editors like emacs and vim. That alone suggests that commoditising it as an open source product would indeed add value.
And if the sublime text author had followed your argument, Sublime Text would not have existed. "Textmate already exists, and so do excellent open source editors. Why bother cloning textmate on windows?"
I for one would be very interested in an open source Sublime Text clone.
Seems like the dominant sentiment is that the maintainer is being defensive... I'd rather like to think he's being up-front and clear about his intentions for the project.
Nice effort, not sure if thats the right approach though. SublimeText is awesome and alot of work went into it. Before creating your own version of it disregarding everything the original author put into it, one should maybe try to collaborate with him on an unsupported open-source lite version or something.
No, but the author (Jon) has been taking a long time to reply to comments on the forum — which isn't unusual — and there has been a lack of recent updates. The last one was released a couple of days ago and didn't really bring anything new, even after months of waiting.
When I emailed Jon directly about his disappearance (just before the last release) he did say he's aware of his lack of communication and will address it shortly.
This sort of thing is exactly why I didn't install Sublime Text on my new laptop. After using v2 for nearly a year and buying a license, I became more and more uncomfortable that if there was a problem with the product, I couldn't fix it myself. Having already been burned by TextMate, I decided enough was enough and only installed Emacs. That was last December, and I'd say I'm much happier - but I also spend a bit more time tweaking my editor than I probably should.
This is not to say I have anything against Sublime Text. It's a beautiful piece of work. It's simply not open source, and that's a deal breaker for a tool as integral to my day to day as a text editor.
can you please make it so people can post issues? It is a big part of community. even if you do not personally fix any issues it will allow contributors to collaborate about them.
Splitting into a generic back end that deals with data means you can adapt different UIs to it. For example, you could provide a native app such as Cocoa without having to rewrite the entire app for that GUI framework.
Why? I mean, Python 3 is already up for years, and using Python 2x for me personally feels like shooting myself in the foot due to the horrible unicode handling, for example. Why can't we finaly draw the line and abandon Python 2 forever?
Calm down people and learn to say thank you every once and a while. This is seriously cool, it's written in Go (which HN has a raging hard on for), what's not to love about this? I'm grateful someone took the time to get this far, now lets take it further.