I found and fixed another annoyance when trying to M-. on a presentation in the REPL buffer with the slime-fancy contrib enabled. This appears to be traceable to the slime-presentations contrib, so I'm cc'ing the authors
The function I changed must return nil on failure so as not to break the `run-hooks-until-success' logic of `slime-edit-definition-hooks'.
diff --git a/contrib/slime-presentations.el b/contrib/slime-presentations.el index a462669..fd0fd63 100644 --- a/contrib/slime-presentations.el +++ b/contrib/slime-presentations.el @@ -401,11 +401,12 @@ Also return the start position, end position, and buffer of the presentation." (location (slime-eval `(swank:find-definition-for-thing (swank:lookup-presented-object ',(slime-presentation-id presentation)))))) + (unless (eq (car location) :error) (slime-edit-definition-cont (and location (list (make-slime-xref :dspec `(,presentation-string) :location location))) presentation-string - where))) + where))))
BTW, I wonder if providing these patches with full changelog and ready to commit would somehow speed up the analysis/integration
BTW, I wonder if providing these patches with full changelog and ready to commit would somehow speed up the analysis/integration
the issue you're trying to address by providing more convenient patches is unfortunately not an engineering or convenience issue, but is rather social in nature.
there are very few active committers due to the conservative attitude of the maintainer(s) of slime (or at least that's my narrative to make sense of the facts), and a surprisingly low pace development for an IDE -- a piece of software whose users are exclusively programmers proficient in the same language the IDE itself is written in.
but i don't really have the motivation to try to tackle this issue by initiating and maintaining a constructive discussion. i just thought that it's worth it to at least throw in my 0.02 in a short note.
so, it's just some 0.02,
On Mon, Jul 15, 2013 at 6:24 AM, Attila Lendvai attila.lendvai@gmail.com wrote: the issue you're trying to address by providing more convenient patches is unfortunately not an engineering or convenience issue, but is rather social in nature.
Well, I myself maintain a fairly popular open source repo and go months without replying to perfectly usable pull requests. It's just a question of time (and conservatorism you're right, since I also get lots of unusable, if creative, contributions ).
But I do value neat, ready-to-commit contributions. Tests and peer backings help, too. These I normally merge without even testing them myself (github makes it easy). So "neater" contributions are not only more convenient, they offer more security to a maintainer that it isn't just a one-off hack to scratch some itch.
so, it's just some 0.02,
Throw in another 0.02 and try out the patches. Report back here if they're good to go.
João
PS: interesting point about the surprising slowness of SLIME. Interesting indeed, but lets spend more time fixing and improving it than evaluating the interest of such discussions :-)
PS: interesting point about the surprising slowness of SLIME.
just to make sure, i meant the slowness of the *development* of slime.
Interesting indeed, but lets spend more time fixing and improving it than evaluating the interest of such discussions :-)
long story short, i (and a couple of my colleagues) used to have even the commit bit and we used to invest a non-marginal amount of time into working on slime, but not anymore. some of our work is still there (e.g. making fuzzy completion's UI usable), and i still keep rebasing a minimal set of fixes for really annoying bugs/features in my fork, but these days it's much more about lowering annoyance than making slime any better, and with as little effort as possible.
which is sad, especially if i'm not alone with this attitude, and i have heard similar sentiments.
On Mon, Jul 15, 2013 at 10:48 AM, Attila Lendvai attila.lendvai@gmail.com wrote:
PS: interesting point about the surprising slowness of SLIME.
just to make sure, i meant the slowness of the *development* of slime.
Yes, I understood perfectly, but admit my remark was ambiguous.
my fork, but these days it's much more about lowering annoyance than making slime any better, and with as little effort as possible.
... which is a normal part of the software development cycle when "user demand" goes down. So wonder though if it isn't more a question of there being an active enough user base to raise and discuss issues. It *might* also be a question of hosting platform, github has spoiled most of us, so CVS+mailing-list might be acting as a deterrent to collaboration.
Anyway, I'll soon be proposing a fairly new and substantial feature to slime's contribs, see https://github.com/capitaomorte/slime/tree/slime-trace-dialog for a preview and make comments.
João Távora
-
Attila Lendvai -
João Távora