On Sat, Jan 04 2014, João Távora wrote:
Helmut Eller notifications@github.com writes:
On Fri, Jan 03 2014, João Távora wrote:
In any case we should reopen the issue and mark it low priority. It would make nice a feature, whatever the implementation.
I consider this bloat and not a valuable feature.
Helmut,
I assigned the issue to me and reopened it. At the end of this message I explain what I intend to do with it, and will not do any rogue commit or anything.
I really think we should not close off such feature requests with statements of personal preference. While stating opinion is of course OK, closing discussions out of view not only doesn't make the demand go away, but detracts from one of the advantages of the github ecosystem which is attracting hackers that might be willing to do Slime "the sincerest form of code appreciation".
OK, as you wish.
Given the conditions we're in (daily hungry SLIME users), as Luís explained, we are committed to inverting the effective dev stall that Slime has seen in the past years (lately completely dead). We went to some lengths to refrain from forking and keep the general project policies.
I think it's only fair to list at least approximately my personal goals for the project:
All current slime tests should pass in various combinations (this is being worked on currently).
Slime should be installable via ELPA and el-get
Contribs should be completely independent (no need to add their swank files to *CONTRIBS*) and also installable via ELPA and el-get, which both manage dependencies nicely.
Modern emacs coding conventions should be adhered to.
This sounds all good.
I'd also like hear your (and everyone else's) plans for the future of Slime.
My goals are:
* keep maintance effort down, i.e. I don't want to spend my time or have endless discussions on features that I don't actually use
* make it easier for other people to create and cooperate on contribs or features that they care about but are of limited interest to me or the average SLIME user
* continued support for Emacs 23. Using the Emacs version that is in Debian Stable should be as hassle-free as possible.
* There are always some cleanups to do, e.g. the CMUCL backend should finally use Gray streams.
* for the dedicated output stream it would be reasonable to keep the initial port open to avoid some firewall issues. That would also make it easy to open other sockets, which is much more likely to fly than the idea with multiplexed streams on a single connection.
* I would like to compile my Lisp code with makefiles. Maybe SLIME could ship some command line tools to make that easier. This may be outside the scope of SLIME, tho.
Reading through slime.el I agree with you that it is indeed a bit bloated. I'm also commited to cleaning it up. By offloading tests to ert.el for example I relieved slime of 250 lines of test framework. If you look at the diffs you'll see other small refactorings.
Yes, that was good work.
So while I think the patch at hand is hardly bloat (because of its small size), I also agree that Slime's core should grow smaller and offer more consistent interfaces so features like the one requested by Attila can be implemented as contribs. Lets keep this issue open as an attempt to do that, who knows, you might be surprised with less and more maintainable lines of code instead of more.
That would indeed be a surprise.
Helmut