Hi,
Attached is a patch which defines and implements (for SBCL and CMUCL) a basic profiling interface for SLIME.
Profiling submenu and following key combos added: C-c p {t,u,f,r,c}
The CMUCL implementation is not tested, since my swank-cmucl.lisp does not compile currently, but it is written according to docs. If somebody with working CMUCL SLIME could have a look, that would be fine :)
Cheers, Michael
Michael Weber michaelw+slime@foldr.org writes:
Attached is a patch which defines and implements (for SBCL and CMUCL) a basic profiling interface for SLIME.
Very nice! It's in CVS.
Profiling submenu and following key combos added: C-c p {t,u,f,r,c}
C-c p is by convention reserved for users[*]. We have to find another key. C-c C-p is already taken, perhaps C-c C-o ?
The CMUCL implementation is not tested, since my swank-cmucl.lisp does not compile currently, but it is written according to docs. If somebody with working CMUCL SLIME could have a look, that would be fine :)
The code seems to work in CMUCL.
Helmut.
[*] http://www.gnu.org/software/emacs/elisp-manual/html_node/elisp_709.html
* Helmut Eller e9626484@stud3.tuwien.ac.at [2004-01-29T09:55+0100]:
C-c p is by convention reserved for users[*].
Ah, okay. Too bad.
We have to find another key. C-c C-p is already taken, perhaps C-c C-o ?
I considered C-c C-o, but it is bound in slime-repl to SLIME-REPL-CLEAR-OUTPUT.
The following (simple) C-c C-<letter> combinations are unused in both lisp-mode and slime-repl:
C-i C-j C-q C-s C-u C-y
There are quite some free C-c M-<letter> combinations as well, but I found it awkward to type e.g. C-c M-<letter> t.
Cheers, Michael
Michael Weber michaelw+slime@foldr.org writes:
The following (simple) C-c C-<letter> combinations are unused in both lisp-mode and slime-repl:
I think we should start introducing more subtrees in our keymap hierarchy - we're going to run out of C-c C-<something> keys pretty soon.
I think that our current `C-c M-<foo>' and `C-c Shift-<foo>' are a little bit un-Emacsey and it would be nice to put some of them onto key sequences that only use control.
Exactly which bits to turn into subtress I'm not sure :-) but one idea is to move the documentation-related keys under a `C-c C-d' prefix. That is a pretty convenient-on-the-fingers prefix, and it would free up a lot of other keys.
-Luke
Luke Gorrie wrote:
[...]
I think that our current `C-c M-<foo>' and `C-c Shift-<foo>' are a little bit un-Emacsey and it would be nice to put some of them onto key sequences that only use control.
Exactly which bits to turn into subtress I'm not sure :-) but one idea is to move the documentation-related keys under a `C-c C-d' prefix. That is a pretty convenient-on-the-fingers prefix, and it would free up a lot of other keys.
Not to mention the fact that it would free up C-c C-h, which the elisp manual generally recommends to leave untouched. In fact, it's recommended not to bind "Anything C-h", since, if unbound C-h acts as a magic key, showing the current prefix's submap.
| * Do not bind `C-h' following any prefix character (including | `C-c'). If you don't bind `C-h', it is automatically available | as a help character for listing the subcommands of the prefix | character.
E.g.
C-x a C-h:
| Global Bindings Starting With C-x a: | key binding | --- -------
| C-x a n expand-jump-to-next-slot
[...]
| C-x a i g inverse-add-global-abbrev
Also on major mode keybinding conventions, in addition to C-c {C-letter, C-digit}, the following are also reserved for major modes:
(elisp) Coding Conventions | * Sequences consisting of `C-c' followed by `{', `}', `<', `>', | `:' or `;' are also reserved for major modes.