search

emacs-evil / evil

The extensible vi layer for Emacs.
GNU General Public License v3.0
3.36k stars 281 forks source link

Evil jump list is cleared on window recreation #732

Open TheBB opened 7 years ago

TheBB commented 7 years ago

Originally reported by: Oleg Kostyuchenko (Bitbucket: olegkst, GitHub: olegkst)

Hi,

Please do not use window id as a hash key in evil-jump.el.

If the workflow is based on "emacs --server" + emacsclient, a window id is a very ephemeral thing. Consider the following scenario:

Please implement a jump list storage that is able to survive a window id change.

Thanks

nnicandro commented 5 years ago

This is an issue that I frequently bump into, especially since I use the perspective package which saves and restores window configurations. The current jumplist implementation will delete the jumps stored for a window if it isn't visible which means whenever I restore a window configuration all of my jumps are gone.

This issue can be solved by storing each jumplist as a window parameter so that the jumplist is associated with the window object itself.

There are also other issues with the jumplist: jump points that point to the same location if the text between them was deleted (due to the markers being moved), multiple jump points can be stored on a singe line (in VIM only one jump point per line is stored), a previous jump point that was returned to and then jumped from is not "bubbled up" to the top of the jumplist (also like in VIM). The style of evil-jumps.el does not really match the rest of evil either. Is there any interest in a re-implementation of jumplists that will fix this issue and the ones mentioned?

braham-snyder commented 5 years ago

Not sure if you were asking the maintainers or users, but I would definitely appreciate that re-implementation

nnicandro commented 5 years ago

Actually I don't think this particular issue can be fully solved in the way that @olegkst intends since it would not be fully compatible with how jumplists work in VIM. Jumplists in VIM are associated with a window and not with a buffer so closing the window and losing the jumps is expected behavior as far as VIM is concerned.

But when you use packages like winner or perspective you still lose the jumps whenever you revisit old window configurations. This is because of how jumplists are currently implemented and this issue (losing jumps when revisiting old window configurations) would be solved by using a window parameter to store the jumplist.

A possible solution to having jumps persist in the way that @olegkst describes would be to, in addition to having a jumplist stored as a window parameter, have one as a frame parameter. Then when a window is closed, its jumplist is merged into the frame's jumplist. The jumps in the merged jumplist being ordered by a jump id (incremented whenever a jump is created). Then the frame's jumplist is used as the default jumplist of a new window after a split instead of using the jumplist of the window being split. This way the jumplist of any new window always has the most recent jumps made instead of being a copy of the split window's jumplist. This would persist the jumps from closed windows into new ones, but assumes that a frame to store the jumplist is never garbage collected. I'm not sure this is always true when using emacsclient, specifically when using emacs --daemon.

This would also make saving the jumplist to the hard drive easier since the jumplist of all the windows could be merged into the frame's jumplist and the frame's jumplist saved so that the saved jumplist contains the most recent jumps in all of the visible windows instead of just the currently selected window. I don't know how this would work in a workflow that uses more than one frame though.