Kickstarter for Emacs

Kickstarter for Emacs

[Tom]

I wonder if it would be possible to fund adding new features, improvements
to emacs using kickstarter. In case of Emacs most developers work on it
for free as far as I know and people usually work on features they personally
need and there is usually not enough motivation to work on complex features 
which need a lot of tinkering (for example, zero config C++/Java completion,
refactoring comparable to the level what Eclipse/Visual Studio provides).

Recently there were quite a few successful fundraises on Kickstarter and
currently there is a project for implementing an IDE too:

http://www.kickstarter.com/projects/306316578/light-table

What if someone would think up a project (like out of the box
Eclipse-level Java completion/refactoringin emacs) and start a fundraising
for that, so he (maybe together with others) can work on it full time for,
say, half a year or a year?

I wonder if there be would be enough backers to implement such features
in emacs. Could it be an alternative model for funding Emacs development?
(Of course, the code should be GPL and stuff, so it would be released
to the community when the project is completed.)

The point of the model is that people don't make generic contributions 
to some organization, but they fund actual features which they care
about, so they are more motivated to donate some money. And the amount
does not need to be a large sum, it can even be a few dollars if 
enough people donates for the cause.

There were successes with this model on Kickstarter and knowing the 
enthusiasm of Emacs users it may work for Emacs too.

(Kickstart itself is not the point, the model is.)

Re: Kickstarter for Emacs

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> There were successes with this model on Kickstarter and knowing the 
> enthusiasm of Emacs users it may work for Emacs too.
> 
> (Kickstart itself is not the point, the model is.)
> 

I checked out Kickstarter's FAQ and it says:

  I only need to raise a small amount of funding. Is Kickstarter
  for me?

  Absolutely! Kickstarter is for creative projects big and small,
  serious and whimsical, traditional and experimental. Small
  projects that you (or you and a few friends) can do over a
  weekend are perfect for Kickstarter. In fact, the most common
  projects on Kickstarter are not blockbusters but smaller projects
  that raise $5,000 or less. Check out some fun project stats and
  some currently funding Small Projects looking to raise $1,000 or
  less.

http://www.kickstarter.com/help/faq/kickstarter%20basics#HowDoIStarAProj


So it looks like it would be suitable for smaller projects too and
apparently people do use it to fund software projects like this one
which aims to create a better coffeescript compiler:

http://www.kickstarter.com/projects/1182995593/make-a-better-coffeescript-compiler?
ref=live

Re: Kickstarter for Emacs

[Chong Yidong]

Tom <adatgyujto@gmail.com> writes:

> So it looks like it would be suitable for smaller projects too and
> apparently people do use it to fund software projects like this one
> which aims to create a better coffeescript compiler

So far, I haven't seen much call from individual Emacs developers for
financial support, but individual developers (e.g. of third-party
packages) can always set up their own donations mechanism, rather than
using Kickstarter, which as far as I can tell is just a way to funnel
money to Kickstarter Inc and Amazon (who take a whopping 10% cut from
donations).  Their PR campaign sure is impressive, though.

If there is interest in funding anything at the Emacs project level, the
FSF has set up a mechanism for donating to individual GNU packages,
currently used by GNU Octave and GNU Telephony; see

  https://my.fsf.org/associate/donate/working-together

But, as I said, I don't currently see much need.  (OT: I believe
Octave's maintainer is supported by donations, so I strongly encourage
anyone who uses that software to donate.)

Re: Kickstarter for Emacs

[Tom]

Chong Yidong <cyd <at> gnu.org> writes:
> 
> So far, I haven't seen much call from individual Emacs developers for
> financial support, but individual developers (e.g. of third-party
> packages) can always set up their own donations mechanism, rather than
> using Kickstarter, which as far as I can tell is just a way to funnel
> money to Kickstarter Inc and Amazon (who take a whopping 10% cut from
> donations).  Their PR campaign sure is impressive, though.

That's why I said the model is the point, not Kickstart itself.
If there is other ways to do it it's also good. The important part
is there should be a way to quickly set up projects to fund 
specific features like on Kickstartes instead of having static,
generic donation points like the FSF donation page.

> 
> If there is interest in funding anything at the Emacs project level, the
> FSF has set up a mechanism for donating to individual GNU packages,
> currently used by GNU Octave and GNU Telephony; see
> 
>   https://my.fsf.org/associate/donate/working-together
> 

Yes, but it's project level support. I was talking about feature
level funding, so that people can fund the implementation of their pet
feature explicitly instead of giving money to the generic project
and let the developers decide what they want to work on.

People are much more willing to give money if they know it will 
go to fund the specific feature they want implemented. Paying
for scratching my itch makes my itch go away, so I'm willing to
pay for it.


> But, as I said, I don't currently see much need. 

There is no neeed, because there is no way to fund specific features.

For example, I often read on the net people saying that they love
emacs, but for Java they use Eclipse, because that understands
the language (intelligent completion/refactoring out of the box)
better.

What if someone, say a freelance developer, says the he wants to
improve emacs java support significantly (of course, the goal should
be more specific), but for that he needs to work on it several months
full time. In order to do it he needs funding, so he doesn't have to
take up on other jobs during these months, so he does it if people
donate a certain amount.

That's how the projects on Kickstarter work and I bet there would
be quite a few people willing to pay a few dollars for emacs to have
Java support comparable to Eclipse. The only problem is currently
they can't do it, because there is no way to fund a certain feature
explicitly.

So I think there is a need, only developers don't consider this
possibility of funding their work. That's why I started this thread,
so somebody may start such a project which he wants
to do, but can't, because of lack of time and other work commitments
and money making needs.

The only thing to keep in mind the project should be something 
which interests lots of users (like better Java support, but surely,
there are quite a few others), because people won't fund niche features
which only a handful of people need.

Re: Kickstarter for Emacs

[Vyacheslav Gonakhchyan]

[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]

On kickstarter there is a reward system. The point is that you can buy
final product for a lower price. And then after the completion of a project
price goes up. That gives people motivation to buy early.
In emacs the only motivation is that you know that the money will go
towards completion of certain feature. But there are no rewards because
emacs is free. So I think it won't be as much successful.

On Wed, Apr 18, 2012 at 1:25 PM, Tom <adatgyujto@gmail.com> wrote:

