* 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

* Helmut Eller m2skol9vin.fsf@common-lisp.net : Wrote on Thu, 18 Dec 2008 19:40:48 +0100:

| * Madhu [2008-12-18 17:05+0100] writes: | |> In this case it was just output to the repl. I disabled all repl text |> properties and this made things reasonably.fast. | | Have you some repeatable benchmarks?

I could come up with them, but I do not see the point of posting them here. I can come up with 3 different arguments [not based on validity but based on projections of your ego] as to how you can reject them.

-- Madhu

* Helmut Eller m2skokh60z.fsf@common-lisp.net : Wrote on Fri, 19 Dec 2008 10:24:12 +0100:

| * Madhu [2008-12-19 02:00+0100] writes: | |> I could come up with them, but I do not see the point of posting them |> here. I can come up with 3 different arguments [not based on validity |> but based on projections of your ego] as to how you can reject them. | | Your arguments don't prove that text properties have any effect on | rendering speed. If you can't show me reproducible benchmarks I don't | believe it.

Nevertheless it is important to me that I can control whether or not text properties are set.

The current API and is a mess to support this. And the direction you are taking SLIME in with your style of refactoring code does not help.

I understand you believe it makes it easier for you to maintain SLIME but it is at the expense of others maintining other behaviours possible from SLIME, or using it in ways you cannot [because of limitations] imagine or [because of politics] agree with. In effect it makes the work of others working with slime except as end users much harder, while fortifying your own position as maintainer.

-- Madhu

* Helmut Eller m28wpjpokn.fsf@common-lisp.net : Wrote on Sat, 10 Jan 2009 09:12:08 +0100: |> Nevertheless it is important to me that I can control whether or not |> text properties are set. | | Customizing slime-write-string-function is probably not an option for you.

No it is an option and of course it works.

I considered both approaches. This approach had me replicating all bodies of slime-repl-emit* and insert functions. The other approach was to bind special variables and check just before where properties are added. The API comment below is from the code I get when trying to reuse slime functions in achieving these. [My current opinion is that the latter approach is cleaner, but this is moot anyway is slime-repl is in contrib and I currently only care about repl properties. So I'm done on this thread.]

|>The current API and is a mess to support this . And the direction |>you are taking SLIME in with your style of refactoring code does not |>help.

[snip]

The intent was not to call you stupid or a jerk but to indicate that these are reasons for you to give the benefit of the doubt when evaluating code to rearrange

| Why should I support features that I can't imagine [because I'm too | stupid] or disagree with [because I'm a jerk]? Isn't it your task to | convince me that those feature have some worth [for me]?

On the whole I agree with this.

-- Madhu

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

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

* "Matthew D. Swank" 20081219234257.1bc9639e@inky : Wrote on Fri, 19 Dec 2008 23:42:57 -0600:

| On Fri, 19 Dec 2008 15:26:49 +0530 | Madhu enometh@meer.net wrote: | | Of course not. Most of your proposals are gloriously free of code. If | you're going to whine without any concrete alternate implementation, at | least have the decency to recruit a mob. That is if you can find any | that shares your petty irritations.

* "Matthew D. Swank" 20081219234257.1bc9639e@inky : Wrote on Fri, 19 Dec 2008 23:42:57 -0600:

|> |> No, I do not believe this warrants a fork. | | Of course not. Most of your proposals are gloriously free of code.

The next part of what I wrote that you snipped out explains why. Let me repeat it and see if you can follow why.

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

| If you're going to whine without any concrete alternate

Moving the code out to a separate file is trivial. You're request for a concrete example makes no sense. I could do it you could do it anyone can do it.

I prefer it if Helmut does it as he is the chief developer of

Further try to follow the reasoning in.

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

| implementation, at least have the decency to recruit a mob. That is | if you can find any that shares your petty irritations.

I'll do nothing of that sort and you can shove it. Is Xach waiting to butt in pointlessly like you did next?

-- Madhu

Of course not. Most of your proposals are gloriously free of code. If you're going to whine without any concrete alternate implementation, at least have the decency to recruit a mob. That is if you can find any that shares your petty irritations.

fyi, there are some irritated slime users lurking around here, who already understood the situation and stopped wasting time with argument. Madhu is just not in that phase yet...

* Madhu [2008-12-19 01:56+0100] writes:

However I don't mind persisting because the intention and hope is SLIME should improve.

But apparently you aren't willing to repeat your arguments so that I have chance to understand what you mean. I don't keep a record what every complainer has said a half year ago.

Helmut.

* Madhu [2008-12-20 11:32+0100] writes:

The specifics of the history behaviour are not relevant. But FTR they were discussed in Jan 2007. I suggested splitting on 12 Aug 2007 in the "[RfC] Reorganization of source" thread. Since then the contrib packages have been moved out. Now once again I believe that a start can be made in cutting down SLOC in slime.el by moving out the history component and completion component.

It is not hard to move the history functions to a sepearate file. The first time I did it, I posted a message on this mailing list on 13 Jul 2007 with the "load me over patch" to get a different behaviour . But this is a pointless and time-wasting exercise to repeat unless you agree to support it, like you factored out contrib.

I think a REPL without history would be rather painful. It's probably the best if I move the entire REPL to contrib.

Helmut.