[slime-devel] text properties in REPL

[Madhu]

* michaelw+slime at foldr.org <995BC906-2C23-4069-88CD-E2F0BBD9401F at 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