Rationale: Debugging

[jojojames]

It'd be good to make some requests too. :)

I'd like to see realgud (especially the shortkey mode keymap) set up for evil.

I don't use realgud yet because I don't have bindings set up and setting it up just to set up bindings for the future is a little daunting.

It'd be great if anyone already had something for realgud. I think the DOOM config might have something for it...

[Ambrevar]

I recently heard about it and I'm going to give it a try real soon once I leave the realm of Elisp...

[Ambrevar]

Also see the link of the DOOM config in the readme: it will lead you directly to a file full of bindings.

[jojojames]

Hmnn, I'm starting to want to set up some debugger keys. The problem with is really precedence. When a debugger is in play, how much precedence should it have over regular keys (even navigation keys)?

For example, playing with indium today,

(evil-define-key 'normal indium-debugger-mode-map
  "n" 'indium-debugger-step-over
  "i" 'indium-debugger-step-into
  "o" 'indium-debugger-step-out
  "c" 'indium-debugger-resume
  "l" 'indium-debugger-locals
  "s" 'indium-debugger-stack-frames
  "q" 'indium-debugger-resume
  "h" 'indium-debugger-here
  "e" 'indium-debugger-evaluate
  "M-n" 'indium-debugger-next-frame
  "M-p" 'indium-debugger-previous-frame)

The short keys takes over n, i, o, c, l, s, q, h, e (all very good keys in normal state). But you could make the case when a debugger is up, most likely that's the highest priority thing in your workflow.

Some options:

1. Make these keys longer.

Pro: navigation keys are in tact
Con: I doubt anyone will actually use these keys, they'll probably be too long.

2. For this particular case (and probably many other), using the capitalized version of these keys might be doable.
   Pro: Same as above (mostly)
   Con: Still seems too long for something that should be relatively easy to do.

3. Move the common ones like step over/into /next into function keys like popular ides (e.g. F8-F12)

Pro: Mostly helps with the above
Con: Quite a few keys will still have to live somewhere.

4. Allow debugger keys to take precedence but try to keep the most common keys (e.g. hjkl) intact.

As described above already.

I'm thinking 4 is probably ideal but open to opinions. At some point I'll take a look and add debugger keys for modes that I actually use.

[fbergroth]

Have you considered a separate state or a hydra, rather than hijacking movement keys in normal state?

[jojojames]

The separate state thing I was thinking about before but the number of states might be too excessive. Dunno.

The debug mode being on is already some kind of extra transient state already so I was thinking it might be overkill to use another one.

As for hydra, I use hydra myself but I find launching the hydra and using it not as nice an experience as single key debugging. That and not wanting to use hydra as a dependency is another reason why I didn't consider it.

Overriding some normal keys (maybe not the highest priority keys) have some precedence in emacs already though with edebug, realgud, gdb-mi?, etc kinda taking over in that way.

[jojojames]

Added first pass of both realgud/debugger rationale/debugger keys for indium/realgud.

It actually works fairly well when the given constraints are consistent.

[jojojames]

Closing this for now, if anyone had any other opinions on debugger bindings, feel free to reopen.