Re: Window-local and Tab-local previous directories?
On Tuesday, May 14, 2019 at 12:17:06 PM UTC-4, yega...@gmail.com wrote: > Hi, > > On Sat, May 11, 2019 at 10:12 AM Manuel Ortega wrote: > > > > On Friday, May 10, 2019 at 5:20:08 PM UTC-4, Bram Moolenaar wrote: > > > > > I think that's the best way we provide this functionality. But I like > > > to hear from others. > > > > I think this is adding complexity, a maintenance burden, and yet another > > corner for corner-cases to hide in, all for the sake of a *very* niche > > use-case. (Has anybody complained about this yet in all the years of :lcd > > existing?) > > > > When the ":cd -" or ":tcd -" or ":lcd -" commands are used, a user will > expect to go back to the previous directory. When a tab-local directory > is used, a user will expect that the previous current directory will be > the one before the last :tcd command used for the current tabpage. With > the current implementation, the previous directory will be the current > directory before invoking the last ":cd" or ":tcd" or ":lcd" command. > This may not be the expected directory. > > For example, let us say you are using a separate tabpage for each > project. You use the ":tcd" command to switch to the project specific > root directory in each tabpage. Now you change the directory in one of > the tabpages to look at some files inside the corresponding project. Now > the previous directory of all the other tabpages will also be changed. > If you go to some other tabpage and use the ":tcd -" command, the > current directory will be changed to that of the other project and not > the current project. This may not be expected behavior. This does not address anything in my objection. -Manny -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2b1c0926-b470-4c41-b607-753b6d43df92%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
E353: Nothing in register * from UnconditionalPaste glp in Windows
I use Ingo Karkat's UnconditionalPaste plugin a lot, especially the glp command when I've copied something character-wise and want to paste it line-wise. I've noticed on Windows, that if I copy text from some other Windows program and attempt to paste into gvim using the glp command, I get this error message and no pasted text. E353: Nothing in register * However, pasting with the "*p command works fine. I tried to troubleshoot the problem using the command :debug normal glp but when single-stepping through the plugin, there was no error and pasting worked. I finally discovered that by setting a breakpoint at line 32 of the UnconditionalPaste#Paste function, I could use the continue command to run the plugin to that point and also use continue to finish running the plugin without error. If I set the breakpoint any later in that function, I would get the error after the first continue. If I set the breakpoint any earlier in that function, I would get the error after the second continue. Here is line 32 of that function: execute 'normal! "' . l:regName . (l:count ? l:count : '') . a:1 Since this behaved like a timing problem, I inserted this command immediately before that line. sleep 10m With that, the glp command works fine. That's my workaround for now. The vimrc I used for troubleshooting contains only this line. set clipboard^=unnamed I'm using Vim 8.1.1244 and UnconditionalPaste 4.20 on Windows 10. I've had no problems using glp on Linux, neither in gvim nor in terminal vim. Regards, Gary -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20190516215206.GC21348%40phoenix. For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
> You are right, the changes are flushed before adding one that changes > the line numbers, but the text has already changed. I'll see how that > can be fixed... Thanks very much for the quick fix; I've confirmed it's working. Thanks again for your patience; I think I now have a sufficient handle on this to try and implement deltas within govim. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn6nqEF%3DMKKfnEj%2BwkchWyuhn6-8aCtvURThYTHNa8Lm4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1336
Patch 8.1.1336
Solution: Add a few more test cases. (Masato Nishihata, closes #4374)
Files: src/testdir/test_bufline.vim, src/testdir/test_cindent.vim,
src/testdir/test_cursor_func.vim, src/testdir/test_delete.vim,
src/testdir/test_expand_func.vim, src/testdir/test_float_func.vim,
src/testdir/test_fnamemodify.vim, src/testdir/test_functions.vim
*** ../vim-8.1.1335/src/testdir/test_bufline.vim2019-04-20
15:10:06.382607095 +0200
--- src/testdir/test_bufline.vim2019-05-16 22:19:22.844760343 +0200
***
*** 8,14
hide
call assert_equal(0, setbufline(b, 1, ['foo', 'bar']))
call assert_equal(['foo'], getbufline(b, 1))
! call assert_equal(['bar'], getbufline(b, 2))
call assert_equal(['foo', 'bar'], getbufline(b, 1, 2))
exe "bd!" b
call assert_equal([], getbufline(b, 1, 2))
--- 8,14
hide
call assert_equal(0, setbufline(b, 1, ['foo', 'bar']))
call assert_equal(['foo'], getbufline(b, 1))
! call assert_equal(['bar'], getbufline(b, '$'))
call assert_equal(['foo', 'bar'], getbufline(b, 1, 2))
exe "bd!" b
call assert_equal([], getbufline(b, 1, 2))
***
*** 81,86
--- 81,87
call setline(1, ['a', 'b', 'c'])
let b = bufnr('%')
wincmd w
+ call assert_equal(1, appendbufline(b, -1, ['x']))
call assert_equal(1, appendbufline(b, 4, ['x']))
call assert_equal(1, appendbufline(1234, 1, ['x']))
call assert_equal(0, appendbufline(b, 3, ['d', 'e']))
***
*** 130,137
--- 131,141
exe "bd!" b
call assert_equal(1, deletebufline(b, 1))
+ call assert_equal(1, deletebufline(-1, 1))
+
split Xtest
call setline(1, ['a', 'b', 'c'])
+ call cursor(line('$'), 1)
let b = bufnr('%')
wincmd w
call assert_equal(1, deletebufline(b, 4))
*** ../vim-8.1.1335/src/testdir/test_cindent.vim2017-09-02
20:09:52.0 +0200
--- src/testdir/test_cindent.vim2019-05-16 22:23:43.643380089 +0200
***
*** 102,105
--- 102,115
bw!
endfunc
+ func Test_cindent_func()
+ new
+ setlocal cindent
+ call setline(1, ['int main(void)', '{', 'return 0;', '}'])
+ call assert_equal(cindent(0), -1)
+ call assert_equal(cindent(3), )
+ call assert_equal(cindent(line('$')+1), -1)
+ bwipe!
+ endfunc
+
" vim: shiftwidth=2 sts=2 expandtab
*** ../vim-8.1.1335/src/testdir/test_cursor_func.vim2019-01-15
21:12:53.602254042 +0100
--- src/testdir/test_cursor_func.vim2019-05-16 22:19:22.844760343 +0200
***
*** 25,30
--- 25,36
call cursor(9, 1)
call assert_equal([4, 1, 0, 1], getcurpos()[1:])
+ call setline(1, ["\"])
+ call cursor(1, 1, 1)
+ call assert_equal([1, 1, 1], getcurpos()[1:3])
+
+ call assert_equal(-1, cursor(-1, -1))
+
quit!
endfunc
*** ../vim-8.1.1335/src/testdir/test_delete.vim 2017-03-19 15:57:08.0
+0100
--- src/testdir/test_delete.vim 2019-05-16 22:19:22.844760343 +0200
***
*** 105,107
--- 105,112
bwipe Xdir3/subdir/Xfile
bwipe Xdir4/Xfile
endfunc
+
+ func Test_delete_errors()
+ call assert_fails('call delete()', 'E474:')
+ call assert_fails('call delete(''foo'', 0)', 'E15:')
+ endfunc
*** ../vim-8.1.1335/src/testdir/test_expand_func.vim2018-09-10
21:04:09.872392623 +0200
--- src/testdir/test_expand_func.vim2019-05-16 22:19:22.844760343 +0200
***
*** 64,66
--- 64,75
call assert_equal(64, str2nr(trim(execute('Flnum'
delcommand Flnum
endfunc
+
+ func Test_expand()
+ new
+ call assert_equal("", expand('%:S'))
+ call assert_equal('3', expand(''))
+ call assert_equal(['4'], expand('', v:false, v:true))
+ " Don't add any line above this, otherwise will change.
+ quit
+ endfunc
*** ../vim-8.1.1335/src/testdir/test_float_func.vim 2019-04-04
13:44:31.035594516 +0200
--- src/testdir/test_float_func.vim 2019-05-16 22:19:22.844760343 +0200
***
*** 13,18
--- 13,19
call assert_equal('inf', string(abs(1.0/0.0)))
call assert_equal('inf', string(abs(-1.0/0.0)))
call assert_equal('nan', string(abs(0.0/0.0)))
+ call assert_equal('12', string(abs('12abc')))
call assert_equal('12', string(abs('-12abc')))
call assert_fails("call abs([])", 'E745:')
call assert_fails("call abs({})", 'E728:')
*** ../vim-8.1.1335/src/testdir/test_fnamemodify.vim2017-03-19
15:48:35.0 +0100
--- src/testdir/test_fnamemodify.vim2019-05-16 22:19:22.844760343 +0200
***
*** 45,53
let $HOME = save_home
let = save_shell
endfunc
-
- func Test_expand()
- new
- call assert_equal("", expand('%:S'))
- quit
- endfunc
--- 45,47
*** ../vim-8.1.1335/src/testdir/test_functions.vim 2019-04-05
22:50:35.025737353 +0200
--- src/testdir/test_functions.vim 2019-05-16 22:19:22.844760343 +0200
***
*** 52,57
--- 52,58
endif
Patch 8.1.1335
Patch 8.1.1335
Problem:Listener callback is called after inserting text.
Solution: Flush the changes before inserting or deleting a line. Store
changes per buffer.
Files: src/change.c, src/proto/change.pro, src/memline.c,
src/structs.h, src/testdir/test_listener.vim
*** ../vim-8.1.1334/src/change.c2019-05-15 22:45:33.956067651 +0200
--- src/change.c2019-05-16 21:44:23.932078618 +0200
***
*** 152,183
}
#ifdef FEAT_EVAL
- static list_T *recorded_changes = NULL;
static long next_listener_id = 0;
/*
! * Record a change for listeners added with listener_add().
*/
! static void
! may_record_change(
! linenr_T lnum,
! colnr_T col,
! linenr_T lnume,
! long xtra)
{
! dict_T*dict;
!
! if (curbuf->b_listener == NULL)
! return;
!
! // If the new change is going to change the line numbers in already listed
! // changes, then flush.
! if (recorded_changes != NULL && xtra != 0)
{
listitem_T *li;
linenr_Tnr;
! for (li = recorded_changes->lv_first; li != NULL; li = li->li_next)
{
nr = (linenr_T)dict_get_number(
li->li_tv.vval.v_dict, (char_u *)"lnum");
--- 152,181
}
#ifdef FEAT_EVAL
static long next_listener_id = 0;
/*
! * Check if the change at "lnum" / "col" is above or overlaps with an existing
! * changed. If above then flush changes and invoke listeners.
! * If "merge" is TRUE do the merge.
! * Returns TRUE if the change was merged.
*/
! static int
! check_recorded_changes(
! buf_T *buf,
! linenr_Tlnum,
! colnr_T col,
! linenr_Tlnume,
! longxtra,
! int merge)
{
! if (buf->b_recorded_changes != NULL && xtra != 0)
{
listitem_T *li;
linenr_Tnr;
! for (li = buf->b_recorded_changes->lv_first; li != NULL;
! li = li->li_next)
{
nr = (linenr_T)dict_get_number(
li->li_tv.vval.v_dict, (char_u *)"lnum");
***
*** 187,221
&& col + 1 == (colnr_T)dict_get_number(
li->li_tv.vval.v_dict, (char_u *)"col"))
{
! dictitem_T *di;
!
! // Same start point and nothing is following, entries can
! // be merged.
! di = dict_find(li->li_tv.vval.v_dict, (char_u *)"end", -1);
! nr = tv_get_number(>di_tv);
! if (lnume > nr)
! di->di_tv.vval.v_number = lnume;
! di = dict_find(li->li_tv.vval.v_dict,
(char_u *)"added", -1);
! di->di_tv.vval.v_number += xtra;
! return;
}
-
- // the current change is going to make the line number in the
- // older change invalid, flush now
- invoke_listeners(curbuf);
- break;
}
}
}
! if (recorded_changes == NULL)
{
! recorded_changes = list_alloc();
! if (recorded_changes == NULL) // out of memory
return;
! ++recorded_changes->lv_refcount;
! recorded_changes->lv_lock = VAR_FIXED;
}
dict = dict_alloc();
--- 185,248
&& col + 1 == (colnr_T)dict_get_number(
li->li_tv.vval.v_dict, (char_u *)"col"))
{
! if (merge)
! {
! dictitem_T *di;
!
! // Same start point and nothing is following, entries
! // can be merged.
! di = dict_find(li->li_tv.vval.v_dict,
! (char_u *)"end", -1);
! nr = tv_get_number(>di_tv);
! if (lnume > nr)
! di->di_tv.vval.v_number = lnume;
! di = dict_find(li->li_tv.vval.v_dict,
(char_u *)"added", -1);
! di->di_tv.vval.v_number += xtra;
! return TRUE;
! }
! }
! else
! {
! // the current change is going to make the line number in
! // the older change invalid, flush now
! invoke_listeners(curbuf);
! break;
}
}
}
}
+ return FALSE;
+ }
! /*
! * Record a change for listeners added with listener_add().
! * Always for the current buffer.
! */
! static void
!
Re: Listener functionality
Paul Jolly wrote:
> > > Again, apologies if I'm missing something obvious here.
> >
> > This is not inserting a line but splitting a line. There could be text
> > after the insertion point, which moves to the next line when pressing
> > Enter. In your case there might be nothing, but that doesn't cause a
> > different change item. You can see "lnum" and "end" are not the same
> > here, meaning that this line might be changed.
>
> Bram - that makes total sense, thanks very much for your patience.
>
> One further issue I'm seeing relates to how undos are processed.
>
> Now with the following:
>
> function EchoChanges(bufnr, start, end, added, changes)
> redir >> /tmp/listener.log | echom getbufline(a:bufnr, 0, "$")
> a:changes | redir END
> endfunction
> call listener_add("EchoChanges")
>
> loaded via -u, with an initial file of:
>
> Line 1
> Line 2 #
> Line 3
> Line 4 #
> Line 5
> Line 6 #
>
> and then executing the following commands:
>
> :g/#/d
> u
>
> I see the following log line for the global command (which makes sense):
>
> ['Line 1', 'Line 3', 'Line 5'] [{'lnum': 2, 'col': 1, 'added': -1,
> 'end': 3}, {'lnum': 3, 'col': 1, 'added': -1, 'end': 4}, {'lnum': 4,
> 'col': 1, 'added': -1, 'end': 5}]
>
> And then the following sequence as a result of the undo:
>
> ['Line 1', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #'] [{'lnum': 4,
> 'col': 1, 'added': 1, 'end': 4}]
> ['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
> [{'lnum': 3, 'col': 1, 'added': 1, 'end': 3}]
> ['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
> [{'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
>
> Now I'm guessing the undo is being processed step-by-step (so to
> speak) in reverse.
>
> So the first and second lines look wrong, because they appear to show
> the buffer already has the "next" undo applied.
>
> Again, apologies if (as is likely) I'm missing something obvious.
You are right, the changes are flushed before adding one that changes
the line numbers, but the text has already changed. I'll see how that
can be fixed...
--
|
Ceci n'est pas une pipe.
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201905162012.x4GKCGPB010443%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
> > Again, apologies if I'm missing something obvious here.
>
> This is not inserting a line but splitting a line. There could be text
> after the insertion point, which moves to the next line when pressing
> Enter. In your case there might be nothing, but that doesn't cause a
> different change item. You can see "lnum" and "end" are not the same
> here, meaning that this line might be changed.
Bram - that makes total sense, thanks very much for your patience.
One further issue I'm seeing relates to how undos are processed.
Now with the following:
function EchoChanges(bufnr, start, end, added, changes)
redir >> /tmp/listener.log | echom getbufline(a:bufnr, 0, "$")
a:changes | redir END
endfunction
call listener_add("EchoChanges")
loaded via -u, with an initial file of:
Line 1
Line 2 #
Line 3
Line 4 #
Line 5
Line 6 #
and then executing the following commands:
:g/#/d
u
I see the following log line for the global command (which makes sense):
['Line 1', 'Line 3', 'Line 5'] [{'lnum': 2, 'col': 1, 'added': -1,
'end': 3}, {'lnum': 3, 'col': 1, 'added': -1, 'end': 4}, {'lnum': 4,
'col': 1, 'added': -1, 'end': 5}]
And then the following sequence as a result of the undo:
['Line 1', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #'] [{'lnum': 4,
'col': 1, 'added': 1, 'end': 4}]
['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
[{'lnum': 3, 'col': 1, 'added': 1, 'end': 3}]
['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
[{'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
Now I'm guessing the undo is being processed step-by-step (so to
speak) in reverse.
So the first and second lines look wrong, because they appear to show
the buffer already has the "next" undo applied.
Again, apologies if (as is likely) I'm missing something obvious.
Thanks
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CACoUkn5ndNDTLWff_kK_wyB8dQuLXo1CC5Mt0x_LQm0ZrNbGhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Patch 8.1.1334
Patch 8.1.1334
Problem:When buffer is hidden "F" in 'shortmess' is not used.
Solution: Check the "F" flag in 'shortmess' when the buffer is already
loaded. (Jason Franklin) Add test_getvalue() to be able to test
this.
Files: src/buffer.c, src/evalfunc.c, src/testdir/test_options.vim,
runtime/doc/eval.txt
*** ../vim-8.1.1333/src/buffer.c2019-04-28 22:25:03.244480028 +0200
--- src/buffer.c2019-05-16 20:10:50.813287936 +0200
***
*** 1742,1750
}
else
{
! if (!msg_silent)
! need_fileinfo = TRUE; /* display file info after redraw */
! (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
curwin->w_topline = 1;
#ifdef FEAT_DIFF
curwin->w_topfill = 0;
--- 1742,1753
}
else
{
! if (!msg_silent && !shortmess(SHM_FILEINFO))
! need_fileinfo = TRUE; // display file info after redraw
!
! // check if file changed
! (void)buf_check_timestamp(curbuf, FALSE);
!
curwin->w_topline = 1;
#ifdef FEAT_DIFF
curwin->w_topfill = 0;
*** ../vim-8.1.1333/src/evalfunc.c 2019-05-14 21:20:32.593441058 +0200
--- src/evalfunc.c 2019-05-16 20:09:47.749554193 +0200
***
*** 442,447
--- 442,448
static void f_test_alloc_fail(typval_T *argvars, typval_T *rettv);
static void f_test_autochdir(typval_T *argvars, typval_T *rettv);
static void f_test_feedinput(typval_T *argvars, typval_T *rettv);
+ static void f_test_getvalue(typval_T *argvars, typval_T *rettv);
static void f_test_option_not_set(typval_T *argvars, typval_T *rettv);
static void f_test_override(typval_T *argvars, typval_T *rettv);
static void f_test_refcount(typval_T *argvars, typval_T *rettv);
***
*** 991,996
--- 992,998
{"test_autochdir",0, 0, f_test_autochdir},
{"test_feedinput",1, 1, f_test_feedinput},
{"test_garbagecollect_now", 0, 0, f_test_garbagecollect_now},
+ {"test_getvalue", 1, 1, f_test_getvalue},
{"test_ignore_error", 1, 1, f_test_ignore_error},
{"test_null_blob",0, 0, f_test_null_blob},
#ifdef FEAT_JOB_CHANNEL
***
*** 14413,14418
--- 14415,14439
}
/*
+ * "test_getvalue({name})" function
+ */
+ static void
+ f_test_getvalue(typval_T *argvars, typval_T *rettv)
+ {
+ if (argvars[0].v_type != VAR_STRING)
+ emsg(_(e_invarg));
+ else
+ {
+ char_u *name = tv_get_string([0]);
+
+ if (STRCMP(name, (char_u *)"need_fileinfo") == 0)
+ rettv->vval.v_number = need_fileinfo;
+ else
+ semsg(_(e_invarg2), name);
+ }
+ }
+
+ /*
* "test_option_not_set({name})" function
*/
static void
*** ../vim-8.1.1333/src/testdir/test_options.vim2019-04-03
22:52:30.112905530 +0200
--- src/testdir/test_options.vim2019-05-16 20:09:36.533601448 +0200
***
*** 470,482
--- 470,488
call assert_match('file2', execute('bn', ''))
set shortmess+=F
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
set hidden
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
set nohidden
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
call assert_true(empty(execute('bn', '')))
+ call assert_false(test_getvalue('need_fileinfo'))
set shortmess&
call assert_match('file1', execute('bn', ''))
call assert_match('file2', execute('bn', ''))
*** ../vim-8.1.1333/runtime/doc/eval.txt2019-05-14 21:20:32.597441034
+0200
--- runtime/doc/eval.txt2019-05-16 20:07:50.766045098 +0200
***
*** 2701,2706
--- 2701,2707
test_autochdir() noneenable 'autochdir' during startup
test_feedinput({string}) noneadd key sequence to input buffer
test_garbagecollect_now() nonefree memory right now for testing
+ test_getvalue({string}) any get value of an internal
variable
test_ignore_error({expr}) noneignore a specific error
test_null_blob() Blobnull value for testing
test_null_channel() Channel null value for testing
***
*** 9894,9899
--- 9895,9905
internally, and |v:testing| must have been set before calling
any function.
+ test_getvalue({name}) *test_getvalue()*
+ Get the value of an internal variable. These values for
+ {name} are supported:
+ need_fileinfo
+
test_ignore_error({expr})
Re: [BUG] :bn/:bp do not respect shortmess+=F when 'hidden' is set (ATTN: chrisbra)
Jason Franklin wrote:
> To reproduce:
>
> $ ./vim --clean # at latest commit on master
>
> :set hidden shortmess+=F
> :e file1
> :e file2
> " Notice, no messages are output, as expected.
> :bn
> :bp
> " Notice fileinfo messages are output.
>
> The main problem appears to be in the enter_buffer() function:
>
> /* Make sure the buffer is loaded. */
> if (curbuf->b_ml.ml_mfp == NULL)/* need to load the file */
> {
> /* If there is no filetype, allow for detecting one. Esp. useful for
> * ":ball" used in a autocommand. If there already is a filetype we
> * might prefer to keep it. */
> if (*curbuf->b_p_ft == NUL)
> did_filetype = FALSE;
>
> open_buffer(FALSE, NULL, 0);
> }
> else
> {
> if (!msg_silent)
> need_fileinfo = TRUE; /* display file info after redraw */
> (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
>
> When 'nohidden', the first path is executed (we have to load
> the buffer). When 'hidden' is set, the "else" is executed, and so
> we rely on msg_silent to avoid the fileinfo message. However, msg_silent
> is not reliably set for shortmess+=F in all scenarios.
>
> Thus, I recommend the following patch:
>
> diff --git a/src/buffer.c b/src/buffer.c
> index e825a99..08595a9 100644
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -1742,9 +1742,9 @@ enter_buffer(buf_T *buf)
> }
> else
> {
> - if (!msg_silent)
> - need_fileinfo = TRUE; /* display file info after redraw */
> - (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
> + if (!msg_silent && !shortmess(SHM_FILEINFO))
> + need_fileinfo = TRUE;
> + (void)buf_check_timestamp(curbuf, FALSE);
> curwin->w_topline = 1;
> #ifdef FEAT_DIFF
> curwin->w_topfill = 0;
>
> This fixes the problem with :bn/:bp, and all of the tests still pass.
Thanks, that looks OK.
> At this point, I also want to point out a problem with the existing test,
> reproduced below:
>
> func Test_shortmess_F2()
> e file1
> e file2
> call assert_match('file1', execute('bn', ''))
> call assert_match('file2', execute('bn', ''))
> set shortmess+=F
> call assert_true(empty(execute('bn', '')))
> call assert_true(empty(execute('bn', '')))
> set hidden
> call assert_true(empty(execute('bn', '')))
> call assert_true(empty(execute('bn', '')))
> set nohidden
> call assert_true(empty(execute('bn', '')))
> call assert_true(empty(execute('bn', '')))
> set shortmess&
> call assert_match('file1', execute('bn', ''))
> call assert_match('file2', execute('bn', ''))
> bwipe
> bwipe
> endfunc
>
> This test is correct, meaning it should pass for the commands to be considered
> working properly. The question is: Why doesn't this test catch the problem I
> noticed here?
>
> Well, we can go back to the master branch (no patch) and see:
>
> $ ./vim --clean
>
> :set hidden
> :e file1
> :e file2
> :let x = execute('bn', '')
> " Notice, the message appears, as expected.
> :echo x
> " But, it wasn't captured!
>
> I'm not sure how to fix this problem. The bug appears to be that execute()
> does not capture messages that are set to be printed after the next redraw,
> as opposed to being printed immediately. Is my understanding correct here?
You cannot get this message from execute(), because it only happens in
the main loop, after commands have been executed. I think the only way
is to check whether the need_fileinfo flag is set. And that only works
if we add a function for that.
--
"Beware of bugs in the above code; I have only proved
it correct, not tried it." -- Donald Knuth
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201905161830.x4GIU5OI021535%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
Paul Jolly wrote:
> > The help is wrong, it should say "line above which".
> > Of course we could change the implementation, but it would be an exception.
>
> Ah, if it's "line above which" then I think there is a problem with
> the following sequence:
>
> iasdf
>
> which gives:
>
> [{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 2, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 3, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 4, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 5, 'added': 1, 'end': 2}]
>
> Again, apologies if I'm missing something obvious here.
This is not inserting a line but splitting a line. There could be text
after the insertion point, which moves to the next line when pressing
Enter. In your case there might be nothing, but that doesn't cause a
different change item. You can see "lnum" and "end" are not the same
here, meaning that this line might be changed.
--
Any resemblance between the above views and those of my employer, my terminal,
or the view out my window are purely coincidental. Any resemblance between
the above and my own views is non-deterministic. The question of the
existence of views in the absence of anyone to hold them is left as an
exercise for the reader. The question of the existence of the reader is left
as an exercise for the second god coefficient. (A discussion of
non-orthogonal, non-integral polytheism is beyond the scope of this article.)
(Ralph Jennings)
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201905161607.x4GG7nFg007387%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
> The help is wrong, it should say "line above which".
> Of course we could change the implementation, but it would be an exception.
Ah, if it's "line above which" then I think there is a problem with
the following sequence:
iasdf
which gives:
[{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 2, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 3, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 4, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 5, 'added': 1, 'end': 2}]
Again, apologies if I'm missing something obvious here.
Thanks,
Paul
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CACoUkn7twJqXAdZOBJ5Ho-a8b4wdm0xSz6XP6Xtg%2B4SqnxROGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
Paul Jolly wrote:
> > I'll make a patch that does this, please check it out.
>
> Hi Bram - I've only spotted one potential issue working with v8.1.1333.
>
> Using the following vimrc
>
> function EchoChanges(bufnr, start, end, added, changes)
> redir >> /tmp/listener.log | echom a:changes | redir END
> endfunction
> call listener_add("EchoChanges")
>
> via -u and then issuing the following keys:
>
> iasdfyyp
>
> gives the following log sequence:
>
> [{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 2, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 3, 'added': 0, 'end': 2}]
> [{'lnum': 1, 'col': 4, 'added': 0, 'end': 2}]
> [{'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
>
> It's the last line that I think is wrong; it's an add and according to the
> docs:
>
> When lines are inserted the values are:
> lnum line below which the new line is added
> end equal to "lnum"
> added number of lines inserted
> col 1
>
> I think lnum should be 1, no?
>
> Apologies if I'm missing something obvious here.
The help is wrong, it should say "line above which".
Of course we could change the implementation, but it would be an exception.
--
Mrs Abbott: I'm a paediatrician.
Basil: Feet?
Mrs Abbott: Children.
Sybil: Oh, Basil!
Basil: Well, children have feet, don't they? That's how they move
around, my dear. You must take a look next time, it's most
interesting. (Fawlty Towers)
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201905161501.x4GF17Rh029036%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
[BUG] :bn/:bp do not respect shortmess+=F when 'hidden' is set (ATTN: chrisbra)
To reproduce:
$ ./vim --clean # at latest commit on master
:set hidden shortmess+=F
:e file1
:e file2
" Notice, no messages are output, as expected.
:bn
:bp
" Notice fileinfo messages are output.
The main problem appears to be in the enter_buffer() function:
/* Make sure the buffer is loaded. */
if (curbuf->b_ml.ml_mfp == NULL)/* need to load the file */
{
/* If there is no filetype, allow for detecting one. Esp. useful for
* ":ball" used in a autocommand. If there already is a filetype we
* might prefer to keep it. */
if (*curbuf->b_p_ft == NUL)
did_filetype = FALSE;
open_buffer(FALSE, NULL, 0);
}
else
{
if (!msg_silent)
need_fileinfo = TRUE; /* display file info after redraw */
(void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
When 'nohidden', the first path is executed (we have to load
the buffer). When 'hidden' is set, the "else" is executed, and so
we rely on msg_silent to avoid the fileinfo message. However, msg_silent
is not reliably set for shortmess+=F in all scenarios.
Thus, I recommend the following patch:
diff --git a/src/buffer.c b/src/buffer.c
index e825a99..08595a9 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1742,9 +1742,9 @@ enter_buffer(buf_T *buf)
}
else
{
- if (!msg_silent)
- need_fileinfo = TRUE; /* display file info after redraw */
- (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
+ if (!msg_silent && !shortmess(SHM_FILEINFO))
+ need_fileinfo = TRUE;
+ (void)buf_check_timestamp(curbuf, FALSE);
curwin->w_topline = 1;
#ifdef FEAT_DIFF
curwin->w_topfill = 0;
This fixes the problem with :bn/:bp, and all of the tests still pass.
At this point, I also want to point out a problem with the existing test,
reproduced below:
func Test_shortmess_F2()
e file1
e file2
call assert_match('file1', execute('bn', ''))
call assert_match('file2', execute('bn', ''))
set shortmess+=F
call assert_true(empty(execute('bn', '')))
call assert_true(empty(execute('bn', '')))
set hidden
call assert_true(empty(execute('bn', '')))
call assert_true(empty(execute('bn', '')))
set nohidden
call assert_true(empty(execute('bn', '')))
call assert_true(empty(execute('bn', '')))
set shortmess&
call assert_match('file1', execute('bn', ''))
call assert_match('file2', execute('bn', ''))
bwipe
bwipe
endfunc
This test is correct, meaning it should pass for the commands to be considered
working properly. The question is: Why doesn't this test catch the problem I
noticed here?
Well, we can go back to the master branch (no patch) and see:
$ ./vim --clean
:set hidden
:e file1
:e file2
:let x = execute('bn', '')
" Notice, the message appears, as expected.
:echo x
" But, it wasn't captured!
I'm not sure how to fix this problem. The bug appears to be that execute()
does not capture messages that are set to be printed after the next redraw,
as opposed to being printed immediately. Is my understanding correct here?
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/50b36ba4-ddfa-4a14-acae-dd8aa062e72f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Listener functionality
> I'll make a patch that does this, please check it out.
Hi Bram - I've only spotted one potential issue working with v8.1.1333.
Using the following vimrc
function EchoChanges(bufnr, start, end, added, changes)
redir >> /tmp/listener.log | echom a:changes | redir END
endfunction
call listener_add("EchoChanges")
via -u and then issuing the following keys:
iasdfyyp
gives the following log sequence:
[{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 2, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 3, 'added': 0, 'end': 2}]
[{'lnum': 1, 'col': 4, 'added': 0, 'end': 2}]
[{'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
It's the last line that I think is wrong; it's an add and according to the docs:
When lines are inserted the values are:
lnum line below which the new line is added
end equal to "lnum"
added number of lines inserted
col 1
I think lnum should be 1, no?
Apologies if I'm missing something obvious here.
Thanks
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CACoUkn4RV_s7LGXTG_0KpvT4-pSB1boa3-Ee9i0huCUoYAvinw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: CursorLineMoved
> > See https://github.com/vim/vim/issues/3127 for that I think. > > Indeed, just so long as this is triggered for all visible windows when > their viewport changes (e.g. window resize) Sorry, that sent too quickly. I meant to finish by saying thank you for linking to that issue; I've now added a comment there and linked back to this discussion. Best, Paul -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn4Cbq7azCW%3DOrq7nGys1L%3DEhG0wriw4a31im%2Bkc8oBnFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: CursorLineMoved
> See https://github.com/vim/vim/issues/3127 for that I think. Indeed, just so long as this is triggered for all visible windows when their viewport changes (e.g. window resize) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn616aGVczVtcsZ4J%2BkGCO3dtdqPWfpAkZg8jPjaf-3B_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: CursorLineMoved
On Do, 16 Mai 2019, Paul Jolly wrote: > > This doesn't exist yet. To consider such an addition: > > - - Is there a need? Now, we've already got at least two use cases (from > > you and me). > > - - Is it easy to implement with few changes? You say it is. > > - - Does it help improving performance? If the core C code essentially > > does the same as a Vimscript would do, all we'd save is a little > > interpretation overhead. But if there's a better place (e.g. the > > 'cursorline' drawing code also has to consider the current line > > number), it could be more efficient. > > - - Does it improve the Vimscript API? A dedicated CursorLineMoved event > > type provides precise semantics, and would avoid boilerplate code (if > > just a single conditional here). > > - - Is this easy to emulate? Only future Vim versions will have the new > > event. Plugin writers still have to provide a fallback implementation > > for older versions. Here, I think this is not a problem, as this is > > just about efficiency gains. I am against it as long as current vimscript solutions are being able to handle this case (which seems to be the case). > > The only thing I would suggest we consider at the same time is an > event that is triggered pre/post viewport changes. And by viewport, I > mean the information returned by getwininfo() (minus the variable > key), along with the current window number. Current line number > could/should be part of this. > > My proposed use case here is an AST-based syntax highlighting. > > I will note however that this would likely require some changes to > matchaddpos/deletematch to make them more batch friendly. > > In https://github.com/myitcv/govim/pull/24 I have simulated such a > viewport changed event using timers (ideally I would have the new > highlights be added in response to the pre viewport changed event). > But the lag because of the multiple calls required to > matchaddpos/deletepos over a channel start to become apparent. See https://github.com/vim/vim/issues/3127 for that I think. Best, Christian -- Das ist die wahre Symbolik, wo das Besondere das Allgemeinere repräsentiert, nicht als Traum und Schatten, sondern als lebendig augenblickliche Offenbarung des Unerforschlichen. -- Goethe, Maximen und Reflektionen, Nr. 451 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20190516100319.GE2769%40256bit.org. For more options, visit https://groups.google.com/d/optout.
Re: CursorLineMoved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13-May-2019 21:20 +0200, Edward Peschko wrote: > All, > > I'd like to be able to write a macro that could be triggered each time > the line changed - so that I could write an autocmd to say > automatically split a logfile in vim that has stack traces to show the > corresponding code for each line in that stack trace. > > However, the closest thing that was brought to my attention was > CursorMoved, which IMO is way too broad. After all I don't want a > potentially expensive macro to be done *every* single time the cursor > is moved, just when it moves lines. I've encountered the same use case (also around logfile processing - the conditional is here [1]); if you do a quick comparison with the stored last line number at the beginning of the :autocmd and return early if the line hasn't changed, the performance seems to be okay (for me, so far). > So I was thinking CursorLineMoved. Is there such a thing? If not, it > looks fairly easy to add, but i'm not all that keen on supporting my > own vim, so would a patch like this be welcomed? This doesn't exist yet. To consider such an addition: - - Is there a need? Now, we've already got at least two use cases (from you and me). - - Is it easy to implement with few changes? You say it is. - - Does it help improving performance? If the core C code essentially does the same as a Vimscript would do, all we'd save is a little interpretation overhead. But if there's a better place (e.g. the 'cursorline' drawing code also has to consider the current line number), it could be more efficient. - - Does it improve the Vimscript API? A dedicated CursorLineMoved event type provides precise semantics, and would avoid boilerplate code (if just a single conditional here). - - Is this easy to emulate? Only future Vim versions will have the new event. Plugin writers still have to provide a fallback implementation for older versions. Here, I think this is not a problem, as this is just about efficiency gains. - -- regards, ingo [1] https://github.com/inkarkat/vim-LogViewer/blob/eb5f2601d3521b001612002d609386713d2ad707/autoload/LogViewer.vim#L200-L203 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJc3S1pAAoJEA7ziXlAzQ/vwXEH/1DJ5Gs/wv3/gSpnimVEa9SX lEAtcaGgD3ko7J88rla1l4HoyQddOwRiLoqvKrlobC7QbizLHJsCXEHa1LL0/6Q0 ImduN5PQxUIml5J5EbH2pBvfLvSqjOWKLrIiLbnjuMLBMJXr3Ia4XbVyEPCgHMdu cG0X0pqtlJw2+pozYxWUj5bYETmd4OgWqOajPRXZZzGUG37O7dJvlvIuDVctlZtF OWRcaS2BGMy5yX0ZRTnmbXlv7wpEs3KhMo5G7GcXiid2o4yIZwRLgAXReiRT3lbH gr1jKgxMFObUVTBnbYy+OHxOtIyfGS+aHyb9SazJxmpE0is7Wpy0zZ2tFvEyf/I= =SLMR -END PGP SIGNATURE- -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0e53c6cb-1a8c-a347-96f8-cf0a04f2a4b2%40ingo-karkat.de. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Makefile changes (#4376)
I suggest making your changes in your own git branch. My workflow is git checkout master git pull git checkout john git merge master I find this cleaner and more flexible than git stash. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cc5a0e3a-86a2-438f-9212-2a146a2947b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: E484 after GVIM update
Hi,
2019/5/16 Thu 15:50:40 UTC+9 Ni Va wrote:
> Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> > Hi,
> >
> > 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > > > On Tuesday, April 30, 2019 at 3:31:31 AM UTC-4, niva...@gmail.com
> > > > > wrote:
> > > > > > Le mardi 30 avril 2019 08:49:27 UTC+2, niva...@gmail.com a écrit :
> > > > > > > Le mardi 30 avril 2019 07:46:42 UTC+2, Christian Brabandt a écrit
> > > > > > > :
> > > > > > > > On Mo, 29 Apr 2019, Blay263 wrote:
> > > > > > > >
> > > > > > > > > After updating my vim version I am getting the error below:
> > > > > > > > >
> > > > > > > > > E484: Can't open file
> > > > > > > > > C:\Users\\AppData\Local\Temp\VIoCC2F.tmp
> > > > > > > > >
> > > > > > > > > I am using GVIM on windows with the WSL subsytem. It looks
> > > > > > > > > like the way the escape sequences work has changed.
> > > > > > > >
> > > > > > > > So what is in that particular line of your .vimrc? Might
> > > > > > > > already be
> > > > > > > > fixed by 8.1.1239
> > > > > > > >
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Christian
> > > > > > > > --
> > > > > > > > Bauer Pichler fährt zur Kur. Schon bald bekommt er Post von
> > > > > > > > seiner Frau:
> > > > > > > > "Heute ist unser Ochse eingegangen. Nun weiß ich nicht so
> > > > > > > > recht, soll ich
> > > > > > > > einen neuen kaufen oder auf Dich warten?"
> > > > > > >
> > > > > > > Same problem at startup
> > > > > > >
> > > > > > > E484: Can't open file
> > > > > > > C:\Users\NICOLA~1.VAL\AppData\Local\Temp\VIo9A
> > > > > > > 54.tmp
> > > > > > >
> > > > > > > line 184 of _vimrc:
> > > > > > > let g:Explorer_RubyLibPath=substitute(fnamemodify(system('which
> > > > > > > '.g:Explorer_RubyLibName),":p"),':..',':',"")
> > > > > >
> > > > > > Same problem with Vim.8.1.1239 patch
> > > > >
> > > > > Line 645:
> > > > > let g:startify_custom_header =
> > > > > \ map(split(system('fortune -s'), '\n'), '" ". v:val') +
> > > > > ['']
> > > >
> > > > This version works fine:
> > >
> > > Under windows 10, gvim.8.1.1239 launched in administrator or not, there
> > > is a change using system func like that:
> > > let g:Explorer_RubyLibName = 'msvcrt-ruby260.dll'
> > > let try1=system('which '.g:Explorer_RubyLibName)
> > >
> > >
> > > It causes this kind of error accessing temp file:
> > > E484: Can't open file C:\Users\FOO~1.BAR\AppData\Local\Temp\VIoC1
> > > 0E.tmp
> >
> > Can you bisect to find the offending patch?
> >
> > Regards,
> > Ken Takata
>
> Sorry I tried to rollback until 8.1.1210 but since I got this kind of errors
> (attached) I cannot bisect.
Then, can you edit proto/usercmd.pro and change "compl" to "complp" manually?
Regards,
Ken Takata
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/34bc0106-a54a-4fdd-9ee9-fa0e8302c5b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: E484 after GVIM update
Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> Hi,
>
> 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > > On Tuesday, April 30, 2019 at 3:31:31 AM UTC-4, niva...@gmail.com wrote:
> > > > > Le mardi 30 avril 2019 08:49:27 UTC+2, niva...@gmail.com a écrit :
> > > > > > Le mardi 30 avril 2019 07:46:42 UTC+2, Christian Brabandt a écrit :
> > > > > > > On Mo, 29 Apr 2019, Blay263 wrote:
> > > > > > >
> > > > > > > > After updating my vim version I am getting the error below:
> > > > > > > >
> > > > > > > > E484: Can't open file
> > > > > > > > C:\Users\\AppData\Local\Temp\VIoCC2F.tmp
> > > > > > > >
> > > > > > > > I am using GVIM on windows with the WSL subsytem. It looks like
> > > > > > > > the way the escape sequences work has changed.
> > > > > > >
> > > > > > > So what is in that particular line of your .vimrc? Might already
> > > > > > > be
> > > > > > > fixed by 8.1.1239
> > > > > > >
> > > > > > >
> > > > > > > Best,
> > > > > > > Christian
> > > > > > > --
> > > > > > > Bauer Pichler fährt zur Kur. Schon bald bekommt er Post von
> > > > > > > seiner Frau:
> > > > > > > "Heute ist unser Ochse eingegangen. Nun weiß ich nicht so recht,
> > > > > > > soll ich
> > > > > > > einen neuen kaufen oder auf Dich warten?"
> > > > > >
> > > > > > Same problem at startup
> > > > > >
> > > > > > E484: Can't open file C:\Users\NICOLA~1.VAL\AppData\Local\Temp\VIo9A
> > > > > > 54.tmp
> > > > > >
> > > > > > line 184 of _vimrc:
> > > > > > let g:Explorer_RubyLibPath=substitute(fnamemodify(system('which
> > > > > > '.g:Explorer_RubyLibName),":p"),':..',':',"")
> > > > >
> > > > > Same problem with Vim.8.1.1239 patch
> > > >
> > > > Line 645:
> > > > let g:startify_custom_header =
> > > > \ map(split(system('fortune -s'), '\n'), '" ". v:val') +
> > > > ['']
> > >
> > > This version works fine:
> >
> > Under windows 10, gvim.8.1.1239 launched in administrator or not, there is
> > a change using system func like that:
> > let g:Explorer_RubyLibName = 'msvcrt-ruby260.dll'
> > let try1=system('which '.g:Explorer_RubyLibName)
> >
> >
> > It causes this kind of error accessing temp file:
> > E484: Can't open file C:\Users\FOO~1.BAR\AppData\Local\Temp\VIoC1
> > 0E.tmp
>
> Can you bisect to find the offending patch?
>
> Regards,
> Ken Takata
Sorry I tried to rollback until 8.1.1210 but since I got this kind of errors
(attached) I cannot bisect.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/d731e6e1-cb29-428e-b979-48a8940d1e36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
