Patch 7.4.1869
Patch 7.4.1869
Problem:Can't build with old version of Perl.
Solution: Define PERLIO_FUNCS_DECL. (Tom G. Christensen)
Files: src/if_perl.xs
*** ../vim-7.4.1868/src/if_perl.xs 2016-06-01 20:31:40.273551014 +0200
--- src/if_perl.xs 2016-06-02 11:53:17.220790361 +0200
***
*** 61,66
--- 61,77
# include
#endif
+ /* Workaround for perl < 5.8.7 */
+ #ifndef PERLIO_FUNCS_DECL
+ # ifdef PERLIO_FUNCS_CONST
+ # define PERLIO_FUNCS_DECL(funcs) const PerlIO_funcs funcs
+ # define PERLIO_FUNCS_CAST(funcs) (PerlIO_funcs*)(funcs)
+ # else
+ # define PERLIO_FUNCS_DECL(funcs) PerlIO_funcs funcs
+ # define PERLIO_FUNCS_CAST(funcs) (funcs)
+ # endif
+ #endif
+
/*
* Work around clashes between Perl and Vim namespace.proto.h doesn't
* include if_perl.pro and perlsfio.pro when IN_PERL_FILE is defined, because
*** ../vim-7.4.1868/src/version.c 2016-06-01 23:08:35.253421504 +0200
--- src/version.c 2016-06-02 11:49:58.940793088 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1869,
/**/
--
hundred-and-one symptoms of being an internet addict:
33. You name your children Eudora, Mozilla and Dotcom.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1863
Ken Takata wrote: > Hi Bram, > > 2016/6/2 Thu 3:31:57 UTC+9 Bram Moolenaar wrote: > > Patch 7.4.1863 > > Problem:Compiler warnings on Win64. > > Solution: Adjust types, add type casts. (Ken Takata) > > Files: src/if_mzsch.c, src/if_perl.xs, src/if_ruby.c, src/version.c > > Sorry, this patch was not enough. > Here is an additional fix: > > --- a/src/if_mzsch.c > +++ b/src/if_mzsch.c > @@ -849,7 +849,7 @@ static long range_end; > static int mz_threads_allow = 0; > > #if defined(FEAT_GUI_W32) > -static void CALLBACK timer_proc(HWND, UINT, UINT, DWORD); > +static void CALLBACK timer_proc(HWND, UINT, UINT_PTR, DWORD); > static UINT timer_id = 0; > #elif defined(FEAT_GUI_GTK) > # if GTK_CHECK_VERSION(3,0,0) Thanks! -- My sister Cecilia opened a computer store in Hawaii. She sells C shells by the seashore. /// 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1870
Patch 7.4.1870 (after 7.4.1863)
Problem:One more Win64 compiler warning.
Solution: Change declared argument type. (Ken Takata)
Files: src/if_mzsch.c
*** ../vim-7.4.1869/src/if_mzsch.c 2016-06-01 20:31:40.273551014 +0200
--- src/if_mzsch.c 2016-06-02 11:55:36.988788438 +0200
***
*** 849,855
static int mz_threads_allow = 0;
#if defined(FEAT_GUI_W32)
! static void CALLBACK timer_proc(HWND, UINT, UINT, DWORD);
static UINT timer_id = 0;
#elif defined(FEAT_GUI_GTK)
# if GTK_CHECK_VERSION(3,0,0)
--- 849,855
static int mz_threads_allow = 0;
#if defined(FEAT_GUI_W32)
! static void CALLBACK timer_proc(HWND, UINT, UINT_PTR, DWORD);
static UINT timer_id = 0;
#elif defined(FEAT_GUI_GTK)
# if GTK_CHECK_VERSION(3,0,0)
*** ../vim-7.4.1869/src/version.c 2016-06-02 11:54:01.424789753 +0200
--- src/version.c 2016-06-02 11:56:24.552787784 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1870,
/**/
--
Q. What happens to programmers when they die?
A: MS-Windows programmers are reinstalled. C++ programmers become undefined,
anyone who refers to them will die as well. Java programmers reincarnate
after being garbage collected, unless they are in permgen, in which case
they become zombies. Zimbu programmers leave a stack trace that tells us
exactly where they died and how they got there.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1849
On Do, 02 Jun 2016, Christian Brabandt wrote: > Am 2016-06-01 19:27, schrieb Ben Fritz: > >On Thursday, May 26, 2016 at 3:10:17 PM UTC-5, Bram Moolenaar wrote: > >>Patch 7.4.1848 > >>Problem:Can't build with Strawberry Perl 5.24. > >>Solution: Define S_SvREFCNT_dec() if needed. (Damien, Ken Takata) > >>Files: src/if_perl.xs > >> > > > >This patch breaks compatibility with old versions of Perl. > > > >I build my own Vim on an old Solaris server at work, which has Perl > >5.6.1. I'm not interested in compiling my own Perl. With this patch > >included, I get an error during compile or link about not finding > >SvREFCNT_inc_void_NN. If I revert the patch (so that I have "Included > >patches: 1-1847, 1849-1862"), Vim builds and runs fine. > > Yes, this has been briefly discussed in issue 790 and a > simple patch has been posted: > https://github.com/vim/vim/issues/790#issuecomment-222119586 I think this is fixed by 7.4.1870 Mit freundlichen Grüßen Christian -- Die Schweden sind keine Holländer - das hat man ganz genau gesehen. -- Franz Beckenbauer -- -- 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1871
Patch 7.4.1871
Problem:Appending to the quickfix list while the quickfix window is open
is very slow.
Solution: Do not delete all the lines, only append the new ones. Avoid
using a window while updating the list. (closes #841)
Files: src/quickfix.c
*** ../vim-7.4.1870/src/quickfix.c 2016-05-24 19:59:48.203085324 +0200
--- src/quickfix.c 2016-06-02 13:21:44.180717359 +0200
***
*** 126,134
static intis_qf_win(win_T *win, qf_info_T *qi);
static win_T *qf_find_win(qf_info_T *qi);
static buf_T *qf_find_buf(qf_info_T *qi);
! static void qf_update_buffer(qf_info_T *qi, int update_cursor);
static void qf_set_title_var(qf_info_T *qi);
! static void qf_fill_buffer(qf_info_T *qi);
#endif
static char_u *get_mef_name(void);
static void restore_start_dir(char_u *dirname_start);
--- 126,134
static intis_qf_win(win_T *win, qf_info_T *qi);
static win_T *qf_find_win(qf_info_T *qi);
static buf_T *qf_find_buf(qf_info_T *qi);
! static void qf_update_buffer(qf_info_T *qi, qfline_T *old_last);
static void qf_set_title_var(qf_info_T *qi);
! static void qf_fill_buffer(qf_info_T *qi, buf_T *buf, qfline_T *old_last);
#endif
static char_u *get_mef_name(void);
static void restore_start_dir(char_u *dirname_start);
***
*** 207,213
/*
* Read the errorfile "efile" into memory, line by line, building the error
* list.
! * Alternative: when "efile" is null read errors from buffer "buf".
* Always use 'errorformat' from "buf" if there is a local value.
* Then "lnumfirst" and "lnumlast" specify the range of lines to use.
* Set the title of the list to "qf_title".
--- 207,214
/*
* Read the errorfile "efile" into memory, line by line, building the error
* list.
! * Alternative: when "efile" is NULL read errors from buffer "buf".
! * Alternative: when "tv" is not NULL get errors from the string or list.
* Always use 'errorformat' from "buf" if there is a local value.
* Then "lnumfirst" and "lnumlast" specify the range of lines to use.
* Set the title of the list to "qf_title".
***
*** 245,250
--- 246,254
int enr = 0;
FILE *fd = NULL;
qfline_T *qfprev = NULL; /* init to make SASC shut up */
+ #ifdef FEAT_WINDOWS
+ qfline_T *old_last = NULL;
+ #endif
char_u*efmp;
efm_T *fmt_first = NULL;
efm_T *fmt_last = NULL;
***
*** 304,313
--- 308,320
/* make place for a new list */
qf_new_list(qi, qf_title);
else if (qi->qf_lists[qi->qf_curlist].qf_count > 0)
+ {
/* Adding to existing list, find last entry. */
for (qfprev = qi->qf_lists[qi->qf_curlist].qf_start;
qfprev->qf_next != qfprev; qfprev = qfprev->qf_next)
;
+ old_last = qfprev;
+ }
/*
* Each part of the format string is copied and modified from errorformat to
***
*** 1051,1057
vim_free(growbuf);
#ifdef FEAT_WINDOWS
! qf_update_buffer(qi, TRUE);
#endif
return retval;
--- 1058,1064
vim_free(growbuf);
#ifdef FEAT_WINDOWS
! qf_update_buffer(qi, old_last);
#endif
return retval;
***
*** 2347,2353
qi->qf_curlist + 1, qi->qf_listcount,
qi->qf_lists[qi->qf_curlist].qf_count);
#ifdef FEAT_WINDOWS
! qf_update_buffer(qi, TRUE);
#endif
}
--- 2354,2360
qi->qf_curlist + 1, qi->qf_listcount,
qi->qf_lists[qi->qf_curlist].qf_count);
#ifdef FEAT_WINDOWS
! qf_update_buffer(qi, NULL);
#endif
}
***
*** 2649,2655
/*
* Fill the buffer with the quickfix list.
*/
! qf_fill_buffer(qi);
curwin->w_cursor.lnum = qi->qf_lists[qi->qf_curlist].qf_index;
curwin->w_cursor.col = 0;
--- 2656,2662
/*
* Fill the buffer with the quickfix list.
*/
! qf_fill_buffer(qi, curbuf, NULL);
curwin->w_cursor.lnum = qi->qf_lists[qi->qf_curlist].qf_index;
curwin->w_cursor.col = 0;
***
*** 2777,2783
* Find the quickfix buffer. If it exists, update the contents.
*/
static void
! qf_update_buffer(qf_info_T *qi, int update_cursor)
{
buf_T *buf;
win_T *win;
--- 2784,2790
* Find the quickfix buffer. If it exists, update the contents.
*/
static void
! qf_update_buffer(qf_info_T *qi, qfline_T *old_last)
{
buf_T *buf;
win_T *win;
***
*** 2788,2795
buf = qf_find_buf(qi);
if (buf != NULL)
{
! /* set curwin/curbuf to buf and save a few things */
! aucmd_prepbuf(&aco, buf);
if ((win = qf_find_win(qi)) != NULL)
{
--- 2795,2805
buf = qf_find_buf(qi);
if (buf != NULL)
{
! linenr_Told_lin
Patch 7.4.1872
Patch 7.4.1872
Problem:Still build problem with old version of Perl.
Solution: Also define SvREFCNT_inc_void_NN if needed. (Ken Takata)
Files: src/if_perl.xs
*** ../vim-7.4.1871/src/if_perl.xs 2016-06-02 11:54:01.420789753 +0200
--- src/if_perl.xs 2016-06-02 13:52:02.692692344 +0200
***
*** 71,76
--- 71,79
# define PERLIO_FUNCS_CAST(funcs) (funcs)
# endif
#endif
+ #ifndef SvREFCNT_inc_void_NN
+ # define SvREFCNT_inc_void_NN SvREFCNT_inc
+ #endif
/*
* Work around clashes between Perl and Vim namespace.proto.h doesn't
*** ../vim-7.4.1871/src/version.c 2016-06-02 13:40:00.824702274 +0200
--- src/version.c 2016-06-02 13:52:54.188691636 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1872,
/**/
--
hundred-and-one symptoms of being an internet addict:
34. You laugh at people with a 10 Mbit connection.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1873
Patch 7.4.1873
Problem:When a callback adds a timer the GUI doesn't use it until later.
(Ramel Eshed)
Solution: Return early if a callback adds a timer.
Files: src/ex_cmds2.c, src/gui_gtk_x11.c, src/gui_w32.c, src/gui_x11.c,
src/globals.h
*** ../vim-7.4.1872/src/ex_cmds2.c 2016-05-31 21:37:32.962685143 +0200
--- src/ex_cmds2.c 2016-06-02 14:08:06.816679082 +0200
***
*** 1101,1106
--- 1101,1107
if (first_timer != NULL)
first_timer->tr_prev = timer;
first_timer = timer;
+ did_add_timer = TRUE;
}
/*
*** ../vim-7.4.1872/src/gui_gtk_x11.c 2016-04-17 20:49:46.133819400 +0200
--- src/gui_gtk_x11.c 2016-06-02 14:11:35.104676217 +0200
***
*** 6535,6549
int
gui_mch_wait_for_chars(long wtime)
{
! int focus;
! guint timer;
! static int timed_out;
timed_out = FALSE;
/* this timeout makes sure that we will return if no characters arrived in
* time */
-
if (wtime > 0)
#if GTK_CHECK_VERSION(3,0,0)
timer = g_timeout_add((guint)wtime, input_timer_cb, &timed_out);
--- 6535,6549
int
gui_mch_wait_for_chars(long wtime)
{
! int focus;
! guint timer;
! static inttimed_out;
! int retval = FAIL;
timed_out = FALSE;
/* this timeout makes sure that we will return if no characters arrived in
* time */
if (wtime > 0)
#if GTK_CHECK_VERSION(3,0,0)
timer = g_timeout_add((guint)wtime, input_timer_cb, &timed_out);
***
*** 6568,6574
--- 6568,6582
}
#ifdef MESSAGE_QUEUE
+ # ifdef FEAT_TIMERS
+ did_add_timer = FALSE;
+ # endif
parse_queued_messages();
+ # ifdef FEAT_TIMERS
+ if (did_add_timer)
+ /* Need to recompute the waiting time. */
+ goto theend;
+ # endif
#endif
/*
***
*** 6582,6594
/* Got char, return immediately */
if (input_available())
{
! if (timer != 0 && !timed_out)
! #if GTK_CHECK_VERSION(3,0,0)
! g_source_remove(timer);
! #else
! gtk_timeout_remove(timer);
! #endif
! return OK;
}
} while (wtime < 0 || !timed_out);
--- 6590,6597
/* Got char, return immediately */
if (input_available())
{
! retval = OK;
! goto theend;
}
} while (wtime < 0 || !timed_out);
***
*** 6597,6603
*/
gui_mch_update();
! return FAIL;
}
--- 6600,6614
*/
gui_mch_update();
! theend:
! if (timer != 0 && !timed_out)
! #if GTK_CHECK_VERSION(3,0,0)
! g_source_remove(timer);
! #else
! gtk_timeout_remove(timer);
! #endif
!
! return retval;
}
*** ../vim-7.4.1872/src/gui_w32.c 2016-04-26 21:51:45.014007644 +0200
--- src/gui_w32.c 2016-06-02 14:21:55.296667686 +0200
***
*** 2022,2027
--- 2022,2043
process_message();
}
+ static void
+ remove_any_timer(void)
+ {
+ MSG msg;
+
+ if (s_wait_timer != 0 && !s_timed_out)
+ {
+ KillTimer(NULL, s_wait_timer);
+
+ /* Eat spurious WM_TIMER messages */
+ while (pPeekMessage(&msg, s_hwnd, WM_TIMER, WM_TIMER, PM_REMOVE))
+ ;
+ s_wait_timer = 0;
+ }
+ }
+
/*
* GUI input routine called by gui_wait_for_chars(). Waits for a character
* from the keyboard.
***
*** 2073,2078
--- 2089,2097
s_need_activate = FALSE;
}
+ #ifdef FEAT_TIMERS
+ did_add_timer = FALSE;
+ #endif
#ifdef MESSAGE_QUEUE
/* Check channel while waiting message. */
for (;;)
***
*** 2098,2112
if (input_available())
{
! if (s_wait_timer != 0 && !s_timed_out)
! {
! KillTimer(NULL, s_wait_timer);
!
! /* Eat spurious WM_TIMER messages */
! while (pPeekMessage(&msg, s_hwnd, WM_TIMER, WM_TIMER,
PM_REMOVE))
! ;
! s_wait_timer = 0;
! }
allow_scrollbar = FALSE;
/* Clear pending mouse button, the release event may have been
--- 2117,2123
if (input_available())
{
! remove_any_timer();
allow_scrollbar = FALSE;
/* Clear pending mouse button, the release event may have been
***
*** 2117,2122
--- 2128,2142
return OK;
}
+
+ #ifdef FEAT_TIMERS
+ if (did_add_timer)
+ {
+ /* Need to recompute the waiting time. */
+ remove_any_timer();
+ break;
+ }
+ #endif
}
allow_scrollbar = FALSE;
return FAIL;
*** ../vim-7.4.1872/src/gui_x11.c 2016-02-27 18:13:05.236593109 +0100
--- src/gui_x11.c 2016-06-02 14:24:32.900665518
Re: Patch 7.4.1872
Hi Bram, 2016/6/2 Thu 20:55:01 UTC+9 Bram Moolenaar wrote: > Patch 7.4.1872 > Problem:Still build problem with old version of Perl. > Solution: Also define SvREFCNT_inc_void_NN if needed. (Ken Takata) > Files: src/if_perl.xs This patch is written by Tom G. Christensen, not me. 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1874
Patch 7.4.1874
Problem:Unused variable in Win32 code.
Solution: Remove it. (Mike Williams)
Files: src/gui_w32.c
*** ../vim-7.4.1873/src/gui_w32.c 2016-06-02 14:29:59.136661030 +0200
--- src/gui_w32.c 2016-06-02 15:47:30.140597052 +0200
***
*** 2050,2056
int
gui_mch_wait_for_chars(int wtime)
{
- MSG msg;
int focus;
s_timed_out = FALSE;
--- 2050,2055
*** ../vim-7.4.1873/src/version.c 2016-06-02 14:29:59.136661030 +0200
--- src/version.c 2016-06-02 15:48:14.696596439 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1874,
/**/
--
hundred-and-one symptoms of being an internet addict:
37. You start looking for hot HTML addresses in public restrooms.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1875
Patch 7.4.1875
Problem:Comparing functions and partials doesn't work well.
Solution: Add tests. (Nikolai Pavlov) Compare the dict and arguments in the
partial. (closes #813)
Files: src/eval.c, src/testdir/test_partial.vim
*** ../vim-7.4.1874/src/eval.c 2016-06-01 23:08:35.249421504 +0200
--- src/eval.c 2016-06-02 17:37:10.884506528 +0200
***
*** 4627,4633
clear_tv(&var2);
return FAIL;
}
! n1 = tv_equal(rettv, &var2, FALSE, FALSE);
if (type == TYPE_NEQUAL)
n1 = !n1;
}
--- 4627,4652
clear_tv(&var2);
return FAIL;
}
! if ((rettv->v_type == VAR_PARTIAL
!&& rettv->vval.v_partial == NULL)
! || (var2.v_type == VAR_PARTIAL
! && var2.vval.v_partial == NULL))
! /* when a partial is NULL assume not equal */
! n1 = FALSE;
! else if (type_is)
! {
! if (rettv->v_type == VAR_FUNC && var2.v_type == VAR_FUNC)
! /* strings are considered the same if their value is
!* the same */
! n1 = tv_equal(rettv, &var2, ic, FALSE);
! else if (rettv->v_type == VAR_PARTIAL
! && var2.v_type == VAR_PARTIAL)
! n1 = (rettv->vval.v_partial == var2.vval.v_partial);
! else
! n1 = FALSE;
! }
! else
! n1 = tv_equal(rettv, &var2, ic, FALSE);
if (type == TYPE_NEQUAL)
n1 = !n1;
}
***
*** 6258,6263
--- 6277,6334
static int tv_equal_recurse_limit;
+ static int
+ func_equal(
+ typval_T *tv1,
+ typval_T *tv2,
+ intic)/* ignore case */
+ {
+ char_u*s1, *s2;
+ dict_T*d1, *d2;
+ int a1, a2;
+ int i;
+
+ /* empty and NULL function name considered the same */
+ s1 = tv1->v_type == VAR_FUNC ? tv1->vval.v_string
+ : tv1->vval.v_partial->pt_name;
+ if (s1 != NULL && *s1 == NUL)
+ s1 = NULL;
+ s2 = tv2->v_type == VAR_FUNC ? tv2->vval.v_string
+ : tv2->vval.v_partial->pt_name;
+ if (s2 != NULL && *s2 == NUL)
+ s2 = NULL;
+ if (s1 == NULL || s2 == NULL)
+ {
+ if (s1 != s2)
+ return FALSE;
+ }
+ else if (STRCMP(s1, s2) != 0)
+ return FALSE;
+
+ /* empty dict and NULL dict is different */
+ d1 = tv1->v_type == VAR_FUNC ? NULL : tv1->vval.v_partial->pt_dict;
+ d2 = tv2->v_type == VAR_FUNC ? NULL : tv2->vval.v_partial->pt_dict;
+ if (d1 == NULL || d2 == NULL)
+ {
+ if (d1 != d2)
+ return FALSE;
+ }
+ else if (!dict_equal(d1, d2, ic, TRUE))
+ return FALSE;
+
+ /* empty list and no list considered the same */
+ a1 = tv1->v_type == VAR_FUNC ? 0 : tv1->vval.v_partial->pt_argc;
+ a2 = tv2->v_type == VAR_FUNC ? 0 : tv2->vval.v_partial->pt_argc;
+ if (a1 != a2)
+ return FALSE;
+ for (i = 0; i < a1; ++i)
+ if (!tv_equal(tv1->vval.v_partial->pt_argv + i,
+ tv2->vval.v_partial->pt_argv + i, ic, TRUE))
+ return FALSE;
+
+ return TRUE;
+ }
+
/*
* Return TRUE if "tv1" and "tv2" have the same value.
* Compares the items just like "==" would compare them, but strings and
***
*** 6275,6296
static int recursive_cnt = 0;/* catch recursive loops */
int r;
- /* For VAR_FUNC and VAR_PARTIAL only compare the function name. */
- if ((tv1->v_type == VAR_FUNC
- || (tv1->v_type == VAR_PARTIAL && tv1->vval.v_partial != NULL))
- && (tv2->v_type == VAR_FUNC
- || (tv2->v_type == VAR_PARTIAL && tv2->vval.v_partial != NULL)))
- {
- s1 = tv1->v_type == VAR_FUNC ? tv1->vval.v_string
- : tv1->vval.v_partial->pt_name;
- s2 = tv2->v_type == VAR_FUNC ? tv2->vval.v_string
- : tv2->vval.v_partial->pt_name;
- return (s1 != NULL && s2 != NULL && STRCMP(s1, s2) == 0);
- }
-
- if (tv1->v_type != tv2->v_type)
- return FALSE;
-
/* Catch lists and dicts that have an endless loop by limiting
* recursiveness to a limit. We guess they are equal then.
* A fixed limit has the problem of still taking an awful long time.
--- 6346,6351
***
*** 6305,6310
--- 6360,6380
return TRUE;
}
+ /* For VAR_FUNC and VAR_PARTIAL only compare th
Patch 7.4.1876
Patch 7.4.1876
Problem:Typing "k" at the hit-enter prompt has no effect.
Solution: Don't assume recursive use of the prompt if a character was typed.
(Hirohito Higashi)
Files: src/message.c
*** ../vim-7.4.1875/src/message.c 2016-04-14 19:44:33.10027 +0200
--- src/message.c 2016-06-02 18:25:35.612466571 +0200
***
*** 2475,2483
int i;
/* We get called recursively when a timer callback outputs a message. In
! * that case don't show another prompt. Also when at the hit-Enter prompt.
! */
! if (entered || State == HITRETURN)
return FALSE;
entered = TRUE;
--- 2475,2483
int i;
/* We get called recursively when a timer callback outputs a message. In
! * that case don't show another prompt. Also when at the hit-Enter prompt
! * and nothing was typed. */
! if (entered || (State == HITRETURN && typed_char == 0))
return FALSE;
entered = TRUE;
*** ../vim-7.4.1875/src/version.c 2016-06-02 17:46:16.248499026 +0200
--- src/version.c 2016-06-02 18:26:58.456465432 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1876,
/**/
--
He who laughs last, thinks slowest.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: Asynchronous grep plugin - thoughts and issues
Ramel Eshed wrote: > Hi All, > > Thanks to Bram and his recent work on channels, I have a preliminary > version of an asynchronous grep plugin which lets you work with the > available results while grep is still running. I would like to take > advantage of this relatively short script to raise some issues and > thoughts I have. The plugin can be found at > https://github.com/ramele/agrep. > > My original idea was to use the quickfix list and add each match to it > from the out callback. I had some issues with it, so temporarily (I > hope..) I’m using my own window to display the results (“agrep > window”). This is the default now and it should demonstrate what this > plugin should do eventually. In order to reproduce the quickfix > issues, you'll need to tell agrep to use quickfix list instead of > agrep window (:let qgrep_use_qf=1). You can install the plugin as is > or load it with $vim -u NONE -N -S Several of the problems have been fixed. Especially appending to the quickfix list should now be much faster. Let us know if you still encounter problems. > 3. Changing other buffers: > As far as I know, there is no nice way to change buffers other than > the current one. There is the getbufline() function, but the symmetry > is broken since there is no setbufline(). I found a discussion about > this from 10 years ago > (http://vim.1045645.n5.nabble.com/missing-setbufline-td1155970.html) > but I'm not sure if Bram added it to his TODO list or not. In this > script I'm using the move_to_buf() and back_from_buf() functions. The > problems with this approach are: > > - It is ugly. > - Poor performance (it is slow, you can see the cursor jumping between > windows, it can cause Vim to hang). > - Difficult to change hidden buffers or buffers in other tab pages. > - Is has side effects - It seems to break my undo tree and I'm sure > that there are more. This is actually difficult to do. The internals of Vim only expect a buffer to change when it's in a window. Also when invoking autocommands, which expect a valid buffer and window. And undo expects the buffer to be the current buffer. This would be a lot of work to change, and it's likely to introduce a few bugs. > I'm not very much experienced with external plugins (like Python) > which can change any buffer, but it seems that when using a channel > with "out_io": "buffer" the performance is much better. Is it possible > to implement such a function based on how it's done there? Python uses switch_to_win_for_buf(). It doesn't work perfectly though. Marks may be wrong and it may redraw the current window even though it didn't change. -- Micro$oft: where do you want to go today? Linux: where do you want to go tomorrow? FreeBSD: are you guys coming, or what? /// 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1877
Patch 7.4.1877
Problem:No test for invoking "close_cb" when writing to a buffer.
Solution: Add using close_cb to a test case.
Files: src/testdir/test_channel.vim
*** ../vim-7.4.1876/src/testdir/test_channel.vim2016-05-29
16:16:39.381326993 +0200
--- src/testdir/test_channel.vim2016-06-02 18:59:22.556438689 +0200
***
*** 676,687
endtry
endfunc
func Run_test_pipe_to_buffer(use_name, nomod)
if !has('job')
return
endif
call ch_log('Test_pipe_to_buffer()')
! let options = {'out_io': 'buffer'}
if a:use_name
let options['out_name'] = 'pipe-output'
let firstline = 'Reading from channel output...'
--- 676,692
endtry
endfunc
+ func BufCloseCb(ch)
+ let s:bufClosed = 'yes'
+ endfunc
+
func Run_test_pipe_to_buffer(use_name, nomod)
if !has('job')
return
endif
call ch_log('Test_pipe_to_buffer()')
! let s:bufClosed = 'no'
! let options = {'out_io': 'buffer', 'close_cb': 'BufCloseCb'}
if a:use_name
let options['out_name'] = 'pipe-output'
let firstline = 'Reading from channel output...'
***
*** 704,718
call ch_sendraw(handle, "quit\n")
sp pipe-output
call s:waitFor('line("$") >= 6')
- if getline('$') == 'DETACH'
- $del
- endif
call assert_equal([firstline, 'line one', 'line two', 'this', 'AND this',
'Goodbye!'], getline(1, '$'))
if a:nomod
call assert_equal(0, &modifiable)
else
call assert_equal(1, &modifiable)
endif
bwipe!
finally
call job_stop(job)
--- 709,721
call ch_sendraw(handle, "quit\n")
sp pipe-output
call s:waitFor('line("$") >= 6')
call assert_equal([firstline, 'line one', 'line two', 'this', 'AND this',
'Goodbye!'], getline(1, '$'))
if a:nomod
call assert_equal(0, &modifiable)
else
call assert_equal(1, &modifiable)
endif
+ call assert_equal('yes', s:bufClosed)
bwipe!
finally
call job_stop(job)
*** ../vim-7.4.1876/src/version.c 2016-06-02 18:37:00.776457146 +0200
--- src/version.c 2016-06-02 19:04:17.708434629 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1877,
/**/
--
Everyone has a photographic memory. Some don't have film.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Invoking close_cb when writing to a buffer
Luc - You wrote that when writing to a buffer close_cb isn't invoked. I added a test for it and it appears to work just fine. Any special circumstances when close_cb is not invoked? -- A day without sunshine is like, well, night. /// 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1878
Patch 7.4.1878
Problem:Whether a job has exited isn't detected until a character is
typed. After calling exit_cb the cursor is in the wrong place.
Solution: Don't wait forever for a character to be typed when there is a
pending job. Update the screen if neede after calling exit_cb.
Files: src/os_unix.c, src/channel.c, src/proto/channel.pro
*** ../vim-7.4.1877/src/os_unix.c 2016-05-08 09:40:46.490843730 +0200
--- src/os_unix.c 2016-06-02 19:55:47.112392132 +0200
***
*** 438,454
for (;;) /* repeat until we got a character */
{
while (do_resize)/* window changed size */
handle_resize();
#ifdef MESSAGE_QUEUE
parse_queued_messages();
#endif
/*
* We want to be interrupted by the winch signal
* or by an event on the monitored file descriptors.
*/
! if (!WaitForChar(-1L))
{
if (do_resize) /* interrupted by SIGWINCH signal */
handle_resize();
--- 438,468
for (;;) /* repeat until we got a character */
{
+ longwtime_now = -1L;
+
while (do_resize)/* window changed size */
handle_resize();
#ifdef MESSAGE_QUEUE
parse_queued_messages();
+
+ # ifdef FEAT_JOB_CHANNEL
+ if (has_pending_job())
+ {
+ /* Don't wait longer than a few seconds, checking for a finished
+* job requires polling. */
+ if (p_ut > 9000L)
+ wtime_now = 1000L;
+ else
+ wtime_now = 1L - p_ut;
+ }
+ # endif
#endif
/*
* We want to be interrupted by the winch signal
* or by an event on the monitored file descriptors.
*/
! if (!WaitForChar(wtime_now))
{
if (do_resize) /* interrupted by SIGWINCH signal */
handle_resize();
*** ../vim-7.4.1877/src/channel.c 2016-05-29 16:44:22.153304121 +0200
--- src/channel.c 2016-06-02 20:00:37.012388144 +0200
***
*** 4403,4408
--- 4403,4423
}
/*
+ * Return TRUE when there is any job that might exit, which means
+ * job_check_ended() should be called once in a while.
+ */
+ int
+ has_pending_job()
+ {
+ job_T *job;
+
+ for (job = first_job; job != NULL; job = job->jv_next)
+ if (job->jv_status == JOB_STARTED && job_still_useful(job))
+ return TRUE;
+ return FALSE;
+ }
+
+ /*
* Called once in a while: check if any jobs that seem useful have ended.
*/
void
***
*** 4425,4430
--- 4440,4450
job_status(job); /* may free "job" */
}
}
+ if (channel_need_redraw)
+ {
+ channel_need_redraw = FALSE;
+ redraw_after_callback();
+ }
}
/*
***
*** 4658,4663
--- 4678,4684
job->jv_exit_partial, NULL);
clear_tv(&rettv);
--job->jv_refcount;
+ channel_need_redraw = TRUE;
}
if (job->jv_status == JOB_ENDED && job->jv_refcount == 0)
{
*** ../vim-7.4.1877/src/proto/channel.pro 2016-05-28 22:22:28.830213562
+0200
--- src/proto/channel.pro 2016-06-02 19:55:45.164392159 +0200
***
*** 57,62
--- 57,63
void free_unused_jobs(int copyID, int mask);
void job_set_options(job_T *job, jobopt_T *opt);
void job_stop_on_exit(void);
+ int has_pending_job(void);
void job_check_ended(void);
job_T *job_start(typval_T *argvars);
char *job_status(job_T *job);
*** ../vim-7.4.1877/src/version.c 2016-06-02 19:06:20.276432943 +0200
--- src/version.c 2016-06-02 20:02:30.500386583 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1878,
/**/
--
The users that I support would double-click on a landmine to find out
what happens. -- A system administrator
/// 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.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1879
Patch 7.4.1879 (after 7.4.1877)
Problem:Channel test is flaky.
Solution: Wait for close_cb to be invoked.
Files: src/testdir/test_channel.vim
*** ../vim-7.4.1878/src/testdir/test_channel.vim2016-06-02
19:06:20.276432943 +0200
--- src/testdir/test_channel.vim2016-06-02 20:04:02.856385313 +0200
***
*** 708,714
call ch_sendraw(handle, "double this\n")
call ch_sendraw(handle, "quit\n")
sp pipe-output
! call s:waitFor('line("$") >= 6')
call assert_equal([firstline, 'line one', 'line two', 'this', 'AND this',
'Goodbye!'], getline(1, '$'))
if a:nomod
call assert_equal(0, &modifiable)
--- 708,714
call ch_sendraw(handle, "double this\n")
call ch_sendraw(handle, "quit\n")
sp pipe-output
! call s:waitFor('line("$") >= 6 && s:bufClosed == "yes"')
call assert_equal([firstline, 'line one', 'line two', 'this', 'AND this',
'Goodbye!'], getline(1, '$'))
if a:nomod
call assert_equal(0, &modifiable)
*** ../vim-7.4.1878/src/version.c 2016-06-02 20:05:22.480384217 +0200
--- src/version.c 2016-06-02 20:06:18.104383452 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1879,
/**/
--
On the other hand, you have different fingers.
-- Steven Wright
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: Asynchronous grep plugin - thoughts and issues
Hi Bram, On Thu, Jun 2, 2016 at 9:53 AM, Bram Moolenaar wrote: > > Ramel Eshed wrote: > >> Hi All, >> >> Thanks to Bram and his recent work on channels, I have a preliminary >> version of an asynchronous grep plugin which lets you work with the >> available results while grep is still running. I would like to take >> advantage of this relatively short script to raise some issues and >> thoughts I have. The plugin can be found at >> https://github.com/ramele/agrep. >> >> My original idea was to use the quickfix list and add each match to it >> from the out callback. I had some issues with it, so temporarily (I >> hope..) I’m using my own window to display the results (“agrep >> window”). This is the default now and it should demonstrate what this >> plugin should do eventually. In order to reproduce the quickfix >> issues, you'll need to tell agrep to use quickfix list instead of >> agrep window (:let qgrep_use_qf=1). You can install the plugin as is >> or load it with $vim -u NONE -N -S > > Several of the problems have been fixed. Especially appending to the > quickfix list should now be much faster. > > Let us know if you still encounter problems. > The problem with adding large number of entries to a quickfix list is not fixed yet. I am attaching a test script to illustrate the problem. Source the script and run "call Measure_Caddexpr_Time()". You will see that it takes around 2 minutes to add the entries. The patch I sent earlier address this problem. - Yegappan >> 3. Changing other buffers: >> As far as I know, there is no nice way to change buffers other than >> the current one. There is the getbufline() function, but the symmetry >> is broken since there is no setbufline(). I found a discussion about >> this from 10 years ago >> (http://vim.1045645.n5.nabble.com/missing-setbufline-td1155970.html) >> but I'm not sure if Bram added it to his TODO list or not. In this >> script I'm using the move_to_buf() and back_from_buf() functions. The >> problems with this approach are: >> >> - It is ugly. >> - Poor performance (it is slow, you can see the cursor jumping between >> windows, it can cause Vim to hang). >> - Difficult to change hidden buffers or buffers in other tab pages. >> - Is has side effects - It seems to break my undo tree and I'm sure >> that there are more. > > This is actually difficult to do. The internals of Vim only expect a > buffer to change when it's in a window. Also when invoking > autocommands, which expect a valid buffer and window. And undo expects > the buffer to be the current buffer. This would be a lot of work to > change, and it's likely to introduce a few bugs. > >> I'm not very much experienced with external plugins (like Python) >> which can change any buffer, but it seems that when using a channel >> with "out_io": "buffer" the performance is much better. Is it possible >> to implement such a function based on how it's done there? > > Python uses switch_to_win_for_buf(). It doesn't work perfectly though. > Marks may be wrong and it may redraw the current window even though it > didn't change. > -- -- 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. For more options, visit https://groups.google.com/d/optout. caddexpr.vim Description: Binary data
Patch 7.4.1880
Patch 7.4.1880
Problem:MS-Windows console build defaults to not having +channel.
Solution: Include the channel feature if building with huge features.
Files: src/Make_mvc.mak
*** ../vim-7.4.1879/src/Make_mvc.mak2016-03-11 22:52:00.742438030 +0100
--- src/Make_mvc.mak2016-06-02 20:26:00.586714614 +0200
***
*** 263,268
--- 263,272
# INCLUDE = c:\msvc20\include
# LIB = c:\msvc20\lib
+ !if "$(FEATURES)"==""
+ FEATURES = HUGE
+ !endif
+
!ifndef CTAGS
CTAGS = ctags
!endif
***
*** 283,290
--- 287,298
!endif
!ifndef CHANNEL
+ !if "$(FEATURES)"=="HUGE"
+ CHANNEL = yes
+ !else
CHANNEL = $(GUI)
!endif
+ !endif
# Only allow NETBEANS and XPM for a GUI build and CHANNEL.
!if "$(GUI)" == "yes"
***
*** 953,961
#
# FEATURES: TINY, SMALL, NORMAL, BIG or HUGE
#
- !if "$(FEATURES)"==""
- FEATURES = HUGE
- !endif
CFLAGS = $(CFLAGS) -DFEAT_$(FEATURES)
#
--- 961,966
*** ../vim-7.4.1879/src/version.c 2016-06-02 20:07:05.552382799 +0200
--- src/version.c 2016-06-02 20:26:12.856367017 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1880,
/**/
--
Seen it all, done it all, can't remember most of it.
/// 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.
For more options, visit https://groups.google.com/d/optout.
[bug] logical condition always true in quickfix.c:642 introduced by vim-7.4.1802
Hi cppcheck static analyzer gives this warning which is a bug in Vim: [vim/src/quickfix.c:649]: (warning) Logical disjunction always evaluates to true: EXPR != '\n' || EXPR != '\r'. Code in quickfix.c looks liks this: 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' 641 #ifdef USE_CRNL 642 || IObuff[linelen - 1] != '\r' 643 #endif 644 )) It looks wrong indeed when USE_CRNL is defined. Maybe it was meant to be: 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' 641 #ifdef USE_CRNL 642 && IObuff[linelen - 1] != '\r' 643 #endif 644 )) But I'm not even sure this is correct either. With CRNL, there are 2 characters \r\n for end of line. So maybe it was mean to be: 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' 641 #ifdef USE_CRNL 642 || IObuff[linelen - 2] != '\r' 643 #endif 644 )) Code with the bug was introduced in this recent checkin: === commit 6be8c8e165204b8aa4eeb8a52be87a58d8b41b9e Author: Bram Moolenaar Date: Sat Apr 30 13:17:09 2016 +0200 patch 7.4.1802 Problem:Quickfix doesn't handle long lines well, they are split. Solution: Drop characters after a limit. (Anton Lindqvist) === Regards Dominique -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Asynchronous grep plugin - thoughts and issues
Yegappan Lakshmanan wrote: > On Thu, Jun 2, 2016 at 9:53 AM, Bram Moolenaar wrote: > > > > Ramel Eshed wrote: > > > >> Hi All, > >> > >> Thanks to Bram and his recent work on channels, I have a preliminary > >> version of an asynchronous grep plugin which lets you work with the > >> available results while grep is still running. I would like to take > >> advantage of this relatively short script to raise some issues and > >> thoughts I have. The plugin can be found at > >> https://github.com/ramele/agrep. > >> > >> My original idea was to use the quickfix list and add each match to it > >> from the out callback. I had some issues with it, so temporarily (I > >> hope..) I’m using my own window to display the results (“agrep > >> window”). This is the default now and it should demonstrate what this > >> plugin should do eventually. In order to reproduce the quickfix > >> issues, you'll need to tell agrep to use quickfix list instead of > >> agrep window (:let qgrep_use_qf=1). You can install the plugin as is > >> or load it with $vim -u NONE -N -S > > > > Several of the problems have been fixed. Especially appending to the > > quickfix list should now be much faster. > > > > Let us know if you still encounter problems. > > > > The problem with adding large number of entries to a quickfix list is not > fixed yet. I am attaching a test script to illustrate the problem. Source the > script and run "call Measure_Caddexpr_Time()". You will see that it > takes around 2 minutes to add the entries. > > The patch I sent earlier address this problem. Yes, but I wanted to use another solution: add qf_last. I'm doing that now, the time goes down from 150 seconds to 2 seconds. -- Those who live by the sword get shot by those who don't. /// 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1881
Patch 7.4.1881
Problem:Appending to a long quickfix list is slow.
Solution: Add qf_last.
Files: src/quickfix.c
*** ../vim-7.4.1880/src/quickfix.c 2016-06-02 13:40:00.820702274 +0200
--- src/quickfix.c 2016-06-02 22:07:47.024283187 +0200
***
*** 52,57
--- 52,58
typedef struct qf_list_S
{
qfline_T *qf_start; /* pointer to the first error */
+ qfline_T *qf_last; /* pointer to the last error */
qfline_T *qf_ptr;/* pointer to the current error */
int qf_count; /* number of errors (0 means no error
list) */
int qf_index; /* current index in the error list */
***
*** 110,116
static void qf_store_title(qf_info_T *qi, char_u *title);
static void qf_new_list(qf_info_T *qi, char_u *qf_title);
static void ll_free_all(qf_info_T **pqi);
! static intqf_add_entry(qf_info_T *qi, qfline_T **prevp, char_u *dir,
char_u *fname, int bufnum, char_u *mesg, long lnum, int col, int vis_col,
char_u *pattern, int nr, int type, int valid);
static qf_info_T *ll_new_list(void);
static void qf_msg(qf_info_T *qi);
static void qf_free(qf_info_T *qi, int idx);
--- 111,117
static void qf_store_title(qf_info_T *qi, char_u *title);
static void qf_new_list(qf_info_T *qi, char_u *qf_title);
static void ll_free_all(qf_info_T **pqi);
! static intqf_add_entry(qf_info_T *qi, char_u *dir, char_u *fname, int
bufnum, char_u *mesg, long lnum, int col, int vis_col, char_u *pattern, int nr,
int type, int valid);
static qf_info_T *ll_new_list(void);
static void qf_msg(qf_info_T *qi);
static void qf_free(qf_info_T *qi, int idx);
***
*** 245,251
long lnum = 0L;
int enr = 0;
FILE *fd = NULL;
- qfline_T *qfprev = NULL; /* init to make SASC shut up */
#ifdef FEAT_WINDOWS
qfline_T *old_last = NULL;
#endif
--- 246,251
***
*** 307,320
if (newlist || qi->qf_curlist == qi->qf_listcount)
/* make place for a new list */
qf_new_list(qi, qf_title);
else if (qi->qf_lists[qi->qf_curlist].qf_count > 0)
{
! /* Adding to existing list, find last entry. */
! for (qfprev = qi->qf_lists[qi->qf_curlist].qf_start;
! qfprev->qf_next != qfprev; qfprev = qfprev->qf_next)
! ;
! old_last = qfprev;
}
/*
* Each part of the format string is copied and modified from errorformat to
--- 307,319
if (newlist || qi->qf_curlist == qi->qf_listcount)
/* make place for a new list */
qf_new_list(qi, qf_title);
+ #ifdef FEAT_WINDOWS
else if (qi->qf_lists[qi->qf_curlist].qf_count > 0)
{
! /* Adding to existing list, use last entry. */
! old_last = qi->qf_lists[qi->qf_curlist].qf_last;
}
+ #endif
/*
* Each part of the format string is copied and modified from errorformat to
***
*** 936,941
--- 935,942
}
else if (vim_strchr((char_u *)"CZ", idx) != NULL)
{ /* continuation of multi-line msg */
+ qfline_T *qfprev = qi->qf_lists[qi->qf_curlist].qf_last;
+
if (qfprev == NULL)
goto error2;
if (*errmsg && !multiignore)
***
*** 995,1001
}
}
! if (qf_add_entry(qi, &qfprev,
directory,
(*namebuf || directory)
? namebuf
--- 996,1002
}
}
! if (qf_add_entry(qi,
directory,
(*namebuf || directory)
? namebuf
***
*** 1159,1165
static int
qf_add_entry(
qf_info_T *qi,/* quickfix list */
- qfline_T **prevp,/* pointer to previously added entry or NULL */
char_u*dir, /* optional directory name */
char_u*fname, /* file name or NULL */
int bufnum, /* buffer number or zero */
--- 1160,1165
***
*** 1173,1178
--- 1173,1179
int valid) /* valid entry */
{
qfline_T *qfp;
+ qfline_T **lastp;/* pointer to qf_last or NULL */
if ((qfp = (qfline_T *)alloc((unsigned)sizeof(qfline_T))) == NULL)
return FAIL;
***
*** 1202,1223
qfp->qf_type = type;
qfp->qf_valid = valid;
if (qi->qf_lists[qi->qf_curlist].qf_count == 0)
/* first element in the list */
{
qi->qf_lists[qi->qf_curlist].qf_start = qfp;
qi->qf_lists[qi->qf_curlist].qf_ptr = qfp;
qi->qf_lists[qi->qf_curlist].qf_index = 0;
! qfp->qf_prev = qfp; /* first element points to itself */
}
Patch 7.4.1882
Patch 7.4.1882
Problem:Check for line break at end of line wrong. (Dominique Pelle)
Solution: Correct the logic.
Files: src/quickfix.c
*** ../vim-7.4.1881/src/quickfix.c 2016-06-02 22:08:01.992282981 +0200
--- src/quickfix.c 2016-06-02 22:16:10.264276265 +0200
***
*** 643,651
discard = FALSE;
linelen = (int)STRLEN(IObuff);
! if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n'
#ifdef USE_CRNL
! || IObuff[linelen - 1] != '\r'
#endif
))
{
--- 643,651
discard = FALSE;
linelen = (int)STRLEN(IObuff);
! if (linelen == IOSIZE - 1 && !(IObuff[linelen - 1] == '\n'
#ifdef USE_CRNL
! || IObuff[linelen - 1] == '\r'
#endif
))
{
*** ../vim-7.4.1881/src/version.c 2016-06-02 22:08:01.996282981 +0200
--- src/version.c 2016-06-02 22:17:03.780275529 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1882,
/**/
--
Portable Computer: A device invented to force businessmen
to work at home, on vacation, and on business trips.
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: [bug] logical condition always true in quickfix.c:642 introduced by vim-7.4.1802
Dominique wrote: > cppcheck static analyzer gives this warning which > is a bug in Vim: > > [vim/src/quickfix.c:649]: (warning) Logical disjunction always > evaluates to true: EXPR != '\n' || EXPR != '\r'. > > Code in quickfix.c looks liks this: > > 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' > 641 #ifdef USE_CRNL > 642 || IObuff[linelen - 1] != '\r' > 643 #endif > 644 )) > > It looks wrong indeed when USE_CRNL is defined. > Maybe it was meant to be: > > 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' > 641 #ifdef USE_CRNL > 642 && IObuff[linelen - 1] != '\r' > 643 #endif > 644 )) > > But I'm not even sure this is correct either. With CRNL, there > are 2 characters \r\n for end of line. So maybe it was mean to be: > > 640 if (linelen == IOSIZE - 1 && (IObuff[linelen - 1] != '\n' > 641 #ifdef USE_CRNL > 642 || IObuff[linelen - 2] != '\r' > 643 #endif > 644 )) > > Code with the bug was introduced in this recent checkin: > > === > commit 6be8c8e165204b8aa4eeb8a52be87a58d8b41b9e > Author: Bram Moolenaar > Date: Sat Apr 30 13:17:09 2016 +0200 > > patch 7.4.1802 > Problem:Quickfix doesn't handle long lines well, they are split. > Solution: Drop characters after a limit. (Anton Lindqvist) > === Further down there is this code: if (growbuf[growbuflen - 1] == '\n' #ifdef USE_CRNL || growbuf[growbuflen - 1] == '\r' #endif ) break; Thus it's really checking for NL or CR. Apparently using || instead of && was a mistake, because of the unequal check. It's easier to read like this: 640 if (linelen == IOSIZE - 1 && !(IObuff[linelen - 1] == '\n' 641 #ifdef USE_CRNL 642 || IObuff[linelen - 1] == '\r' 643 #endif 644 )) -- I wonder how much deeper the ocean would be without sponges. /// 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. For more options, visit https://groups.google.com/d/optout.
[patch] fixed incorrect printf format
Hi
cppcheck found 2 incorrect printf formats where
'long' variables were printed with %d and %x
instead of %ld and %lx.
Regards
Dominique
--
--
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.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/VisVim/Commands.cpp b/src/VisVim/Commands.cpp
index 111b163..569fbb8 100644
--- a/src/VisVim/Commands.cpp
+++ b/src/VisVim/Commands.cpp
@@ -575,7 +575,7 @@ static BOOL VimOpenFile(BSTR& FileName, long LineNr)
if (LineNr > 0)
{
// Goto line
- sprintf(VimCmd, ":%d\n", LineNr);
+ sprintf(VimCmd, ":%ld\n", LineNr);
if (! VimOle.Method(DispatchId, "s", TO_OLE_STR_BUF(VimCmd, Buf)))
goto OleError;
}
diff --git a/src/gui_mac.c b/src/gui_mac.c
index b3f76af..8990b05 100644
--- a/src/gui_mac.c
+++ b/src/gui_mac.c
@@ -5040,7 +5040,7 @@ gui_mch_set_scrollbar_thumb(
SetControl32BitValue (sb->id, val);
SetControlViewSize (sb->id, size);
#ifdef DEBUG_MAC_SB
-printf("thumb_sb (%x) %x, %x,%x\n",sb->id, val, size, max);
+printf("thumb_sb (%x) %lx, %lx,%lx\n",sb->id, val, size, max);
#endif
}
Patch 7.4.1883
Patch 7.4.1883
Problem:Cppcheck found 2 incorrect printf formats.
Solution: Use %ld and %lx. (Dominique Pelle)
Files: src/VisVim/Commands.cpp, src/gui_mac.c
*** ../vim-7.4.1882/src/VisVim/Commands.cpp 2011-08-10 17:21:27.0
+0200
--- src/VisVim/Commands.cpp 2016-06-02 22:24:28.856269406 +0200
***
*** 575,581
if (LineNr > 0)
{
// Goto line
! sprintf(VimCmd, ":%d\n", LineNr);
if (! VimOle.Method(DispatchId, "s", TO_OLE_STR_BUF(VimCmd,
Buf)))
goto OleError;
}
--- 575,581
if (LineNr > 0)
{
// Goto line
! sprintf(VimCmd, ":%ld\n", LineNr);
if (! VimOle.Method(DispatchId, "s", TO_OLE_STR_BUF(VimCmd,
Buf)))
goto OleError;
}
*** ../vim-7.4.1882/src/gui_mac.c 2016-04-26 20:59:24.728486510 +0200
--- src/gui_mac.c 2016-06-02 22:24:28.856269406 +0200
***
*** 5040,5046
SetControl32BitValue (sb->id, val);
SetControlViewSize (sb->id, size);
#ifdef DEBUG_MAC_SB
! printf("thumb_sb (%x) %x, %x,%x\n",sb->id, val, size, max);
#endif
}
--- 5040,5046
SetControl32BitValue (sb->id, val);
SetControlViewSize (sb->id, size);
#ifdef DEBUG_MAC_SB
! printf("thumb_sb (%x) %lx, %lx,%lx\n",sb->id, val, size, max);
#endif
}
*** ../vim-7.4.1882/src/version.c 2016-06-02 22:18:44.040274149 +0200
--- src/version.c 2016-06-02 22:25:20.564268695 +0200
***
*** 755,756
--- 755,758
{ /* Add new patch number below this line */
+ /**/
+ 1883,
/**/
--
Despite the cost of living, have you noticed how it remains so popular?
/// 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.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] fixed incorrect printf format
Dominique wrote: > cppcheck found 2 incorrect printf formats where > 'long' variables were printed with %d and %x > instead of %ld and %lx. Thanks. Looks like the Mac code is unused. And this VisVim feature probably isn't used much. Anyway, always good to fix it. -- Bumper sticker: Honk if you love peace and quiet. /// 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. For more options, visit https://groups.google.com/d/optout.
Re: Asynchronous grep plugin - thoughts and issues
Hi Bram and Yegappan, Yegappan, You were right -saving the qf_last makes a big difference. I probably checked your patch after using many quickfix operations (see below). Let me summarize the problems found so far using the agrep plugin: 1. SEGV crashes - fixed 2. Vim hangs while quickfix window is opened - fixed. 3. GUI hangs - fixed 4. Timer issue in the GUI - fixed 5. quickfix is slow in general - it's much better with Yegappan's patch or 1881 but Vim is still not as responsive as it is when using the same search without quickfix (with Agrep window). Following are the top lines from the profiler log, in case you'll see something that can be optimized: % cumulative self self total time seconds secondscalls ms/call ms/call name 11.34 0.11 0.1111084 0.01 0.01 buf_valid 10.31 0.21 0.1011378 0.01 0.01 do_cmdline 5.15 0.26 0.05 9912382 0.00 0.00 otherfile_buf 5.15 0.31 0.05 452997 0.00 0.00 get_func_tv 5.15 0.36 0.0511083 0.00 0.02 buflist_new 5.15 0.41 0.0511082 0.00 0.01 buflist_findname_stat 5.15 0.46 0.05 2131 0.02 0.02 buflist_findnr 6. Agrep become very slow after using the quickfix list many times. Well, this is what I see in the profiler log: % cumulative self self total time seconds secondscalls ms/call ms/call name 55.98 4.21 4.2133246 0.13 0.13 qf_mark_adjust <<< 12.10 5.12 0.9150685 0.02 0.02 buf_valid 6.38 5.60 0.4811091 0.04 0.05 buflist_findpat 5.05 5.98 0.3813256 0.03 0.03 buflist_findnr It looks like qf_mark_adjust is called each time line is appended to a buffer using 'out_io': 'buffer' for each entry in any quickfix list available. Can we avoid this? Thanks, Ramel -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Asynchronous grep plugin - thoughts and issues
On Thursday, June 2, 2016 at 7:53:25 PM UTC+3, Bram Moolenaar wrote: > Ramel Eshed wrote: > > > Hi All, > > > > Thanks to Bram and his recent work on channels, I have a preliminary > > version of an asynchronous grep plugin which lets you work with the > > available results while grep is still running. I would like to take > > advantage of this relatively short script to raise some issues and > > thoughts I have. The plugin can be found at > > https://github.com/ramele/agrep. > > > > My original idea was to use the quickfix list and add each match to it > > from the out callback. I had some issues with it, so temporarily (I > > hope..) I’m using my own window to display the results (“agrep > > window”). This is the default now and it should demonstrate what this > > plugin should do eventually. In order to reproduce the quickfix > > issues, you'll need to tell agrep to use quickfix list instead of > > agrep window (:let qgrep_use_qf=1). You can install the plugin as is > > or load it with $vim -u NONE -N -S > > Several of the problems have been fixed. Especially appending to the > quickfix list should now be much faster. > > Let us know if you still encounter problems. > > > 3. Changing other buffers: > > As far as I know, there is no nice way to change buffers other than > > the current one. There is the getbufline() function, but the symmetry > > is broken since there is no setbufline(). I found a discussion about > > this from 10 years ago > > (http://vim.1045645.n5.nabble.com/missing-setbufline-td1155970.html) > > but I'm not sure if Bram added it to his TODO list or not. In this > > script I'm using the move_to_buf() and back_from_buf() functions. The > > problems with this approach are: > > > > - It is ugly. > > - Poor performance (it is slow, you can see the cursor jumping between > > windows, it can cause Vim to hang). > > - Difficult to change hidden buffers or buffers in other tab pages. > > - Is has side effects - It seems to break my undo tree and I'm sure > > that there are more. > > This is actually difficult to do. The internals of Vim only expect a > buffer to change when it's in a window. Also when invoking > autocommands, which expect a valid buffer and window. And undo expects > the buffer to be the current buffer. This would be a lot of work to > change, and it's likely to introduce a few bugs. > > > I'm not very much experienced with external plugins (like Python) > > which can change any buffer, but it seems that when using a channel > > with "out_io": "buffer" the performance is much better. Is it possible > > to implement such a function based on how it's done there? > > Python uses switch_to_win_for_buf(). It doesn't work perfectly though. > Marks may be wrong and it may redraw the current window even though it > didn't change. > Is it different from how 'out_io': 'buffer' is handled? Also, I tried this patch (which I found eventually in the TODO list): https://gist.github.com/mattn/23c1f50999084992ca98 and it worked very well for me. I guess that it can break other things, but maybe something like this can be added with an appropriate documentation which specify when it can be used? In order to update my buffer now, I'm using a ridiculous workaround - Vim is writing to itself through a pipe... > > -- > Micro$oft: where do you want to go today? > Linux: where do you want to go tomorrow? > FreeBSD: are you guys coming, or what? > > /// 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. For more options, visit https://groups.google.com/d/optout.
Re: Behavior of End key with mswin.vim
2016-06-03 0:06 GMT-06:00 Alex Henrie : > 2016-06-02 23:48 GMT-06:00 Alex Henrie : >> set virtualedit=onemore >> map g$ > > Actually, it looks like this would have to be something like > > imap :SmartHomeKey > map $ > > in order to support very long lines. Sorry, ignore that first line, I pasted it in by mistake. I need to just go to bed... -Alex -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Behavior of End key with mswin.vim
2016-06-02 23:48 GMT-06:00 Alex Henrie : > set virtualedit=onemore > map g$ Actually, it looks like this would have to be something like imap :SmartHomeKey map $ in order to support very long lines. -Alex -- -- 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. For more options, visit https://groups.google.com/d/optout.
Behavior of End key with mswin.vim
Hello, I have been very happy in general with the mswin.vim file distributed with Vim. However, I've run into one annoyance: I'm used to pressing End, then Ctrl+V to paste at the end of a line. But when I use this key combination with mswin.vim, my text is pasted before the last character of the line. For example, if I have the string "! Viva Uganda!" on the clipboard, and I move in normal mode to a line that says "Hello World", I expect this key combination to yield "Hello World! Viva Uganda!" Instead, I get "Hello Worl! Viva Uganda!d" Would you please consider changing the default behavior here to be more Windows-like? The following seems to work: set virtualedit=onemore map g$ I realize that I can do this in my own .vimrc, it just seems like something that would trip up everyone who is looking for Windows-like behavior. -Alex -- -- 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. For more options, visit https://groups.google.com/d/optout.
