[slime-devel] text properties in REPL

[Madhu]

* Helmut Eller <m263lhg14b.fsf at common-lisp.net> :
Wrote on Thu, 18 Dec 2008 12:43:16 +0100:

| * Madhu [2008-12-17 04:33+0100] writes:
|
|> How about a global switch which would be checked before propertising any
|> string in SLIME?
|
| That's not easy to do because some commands wouldn't work without text
| props.
|
|> I'm facing emacs rendering-speed issues so I'm asking.  And its not like
|> you can do M-x font-lock-mode and turn display properties off
|
| I think that text properties have only a small impact on rendering
| speed.  We shouldn't optimize this before we actually know that the
| problem is caused by text props.

In this case it was just output to the repl. I disabled all repl text
properties and this made things reasonably.fast.


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

SLIME history is one example of idiosyncratic behaviour which was
introduced which has no parallel in any emacs application I've seen.

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

--
Madhu