> Chong Yidong <cyd <at> gnu.org> writes:
> >
> > So far, I haven't seen much call from individual Emacs developers for
> > financial support, but individual developers (e.g. of third-party
> > packages) can always set up their own donations mechanism, rather than
> > using Kickstarter, which as far as I can tell is just a way to funnel
> > money to Kickstarter Inc and Amazon (who take a whopping 10% cut from
> > donations).  Their PR campaign sure is impressive, though.
>
> That's why I said the model is the point, not Kickstart itself.
> If there is other ways to do it it's also good. The important part
> is there should be a way to quickly set up projects to fund
> specific features like on Kickstartes instead of having static,
> generic donation points like the FSF donation page.
>
> >
> > If there is interest in funding anything at the Emacs project level, the
> > FSF has set up a mechanism for donating to individual GNU packages,
> > currently used by GNU Octave and GNU Telephony; see
> >
> >   https://my.fsf.org/associate/donate/working-together
> >
>
> Yes, but it's project level support. I was talking about feature
> level funding, so that people can fund the implementation of their pet
> feature explicitly instead of giving money to the generic project
> and let the developers decide what they want to work on.
>
> People are much more willing to give money if they know it will
> go to fund the specific feature they want implemented. Paying
> for scratching my itch makes my itch go away, so I'm willing to
> pay for it.
>
>
> > But, as I said, I don't currently see much need.
>
> There is no neeed, because there is no way to fund specific features.
>
> For example, I often read on the net people saying that they love
> emacs, but for Java they use Eclipse, because that understands
> the language (intelligent completion/refactoring out of the box)
> better.
>
> What if someone, say a freelance developer, says the he wants to
> improve emacs java support significantly (of course, the goal should
> be more specific), but for that he needs to work on it several months
> full time. In order to do it he needs funding, so he doesn't have to
> take up on other jobs during these months, so he does it if people
> donate a certain amount.
>
> That's how the projects on Kickstarter work and I bet there would
> be quite a few people willing to pay a few dollars for emacs to have
> Java support comparable to Eclipse. The only problem is currently
> they can't do it, because there is no way to fund a certain feature
> explicitly.
>
> So I think there is a need, only developers don't consider this
> possibility of funding their work. That's why I started this thread,
> so somebody may start such a project which he wants
> to do, but can't, because of lack of time and other work commitments
> and money making needs.
>
> The only thing to keep in mind the project should be something
> which interests lots of users (like better Java support, but surely,
> there are quite a few others), because people won't fund niche features
> which only a handful of people need.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4356 bytes --]

Re: Kickstarter for Emacs

[Tom]

Vyacheslav Gonakhchyan <ytriffy <at> gmail.com> writes:

>  On kickstarter there is a reward system. The point is that you
> can buy final product for a lower price. And then after the
> completion of a project price goes up.  That gives people
> motivation to buy early.In emacs the only motivation is that
> you know that the money will go towards completion of certain
> feature. But there are no rewards because emacs is free. So I
> think it won't be as much successful.


The reward is your pet feature will finally get implemented in Emacs
and you don't have to use an other editor/IDE for certain tasks.
I think it's a pretty big reward.

BTW, the coffescript compiler will be released with a BSD license for
free and people are still donating:

http://www.kickstarter.com/projects/1182995593/make-a-better-coffeescript-compiler?

Re: Kickstarter for Emacs

[Vyacheslav Gonakhchyan]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

Ok, good example. It can fly if it will get enough visibility(perhaps on
slashdot).
But what about support? Emacs and Java are constantly in development.
New version will come out and additional work will be required. Another
kickstarter might be a solution,
but I don't think that this model is sustainable.

On Wed, Apr 18, 2012 at 1:43 PM, Tom <adatgyujto@gmail.com> wrote:

> Vyacheslav Gonakhchyan <ytriffy <at> gmail.com> writes:
>
> >  On kickstarter there is a reward system. The point is that you
> > can buy final product for a lower price. And then after the
> > completion of a project price goes up.  That gives people
> > motivation to buy early.In emacs the only motivation is that
> > you know that the money will go towards completion of certain
> > feature. But there are no rewards because emacs is free. So I
> > think it won't be as much successful.
>
>
> The reward is your pet feature will finally get implemented in Emacs
> and you don't have to use an other editor/IDE for certain tasks.
> I think it's a pretty big reward.
>
> BTW, the coffescript compiler will be released with a BSD license for
> free and people are still donating:
>
>
> http://www.kickstarter.com/projects/1182995593/make-a-better-coffeescript-compiler
> ?
>
>
>

[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: Kickstarter for Emacs

[Tom]

Vyacheslav Gonakhchyan <ytriffy <at> gmail.com> writes:

>  Ok, good example. It can fly if it will get enough
> visibility(perhaps on slashdot).But what about support? Emacs
> and Java are constantly in development.New version will come
> out and additional work will be required. Another kickstarter
> might be a solution,


Code maintenance is easier. The hard task is implementing the feature
itself. I'm sure if a really good Java support were implemented
then there would be people who'd pick up the torch if the original
developer wouldn't want work on it anymore. (Though I think it would
be done by someone who needs good Java support himself, so he would
keep maintaining the code he wrote).

Anyway Java is only an example. There should also be other, maybe
smaller features which could be funded this way.

My point is people are willing to shell out some money if they know
it goes into some feature which they need.

I (and lots of others) would readily donate some money if I could
steer the development to features which I personally need. That's
why the feature-level funding is important. 

It's an opportunity for developers who want to work on improving 
Emacs, but can't find the time and energy to do it beside their
 regular jobs, to do it with this targeted funding model.

It works for other projects, so it could work for Emacs too. Only
somebody has to try.

Re: Kickstarter for Emacs

[Jambunathan K]

> I (and lots of others) would readily donate some money if I could
> steer the development to features which I personally need. That's
> why the feature-level funding is important. 

Could you please point to your Emacs/Java IDE proposal on Kickstarter's
website?

Re: Kickstarter for Emacs

[Tom]

Jambunathan K <kjambunathan <at> gmail.com> writes:

> 
> 
> > I (and lots of others) would readily donate some money if I could
> > steer the development to features which I personally need. That's
> > why the feature-level funding is important. 
> 
> Could you please point to your Emacs/Java IDE proposal on Kickstarter's
> website?
> 

You misunderstood me. I don't want to implement it myself, but
I'd gladly fund the implementation of this feature (together with
quite a few others).

So I started this thread to raise awareness about this specific funding
model, so if somebody is interested to do it and thinks he has the
necessary knowledge for it then he can start such an improvement proposal
for Emacs.

Here are some examples which Eclipse can do with Java code and
which would be useful in Emacs (in addition to intelligent,
context-aware completion, of course):

Quick assist: http://goo.gl/nv4nn

Quick fix: http://goo.gl/LL5TQ

Re: Kickstarter for Emacs

[Jambunathan K]

> http://www.kickstarter.com/projects/306316578/light-table

Interesting.  May I know how this project is related to Emacs?  Please
enlighten me on how it improves the Emacs eco-system?
-- 

Re: Kickstarter for Emacs

[Jambunathan K]

> So I started this thread to raise awareness about this specific funding
> model, so if somebody is interested to do it and thinks he has the
> necessary knowledge for it then he can start such an improvement proposal
> for Emacs.
>
> Here are some examples which Eclipse can do with Java code and
> which would be useful in Emacs (in addition to intelligent,
> context-aware completion, of course):
>
> Quick assist: http://goo.gl/nv4nn
>
> Quick fix: http://goo.gl/LL5TQ

May be you should have posted this information in original mail.
Atleast it would have made the post relevant to this group.

>> Could you please point to your Emacs/Java IDE proposal on Kickstarter's
>> website?
>> 
> You misunderstood me. 

...which is good.  Because it will lead to better understanding.

