[slime-devel] text properties in REPL

[Madhu]

* Helmut Eller <m2zlit8e6a.fsf at common-lisp.net> :
Wrote on Thu, 18 Dec 2008 20:40:45 +0100:

|> |> Also, any hope of REPL history behaviour getting reverted so it works
|> |> like minibuffer history, especially for searching?
|> |
|> | The probability for that is almost zero.
|>
|> Then how about making it easier for alternative implementations to be
|> used instead of the one that is provided with slime? 
|
| You can rebind every key and overwrite every function in Emacs.  How
| much easier could it be?

Indeed and which is the saving grace for EMACS.  If I don't like
something I can change it.

|> SLIME history is one example of idiosyncratic behaviour which was
|> introduced which has no parallel in any emacs application I've seen.
|
| I guess you mean the bit that we take the initial search string from the
| current input.  I'm pretty sure that that wasn't our idea but existed
| somewhere else before.  Probably in ILISP.

No, I've described the behaviour before in the mailing lists, only to
have you ignore it

|> [*Completion* window handling and restoring window configuration is
|>  another component that should be factored out.  The assumptions made in
|>  implementing this code do not cover most cases I face personally all
|>  the time]
|>
|> Speaking as a longterm and heavy user of slime, the other aspects that
|> were recently overhauled like the Inspector, the debugger,
|> output-display routines have also affected productivity: In the past I
|> was able to whack them into a shape that helped me program lisp
|> smoothly. Getting back the behaviour I want has is getting harder.  As a
|> general observation: Instead of the factoring out of these components
|> I've seen tighter coupling which makes implementing alternative
|> behaviours harder and even harder to maintain local modifications when
|> updating SLIME
|
| I don't understand what your intention with this whining and complaining
| is. 

The only intention is that SLIME ought to improve .

| It's not my goal to support every possible feature and a endless
| number of customization options.

My point is you are hellbent on making it harder by removing existing
infrastructure.

| 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.

You misunderstand.  The complaint is about how your changes to SLIME
have made it harder to recover preexisting functionality.  Not how bad
SLIME is.

--
Madhu