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 :)
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.
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..."
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.
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.
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.
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.
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.
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:
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
> 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.
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?
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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.
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..!
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
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.)
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.
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 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.
> 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?
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.
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.
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.
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:
252 comments
[ 3.0 ms ] story [ 274 ms ] threadAs it stand it not likely that many people will build a thing they never even seen a screenshot.
EDIT:Also if this is the only program using go I now have a 300 MB text editor.
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.
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.
Of course I knew what I was getting myself into, and my usage patterns make this limitation somewhat academic. ;)
[1]: https://www.archlinux.org/groups/x86_64/base-devel/
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.
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.
https://github.com/mikepurvis/essential-ros/blob/master/.tra...
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
> 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.
Unless I'm you, I wont care about your project either.
Source code is available. So, if you feel like it, go nuts. And if not, don't. The project is at an early stage so what is there to complain about?
He didn't. Author != submitter.
> 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".
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.
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.
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.
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.
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.
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.
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.
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 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.
I don't know if there is a word for that.
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!
Being a majority doesn't prevent them from being illiterate. For most of human history illiteracy was the norm.
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.
So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
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.
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).
Or are you volunteering to do the bug triage part?
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.
I do not have time or interest in doing this, but I would be happy to accept a pull request which meets our project guidelines.
It just means the source code is 'open' for you or the community to extend as you please. Your comparison to Sublime is apples and oranges.
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.
The point of open source is not that you suddenly get your own personal developer to do things for you.
It's open source, you can download it and add your desired features yourself, that is very much the 'point of open source' in my opinion.
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.".
(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.)
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.
Let's restore a culture where posting a tarball and licensing it and leaving is okay and wonderful, instead of falling short of expectations.
In github, you can fork, and then turn on issues! (I know, we live in the future right!?)
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.
that said, i'm looking forward to giving this a go, as an open source sublime text would be perfect.
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.
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).
They might not be the best, but you can be sure they are able to code. They would get exposed pretty quickly in small communities, if not.
Best of luck with the project.
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'
https://github.com/niemeyer/qml
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.
But I guess I should not be "hoping" for anything when it's about my text editor.
Mature software doesn't mean done.
Ironically I just received a mail from Allan Odgaard warning me that the Maverick update may break some bundles because of the ruby update.
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.
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 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.
$ 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
How did you guys install lime?
---
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.
https://github-camo.global.ssl.fastly.net/b0f3292d2c26070a18...
Hello, thanks for the interest. I hope some of you will take the time to contribute in the form of pull requests.
I just updated README.md with a screenshot, here's a direct link: http://i.imgur.com/VIpmjau.png
Especially the bit down the bottom requesting that Python 3 be built with special configure flags.
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.
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.)
I doubt I'm going to leave Vim anyways, but I really wanted to share my opinion on this point.
Congratulations and good luck.
No thanks.
Yes please.
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.
</2Cents>
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.
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...
> 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?
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.
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.
My point (which perhaps you missed?) is that you don't get to tell me what I choose to spend my time on.
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?
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.
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.
I can definitely see the argument that development slowing and a lack of transparency is a problem worth fixing.
http://sublimetext.userecho.com/topic/100806-armv7-or-armv6-...
If ST were open source, someone would already have built the binaries. But no...