Add separate mark-ring

[immerrr]

Hi there

I've recently tried out emacs-jedi and it turned out an awesome piece of work, thank you.

One thing I do miss though compared to etags-related browsing in C-ish modes is the M-* binding, pop-tag-mark, which moves point to the buffer/location where C-. was last used. I've skimmed through emacs-jedi sources and it appears that there is in fact a call of push-mark performed for each goto-definition.

The problem is that you'd want a global mark so as to be able to jump back across buffers, but push-mark alters global-mark-ring only if the previous push-mark was from a different buffer. Basically, you need to mentally track where did you start your lookup: if goto-definition resulted in a location in different buffer, you need to do global-pop-mark to go back, if not, you need to use buffer-local mark-ring with pop-to-mark-command. This is quite inconvenient.

The obvious solution is to have a separate mark-ring for jedi and it should not be too hard to implement given all the ring manipulation functions are already there (see ring-*).

Cheers,
immerrr

[tkf]

Thanks for your opinion. I don't use tags much so I don't know the conventional approach to this problem, but maintaining separate mark-ring makes sense. I'll try to fix this at some point. If you want to make a patch for this I'd be glad to review and pull :)

[immerrr]

Sure, I'll try to find time for it. I'll post it here if I'm going to proceed so as to avoid repeating one another's work.

[tkf]

Great.

[immerrr]

Started hacking on it :)

While I'm at it, @tkf, could you please tell if there's a rationale behind having so much code dedicated to jedi-mode-map setup and all the customizations around it? I've never seen anything like that before :)

[tkf]

I don't think there is much code for setting up jedi-mode-map. You need one define-key call per one keybind.

If you are talking about one variable per keybind, yes that's unusual. Rationale behind it is that I want it to be configurable before loading jedi.el. Yes, you can use eval-after-load but I thought asking beginners to write some complex lisp is not good. If it is a variable you can even use M-x customize. So, I thought if I can kill eval-after-load for everyone's ~/.emacs.d, a little bit of code worth it.

Making setup for jedi-mode-map optional by having jedi:setup-keys is to follow Emacs convention. Keys allocated for minor mode are C-c + punctuation.

That said, I am not perfectly happy with this approach. Following Emacs convention while providing easy-to-use interface is difficult. If you have better idea, please tell me :)

[immerrr]

Well, I agree that being able to setup whole keymap via "customize" infrastructure would be nice, it is just that it feels like having a separate variable for each possible keybinding is an overkill. It works while you have 5-10 of them, but what if, say, at some point, you'd hack around rope to provide its features via epc (I personally would love that, I consider communicating with inferior python via epc a lot more flexible than via pymacs), imagine all those keybindings to be configured via separate variables :)

Maybe we could agree on something like customizing a list of lists/conses like

'(("C-." jedi:goto-definition) ("C-c d" jedi:show-doc) ("<C-tab>" jedi:complete))

and provide a function to initialize jedi-mode-map from such list :) This function might even be called by a hook as soon as the user confirms customization (see an example here).

[tkf]

I agree that the current approach won't scale well. I think we should provide (1) conventional keybinds that are allowed for minor mode by default and (2) a variable to on/off non-conventional shortcut that may override global binding (like M-., M-*). But nothing in between (i.e., one variable per keybind). So, Emacs beginners can turn it on easily enough, but no complication for normal Emacs users.

By the way, having rope client using EPC is a good idea. Traad is developed in the same spirit, although it is using XML-RPC. The author seems to be open mind for having EPC support:
abingham/traad#33

I think having some kind of comprehensive Python IDE library which wraps Jedi, Rope, pyflakes, IPython etc. would be really great. I haven't started anything yet, though. I am just toying with ideas.

[tkf]

Already fixed by #44