> I don't want to implement it myself, but I'd gladly fund the
> implementation of this feature (together with quite a few others).

A patron cannot kickstart a project?  That's bad.
-- 

Re: Kickstarter for Emacs

[Tassilo Horn]

Tom <adatgyujto@gmail.com> writes:

>> Ok, good example. It can fly if it will get enough visibility(perhaps
>> on slashdot).But what about support? Emacs and Java are constantly in
>> development. New version will come out and additional work will be
>> required. Another kickstarter might be a solution,
>
> Code maintenance is easier. The hard task is implementing the feature
> itself. I'm sure if a really good Java support were implemented then
> there would be people who'd pick up the torch if the original
> developer wouldn't want work on it anymore.

Just to throw something in: Vim has very good Java support simply by
piggy-backing on Eclipse, which can run headless and be controlled via
the command line.

  http://eclim.org/

So basically, vim only needs to implement proper syntax-highlighting for
Java, and the rest (auto-completion, refactoring, project management) is
done by invoking the right command on the Eclipse side.

There's also an Emacs port of Eclim.

  https://github.com/senny/emacs-eclim

Not sure how well that works right now, but that might be a rather cheap
option to catch up on Java support in Emacs.  The downside of this
approach is of course that you still need Eclipse...

Bye,
Tassilo

Re: Kickstarter for Emacs

[Tom]

Jambunathan K <kjambunathan <at> gmail.com> writes:


> > http://www.kickstarter.com/projects/306316578/light-table
> 
> Interesting.  May I know how this project is related to Emacs?  Please
> enlighten me on how it improves the Emacs eco-system?

I can't decide if you really don't understand or you just pretend not
understanding it for some reason.

The above link was an example for a software project which is funded
by users. This thread is about applying the same concept (implementing
features funded by users) to emacs development.

There are some features like multi-occur which do not need such funding
because people can easily implement them in their freetime. However,
there are more complex features (one such example is advanced
Java support) regarding which Emacs lags behind other editors/IDEs.

Apparently, these advanced features need so much effort and development
time that developers are not willing to work on it in their free time,
beside their regular jobs or other commitments.

Here comes in the picture this funding model. If such features can
be prefunded by users, so that a motivated developer can work on it
full time for months then they can get implemented which otherwise
probably would not happen due to lack of free developer resources.

Re: Kickstarter for Emacs

[Tom]

Tassilo Horn <tassilo <at> member.fsf.org> writes:
> 
> Not sure how well that works right now, but that might be a rather cheap
> option to catch up on Java support in Emacs.  The downside of this
> approach is of course that you still need Eclipse...


Yes, this is also an option which needs much less time to effort
to implement, though I think people were much less likely to fund
such a solution if they would still need to use Eclipse. 

So this implementation would be more like a best effort, "working on it
in my free time" version than full time, crowdfunded version.

Re: Kickstarter for Emacs

[Nikodemus Siivola]

Having run one reasonably successful crowdfunding campaign myself
(still working on it, actually), let me say this to those who are
contemplating trying it out:

(1) Don't underestimate the visibility a site like Kickstarter or
IndieGoGo provides. Yes, they take a cut. I still suspect it was a win
for me personally, as opposed to just having my own site with a PayPal
buttom up. Hard to say for sure with a single data-point, of course.

(2) Don't listen to people who think they know what sort of people
will donate and how much. Your guess is as good as theirs unless /you/
have done some research. Doing research is pretty damn easy: post a
web-questionnair on the same social media channels you would use to
publish the actual campaign. It will get less publicity, but it will
give you a hint. It matters that you do this yourself, instead of
relying on other people doing it for you: their social media presence
is different from yours.

(3) I think crowdfunding is a stellar model for free software, but
there are kinks that need to be worked out. Ie. striking a balance
between promising deliverables and promising to work for N months on
it. Promising to work on something for a certain time is ... meh. Why
would I pay for that? Promise to deliver specific things. Just don't
promise too much! Penalty for not delivering: no future in
crowdfunding for you.

(4) Don't expect people to shell out if you don't have a track record
or something to show that makes people trust you.

(5) Crowdfunding isn't a magic money button, but if you can credibly
show that you have the ability to deliver something people want,
they'll be happy to pay for it.

(6) Don't aim too high, but add bonus goals as the campaign gathers
steam. A campaign that asks for $3k and nets $16k is a success, and
gets extra publicity because of that. A campaign that takes over a
week to reach it's first goal seems weak in comparison. Once you've
hit the first goal future funders are easier to get, because you
become a "safe bet" -- provided you have either nice perks, or solid
public-interest bonus goals.

(7) Interestingly enough, all campaigns to which statistics I have
access (not many, but more than my own), seem to pull on average
0.5-1.5 USD per visitor to the campaign page. So spread your net wide.

Cheers,

 -- nikodemus

Re: Kickstarter for Emacs

[Tassilo Horn]

Tom <adatgyujto@gmail.com> writes:

>> Not sure how well that works right now, but that might be a rather
>> cheap option to catch up on Java support in Emacs.  The downside of
>> this approach is of course that you still need Eclipse...
>
> Yes, this is also an option which needs much less time to effort to
> implement, though I think people were much less likely to fund such a
> solution if they would still need to use Eclipse.

Not sure.  Just having Eclipse installed doesn't bother me too much.
Having it running and consuming memory/CPU doesn't bother me, too.  What
really bothers me is that even when using Eclipse with its Emacs
keybinding scheme enabled, it's still hard to use.  I want my kill-ring,
I want keyboard macros, I want my isearch, etc...

> So this implementation would be more like a best effort, "working on
> it in my free time" version than full time, crowdfunded version.

Sure, but even with full-time initial development and crowdfunding, I
think you underestimate the effort needed for catching up on Eclipse's
Java support.  According to the statistics at Ohloh

  https://www.ohloh.net/p/eclipse-jdt

the Eclipse Java Development Tools are about 2 million LOC, estimated
effort ~600 person-years, estimated costs ~33 million USD, ~30 active
committers, and ~90 committers in total.  Ok, you shouldn't take those
numbers to seriously, but well, it's much anyway.

Bye,
Tassilo

Re: Kickstarter for Emacs

[Eric Schulte]

Tom <adatgyujto@gmail.com> writes:

> Chong Yidong <cyd <at> gnu.org> writes:

[...]

>> 
>> If there is interest in funding anything at the Emacs project level, the
>> FSF has set up a mechanism for donating to individual GNU packages,
>> currently used by GNU Octave and GNU Telephony; see
>> 
>>   https://my.fsf.org/associate/donate/working-together
>> 
>
> Yes, but it's project level support. I was talking about feature
> level funding, so that people can fund the implementation of their pet
> feature explicitly instead of giving money to the generic project
> and let the developers decide what they want to work on.
>
> People are much more willing to give money if they know it will 
> go to fund the specific feature they want implemented. Paying
> for scratching my itch makes my itch go away, so I'm willing to
> pay for it.
>

Maybe the FSF donation system linked above should be enhanced adding;

