* Helmut Eller m263lhg14b.fsf@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