* michaelw+slime@foldr.org 995BC906-2C23-4069-88CD-E2F0BBD9401F@foldr.org : Wrote on Fri, 19 Dec 2008 09:20:46 +0100:
| On Dec 19, 2008, at 01:56 , Madhu wrote: | |> | slime.el is already beyond the 10000 LOC limit and I'm more |> | interested to bring that down to 9000 than to add more stuff. |> |> The specific proposal here was to factor out completion, history |> etc. so they can either use vanilla emacs facilities instead of the |> idiosyncractic behaviour you happened to code up and impose on us. |> |> This is not the first time you are ignoring the point made and |> sticking to your views. However I don't mind persisting because the |> intention and hope is SLIME should improve. |> |> | It would be more effective if you would make a proposal how to |> | reduce the number of lines instead of the usual complaining how bad |> | SLIME is. | | the "specific proposal" could be in the form of you setting up a | fork. You can show, in code, how you would like to see SLIME behave, | and others have the chance to try it out and also to contribute. When | there is something to compare, we can think of how to fold it back | into SLIME.
No, I do not believe this warrants a fork. The alternate behaviour is also not interesting. The specific propsal here was to move these two components out of slime.el so there can be drop in replacements which could be maintained separately.
It is not hard to checkout SLIME, hit something which is irritating, and rewrite the code to fit your needs. (You don't hear from me everytime I do that, and I expect every emacser does it). What is harder is updating SLIME to find the code you rewrote is gone and replaced by something that not only does not fit your need; but now to get the old behaviour back, you have to rip out what is new and reintroduce the old code. [<- maybe exagerrated but its to make the point]
When this happens for a whole component, I believe it is reasonable to factor that component out after defining the minimal API with which it is being called.
Let me cite another program I use: the DWM project places minimal SLOC above all else as the most important metric. But there the mainline is maintained in a sucha a way that it is (mostly) possible to add all other behaviours/features cleanly on top of it as patches. I'm asking for that sort of faciliation in SLIME.
| FWIW, I have no complaints about the history behavior,
[Mostly I have no complaints, except when I do, and then I have to fix it each time. History search, via M-r loses position in the history list. M-n M-p will repeat the search but will not let you refine the search string. I've tried explaining this before and offered moving this out of slime]
| but sometimes the completion and window handling gets into my way, | too. I have some local adjustments in place for quite some time now. | I don't actually know how much different vanilla SLIME is still. They | are rather ad- hoc (not configurable) but a VCS (in my case a clone of | Andreas Fuchs' git mirror) makes maintenance of my changes quite | painless.
-- Madhu