1. increased donation granularity to specific features tasks or bugs,

2. user (not-developer) introduction of projects of interest, e.g., "if
   someone did X I'd happily donate Y" and an up-vote or up-donate
   driven system of ranking and displaying pledges.

Making something like this would require both development effort to
build the infrastructure and social effort in advertising to potential
developers and users.  Perhaps the fact that only two projects are
listed at the link above means that the social environment is not yet in
place.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: Kickstarter for Emacs

[Tom]

Tassilo Horn <tassilo <at> member.fsf.org> writes:

> 
> Not sure.  Just having Eclipse installed doesn't bother me too much.

You may be right. It's possible people would willingly fund an
implementation which aims to polish the emacs eclim interface.
Memory/CPU is cheap these days after all as you also said.

> 
> Sure, but even with full-time initial development and crowdfunding, I
> think you underestimate the effort needed for catching up on Eclipse's
> Java support.  

I didn't mean a full catch up in one jump. The first such project
could include only intelligent code completion and such. Refactoring
and such could be done later. 

And there is CEDET/Semantic. An Emacs implementation could be
built on these foundation. There is no need to start everything from
scratch.

But in the end Eclim may prove be the best way to do it. Why
reimplement everything if the bulk of the job is done already?
I tried Eclim once and it worked quite well, only it was unpolished,
so if the interface is polished nicely then it can be a viable
alternative of using Eclipse.

Re: Kickstarter for Emacs

[Tom]

Nikodemus Siivola <nikodemus <at> random-state.net> writes:

> 
> Having run one reasonably successful crowdfunding campaign myself
> (still working on it, actually), let me say this to those who are
> contemplating trying it out:
> 

Thanks for this detailed analysis. It will hopefully motivate
some people to try this with emacs.

People are willing to pay if they care about the goal. Maybe we
should find out somehow what the features are which Emacs users
most want to see implemented. Features which are long overdue
and unlikely to get implemented without some kind of funding.

Re: Kickstarter for Emacs

[Ivan Andrus]

On Apr 18, 2012, at 9:08 AM, Tom wrote:

> I wonder if there be would be enough backers to implement such features
> in emacs. Could it be an alternative model for funding Emacs development?
> (Of course, the code should be GPL and stuff, so it would be released
> to the community when the project is completed.)

How much would it cost me to get the python modes combined into one?  Ideally being backwards compatible with your python-mode of choice.  This is a perfect project I think because it's a large initial undertaking but no additional maintenance work would be necessary once it's done.  If nothing else we could use the money to pay people to not use different modes.  :-)

Also, when I was working on php, I would have been happy to shell out a little for a better php mode.  I don't remember the details of what I wanted now, but I'm sure there are others who feel the same.  Though I recently read about a new php mode, so maybe this has been taken care of.

Really good support for multiple modes is another that would get lots of backers I think.  I certainly don't have the expertise to even speculate on how hard it would be, but I would be willing to pitch in some money for it if I thought it would actually get done well.  I say that not to disparage mmm-mode and friends, but I think it has to be taken into account at a very low level.

Those are a few of my itches that I think could be funded with this model.  I'm sure scouring EmacsWiki would unearth several more.

-Ivan

RE: Kickstarter for Emacs

[Drew Adams]

> If nothing else we could use the money to pay people to not use 
> different modes.  :-)

Sign me up for that!  I don't use any of the different python modes.

And there are lots of other modes I don't use, which I also wouldn't mind being
paid for continuing to not use.

This is a great idea.

Re: Kickstarter for Emacs

[Richard Stallman]

Funding Emacs improvements in this way is a fine idea.

There are many sites that do this; let's not choose Kickstarter
without considering the others.  In fact, if it is associated with
Amazon, that's a reason to prefer any other.  (See
http://stallman.org/amazon.html.)

Issues to judge by include: does the site require users to run nonfree
Javascript?

Thee is no need to argue now about whether this method will work.
Rather than pretend we can predict such things, it is better simply
to try it and see.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Kickstarter for Emacs

[Andreas Röhler]

Am 18.04.2012 18:08, schrieb Ivan Andrus:
> On Apr 18, 2012, at 9:08 AM, Tom wrote:
>
>> I wonder if there be would be enough backers to implement such features
>> in emacs. Could it be an alternative model for funding Emacs development?
>> (Of course, the code should be GPL and stuff, so it would be released
>> to the community when the project is completed.)
>
> How much would it cost me to get the python modes combined into one?


As far as shipped python.el reaches, python-mode.el follows it's path and provides it's features.
Most of python.el is merged, so it's basically a subset of python-mode.el now.

The diff in short is twofold:

- python-mode.el delivers much more, finer grained commands. Have a look at the menu.
- python-mode.el allows to specify a full path/to/local/Python --also on the fly--, instead of the need
  to customize default shell again and again. Should allow to switch easily between virtualenvs.


Andreas

--
http://launchpad.net/python-mode
http://launchpad.net/s-x-emacs-werkstatt/

[ ... ]

Re: Kickstarter for Emacs

[aaditya sood]

Ivan Andrus <darthandrus <at> gmail.com> writes:

>How much would it cost me to get the python modes combined into one?
>Ideally being backwards compatible with your python-mode of choice.
>This is a perfect project I think because it's a large initial
>undertaking but no additional maintenance work would be necessary once
>it's done.  If nothing else we could use the money to pay people to
>not use different modes.

I would happily contribute $200 towards project for out-of-box python
completion and structure parsing. Semantic and cedet, while great, are
slow for large projects and make emacs perceptively slow.

>Really good support for multiple modes is another that would get lots
>of backers I think.  I certainly don't have the expertise to even
>speculate on how hard it would be, but I would be willing to pitch in
>some money for it if I thought it would actually get done well.  I say
>that not to disparage mmm-mode and friends, but I think it has to be
>taken into account at a very low level.

This is another pet peeve. Especially for writing html with css,
javascript and mako.  nxhtml-mode is pretty cool, but again makes
emacs slow. I'd like some support in core emacs, which would be
hopefully faster.

--
aaditya

Re: Kickstarter for Emacs

[Andreas Röhler]

Am 18.04.2012 21:04, schrieb aaditya sood:
> Ivan Andrus<darthandrus<at>  gmail.com>  writes:
>
>> How much would it cost me to get the python modes combined into one?
>> Ideally being backwards compatible with your python-mode of choice.
>> This is a perfect project I think because it's a large initial
>> undertaking but no additional maintenance work would be necessary once
>> it's done.  If nothing else we could use the money to pay people to
>> not use different modes.
>
> I would happily contribute $200 towards project for out-of-box python
> completion and structure parsing. Semantic and cedet, while great, are
> slow for large projects and make emacs perceptively slow.
>

the first is already in the pipe, with several bug-reports around.

As for the structure parsing some specification is useful.

Please make a Blueprint for your requests at

https://blueprints.launchpad.net/python-mode

Thanks,

Andreas


