persistent-undo history is ignored by first session call to :n and :arglocal #5426
Comments
|
This happens because This causes later in I first thought, we should make so I think it is better to use this patch to diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index c8a93bc0a..7f0563790 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -2866,7 +2866,8 @@ do_ecmd(
new_name = NULL;
set_bufref(&bufref, buf);
- if (p_ur < 0 || curbuf->b_ml.ml_line_count <= p_ur)
+ if (!(curbuf->b_ml.ml_flags & ML_EMPTY) &&
+ (p_ur < 0 || curbuf->b_ml.ml_line_count <= p_ur))
{
// Save all the text, so that the reload can be undone.
// Sync first so that this is a separate undo-able action.@brammool what do you think? I can create a PR with a test, if you think this is the right approach. |
|
@chrisbra, |
|
Christian wrote:
This happens because `:next` will eventually set `curbuf` in `buflist_new` (stack:
```
#0 0x00005555555ca739 in buflist_new (ffname_arg=0x5555558fecf0 "/home/chrisbra/.vim/vimrc", sfname_arg=0x0, lnum=0, flags=3) at buffer.c:2156
#1 0x00005555555cce4e in buflist_add (fname=0x5555558fecf0 "/home/chrisbra/.vim/vimrc", flags=3) at buffer.c:3453
#2 0x00005555555c048d in alist_add (al=0x5555558db380 <global_alist>, fname=0x5555558fecf0 "/home/chrisbra/.vim/vimrc", set_fnum=2) at arglist.c:188
#3 0x00005555555c03ba in alist_set (al=0x5555558db380 <global_alist>, count=1, files=0x5555558e9c00, use_curbuf=1, fnum_list=0x0, fnum_len=0) at arglist.c:157
#4 0x00005555555c0d73 in do_arglist (str=0x5555558fc0e2 "~/.vim/vimrc", what=1, after=0, will_edit=1) at arglist.c:458
#5 0x00005555555c176e in ex_next (eap=0x7fffffffd310) at arglist.c:721
#6 0x000055555563df3e in do_one_cmd (cmdlinep=0x7fffffffd9a8, sourcing=0, cstack=0x7fffffffd500, fgetline=0x55555565183c <getexline>, cookie=0x0) at ex_docmd.c:2485
#7 0x000055555563b48d in do_cmdline (cmdline=0x0, fgetline=0x55555565183c <getexline>, cookie=0x0, flags=0) at ex_docmd.c:975
#8 0x00005555556cf0fe in nv_colon (cap=0x7fffffffdae0) at normal.c:3335
#9 0x00005555556cb048 in normal_cmd (oap=0x7fffffffdbd0, toplevel=1) at normal.c:1088
#10 0x0000555555827391 in main_loop (cmdwin=0, noexmode=0) at main.c:1510
#11 0x00005555558266d4 in vim_main2 () at main.c:901
#12 0x0000555555825dd6 in main (argc=3, argv=0x7fffffffddc8) at main.c:444
```
This causes later in `do_ecmd`, that `otherfile()` returns true, as Vim thinks we are editing the same file again, causing it to set the `READ_KEEP_UNDO` flag when loading the buffer (which skips loading the undofile).
I first thought, we should make `otherfile_buf()` return true, if the buffer is not loaded yet and while this fixes the problem, it introduces another one, as this will not reuse the old empty buffer and we will end up with two buffers with the same name, something like this
```
:ls!
:ls
1 # "~/.vim/vimrc" line 1
2 %a "~/.vim/vimrc" line 1
```
so I think it is better to use this patch to `do_ecmd()`
```patch
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index c8a93bc0a..7f0563790 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -2866,7 +2866,8 @@ do_ecmd(
new_name = NULL;
set_bufref(&bufref, buf);
- if (p_ur < 0 || curbuf->b_ml.ml_line_count <= p_ur)
+ if (!(curbuf->b_ml.ml_flags & ML_EMPTY) &&
+ (p_ur < 0 || curbuf->b_ml.ml_line_count <= p_ur))
{
// Save all the text, so that the reload can be undone.
// Sync first so that this is a separate undo-able action.
```
@brammool what do you think? I can create a PR with a test, if you
think this is the right approach.
To do_ecmd() it does look like re-editing the same file again, since
the file name is the same. I don't think we should change it by
guessing that are actually editing another file, passing in a flag to
say so is much clearer and avoids later mistakes.
Thus it would require ex_next() to detect that the current buffer has
been re-used, and passing this to do_argfile(), which will then pass it
to do_ecmd().
…--
If "R" is Reverse, how come "D" is FORWARD?
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
My workaround is sometimes messy:
As I'm not hacking vim code myself since many years now, I would like to know who to beg for some effort in trying to solve this persistent undo issue. |
|
Another workaround could be a clue for a solution;
works only when there is more than one file in the argument list The pipe version is less shaky (same thing .. no screen redraw)
|
|
As it looks like I'm the only one to use :next while working with persistent undo and, as it makes no sense to have a persistent opened tickets, I'm going to to close it right now. |
First call to :arglocal or :n replaces persistent-undo history with current file content
To Reproduce
1 - Setup persistent-undo option :set undofile
2 - Edit and modify a file with this option activated
3 - Restart Windows gvim
4 - From the just-opened-empty-gvim-window
5 - Type ':n file'
6 - Type ':undolist'
... Result is a single command undo history list showing current file contents as if it was just fully written and saved.
7 - Type ':e!'
8 - Type ':undolist'
... Result is as it should be.
Expected behavior
The :undolist should be as expected for a previously persistent-undo edited file.
My current Workaround
Between Steps 4,5, just before calling ':n file'
4'' - Type ':f arglocal_issue_workaround'
This gives a file-name to the 'no-name first buffer' so that the implied ":update"
taking place before leaving it would make the persistent-undo processing happy
while it is busy doing nothing to update a 'nomodified' buffer we're leaving.
... This works fine for me, with no side-effect when I use a script that calls ':arglocal' as a first session command.
Screenshots
n.a.
Environment
Vim version:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 12 2019 13:30:17)
MS-Windows 32-bit GUI version with OLE support
Compiled by mool@tororo
Huge version with GUI.
OS:
Windows 7
Terminal:
GUI
The text was updated successfully, but these errors were encountered: