Lime – Experimental Sublime Text clone
github.com
github.com
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.
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.
Please don't do this.
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.
> 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.
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!?)
As 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. ;)
Packages (1): ghc-7.6.3-1
Total Download Size: 62.08 MiB
Total Installed Size: 735.76 MiB
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
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.
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...)
The presumption that he's trying to destroy the original developers livelihood is naive at best.
Sublime Text itself was very much "inspired" by TextMate back when both of them were commercial and closed source.
Seriously, though, you do know that there's no such thing as a free lunch, even when it comes to open source, right?
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.
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.
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.
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.
https://github.com/shurcooL/Conception
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.
And now piece of anecdotal - I don't know a single person around me that uses it.
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.
If Lime is intended for Mac, could do worse than starting with the Kod code base.
Best of luck with the project.
$ 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.
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...
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.
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.
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.
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).
Try to solve new problems, don't copy the solution to existing problems.
second level of procrastination: programmer writes own IDE
Looks Interesting!
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.
It seems like it could be another worthy alternative to sublime text if it moves in the right direction.
Disclaimer: I'm not looking for an alternative to sublime right now - it's stable enough for me to use as it is.
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.
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?
https://github-camo.global.ssl.fastly.net/b0f3292d2c26070a18...
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.
No.
No thanks.
Yes please.