>> Really good support for multiple modes is another that would get lots
>> of backers I think.  I certainly don't have the expertise to even
>> speculate on how hard it would be, but I would be willing to pitch in
>> some money for it if I thought it would actually get done well.  I say
>> that not to disparage mmm-mode and friends, but I think it has to be
>> taken into account at a very low level.
>
> This is another pet peeve. Especially for writing html with css,
> javascript and mako.  nxhtml-mode is pretty cool, but again makes
> emacs slow. I'd like some support in core emacs, which would be
> hopefully faster.
>
> --
> aaditya
>
>
>

Re: Kickstarter for Emacs

[Phil Hagelberg]

On Wed, Apr 18, 2012 at 7:57 AM, Tom <adatgyujto@gmail.com> wrote:
> People are willing to pay if they care about the goal. Maybe we
> should find out somehow what the features are which Emacs users
> most want to see implemented. Features which are long overdue
> and unlikely to get implemented without some kind of funding.

I'd happily contribute money to the development of the concurrency
branch, the xembed work, or immutable strings/data structures.

-Phil

Re: Kickstarter for Emacs

[Bastien]

Hi Tom,

Tom <adatgyujto@gmail.com> writes:

> Vyacheslav Gonakhchyan <ytriffy <at> gmail.com> writes:
>
>>  Ok, good example. It can fly if it will get enough
>> visibility(perhaps on slashdot).But what about support? Emacs
>> and Java are constantly in development.New version will come
>> out and additional work will be required. Another kickstarter
>> might be a solution,
>
> Code maintenance is easier. The hard task is implementing the feature
> itself. 

The relevant distinction to use here might not be easy vs. hard, but
boring vs. fun instead.  Using this distinction, maintainance is often
boring while developing new features is often fun (and more rewarding).
It is hard to get people paid for doing funny things while others are
not paid for doing boring stuff that the funny ones depend on.

I think that's the real challenge here.

But there have been good advice in this thread:

- enhance https://my.fsf.org/associate/donate/working-together to
  mention more GNU projects;

- try funding a new Emacs feature through a kickstarter-like system.

I hope someone will be bold enough to get one of these things done!

-- 
 Bastien

Re: Kickstarter for Emacs

[Richard Stallman]

    Maybe the FSF donation system linked above should be enhanced adding;

I will show the suggestion to FSF people.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Kickstarter for Emacs

[Richard Stallman]

    (1) Don't underestimate the visibility a site like Kickstarter or
    IndieGoGo provides.

That visibility is useful for some sorts of activities -- those whose
potential supporters are more likely to look at the crowdfunding site
than to be contactable by the project.

Is it likely that Emacs development would excite people who happen
upon it in such a site?  Or would most of the funds come from people
told about the project by the FSF?  I expect the latter.

Maybe it is possible to try both a site and direct donation.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Kickstarter for Emacs

[Chong Yidong]

Ivan Andrus <darthandrus@gmail.com> writes:

> How much would it cost me to get the python modes combined into one?

We cannot use python-mode.el because its copyright is not assigned to
the FSF.

The good news is that Fabian Gallina's python.el, which apparently works
extremely well, is landing in trunk soon.

Re: Kickstarter for Emacs

[Andreas Röhler]

Am 19.04.2012 03:50, schrieb Chong Yidong:
> Ivan Andrus<darthandrus@gmail.com>  writes:
>
>> How much would it cost me to get the python modes combined into one?
>
> We cannot use python-mode.el because its copyright is not assigned to
> the FSF.
>

All people are free to use it, as it GPL v3

If GPL is not good enough, what a kind of signal does it send?

Cheers

> The good news is that Fabian Gallina's python.el, which apparently works
> extremely well, is landing in trunk soon.
>
>

Re: Kickstarter for Emacs

[Tom]

Eric Schulte <eric.schulte <at> gmx.com> writes:

> 
> Maybe the FSF donation system linked above should be enhanced adding;
> 
> 1. increased donation granularity to specific features tasks or bugs,
> 
> 2. user (not-developer) introduction of projects of interest, e.g., "if
>    someone did X I'd happily donate Y" and an up-vote or up-donate
>    driven system of ranking and displaying pledges.
> 

Maybe it should be a simple feature voting system from the user side,
because processing the actual donations (taking them, refunding them
if not enough people actually donates for the feature, etc) is
complicated, and not likely to be implemented quickly.

So this feature could only be about getting an idea how many people
want a particular feature, and when developers see what people
actually want then they could start the actual proposals on one
of the mentioned funding sites by describing eactly what they want
to implement, how much time will it take and how much funding they
need for this, etc.

This simple feature voting system (without payment processing)
is easier to implement on the FSF side, so it's more likely we have
something useful working quickly.

BTW, why not use Google Moderator for this kind of feature voting?
It does exactly this after all: people send in submissions and
other people can vote for the submissions:

https://sites.google.com/site/moderatorhelpcenter/getting-started/guide

Re: Kickstarter for Emacs

[Jambunathan K]

Restricting ourselves to just GNU Emacs (and packages that land in GNU
ELPA),

I think it will be simpler to exploit existing infrastructure.

There is already a bug tracker.  What is possibly missing is 

1. Surface bugs on based on user's perception and needs
2. A way for sponsors to register themselves.

Item 1, could serve as one of the inputs to maintainers to establish
roadmap for the next release (or to dole out GSoC projects)

Item 2, could help an enterprising developer to approach the sponsors
directly.

The real issue is of discovery of feature/people.  (Theoretically
speaking), debbugs or debbugs-based infrastructure could be used for
that.

There is an implicit assumption that (all) transactions between people
should be mediated by (institutions) necessarily.  It need not be so.
-- 

[PROPOSAL] GSoC-like campaingn for FSF/GNU projects

[Jambunathan K]

I think FSF can launch and manage it's own variant of Google Summer Of
Code.

This will ensure that FSF/GNU projects not only get regular, useful
contributions but also gain traction among the young.  

From individual project side, such a campaingn will enable yearly
stock-taking 

Within the GNU umbrella, it can serve as a clearing house for /active/
projects and related tasks.
-- 

Re: Kickstarter for Emacs

[Nikodemus Siivola]

On 19 April 2012 03:45, Richard Stallman <rms@gnu.org> wrote:

> Is it likely that Emacs development would excite people who happen
> upon it in such a site?  Or would most of the funds come from people
> told about the project by the FSF?  I expect the latter.

Neither. Most successful crowdfunding projects get most of their
publicity in a viral manner. Most of the funds would come from Emacs
users who have no contact with FSF, but read about it on some blog
they follow, on Twitter, Facebook, on a mailing lists, etc -- by their
someone who has donated and is excited about it.

That would be my guess, anyways.

The is-it-worth it isn't about most people, though, but about getting
+10% extra $donations or not. More than that and it's a good deal.

I would also /strongly/ suspect that while FSF itself could probably
run a successful crowdfunding campaign to fund it's activities in
general, that for a specific software project the more it is about the
individual developer(s) wanting to implement Their Thing and the less
it is about FSF, the more chance of success it has.

Not because some people don't like FSF, but because they want to give
money to the people who write the code.

