Phil Hagelberg <p...@hagelb.org> writes: > Fred Concklin <fredconck...@gmail.com> writes: > >> Clearly the solution is to turn off slime-highlight-edits. Although why >> is slime bootstrapped on every jack-in? > > Future versions will try to detect if it's already been bootstrapped and > skip that step if so. But this functionality is still new, so I aimed > for the simplest thing that could work.
Yea, I guess there are two possibilities here (off the top of my head). One is [ps aux | grep "lein jack-in"] to see if that process has been launched, but that is only for *nix. Perhaps a better approach is to check if a *swank* buffer is already open, because that is a pretty good confirmation that it has been bootstrapped. Maybe even rename the bootstrap buffer to *clj-swank* so it would never conflict with another lisp (idk if *swank* is used elsewhere). > Also, it's targeted towards my workflow that creates a new Emacs > instance for every project I'm working on and closes them when they're > done. So in my case it's pretty rare for Emacs instances to outlive > their slime sessions. I realize I'm in the minority on that, but > hey--I'm the guy who implemented it, contributions welcome, &c. True, hats off to a badass hacker :). I guess where the problem becomes notable is the opposite end of the spectrum. I use emacs with gnus, erc, etc. so I launch it in daemon mode and then use emacsclient. This keeps everything bundled in one emacs instance where the client can be called with different window configurations for different projects. I just have a screen session where I manage all my clojure swank sessions. >> The slime bundling and bootstrapping also seems to be overkill. Am I missing >> something? > > It was motivated by the fact that 90% of the problems with slime revolve > around "I can't get the damn thing installed". Bootstrapping from swank > turns it into a two-step process, eliminating guesswork where people try > to piece things together from outdated blog posts. That's a good point. As long as emacs is the de facto IDE, I think installation and usability frustration will be pervasive. The amount of outdated clojure material certainly doesn't make this any easier. > I should note that if you've already got slime installed then the old > instructions with M-x slime-connect still work fine! Don't feel a need > to switch, since part of the motivation for jack-in was to reduce the > amount of installation confusion. Sure. Then again, there should be a healthy amount of fear for features that may become deprecated in the future. Jack-in is also a great feature, and I think it's the right direction to take the workflow. Also, it's not everyday you get to launch a command that makes you feel like you're entering the Matrix ;). >> I think the key issue is that slime integration with clojure-mode seems >> to have global effects on all clojure files, which might not be the best >> option. > > It would be great to have a clojure-enable-slime-if-in-current-project > function to use as a hook instead of the naive clojure-enable-slime function. Yea, that's a good idea. The clojure-enable-slime-on-existing-buffers could be modified compare the path of all open clojure buffers to the path of the clojure project you're jacking into and only add the 'clojure-enable-slime hook on buffers who share the top-level project path. > -Phil I guess I should stop complaining and start adding the features. - Fred -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
