[slime-devel] text properties in REPL

[Helmut Eller]

* Madhu [2008-12-18 17:05+0100] writes:

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

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

> The implementation you provided is OK, and may be good for first time
> users but I imagine the behaviour gets in the way of using SLIME
> effectively for one already used to or proficient enough with Emacs to
> expect things to adhere to certain UI "standards"
>
> [*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.  It's not my goal to support every possible feature and a endless
number of customization options.  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.  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.

Helmut.