Apropos: IndieGoGo is open to non-American fundraisers, unlike
Kickstarter, and uses PayPal instead of Amazon as the payment
processor. (Maybe there was also a direct bank deposit option, I
forget.) There are some other differences as well, but those are the
biggest ones.

Cheers,

 -- Nikodemus

Re: Kickstarter for Emacs

[Richard Riley]

Tom <adatgyujto@gmail.com> writes:

> Tassilo Horn <tassilo <at> member.fsf.org> writes:
>> 
>> Not sure how well that works right now, but that might be a rather cheap
>> option to catch up on Java support in Emacs.  The downside of this
>> approach is of course that you still need Eclipse...
>
> Yes, this is also an option which needs much less time to effort
> to implement, though I think people were much less likely to fund
> such a solution if they would still need to use Eclipse. 
>
> So this implementation would be more like a best effort, "working on it
> in my free time" version than full time, crowdfunded version.
>

In addition, like JDE, its more theory than practice and I had
considerable difficulty anyone who actually had it working and actively
used it. And gave up. Java support in Emacs isn't at the same level as
other languages, that's for sure.

Re: Kickstarter for Emacs

[Rasmus]

Chong Yidong <cyd@gnu.org> writes:

> The good news is that Fabian Gallina's python.el, which apparently works
> extremely well, is landing in trunk soon.

That is indeed /very/ good news!  Fabian's python.el works very well and
when I had to find a Python mode last year it worked better for me than
both the shipped python.el and python-mode.el.

Thanks,
Rasmus

-- 
When the facts change, I change my mind. What do you do, sir?

Re: Kickstarter for Emacs

[Ivan Andrus]

Forgot to reply to the list.

On Apr 19, 2012, at 3:50 AM, Chong Yidong wrote:

> Ivan Andrus <darthandrus@gmail.com> writes:
> 
>> How much would it cost me to get the python modes combined into one?
> 
> We cannot use python-mode.el because its copyright is not assigned to
> the FSF.
> 
> The good news is that Fabian Gallina's python.el, which apparently works
> extremely well, is landing in trunk soon.

Gaaa!  Will it be replacing the current python.el?  In a backwards compatible way?  

The reason I ask is that I help maintain sage-mode [1] which is based on the current python.el.  However, I know some people like python-mode.el, so I would like to support it.  But I'd rather not add a whole compatibility layer myself.  Not to mention that the two cannot coexist in a single Emacs since they both define `python-mode'. I fail to see how adding YAPM is going to help my situation.  A similar situation occurred why I and others tried to add python support to expand-region [2].  They finally got something working but it was more trouble that it needed to be.

Of course, I will probably have about as much success asking that Emacs and XEmacs merge.  :-)

-Ivan

[1] https://bitbucket.org/ncalexan/sage-mode
[2] https://github.com/magnars/expand-region.el

Re: [PROPOSAL] GSoC-like campaingn for FSF/GNU projects

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> I think FSF can launch and manage it's own variant of Google Summer Of
> Code.

+1

Of course, this might not be financially reasonable, I don't know.

FWIW, this is something I suggested to FSF when they asked members 
for ideas, a while ago.  We never got feedback on this wide feedback
request, btw.

-- 
 Bastien

Re: Kickstarter for Emacs

[Richard Stallman]

    Maybe it should be a simple feature voting system from the user side,

I don't think it is worth the trouble.  When maintainers would like
guidance from users about features, it is easy enough for them to ask
the users.

When we do polls about Emacs features, we don't interpret the results
by simple counting of votes.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: [PROPOSAL] GSoC-like campaingn for FSF/GNU projects

[Richard Stallman]

    I think FSF can launch and manage it's own variant of Google Summer Of
    Code.

Are you offering to do the work?

The FSF staff are overloaded.  Even supposing we succeed in raising
funds for this, it would be hard to carry it out.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Kickstarter for Emacs

[Richard Stallman]

    > Is it likely that Emacs development would excite people who happen
    > upon it in such a site?  Or would most of the funds come from people
    > told about the project by the FSF?  I expect the latter.

    Neither. Most successful crowdfunding projects get most of their
    publicity in a viral manner. Most of the funds would come from Emacs
    users who have no contact with FSF, but read about it on some blog
    they follow, on Twitter, Facebook, on a mailing lists, etc -- by their
    someone who has donated and is excited about it.

You may be right, but it does not affect this question.
It is a multiplier on both sides.

If X people find out through our announcements and Y people through
the crowdfunding site, and if each of them directly or indirectly
leads to a total donation of M from themselves and various people they
inform, the total will be M (X + Y).  A large value of M is good, but
the question here is about how X and Y compare.

    I would also /strongly/ suspect that while FSF itself could probably
    run a successful crowdfunding campaign to fund it's activities in
    general, that for a specific software project the more it is about the
    individual developer(s) wanting to implement Their Thing and the less
    it is about FSF, the more chance of success it has.

    Not because some people don't like FSF, but because they want to give
    money to the people who write the code.

Maybe we are miscommunicating.  I am comparing two different ways to
inform people they can give money to developers to write a particular
change.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Kickstarter for Emacs

[Tom]

Richard Stallman <rms <at> gnu.org> writes:

> 
>     Maybe it should be a simple feature voting system from the user side,
> 
> I don't think it is worth the trouble.  When maintainers would like
> guidance from users about features, it is easy enough for them to ask
> the users.
> 

It's not about getting feature ideas. It's about getting an idea
about how much people want a certain feature implemented to find
out if it's worth to start a fundraising project for that feature.

If we had a feature voting system then we'd have a top list of 
the most wanted features which are most likely to get funded by users
if a fundraising is started.

So when Emacs users/developers come up with a feature idea and after
discussing on this list it seems like a worthwhile idea then it could
be entered into this idea listing system and users could vote on this
and other ideas to create the list of most wanted unimplemented
features (like multithreading, etc.)

Re: Kickstarter for Emacs

[Stefan Monnier]

> I'd happily contribute money to the development of the concurrency
> branch, the xembed work, or immutable strings/data structures.

Curious: what do you expect "immutable strings/data structures"
to provide?


        Stefan

Re: Kickstarter for Emacs

[Stefan Monnier]

>>> How much would it cost me to get the python modes combined into one?
>> We cannot use python-mode.el because its copyright is not assigned to
>> the FSF.
>> The good news is that Fabian Gallina's python.el, which apparently works
>> extremely well, is landing in trunk soon.
> Gaaa!  Will it be replacing the current python.el?

Yes.

> In a backwards compatible way?

Hopefully, yes.  Fabian has not been particularly careful about that
aspect (e.g. lots of "gratuitous" renamings), so my "yes" really means
"backward incompatibilities will likely show up but will be treated as
bugs to the extent possible".

