Gentlemen,
I've added a branch with tag "contrib" which contains my proposal to split up Slime. Essentially it contains a new directory "contrib" with the fuzzy completion code. To use fuzzy completion you have to add something like this to your .emacs:
(add-to-list 'load-path ".../slime/contrib/") (add-hook 'slime-load-hook (lambda () (require 'slime-fuzzy)))
After that everything should work as before.
Unless we hit some show stopping problem, I'll merge that branch into the main trunk in the next few days.
Helmut.
Helmut Eller <heller <at> common-lisp.net> writes:
Gentlemen,
I've added a branch with tag "contrib" which contains my proposal to split up Slime. Essentially it contains a new directory "contrib" with the fuzzy completion code. To use fuzzy completion you have to add something like this to your .emacs:
(add-to-list 'load-path ".../slime/contrib/") (add-hook 'slime-load-hook (lambda () (require 'slime-fuzzy)))
After that everything should work as before.
Unless we hit some show stopping problem, I'll merge that branch into the main trunk in the next few days.
Helmut.
Hi,
I have just installed the contrib branch - everything's loading and working fine so far.
It seems very tempting now to add some more contributions... :)
I am thinking about one that uses cl-ppcre for find / replace in a specific asdf:system or all asdf::*defined-systems*.
For this I have some old code that I find pretty useful and I will try to write it up more nicely.
I will probably want to add a submenu at the end of the SLIME menu (or somewhere else?).
I have tried using: (easy-menu-add-item menubar-slime nil ["hallo" hallo t])
But it seems to be adding this entry sometimes only in the SLIME menu for the REPL or in the menu for the slime-mode.
What do you think about menus for contributions in general?
For the time being, I'll just try to bind some keys...
Best, Kilian
* Kilian Sprotte [2007-08-19 23:12+0200] writes:
Hi,
I have just installed the contrib branch - everything's loading and working fine so far.
Good to hear that.
It seems very tempting now to add some more contributions... :)
I am thinking about one that uses cl-ppcre for find / replace in a specific asdf:system or all asdf::*defined-systems*.
For this I have some old code that I find pretty useful and I will try to write it up more nicely.
I will probably want to add a submenu at the end of the SLIME menu (or somewhere else?).
I have tried using: (easy-menu-add-item menubar-slime nil ["hallo" hallo t])
But it seems to be adding this entry sometimes only in the SLIME menu for the REPL or in the menu for the slime-mode.
What do you think about menus for contributions in general?
Many Mozilla add-ons insert menu items after a certain separator in the (Mozilla) tools menu. We could adopt a convention like that. I don't know in detail how to implement that in Emacs, but I'm confident that it isn't very hard.
Helmut.
Helmut Eller heller@common-lisp.net writes:
Gentlemen,
I've added a branch with tag "contrib" which contains my proposal to split up Slime. Essentially it contains a new directory "contrib" with the fuzzy completion code. To use fuzzy completion you have to add something like this to your .emacs:
(add-to-list 'load-path ".../slime/contrib/") (add-hook 'slime-load-hook (lambda () (require 'slime-fuzzy)))
After that everything should work as before.
Unless we hit some show stopping problem, I'll merge that branch into the main trunk in the next few days.
I haven't had a chance to look at it, but I'd favor a smoother migration than just throwing fuzzy completion out completely. Like binding `slime-fuzzy-complete-symbol' to something that emits a warning, and autoloads the fuzzy completion code. The warning should advise the user that fuzzy completion is going to become optional and has to be loaded explicitely.
-T.
* Tobias C. Rittweiler [2007-08-20 20:13+0200] writes:
I haven't had a chance to look at it, but I'd favor a smoother migration than just throwing fuzzy completion out completely. Like binding `slime-fuzzy-complete-symbol' to something that emits a warning, and autoloads the fuzzy completion code. The warning should advise the user that fuzzy completion is going to become optional and has to be loaded explicitely.
I think a message to the mailing list is warning enough. Or are you saying that the fuzzy completion code should stay in the core? Or are you criticizing the idea of splitting Slime into core and contrib?
We haven't yet much feedback about the "smoothness" of the migration. I have the impression that Kilian Sprotte (he "looked at it") found the transition quite acceptable.
Helmut
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2007-08-20 20:13+0200] writes:
I haven't had a chance to look at it, but I'd favor a smoother migration than just throwing fuzzy completion out completely. Like binding `slime-fuzzy-complete-symbol' to something that emits a warning, and autoloads the fuzzy completion code. The warning should advise the user that fuzzy completion is going to become optional and has to be loaded explicitely.
I think a message to the mailing list is warning enough. Or are you saying that the fuzzy completion code should stay in the core? Or are you criticizing the idea of splitting Slime into core and contrib?
No, I'm saying just what I wrote: "The [emitted] warning should advise the user that fuzzy completion is going to become optional and has to be loaded explicitely." That warning should stay in there for a couple of months. and can then be removed.
For example, the warning could look like "Fuzzy completion has been made an optional feature of Slime which needs to be enabled explicitely. For more information, see the ChangeLog entry of 2007-08-??."
We haven't yet much feedback about the "smoothness" of the migration. I have the impression that Kilian Sprotte (he "looked at it") found the transition quite acceptable.
Of course, he does, because he has read your message in due time.
-T.
On 8/20/07, Tobias C. Rittweiler tcr@freebits.de wrote:
No, I'm saying just what I wrote: "The [emitted] warning should advise the user that fuzzy completion is going to become optional and has to be loaded explicitely." That warning should stay in there for a couple of months. and can then be removed.
I would tend to think a hard error with an error message that says exactly how to load fuzzy stuff should be fine -- but that error should probably stay in for several months. I'm laboring under the impression that there are quite a few people out there who update Slime only a couple of times a year.
Cheers,
-- Nikodemus
* Helmut Eller [2007-08-19 13:35+0200] writes:
Unless we hit some show stopping problem, I'll merge that branch into the main trunk in the next few days.
It's now in the trunk.
I've also added a binding for C-c M-i which displays a message that fuzzy completion is now in the contrib. It doesn't autoload anything.
I plan to incrementally move quite a bit of code to contrib. More or less the stuff that wasn't present in 1.0.
Helmut.
Helmut Eller heller@common-lisp.net writes:
I plan to incrementally move quite a bit of code to contrib. More or less the stuff that wasn't present in 1.0.
Nice work, Helmut! I'd like to suggest at this point to provide two "default configurations" -- one without contribs and one with all contribs.
So the user can simply put `(require 'slime-minimal)' or `(require 'slime-all-contribs)' into their ~/.emacs. The names are just examples; they could also be `slime-1.x' and `slime-2.x'.
This has the two following advantages:
i) it makes the transition easier.
ii) as I think most people will stick to the latter by default, it's easier to deal with bug reports, and reproduce bugs because there's one common "everything enabled" that you can talk very concretely about. ("Do you use the 2.x config? If not, can you reproduce the problem there?" -- and then it's even easier for developers who don't use every contrib to get a handle at the problem, because they just have to temporarily switch to this config.)
-T.
* Tobias C. Rittweiler [2007-08-25 09:49+0200] writes:
Nice work, Helmut! I'd like to suggest at this point to provide two "default configurations" -- one without contribs and one with all contribs.
So the user can simply put `(require 'slime-minimal)' or `(require 'slime-all-contribs)' into their ~/.emacs. The names are just examples; they could also be `slime-1.x' and `slime-2.x'.
This has the two following advantages:
i) it makes the transition easier.
ii) as I think most people will stick to the latter by default, it's easier to deal with bug reports, and reproduce bugs because there's one common "everything enabled" that you can talk very concretely about. ("Do you use the 2.x config? If not, can you reproduce the problem there?" -- and then it's even easier for developers who don't use every contrib to get a handle at the problem, because they just have to temporarily switch to this config.)
I think we should try the simplest variant first. If that doesn't work, we can try something more sophisticated. The simplest variant is to provide only a single feature set, i.e. only the stuff that is in the core.
Helmut.
Helmut Eller heller@common-lisp.net writes:
I think we should try the simplest variant first. If that doesn't work, we can try something more sophisticated. The simplest variant is to provide only a single feature set, i.e. only the stuff that is in the core.
What exactly do you consider to be the maintaince burden of my proposal?
-T.
* Tobias C. Rittweiler [2007-08-25 11:59+0200] writes:
Helmut Eller heller@common-lisp.net writes:
I think we should try the simplest variant first. If that doesn't work, we can try something more sophisticated. The simplest variant is to provide only a single feature set, i.e. only the stuff that is in the core.
What exactly do you consider to be the maintaince burden of my proposal?
Well, if we provide some default configuration which loads almost all contribs, people will mostly likely expect that that configuration works reasonably well. And we will--perhaps only subconsciously--spend a lot of time on that configuration, even if we don't use it.
It's also more likely that contrib modules depend on each other when contrib authors know that some other module is in the default configuration. I don't say that all contrib modules must be prefectly isolated from each other, but those contribs which depend only on the core are probably easier to maintain.
Helmut.
Helmut Eller heller@common-lisp.net writes:
Well, if we provide some default configuration which loads almost all contribs, people will mostly likely expect that that configuration works reasonably well. And we will--perhaps only subconsciously--spend a lot of time on that configuration, even if we don't use it.
Shouldn't people who make changes to Slime try to introduce as little breakage as possible, including the contribs? (I.e. at least that loading everything should introduce no obvious regression.)
It's also more likely that contrib modules depend on each other when contrib authors know that some other module is in the default configuration. I don't say that all contrib modules must be prefectly isolated from each other, but those contribs which depend only on the core are probably easier to maintain.
I'd still like to see swank.lisp split into swank-utils.lisp for exactly that purpose. The point of swank-utils.list is that it should contain shared functionality between core and contribs (and among the contribs themselves). Because it's supposed to contain _well abstracted_, generic utility functionalities, people are pressured to come up with, and to use abstractions in their code.
-T.
* Tobias C. Rittweiler [2007-08-25 18:41+0200] writes:
Shouldn't people who make changes to Slime try to introduce as little breakage as possible, including the contribs? (I.e. at least that loading everything should introduce no obvious regression.)
Well, contribs are second class citizens. If a contrib breaks it's the burden of the contrib author/maintainer to fix that. I don't expect that we will intentionally break contribs or make it needlessly difficult to fix them, but contribs shouldn't be our primary concern.
I'd still like to see swank.lisp split into swank-utils.lisp for exactly that purpose. The point of swank-utils.list is that it should contain shared functionality between core and contribs (and among the contribs themselves). Because it's supposed to contain _well abstracted_, generic utility functionalities, people are pressured to come up with, and to use abstractions in their code.
Yeah, you said that more than once. It's getting boring.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2007-08-25 18:41+0200] writes:
Shouldn't people who make changes to Slime try to introduce as little breakage as possible, including the contribs? (I.e. at least that loading everything should introduce no obvious regression.)
Well, contribs are second class citizens. If a contrib breaks it's the burden of the contrib author/maintainer to fix that. I don't expect that we will intentionally break contribs or make it needlessly difficult to fix them, but contribs shouldn't be our primary concern.
Which doesn't contradict to what I said, and isn't an argument against what I suggested.
It was you who accused my recent proposal for reorganization that it sounds like an attempt to just move bad code into different files, them to be out of sight. Now you did just that.
I'd still like to see swank.lisp split into swank-utils.lisp for exactly that purpose. The point of swank-utils.list is that it should contain shared functionality between core and contribs (and among the contribs themselves). Because it's supposed to contain _well abstracted_, generic utility functionalities, people are pressured to come up with, and to use abstractions in their code.
Yeah, you said that more than once. [...]
Indeed, it's the second time. And it's also the second time that you didn't actually address the issue.
The issue is not pulled from hot air, FWIW; swank-fuzzy.lisp defines `classify-symbol' and `symbol-classification->string' which is also used in swank-fancy-inspector.lisp. These two functions do have an perfect end in themselves, and may turn out to be useful in other places. I'm going to move them to swank.lisp for now.
-T.
* Tobias C. Rittweiler [2007-08-26 00:15+0200] writes:
It was you who accused my recent proposal for reorganization that it sounds like an attempt to just move bad code into different files, them to be out of sight. Now you did just that.
C'mon, you want to keep everything. I want do remove it.
Indeed, it's the second time. And it's also the second time that you didn't actually address the issue.
Why do you join a project if you don't have the same opinions like the main developers?
Since you are so obsessed with your "utilities", why don't you create a contrib for them?
Helmut.
Nathan Bird nathan@acceleration.net writes:
Just as a note: I, and the couple of developers I work with, like the class inspector and fuzzy complete quite a bit. I might go parse my *slime-events* buffer a bit more for statistics on just how much we use them (anyone else done something like that?)
Note from a lurker, in case it makes any difference to anybody, but I absolutely love and depend on both the fuzzy completion and the inspector. I follow this project somewhat loosely, but was somewhat aghast when I last upgraded and discovered they had gone AWOL.
I thought the idea of having a default "include everything" config available was a pretty good idea...
Yes, I would also love to just be able to
(require 'slime-kitchen-sink) ; load everything they've got! :-)
like somebody suggested upthread.
Just my $0.02...
--ap
On Sun, Sep 02, 2007 at 03:56:02PM +1000, Alain Picard wrote:
Yes, I would also love to just be able to
(require 'slime-kitchen-sink) ; load everything they've got! :-)
The recent addition of contrib/slime-fancy.el by Matthias Koepp lets you add
(add-to-list 'load-path "<directory-of-this-file>") (add-hook 'slime-load-hook (lambda () (require 'slime-fancy)))
to your .emacs to get what you requested.
Also add
(setq slime-complete-symbol-function 'slime-fuzzy-complete-symbol t)
if you prefer fuzzy completion to be bound to TAB rather than C-c M-i.
On 8/26/07, Helmut Eller heller@common-lisp.net wrote:
Why do you join a project if you don't have the same opinions like the main developers?
Do you really need the 's'?
levy
* Levente Mészáros [2007-08-28 21:39+0200] writes:
On 8/26/07, Helmut Eller heller@common-lisp.net wrote:
Why do you join a project if you don't have the same opinions like the main developers?
Do you really need the 's'?
Does it make a difference?
-
Alain Picard -
David J. Neu -
Helmut Eller -
Kilian Sprotte -
Levente Mészáros -
Nathan Bird -
Nikodemus Siivola -
Tobias C. Rittweiler