[slime] the inspector doesn't run the swank side in the initiating thread (#12)

[Helmut Eller]

On Sat, Jan 04 2014, João Távora wrote:

> Helmut Eller <notifications at 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