I.e. keep your eyes open for when the python.el changes and report any
problem so we can fix them promptly.  Or maybe even ask try it out right
away (https://github.com/fgallina/python.el) and work it out
with Fabian.


        Stefan

Re: Kickstarter for Emacs

[Ivan Andrus]

On Apr 20, 2012, at 12:07 AM, Stefan Monnier wrote:

>>>> How much would it cost me to get the python modes combined into one?
>>> We cannot use python-mode.el because its copyright is not assigned to
>>> the FSF.
>>> The good news is that Fabian Gallina's python.el, which apparently works
>>> extremely well, is landing in trunk soon.
>> Gaaa!  Will it be replacing the current python.el?
> 
> Yes.
> 
>> In a backwards compatible way?
> 
> Hopefully, yes.  Fabian has not been particularly careful about that
> aspect (e.g. lots of "gratuitous" renamings), so my "yes" really means
> "backward incompatibilities will likely show up but will be treated as
> bugs to the extent possible".

Excellent.  You just made my day!  :-)

> I.e. keep your eyes open for when the python.el changes and report any
> problem so we can fix them promptly.  Or maybe even ask try it out right
> away (https://github.com/fgallina/python.el) and work it out
> with Fabian.

I'll definitely keep my eyes open.  And if I have some time I'll install his version now.  My python usage tends to go in spurts though.

-Ivan

Re: Kickstarter for Emacs

[Phil Hagelberg]

On Thu, Apr 19, 2012 at 2:02 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I'd happily contribute money to the development of the concurrency
>> branch, the xembed work, or immutable strings/data structures.
>
> Curious: what do you expect "immutable strings/data structures"
> to provide?

I have been thinking about implementing egal from Henry Baker's famous
equality paper[1] in Emacs Lisp, but it is not very practical unless
you can make certain guarantees of immutability. Knowing that two
mutable strings are currently equal is not nearly as useful as knowing
that they will always be equal, and indeed in a concurrent setting is
hardly useful at all. Being able to construct a list or string that is
a stable value (that is, guaranteed not to change) allows you to write
code that is referentially transparent and thus much easier to
understand and maintain.

But then again, there is so much extant code that works in terms of
mutable strings and lists that interoperating between pure code and
mutable-friendly code might be too burdensome. I was thinking about
immutability primarily in the context of a compiler that could target
Emacs Lisp, which is probably crazy. =)

-Phil

[1] - http://home.pipeline.com/~hbaker1/ObjectIdentity.html

Re: Kickstarter for Emacs

[Stefan Monnier]

>>> I'd happily contribute money to the development of the concurrency
>>> branch, the xembed work, or immutable strings/data structures.
>> Curious: what do you expect "immutable strings/data structures"
>> to provide?
> I have been thinking about implementing egal from Henry Baker's famous
> equality paper[1] in Emacs Lisp, but it is not very practical unless
> you can make certain guarantees of immutability.

My own local hacked version of Emacs has aset signal an error when
called on a string (and subst-char-in-string also signals as error when
called with `inplace').  I rarely bump into problems because of
this change.
But note that strings include text-properties, and I still allow those
to be changed.  Making them immutable would break more code (since
until `propertize' was added, all the text-properties were manipulated
by side-effects).
Now, `equal' does not pay attention to strings's text-properties, so
maybe my limited immutability would be good enough for `egal' (which is
really what we call `eql' if you think about it).

For `cons' cells, side-effects are used much too often in Elisp,
I wouldn't hold much hope for making them immutable.  So immutable cells
would have to be a new type (and car/cdr could be made to work with
them as well) with a new constructor (maybe named `icons' or `pair').

The problem still remains: what would be the benefit?


        Stefan

Re: Kickstarter for Emacs

[Phil Hagelberg]

On Fri, Apr 20, 2012 at 7:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> My own local hacked version of Emacs has aset signal an error when
> called on a string (and subst-char-in-string also signals as error when
> called with `inplace').  I rarely bump into problems because of
> this change.
> But note that strings include text-properties, and I still allow those
> to be changed.  Making them immutable would break more code (since
> until `propertize' was added, all the text-properties were manipulated
> by side-effects).

Very interesting! Now that I think of it I haven't actually seen any
code that destructively updates strings other than text-properties as
you say. But given that equality already doesn't take these into
account, this is probably OK. In fact, Baker's paper addresses this
notion directly: "Obviously, material properties--being
contingent--cannot contribute to an object's identity, while formal
properties--being necessary--are an inherent part of an object's
identity."

I'd be interested in trying this patch if you could share it. Are you
fairly sure that those are the only existing functions which can
change the value of a string?

> For `cons' cells, side-effects are used much too often in Elisp,
> I wouldn't hold much hope for making them immutable.  So immutable cells
> would have to be a new type (and car/cdr could be made to work with
> them as well) with a new constructor (maybe named `icons' or `pair').

Indeed; this is a stickier issue. While I wouldn't expect it to be
feasible to change the default, the availability of a separate type of
cons cell upon which destructive operations could not act would be
wonderful provided the nondestructive list operations would still
work. I wonder if it wouldn't be possible to set a file-local variable
that could make the reader return immutable lists while loading that
file, much like the way lexical scoping was introduced in an opt-in
way to reduce breakage.

> The problem still remains: what would be the benefit?

I must confess this is difficult for me to express, simply because
it's something I've taken for granted for so long; it's like being
asked why I like garbage collection. Anyhow, the most obvious benefit
would be that you have a chance at writing code that you know will
function correctly while run concurrently. =)

But while the reduced complexity of referentially transparent
functions is subtler (and more difficult to explain without trying it
for yourself), I think it's no less compelling. The idea that you can
hand an argument to a function and not have to consider whether it's
going to change relieves you of a fair amount of needless mental
overhead while coding and makes certain classes of bugs impossible.
Essentially you can eliminate the difference between call-by-value and
call-by-reference. You can't write referentially transparent functions
that treat mutable objects as equivalent, because these functions will
not always return the same value when called with the same arguments
at different times.

The other benefit of immutable objects is that it allows you to do
away with the confusing eq/eql/equal distinction. This is the main
point of Baker's paper. He makes a compelling case that the usefulness
of hash tables in CL (and Elisp by extension) are severely limited by
having to pick a test function up-front. If you pick a test that is
too fine-grained (like eq or eql), then you are unable to use things
like strings as keys, but if you pick a test that is too coarse like
equal, then you will have false positives when you pass in a different
list that happens to have the same value at the time of the call. The
presence of immutable values allows you to define an equality
predicate that works in terms of operational equivalence, which is far
more useful.

Of course, in a way this amounts to turning Elisp into a functional
language, or possibly a language in which "mostly functional"
programming is encouraged. You could argue that it would be turning
Elisp into something that it isn't; perhaps this is fair. (I can just
go back to writing my Clojure code, but I really like Emacs as a
runtime.) Maybe I should just wait for Guile to gain the capability to
run Elisp, since that would be another way to achieve this goal. I'm
not sure it's the right thing for Emacs given the constraints of
legacy code and the limited time of its developers, but I am fairly
convinced it's a better design for languages in general.

-Phil

Guile based Elisp faster? (was Re: Kickstarter for Emacs)

[Thorsten]

Phil Hagelberg <phil@hagelb.org> writes:

> Maybe I should just wait for Guile to gain the capability to
> run Elisp, since that would be another way to achieve this goal. 

