-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add separate mark-ring #42
Comments
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 :) |
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. |
Great. |
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 :) |
I don't think there is much code for setting up jedi-mode-map. You need one 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 Making setup for jedi-mode-map optional by having 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 :) |
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
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). |
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 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: 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. |
Already fixed by #44 |
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 whereC-.
was last used. I've skimmed through emacs-jedi sources and it appears that there is in fact a call ofpush-mark
performed for eachgoto-definition
.The problem is that you'd want a global mark so as to be able to jump back across buffers, but
push-mark
altersglobal-mark-ring
only if the previouspush-mark
was from a different buffer. Basically, you need to mentally track where did you start your lookup: ifgoto-definition
resulted in a location in different buffer, you need to doglobal-pop-mark
to go back, if not, you need to use buffer-local mark-ring withpop-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
The text was updated successfully, but these errors were encountered: