If I select a line with x followed by X onto the next consequent line from the scratch buffer, or x then delete, then x again and delete the next line, and then if I were to u undo what I had just deleted by any of the prior selections, the inherent visual selection of the former line as a result overtakes because - as I undestand it - this is the current implementation. See for example https://github.com/mawww/kakoune/issues/753#issuecomment-236429855
But this is hardly an improvement over vim.
[*]** this is a *scratch* buffer which won't be automatically saved ***
*** use it for notes or open a file buffer with the :edit command ***
If, upon starting kak, the cursor is on the first character, then the expected behavior would be not to have - after going through an undo operation - the cursor before the newline \n but rather on the first character, where it all started.
*** this is a *scratch* buffer which won't be automatically saved ***[]
*** use it for notes or open a file buffer with the :edit command ***
I can safely say this hehe, nuisance, irks me to the point that the more I do it over and over again, the more I realized how sub-par the undo operation has become because of the way that visual selection with cursor and anchor work.
In other words, and loosely based on the example above, one would have to manually pressgl or gh respectively, in order to keep up where the cursor was at, so it would better resemble where the cursor was the undo operation would take off from the very beginning.
In this sense, the current undo, is not quite an undo. How could it be.
This is not an exclusive setback to x itself but visual selections overall.
It’s been a while since I used emacs, but normally back-and-forth undo/redo operations are accomplished by quitting with the C-g binding. Emacs users in this respect laud this functionality as intrinsically superior among editors. It allows to redo and undo as many times as possible.
The current behaviour with undo is to try to compute what ranges were impacted by the undo/redo operation and select them. It seems to be what you experience here. The reason for this behaviour is to indicate what changes took place with undo/redo.
I know this behaviour is not always desirable, but preserving previous selections is not always what we want either, as it gives no information on what the undo/redo operation did. As I understand it you would prefer your existing selections to be preserved, a possibility for that would be to map those operations to wrappers that restore selections, thankfully that is exactly what draft contexts are for.
map global normal u `: exec -draft u<ret>`
map global normal U `: exec -draft U<ret>`
Additionally, I am not really familiar with how emacs does undo/redo, but Kakone stores undo history in a tree, and every previous state is still available. <a-u> allows <a-U> allows to circle through those, albeit in a pretty impredictible order. We still lack a nice user inteface on top of that, its unclear to me what it would look like.
Well, it does, except that the undo operation does not behave any better than say: saving a selection to a jump list. With the latter the cursorr for this use case is where’s supposed to be at, exactly because it had an effect.
it can’t be the current behavior. Yes, yes. It’s a range. Hence we ought to infer from it, that given fthe example from the first line of the scratch buffer select first sentence with x then d to delete will surely take us to wherever that range is/was computed. Obviously anyone using kak would know what the range is. But it doesn’t make it [undo operation] any less unpredictable. If the cursor starts on the first character, the deterministic non-range action would be to have it on the first character, and not the end of sentence-
@mawww I do agree with you, in that `undo undoes the impact, but it also alters the state by which the cursor relies upon.
I liked the way you put it by referring to as preserve[ing] previous selections…
Perhaps @alexherbo2 is on the right path by mentioning such plugin. I don’t know. I’ve never used it. I may have heard about it before, but can’t say for sure now.
But when you said ‘preserving’…the first thing which came to mind was the slogan for git: everything is local. Because what is undo but just preserving different states throughout a session.