Will Elisp become faster when Guile runs it? Yesterday I did a little
speed comparision between my two favorite Lisps (Elisp and PicoLisp) and
Elisp did not perform that good (even when compiled). See
http://picolisp.com/5000/!wiki?PILvsEL.

-- 
cheers,
Thorsten

Re: Kickstarter for Emacs

[Tassilo Horn]

Steinar Bang <sb@dod.no> writes:

Hi Steinar,

>> Not sure.  Just having Eclipse installed doesn't bother me too much.
>> Having it running and consuming memory/CPU doesn't bother me, too.
>> What really bothers me is that even when using Eclipse with its Emacs
>> keybinding scheme enabled, it's still hard to use.
>
> After a quick try, I decided to skip the emacs keybindings.  It masked
> Ctrl-SPC, which is possibly the most important keybinding in eclipse
> (and I didn't stay with the emacs keybinding long enough to find out
> what, if anything the content assist command was bound to).

I've set

  Word Completion       Alt+/   Editing Text    Edit

in Preferences > General > Editors > Keys to have M-/ as completion key
just like dabbrev-expand in emacs.  (Word completion is the "good"
I-know-Java-completion in java files.)

>> I want my kill-ring, I want keyboard macros, I want my isearch, etc...
>
> So did I.  So what I ended up doing, was to use emacsclient as an
> editor in eclipse, and when I wanted to do editing in emacs (typically
> advanced search and replace, or use keyboard macros for complex
> repetitive tasks) then I used emacsclient to get the file into emacs
> for editing.

Yes, ditto.  But not so convenient...

Bye,
Tassilo

Re: Kickstarter for Emacs

[Steinar Bang]

>>>>> Tassilo Horn <tassilo@member.fsf.org>:

> Not sure.  Just having Eclipse installed doesn't bother me too much.
> Having it running and consuming memory/CPU doesn't bother me, too.  What
> really bothers me is that even when using Eclipse with its Emacs
> keybinding scheme enabled, it's still hard to use. 

After a quick try, I decided to skip the emacs keybindings.  It masked
Ctrl-SPC, which is possibly the most important keybinding in eclipse
(and I didn't stay with the emacs keybinding long enough to find out
what, if anything the content assist command was bound to).  

Also, in my experience it's always easier to go with the default
keybindings for all programs.  They it's easier to ask for assistance,
or google up information.

> I want my kill-ring, I want keyboard macros, I want my isearch, etc...

So did I.  So what I ended up doing, was to use emacsclient as an editor
in eclipse, and when I wanted to do editing in emacs (typically advanced
search and replace, or use keyboard macros for complex repetitive tasks)
then I used emacsclient to get the file into emacs for editing.

I did most of my version control work in emacs.

Re: Kickstarter for Emacs

[Stefan Monnier]

>> The problem still remains: what would be the benefit?
> I must confess this is difficult for me to express, simply because
> it's something I've taken for granted for so long; it's like being
> asked why I like garbage collection. Anyhow, the most obvious benefit
> would be that you have a chance at writing code that you know will
> function correctly while run concurrently. =)

I'm an academic working in functional programming and type systems, so
you don't have to convince me of the general virtues of
side-effect-free code.

So my question is specifically in the context of Emacs where you need to
balance the theoretical benefits against the downsides (mostly
incompatibilities and efforts that could be spent elsewhere).


        Stefan

Re: Guile based Elisp faster?

[Andy Wingo]

On Mon 23 Apr 2012 10:17, Thorsten <quintfall@googlemail.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>
>> Maybe I should just wait for Guile to gain the capability to
>> run Elisp, since that would be another way to achieve this goal. 
>
> Will Elisp become faster when Guile runs it?

I think the current status is that the performance is similar.  However,
as Guile performance improves, we expect ELisp performance to improve as
well.

> Yesterday I did a little speed comparision between my two favorite
> Lisps (Elisp and PicoLisp) and Elisp did not perform that good (even
> when compiled). See http://picolisp.com/5000/!wiki?PILvsEL.

You can check out the "master" branch of Guile and try this with ,L
elisp.  It performs OK.

Regards,

Andy
-- 
http://wingolog.org/

Re: Guile based Elisp faster?

[Thorsten Jolitz]

Andy Wingo <wingo@pobox.com> writes:

> On Mon 23 Apr 2012 10:17, Thorsten <quintfall@googlemail.com> writes:
>
>> Phil Hagelberg <phil@hagelb.org> writes:
>>
>>> Maybe I should just wait for Guile to gain the capability to
>>> run Elisp, since that would be another way to achieve this goal. 
>>
>> Will Elisp become faster when Guile runs it?
>
> I think the current status is that the performance is similar.  However,
> as Guile performance improves, we expect ELisp performance to improve as
> well.
>
>> Yesterday I did a little speed comparision between my two favorite
>> Lisps (Elisp and PicoLisp) and Elisp did not perform that good (even
>> when compiled). See http://picolisp.com/5000/!wiki?PILvsEL.
>
> You can check out the "master" branch of Guile and try this with ,L
> elisp.  It performs OK.

Most of the time Emacs is really 'snappy' (is that the right English
word?) - everything responds immediatly and fast. So it seems the raw
execution speed often doesn't really matter. However, its nice to know
where the limits are. Good to hear that there is some momentum towards
more speed for Elisp.

-- 
cheers,
Thorsten

Re: Kickstarter for Emacs

[Phil Hagelberg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The problem still remains: what would be the benefit?
>> I must confess this is difficult for me to express, simply because
>> it's something I've taken for granted for so long; it's like being
>> asked why I like garbage collection. Anyhow, the most obvious benefit
>> would be that you have a chance at writing code that you know will
>> function correctly while run concurrently. =)
>
> I'm an academic working in functional programming and type systems, so
> you don't have to convince me of the general virtues of
> side-effect-free code.
>
> So my question is specifically in the context of Emacs where you need to
> balance the theoretical benefits against the downsides (mostly
> incompatibilities and efforts that could be spent elsewhere).

I guess the main specific benefit (beyond the general "easier to write
functions you know are correct") is that once you introduce concurrency,
you will need a way to share data between different threads. Shared
mutable state is very very difficult to get right; in order to avoid
race conditions you must construct complex, error-prone, and
non-composable locking strategies and adhere to them rigidly.

Another option of course would be to force all cross-thread
communication to go through channels that cause data to be copied, but
this would probably feel unnatural and would be difficult to enforce in
addition to being more expensive.

The benefit in Emacs as it is today might not be too clear, but I
believe this to be an important step to take as we move into the
concurrent world.

-Phil

Re: Kickstarter for Emacs

[Jordi Gutiérrez Hermoso]

On 18 April 2012 04:59, Chong Yidong <cyd@gnu.org> wrote:
> (OT: I believe Octave's maintainer is supported by donations, so I
> strongly encourage anyone who uses that software to donate.)

We don't get a whole lot from donations, but we do get a little. The
big bucks are in contracts to implement this or that feature, which do
come by once in a while.

HTH,
- Jordi G. H.