September/October/November is definitly the best season of the year. New iOS, Android L, OSX, Ubuntu and of course Emacs :) i hope i'm not missing anything.
So far Emacs has been, for many users, nice abstraction over the OS. As soon as I'm not able to use the same packages and have the same setup on both Linux and Windows, I won't use it anywhere and start looking at the alternatives.
The purpose of this is not to limit functionality to a specific platform, it's to expand the capabilities of Emacs. My understanding is FFI is intended to work on all platforms that Emacs support, so it just means the library authors need to provide platform specific support, just the same as they do with packages that depend on specific binaries in the path.
Throwing out a new feature that provides obvious benefits because of imagined future packages that may choose against being platform agnostic seems rather short sighted.
Wait, I thought RMS is very strongly opposed to this?
Eben is just about the only legal advice that rms will really listen to. If something like this could be done and Eben convinces rms about this, this may ease his (in my opinion) well-founded fears against proprietary Emacs extensions.
> Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs I had just finished implementing Common Lisp, and I did not like it much. It would bloat Emacs terribly, and documenting it would be hard too.
> Scheme is elegant, and it is a better direction to move in.
> Since we have our own Scheme implementation, we should use that one. If it has a serious disadvantage, we should do something about that. There are various things that might be right to do, but simply disregarding it in the case of Emacs cannot be right.
That's 15 years of talking. My personal feeling is that sometimes it's just better to abandon projects that stagnate. There's an open source Go version of Sublime, for example. It would probably be easier to maintain.
That's throwing the baby out with the bathwater. The only thing which makes Emacs-on-Guile difficult is backwards compatibility. If you find Sublime a viable option, then compatibility isn't an issue for you; in which case there's nothing preventing you from using Emacs-on-Guile right now.
It has reached an odd place, there is enough legacy code (or so it's believed) that it can't be abandoned, there are clear innovations that will never go in to elisp (jit compilation, threads, Ffi, etc) and guile isn't being accepted while it is clearly the best way forward that has been suggested. It's like emacs is done.
Considering something else only makes sense...
As with any corporate product, you can't go changing shit when you have a large paying userbase.
That said, there's a lot of information here that's very useful for the starting Elisp programmer.
I don't see how these are evidence of the author having "CL background". CL is pretty much identical to Emacs lisp with regards to both of these things.
Since 1996, Emacs was a kind of IDE replacement when I was in UNIX environments and could not use my beloved MS-DOS/Windows IDEs, but nowadays UNIX systems also enjoy quite powerful IDEs.
Why can't we have a kickstarter campaign for providing funds to develop a real plan of execution for this?
Without a real plan forward, I see Guile realistically taking another 5-10 years, making it a 20-25 year long proposal.
It's not necessarily easy for an open source project to translate money into engineers. A pot of donated cash in the bank doesn't mean that the existing developers have any more time to work on the project, or that somebody new with the right skills and experience with the codebase magically appears. If one or more project members happen to be consultants who can use the money to spend six months working on Guile rather than on some other paid engagement that's one thing; but the amount of money required to make "quit your full time job to work on the project" financially sensible is prohibitively larger.
I can add that for some projects, funding is useful to acquire the hardware and infrastructure to host the project: code hosting, build servers, test machines, bandwidth... However I doubt this is Guile's constraint.
My suggestion is to just keep that momentum going, year around. I know about the mythical man-month, etc, but in this case, some of this low-hanging fruit can be financed.
-  http://lwn.net/Articles/615347/
-  http://www.emacswiki.org/emacs/GuileEmacsTodo
-  https://www.google-melange.com/gsoc/project/details/google/g...
I don't know about that; it sounds very much like dynamic variables. It's usual in a Common Lisp implementation to give each thread its own set of dynamic variables (indeed, that's close to the only sane thing to do); I can't offhand see why it would make sense just to treat buffer-local variables similarly. But perhaps there're some semantics I'm not familiar with.