So basically, this will be a library that you can use to add keyboard shortcuts, a command-line (minibuffer) interface, and extensions/plugins to your application, and they can all can be reconfigured, mixed, matched, and extended, all on the fly without recompiling or even restarting your app.
Currently most of the apps I use don't have all that and I'm getting along fine, but dang, it would be fun to see what could be done with that kind of power added to them.
An alternative: use an embedded Common Lisp and connect to it via SLIME from Emacs. Thus you could build an environment in Emacs for controlling the App and download/executing Lisp code inside the App.
This is a fine way to work. I, for one, love SLIME. However, the main goal of Emacsy is not to load code at runtime; it's to be able to modify the UI of your application at runtime while providing some Emacs-like facilities.
Certainly, the normal way of embracing an application with Emacs is to turn Emacs into your frontend as you suggest. That works well for a number of applications, but it's not something you can distribute as a complete application, instead you might include your-app.el and hope for the best. Emacsy provides a way for you to improve your actual applications UI. Moreover, it allows your users to modify the UI to suit themselves.
I like the idea, but I'd like to better understand how the money is going to be used on the Kickstarter page. Is it basically to spend, say, a month of focused work to get the major girders of emacsy ready to go so the rest can be iterated upon and crystalized? It's clearly not enough to fund the entire effort to the point of having something usable, stable, and with adoption (which would require working with the requirements of other projects), but I get the sense that wasn't really the idea.
Hi, I've updated the page to include my plan. Yes, this is about laying the foundation for Emacsy. However, I expect to deliver on all the features I laid out such that they are usable and documented. There are a number of other features I would like to see in the future, so I expect I'll be working on it and maintaining it for sometime into the future. The funding is essentially to encourage and justify that it's worth my time to go the extra mile in making something usable for everyone instead of just making it for myself, which would be a much easier job.
Agreed. You have sections 'Introduction', 'Vision', 'Motivation', 'Goals', 'Anti-Goals', 'Emacsy Features' and 'How you can help?'. You're missing 'Plan'.
Fair enough. My plan is to work out in the open on github, part-time this Summer. I'll report noteworthy builds and solicit feedback. I believe that by the deadline I can produce a usable and documented Emacsy library that includes all the features mentioned above, and maybe even some features I haven't mentioned. That should provide an excellent foundation for this project to thrive after the deadline, and I expect to maintain it for sometime after that.
ok - there are now definitely too many kickstarter posts appearing here. furthermore, why don't all those people on kickstarter not just write their app/programm, without seeking funding. wasn't the whole open source community a product of a lot of people using their spare time to create new software and give it away for free (linus torvalds, etc.). that spirit is somehow lost on kickstarter...
. wasn't the whole open source community a product of a lot of people using their spare time to create new software and give it away for free (linus torvalds, etc.). that spirit is somehow lost on kickstarter...
I agree that all the Kickstarters on here are starting to wear a bit thin, but strongly disagree with the rest of what you said. Listen to yourself: You're complaining that this person doesn't want to work for you for free. How can you possibly feel entitled to that? Remember that old free software mantra: It's like "free speech," not "free beer."
No, that's not what parent is doing. For example, he may prefer they didn't do the work at all. And "for you"? Where does that come from?
Personally, I have no problem with this - in fact, I'm paid to write FOSS - but some people feel uneasy with the commercialization of the work that traditionally belongs to communities of volunteers, and in certain situations I feel the same.
> No, that's not what parent is doing. For example, he may prefer they didn't do the work at all.
He specifically complained about them taking money to do it. I genuinely don't see how you could read that as "I would prefer it if you did not create an embeddable emacs at all." His comment very strongly suggests that he was fine with them doing the work, but he didn't want them to be paid for it.
> Personally, I have no problem with this - in fact, I'm paid to write FOSS - but some people feel uneasy with the commercialization of the work that traditionally belongs to communities of volunteers
I agree, and that's the attitude I'm arguing against. Free software has never been about demanding that people not take money for their troubles. It has often worked out that way for the vast majority of contributors, but I don't see how the unprofitability of OSS development is a good thing. More money going into free software means more free software and quite possibly higher quality free software (since they don't need to be distracted by other work that puts bread on the table), which is good for everyone. I have no problem with somebody like you or the OP taking money in return for making useful software.
thanks for elaborating. yep, I think it's mostly an issue of commercialization of projects where no actual funding is required. but heck, I mean you can always try to get some funding for your side project if you feel like you need it - please, just don't spam our community with it.
That's a myth, anyways. Projects like Linux, LLVM, and Ruby on Rails succeed because companies devote paid staff to working on them, usually because they sell a complementary product or service.
What's the problem with Kickstarter posts, as long as the project being promoted is technically interesting?
If posting links to interesting technical projects that try to gain mindshare with an eye on eventual VC backing is appropriate to HN (and that seems a fairly uncontroversial proposition to me), why would posting links to interesting technical projects that try to gain mindshare with an eye on kickstarter backing NOT be appropriate?
1. Replacing "scratch your own itch" by "scratch somebody else's itch" can be seen as an improvement over the original model.
2. AFAIK, "Kickstarter" does not imply "open source".
3. Even the Linus'es of this world occasionally stop hacking to eat, and food costs money.
Having said that, I think anything including the term "Emacs" is "scratching your own itch". I do not hold this as a paragon example of the usefulness of Kickstarter.
Sounds like something I wanted to make, got close with lispworks, but then that's not very cheap. Now I'm doing it with lua, mainly due to luajit, but lua is a bit harder to use in repl style, where only a function has changed (it would work only if the function is global)
Nonetheless seems promising, and not futuristic (as in bells and whistles, but nothing more)
This looks like it would be very useful for anyone who wants to develop C applications with an embedded guile interpreter. However I think the pitch would be more clear if it was sold as a Guile library for enhanced interactive interfaces rather than as an Emacs derivative.
Guile is nice embeddable scheme, and seems to have a lot of momentum, cool new developments. If this project is about making it a bit easier to integrate it in your app, that would be great. It's not /too/ hard to embed guile, but I certainly think there's room for making it easier.
If I had reason to believe that programs I want to use would be written with this code, I would be happy to back it. I don't have a lot of hope for that though.
Why I know this: I spent a fair portion of winter break trying to port the R-project into Javascript. It went nowhere (damn fortan), but I learned a ton about emscripten and compiling.
I'm wondering, how can this not be plagued by GPL-hell. Anyway, the fact that a project like this will not be possible to use in non-GPL software is somewhat of a dealbreaker to me. A perfect example of how Stallman is stifling innovation.
Emacsy is LGPL.
On the other hand, you could embed vim legally in anything. That, and it's a much better editor. (Just kidding, I'm not trying to start a flame war. To each his own; I personally cannot live without vim.)
Actually, it was not clear to me from reading the description whether the code is supposed to be based on the GNU Emacs source ("Extracts the kernel of Emacs" may imply that it is). If it is, I wonder how relicensing the GPL Emacs code under LGPL is supposed to work.
You should really clear that up, because I had the same reaction to the kickstarter as other people have. In the write-up it sounds like you're going to use emacs itself as the starting point to build on (but of course emacs is GPL which means if you did use any code from it, that would infect Emacsy and anything built on it and leave you no choice but to use GPL as well).
Either way you're kind of damned if you do, damned if you don't here, IMO. It won't get much use if it is GPLed and it won't get much use if it isn't actually emacs, because if the core isn't actually emacs it is bound to have lots of small incompatibilities which will break compatibility with the large body of existing emacs scripts that are most of the reasons emacs is nice to use in the first place.
I hear you. Yeah, the problem with changing or updating Emacs is it's been too successful. No one can change its constitution without breaking everything that makes it great.
The leg that I'm trying to stand on is, Emacsy isn't a text editor. It does not use elisp. No Emacs code will ever run on it. It provides a set of Emacs-like facilities that do not currently exist in a lot of interactive applications. So the project has the opportunity to make a clean break with past and still provide something of value. We'll see if can obtain even a sliver of the success that Emacs has.
I updated the FAQs to hopefully be more clear on this issue.
Currently most of the apps I use don't have all that and I'm getting along fine, but dang, it would be fun to see what could be done with that kind of power added to them.