date:20160929

Re: Possible problem when running a job immediately followed by a sleep

2016-09-29 Fir de Conversatie Bram Moolenaar


Santiago Alejandro Aguero wrote:

> While I was trying to write some vim code for testing a (async)
> functionality for Neomake plugin, I've noticed the following scenario:
> 
> 
> - Having the following shell script (with errors):
> 
> #!/bin/sh
> 
> a='$var'
> 
> foo(
> 
> 
> - And the next vim test code:
> 
> function! StartJob()
> let g:job = job_start(['/bin/sh', 'errors.sh'], {
> \ 'callback': 'HandlerCallback',
> \ 'close_cb': 'HandlerClose',
> \ 'exit_cb': 'HandlerExit'
> \ })
> endfunction
> 
> function! HandlerCallback(channel, line) abort
> call Debug('[Callback] channel: ' . a:channel . ', line: ' . a:line . ', 
> channelStatus: ' . ch_status(a:channel))
> endfunction
> 
> function! HandlerClose(channel) abort
> call Debug('[Close] channel: ' . a:channel . ', channelStatus: ' . 
> ch_status(a:channel))
> endfunction
> 
> function! HandlerExit(job, status) abort
> call Debug('[Exit] job: ' . a:job . ', status: ' . a:status . ', 
> jobStatus: ' . job_status(a:job))
> endfunction
> 
> function! Debug(msg) abort
> call writefile([a:msg], 'output.log', 'a')
> endfunction
> 
> command! -bar RunJob call StartJob()
> 
> 
> - Then the following thing happens:
> 
>   - RunJob # Works OK, both HandlerCallback (with data) and HandlerClose are 
> called
> 
>   - RunJob | sleep 50m # Does not work, only HandlerClose and HandlerExit are 
> being called (no buffered data)
> 
> 
> The reason I need the sleep is that I want to check every 50m for the 
> job_status in order to continue with some test assertions.
> 
> Also, I've noticed that this does not happen with other commands... Is there 
> something special about /bin/sh?

I did a bit of debugging and found that reading from the pipe fails if
the process has exited.  Vim does try to read, but gets zero bytes.
This is in fd_read() in channel_read() (on Unix fd_read() is a read()
system call).

The manual page for pipe(7) confirm this:

   If all file descriptors referring to the write end of a pipe have
   been closed, then an attempt to read(2) from the pipe will see end-
   of-file (read(2) will return 0).

There is no mention about what happens to the buffered output.  I guess
it's discarded when the write end of the pipe is closed.

I cannot think of a way to read from the pipe when the other end has
exited.  Thus the only workaround is to have the command wait a bit
before exiting.

-- 
ARTHUR:  I did say sorry about the `old woman,' but from the behind you
 looked--
DENNIS:  What I object to is you automatically treat me like an inferior!
ARTHUR:  Well, I AM king...
  The Quest for the Holy Grail (Monty Python)

 /// 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 8.0.0018

2016-09-29 Fir de Conversatie Bram Moolenaar


Patch 8.0.0018
Problem:When using ":sleep" channel input is not handled.
Solution:   When there is a channel check for input also when not in raw mode.
Check every 100 msec.
Files:  src/channel.c, src/proto/channel.pro, src/ui.c, src/proto/ui.pro,
src/ex_docmd.c, src/os_amiga.c, src/proto/os_amiga.pro,
src/os_unix.c, src/proto/os_unix.pro, src/os_win32.c,
src/proto/os_win32.pro


*** ../vim-8.0.0017/src/channel.c   2016-09-26 22:36:50.615386371 +0200
--- src/channel.c   2016-09-29 15:12:13.482556346 +0200
***
*** 341,346 
--- 341,352 
  return channel;
  }
  
+ int
+ has_any_channel(void)
+ {
+ return first_channel != NULL;
+ }
+ 
  /*
   * Called when the refcount of a channel is zero.
   * Return TRUE if "channel" has a callback and the associated job wasn't
*** ../vim-8.0.0017/src/proto/channel.pro   2016-09-26 22:36:50.615386371 
+0200
--- src/proto/channel.pro   2016-09-29 14:59:14.620048830 +0200
***
*** 4,9 
--- 4,10 
  void ch_log(channel_T *ch, char *msg);
  void ch_logs(channel_T *ch, char *msg, char *name);
  channel_T *add_channel(void);
+ int has_any_channel(void);
  int channel_unref(channel_T *channel);
  int free_unused_channels_contents(int copyID, int mask);
  void free_unused_channels(int copyID, int mask);
*** ../vim-8.0.0017/src/ui.c2016-08-29 22:42:20.0 +0200
--- src/ui.c2016-09-29 15:06:26.75344 +0200
***
*** 353,364 
  void
  ui_breakcheck(void)
  {
  #ifdef FEAT_GUI
  if (gui.in_use)
gui_mch_update();
  else
  #endif
!   mch_breakcheck();
  }
  
  /*
--- 353,374 
  void
  ui_breakcheck(void)
  {
+ ui_breakcheck_force(FALSE);
+ }
+ 
+ /*
+  * When "force" is true also check when the terminal is not in raw mode.
+  * This is useful to read input on channels.
+  */
+ void
+ ui_breakcheck_force(int force)
+ {
  #ifdef FEAT_GUI
  if (gui.in_use)
gui_mch_update();
  else
  #endif
!   mch_breakcheck(force);
  }
  
  /*
*** ../vim-8.0.0017/src/proto/ui.pro2016-09-12 13:04:21.0 +0200
--- src/proto/ui.pro2016-09-29 15:06:34.028948742 +0200
***
*** 10,15 
--- 10,16 
  void ui_set_shellsize(int mustset);
  void ui_new_shellsize(void);
  void ui_breakcheck(void);
+ void ui_breakcheck_force(int force);
  void clip_init(int can_use);
  void clip_update_selection(VimClipboard *clip);
  void clip_own_selection(VimClipboard *cbd);
*** ../vim-8.0.0017/src/ex_docmd.c  2016-09-11 14:36:00.0 +0200
--- src/ex_docmd.c  2016-09-29 15:06:48.532846478 +0200
***
*** 9065,9072 
wait_now = due_time;
}
  #endif
ui_delay(wait_now, TRUE);
!   ui_breakcheck();
  #ifdef MESSAGE_QUEUE
/* Process the netbeans and clientserver messages that may have been
 * received in the call to ui_breakcheck() when the GUI is in use. This
--- 9065,9081 
wait_now = due_time;
}
  #endif
+ #ifdef FEAT_JOB_CHANNEL
+   if (has_any_channel() && wait_now > 100L)
+   wait_now = 100L;
+ #endif
ui_delay(wait_now, TRUE);
! #ifdef FEAT_JOB_CHANNEL
!   if (has_any_channel())
!   ui_breakcheck_force(TRUE);
!   else
! #endif
!   ui_breakcheck();
  #ifdef MESSAGE_QUEUE
/* Process the netbeans and clientserver messages that may have been
 * received in the call to ui_breakcheck() when the GUI is in use. This
*** ../vim-8.0.0017/src/os_amiga.c  2016-08-29 22:42:20.0 +0200
--- src/os_amiga.c  2016-09-29 15:07:57.060363361 +0200
***
*** 1381,1387 
   * trouble with lattice-c programs.
   */
  void
! mch_breakcheck(void)
  {
 if (SetSignal(0L, 
(long)(SIGBREAKF_CTRL_C|SIGBREAKF_CTRL_D|SIGBREAKF_CTRL_E|SIGBREAKF_CTRL_F)) & 
SIGBREAKF_CTRL_C)
got_int = TRUE;
--- 1381,1387 
   * trouble with lattice-c programs.
   */
  void
! mch_breakcheck(int force)
  {
 if (SetSignal(0L, 
(long)(SIGBREAKF_CTRL_C|SIGBREAKF_CTRL_D|SIGBREAKF_CTRL_E|SIGBREAKF_CTRL_F)) & 
SIGBREAKF_CTRL_C)
got_int = TRUE;
*** ../vim-8.0.0017/src/proto/os_amiga.pro  2016-09-12 13:04:29.0 
+0200
--- src/proto/os_amiga.pro  2016-09-29 15:08:16.240228159 +0200
***
*** 36,42 
  void mch_set_shellsize(void);
  void mch_new_shellsize(void);
  int mch_call_shell(char_u *cmd, int options);
! void mch_breakcheck(void);
  long Chk_Abort(void);
  int mch_expandpath(garray_T *gap, char_u *pat, int flags);
  int mch_has_exp_wildcard(char_u *p);
--- 36,42 
  void mch_set_shellsize(void);
  void mch_new_shellsize(void);
  int mch_call_shell(char_u *cmd, int options);
! void mch_breakcheck(int force);
  long Chk_Abort(void);
  int

Re: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Kazunobu Kuriyama

2016-09-30 9:51 GMT+09:00 Taylor Venable :

> Thanks, but it seems I have been unclear.
>
> My problem is that, all other things being equal, scrolling through a
> buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2.
> This is not a problem that affects other GTK+ 3 applications. My example
> using the output of seq was only to illustrate how slow the scrolling is.
> Maybe a better example is:
>
> $ vim -g -u NONE -U NONE /usr/include/stdio.h
> --> then hold down the 'j' key
>
> The movement is slow, the display lags, and when you let off 'j' it keeps
> going for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).
>

So...the issue is not about "scrolling" or "shell command output", but
"(downwards) vertical movement of the cursor", right?

I thought you were talking about your issue by making it relevant to the
other issue you referred to, so I gave my explanation based on that,
interpreting it as such.

Hmm...then the (possible) reason of the slowness is probably different from
that, and I have no idea on what causes it yet.


> Sorry for the confusion before. This is not about how vim reads shell
> output. It's about the display speed under GTK+ 3.
>
> --
> --
> 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.
>

-- 
-- 
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: [vim/vim] Fix systemlist() (#1135)

2016-09-29 Fir de Conversatie h_east

Hi thinca,

2016-9-30(Fri) 12:01:55 UTC+9 thinca:
> @h-east Thank you for your advice!
> 
> I updated the patch.

You need select one of the two patches.
I think the first one is good.

> diff -ru vim.orig/src/testdir/Make_all.mak vim/src/testdir/Make_all.mak
> --- vim.orig/src/testdir/Make_all.mak 2016-09-29 11:54:58.0 +0900
> +++ vim/src/testdir/Make_all.mak  2016-09-30 09:26:47.771610300 +0900
> @@ -182,6 +182,7 @@
> test_stat.res \
> test_substitute.res \
> test_syntax.res \
> + test_system_func.res \
> test_textobjects.res \
> test_undo.res \
> test_usercommands.res \
> 
> 
> If you want to run from test_alot.vim as follows:
> diff -ru vim.orig/src/testdir/test_alot.vim vim/src/testdir/test_alot.vim
> --- vim.orig/src/testdir/test_alot.vim2016-09-29 11:54:58.0 
> +0900
> +++ vim/src/testdir/test_alot.vim 2016-09-30 10:00:40.479191900 +0900
> @@ -41,6 +41,7 @@
> source test_tagjump.vim
> source test_timers.vim
> source test_true_false.vim
> +source test_system_func.vim
> source test_unlet.vim
> source test_window_cmd.vim
> source test_options.vim

-- 
Best regards, 
Hirohito Higashi (a.k.a. h_east)

-- 
-- 
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: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Kazunobu Kuriyama

2016-09-30 1:06 GMT+09:00 Taylor Venable :

> Hi, my distribution (Arch Linux) just switched to using the GTK3 build of
> gvim by default. But it behaves very poorly on my computer, the scroll
> speed is so slow that it's very difficult to use. With GTK2, everything is
> fine. Based on another thread about GTK3 performance showing output of a
> shell command, I used this test:
>


Let me talk about the latter issue on shell command output first.  I'll
talk about the former issue on scrolling shortly after that.

I'm afraid it's not much relevant to scrolling.

Roughly speaking, when the GTK+2 GUI sends a series of drawing requests to
the X server, it completely leaves to the server what eventually appears on
the screen.  In other words, it doesn't care much about whether or not each
frame is drawn on the screen.  Not a few frames could be skipped undrawn.

In contrast, the GTK+3 GUI  draws a complete picture on a off-screen first
and then dump it at the server in accordance with a frame clock, so that
every frame will surely be drawn on the screen.

Ensuring each frame is drawn is important to realize animation of high
quality and considered to be one of inevitable features of modern GUI.

For those reasons, I'm now inclined to think that the performance test
you're referring to doesn't make much sense for the purpose of comparison,
because any GUI that cuts corners always beats a deadly earnest one at time
race. :)

As for scrolling, I suspect the refresh rate of the display you're using,
because GTK+ 3 uses a frame clock to update as noted above.



> I hope this gives enough information to help identify the issue. Maybe
> it's not even a vim problem, but in case it is, I wanted to let you know.
> Please tell me if there's anything else I can do to help gather more
> information or test. Thanks for reading!
>

Thank you for sharing your time for Vim development and kind word to help
us.

Best regards,
Kazunobu Kuriyama

>
> --
> --
> 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.
>

-- 
-- 
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: update to todo.txt

2016-09-29 Fir de Conversatie Christian Brabandt

Hi Ben!

On Do, 29 Sep 2016, Ben Fritz wrote:

> On Tuesday, September 27, 2016 at 2:09:10 PM UTC-5, Christian Brabandt
> wrote:
> > -Using ":make" blocks Vim.  Allow running one make in the background
> > (if the -shell supports it), catch errors in a file and update the
> > error list on the -fly.  A bit like "!make > file&" and repeating
> > ":cf file".  ":bgmake", -background make.  ":bgcancel" interrupts
> > it.
> 
> Is this removed, because of the job features added?

Yes.

> So this depends on a plugin? Is there a plugin out there already that 
> integrates with
> Vim's compiler options for generic compiler support, which should be
> included in or pointed to by Vim?

Neomake or syntastic perhaps.


Best,
Christian
-- 
Mein ganzes inneres Wirken erwies sich als eine lebendige 
Heuristik, welche, eine unbekannte geahnete Regel anerkennend, solche 
in der Außenwelt zu finden und in die Außenwelt einzuführen trachtet.
-- Goethe, Maximen und Reflektionen, Nr. 465

-- 
-- 
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: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Taylor Venable

On Thursday, September 29, 2016 at 2:17:45 PM UTC-4, Kazunobu Kuriyama wrote:
> 2016-09-30 1:06 GMT+09:00 Taylor Venable :
> Hi, my distribution (Arch Linux) just switched to using the GTK3 build of 
> gvim by default. But it behaves very poorly on my computer, the scroll speed 
> is so slow that it's very difficult to use. With GTK2, everything is fine. 
> Based on another thread about GTK3 performance showing output of a shell 
> command, I used this test:
> 
> 
> 
> Let me talk about the latter issue on shell command output first.  I'll talk 
> about the former issue on scrolling shortly after that.
> 
> I'm afraid it's not much relevant to scrolling.
> 
> Roughly speaking, when the GTK+2 GUI sends a series of drawing requests to 
> the X server, it completely leaves to the server what eventually appears on 
> the screen.  In other words, it doesn't care much about whether or not each 
> frame is drawn on the screen.  Not a few frames could be skipped undrawn.
> 
> In contrast, the GTK+3 GUI  draws a complete picture on a off-screen first 
> and then dump it at the server in accordance with a frame clock, so that 
> every frame will surely be drawn on the screen.
> 
> Ensuring each frame is drawn is important to realize animation of high 
> quality and considered to be one of inevitable features of modern GUI.
> 
> For those reasons, I'm now inclined to think that the performance test you're 
> referring to doesn't make much sense for the purpose of comparison, because 
> any GUI that cuts corners always beats a deadly earnest one at time race. :)
> 
> As for scrolling, I suspect the refresh rate of the display you're using, 
> because GTK+ 3 uses a frame clock to update as noted above.

Thank you for the information, I'm very ignorant about how this all works. If 
I'm reading you right, GTK3 should be smooth (if slow) because it ensures that 
every frame gets drawn. This test might not be comparable to scrolling, but it 
was far from smooth: I'd see a blank white window for a while, then numbers 
about 280 to 320 frozen on screen for 10 seconds (but at 100% CPU utilization 
the whole time), then the window would close. In contrast, with the GTK2 
version, you could see the text flying by smoothly as I would expect. I use 
some other GTK3 apps like Emacs with performance issues. My monitor's refresh 
rate is 60Hz. Do you have any suggestions on how else I could investigate? 
Thanks again for your advice.

-- 
-- 
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 8.0.0019

2016-09-29 Fir de Conversatie Bram Moolenaar


Patch 8.0.0019
Problem:Test_command_count is old style.
Solution:   Turn it into a new style test. (Naruhiko Nishino)
Use more assert functions.
Files:  src/Makefile, src/testdir/Make_all.mak, src/testdir/test_alot.vim,
src/testdir/test_autocmd.vim, src/testdir/test_command_count.in,
src/testdir/test_command_count.ok,
src/testdir/test_command_count.vim


*** ../vim-8.0.0018/src/Makefile2016-09-26 20:14:49.921906772 +0200
--- src/Makefile2016-09-29 19:23:13.153274891 +0200
***
*** 2028,2034 
test_breakindent \
test_changelist \
test_close_count \
-   test_command_count \
test_comparators \
test_erasebackword \
test_eval \
--- 2028,2033 
***
*** 2066,2071 
--- 2065,2071 
test_channel \
test_charsearch \
test_cmdline \
+   test_command_count \
test_crypt \
test_cscope \
test_cursor_func \
*** ../vim-8.0.0018/src/testdir/Make_all.mak2016-09-26 20:14:49.921906772 
+0200
--- src/testdir/Make_all.mak2016-09-29 19:11:33.650159645 +0200
***
*** 79,85 
test_breakindent.out \
test_changelist.out \
test_close_count.out \
-   test_command_count.out \
test_comparators.out \
test_erasebackword.out \
test_eval.out \
--- 79,84 
*** ../vim-8.0.0018/src/testdir/test_alot.vim   2016-09-11 14:34:48.0 
+0200
--- src/testdir/test_alot.vim   2016-09-29 19:11:33.650159645 +0200
***
*** 3,8 
--- 3,9 
  
  source test_assign.vim
  source test_autocmd.vim
+ source test_command_count.vim
  source test_cursor_func.vim
  source test_delete.vim
  source test_execute_func.vim
*** ../vim-8.0.0018/src/testdir/test_autocmd.vim2016-09-08 
22:06:01.0 +0200
--- src/testdir/test_autocmd.vim2016-09-29 19:11:33.650159645 +0200
***
*** 1,5 
--- 1,13 
  " Tests for autocommands
  
+ function! s:cleanup_buffers() abort
+   for bnr in range(1, bufnr('$'))
+ if bufloaded(bnr) && bufnr('%') != bnr
+   execute 'bd! ' . bnr
+ endif
+   endfor
+ endfunction
+ 
  func Test_vim_did_enter()
call assert_false(v:vim_did_enter)
  
***
*** 254,259 
--- 262,270 
  " Tests for autocommands on :close command.
  " This used to be in test13.
  func Test_three_windows()
+   " Clean up buffers, because in some cases this function fails.
+   call s:cleanup_buffers()
+ 
" Write three files and open them, each in a window.
" Then go to next window, with autocommand that deletes the previous one.
" Do this twice, writing the file.
*** ../vim-8.0.0018/src/testdir/test_command_count.in   2015-02-27 
20:03:15.0 +0100
--- src/testdir/test_command_count.in   1970-01-01 01:00:00.0 +0100
***
*** 1,158 
- Test for user command counts  vim: set ft=vim :
- 
- STARTTEST
- :so small.vim
- :lang C
- :let g:lines = []
- :com -range=% RangeLines :call add(g:lines, 'RangeLines '..' '.)
- :com -range -addr=arguments RangeArguments :call add(g:lines, 'RangeArguments 
'..' '.)
- :com -range=% -addr=arguments RangeArgumentsAll :call add(g:lines, 
'RangeArgumentsAll '..' '.)
- :com -range -addr=loaded_buffers RangeLoadedBuffers :call add(g:lines, 
'RangeLoadedBuffers '..' '.)
- :com -range=% -addr=loaded_buffers RangeLoadedBuffersAll :call add(g:lines, 
'RangeLoadedBuffersAll '..' '.)
- :com -range -addr=buffers RangeBuffers :call add(g:lines, 'RangeBuffers 
'..' '.)
- :com -range=% -addr=buffers RangeBuffersAll :call add(g:lines, 
'RangeBuffersAll '..' '.)
- :com -range -addr=windows RangeWindows :call add(g:lines, 'RangeWindows 
'..' '.)
- :com -range=% -addr=windows RangeWindowsAll :call add(g:lines, 
'RangeWindowsAll '..' '.)
- :com -range -addr=tabs RangeTabs :call add(g:lines, 'RangeTabs '..' 
'.)
- :com -range=% -addr=tabs RangeTabsAll :call add(g:lines, 'RangeTabsAll 
'..' '.)
- :set hidden
- :arga a b c d
- :argdo echo "loading buffers"
- :argu 3
- :.-,$-RangeArguments
- :%RangeArguments
- :RangeArgumentsAll
- :N
- :.RangeArguments
- :split|split|split|split
- :3wincmd w
- :.,$RangeWindows
- :%RangeWindows
- :RangeWindowsAll
- :only
- :blast|bd
- :.,$RangeLoadedBuffers
- :%RangeLoadedBuffers
- :RangeLoadedBuffersAll
- :.,$RangeBuffers
- :%RangeBuffers
- :RangeBuffersAll
- :tabe|tabe|tabe|tabe
- :normal 2gt
- :.,$RangeTabs
- :%RangeTabs
- :RangeTabsAll
- :1tabonly
- :s/\n/\r\r\r\r\r/
- :2ma<
- :$-ma>
- :'<,'>RangeLines
- :com -range=% -buffer LocalRangeLines :call add(g:lines, 'LocalRangeLines 
'..' '.)
- :'<,'>LocalRangeLines
- :b1
- ENDTEST
- 
- STARTTEST
- :call add(g:lines, '')
- :%argd
- :arga a b c d
- :let v:errmsg = ''
- :5argu
- :call add(g:lines, '5argu ' . v:errmsg)
- :$argu
- :call add(g:lines, '4argu ' . expand('%:t'))
- :let v:errmsg = ''
- :1argu
- :call add(g:lines, '1argu ' . expand('%:t'))
- :let v:errmsg = ''
- :100b
-

Re: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Taylor Venable

On Thursday, September 29, 2016 at 3:49:55 PM UTC-4, Taylor Venable wrote:
> I use some other GTK3 apps like Emacs with performance issues.

I'm sorry, this should have said "WITHOUT performance issues." :-)

-- 
-- 
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: update to todo.txt

2016-09-29 Fir de Conversatie Ben Fritz

On Tuesday, September 27, 2016 at 2:09:10 PM UTC-5, Christian Brabandt wrote:
> -Using ":make" blocks Vim.  Allow running one make in the background (if the
> -shell supports it), catch errors in a file and update the error list on the
> -fly.  A bit like "!make > file&" and repeating ":cf file".  ":bgmake",
> -background make.  ":bgcancel" interrupts it.

Is this removed, because of the job features added? So this depends on a 
plugin? Is there a plugin out there already that integrates with Vim's compiler 
options for generic compiler support, which should be included in or pointed to 
by Vim?

-- 
-- 
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: Add ttymouse=xterm support when TERM=tmux

2016-09-29 Fir de Conversatie Christian Brabandt

On Do, 29 Sep 2016, Michael Henry wrote:

> All,
> 
> Vim has compiled-in knowledge of a few terminals whose mouse
> support is like that of xterm.  One such terminal is GNU screen.
> Missing from this list is tmux, a terminal multiplexer similar
> to GNU screen:
> https://tmux.github.io/
> 
> When ``$TERM`` is ``screen``, Vim automatically performs the
> equivalent of ``:set ttymouse=xterm``; when ``$TERM`` is
> ``tmux``, ``ttymouse`` is left unset which causes the following
> incorrect mouse-related settings to be set:
> 
> ^[[
> ^[}
>^[MG
> 
>  in particular interferes with the processing of
> key codes that start with ``^[[``.
> 
> I'd like to propose the below patch which adds supports for tmux
> in the same way that Vim currently supports screen.
> 
> diff --git a/src/os_unix.c b/src/os_unix.c
> index 5f1c487..f12e944 100644
> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -2261,6 +2261,7 @@ use_xterm_like_mouse(char_u *name)
>  return (name != NULL
>  && (term_is_xterm
>  || STRNICMP(name, "screen", 6) == 0
> +|| STRNICMP(name, "tmux", 4) == 0
>  || STRICMP(name, "st") == 0
>  || STRNICMP(name, "st-", 3) == 0
>  || STRNICMP(name, "stterm", 6) == 0));

I thought, tmux proposed to use the screen terminal entry?

Best,
Christian
-- 
Letzte Worte eines Sportschützen:
  "Da klemmt doch was am Abzug."

-- 
-- 
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.

Add ttymouse=xterm support when TERM=tmux

2016-09-29 Fir de Conversatie Michael Henry

All,

Vim has compiled-in knowledge of a few terminals whose mouse
support is like that of xterm.  One such terminal is GNU screen.
Missing from this list is tmux, a terminal multiplexer similar
to GNU screen:
https://tmux.github.io/

When ``$TERM`` is ``screen``, Vim automatically performs the
equivalent of ``:set ttymouse=xterm``; when ``$TERM`` is
``tmux``, ``ttymouse`` is left unset which causes the following
incorrect mouse-related settings to be set:

^[[
^[}
   ^[MG

 in particular interferes with the processing of
key codes that start with ``^[[``.

I'd like to propose the below patch which adds supports for tmux
in the same way that Vim currently supports screen.

diff --git a/src/os_unix.c b/src/os_unix.c
index 5f1c487..f12e944 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -2261,6 +2261,7 @@ use_xterm_like_mouse(char_u *name)
 return (name != NULL
 && (term_is_xterm
 || STRNICMP(name, "screen", 6) == 0
+|| STRNICMP(name, "tmux", 4) == 0
 || STRICMP(name, "st") == 0
 || STRNICMP(name, "st-", 3) == 0
 || STRNICMP(name, "stterm", 6) == 0));

Thanks,
Michael Henry

-- 
-- 
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: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Kazunobu Kuriyama

2016-09-30 5:01 GMT+09:00 Taylor Venable :

> On Thursday, September 29, 2016 at 3:49:55 PM UTC-4, Taylor Venable wrote:
> > I use some other GTK3 apps like Emacs with performance issues.
>
> I'm sorry, this should have said "WITHOUT performance issues." :-)
>

Really?  I think Emacs's "M! seq 1 2000" does not correspond to Vim's
'":!seq 1 2000".  It rather corresponds to

function! EmulateEmacsMetaExclam()
  let cmd = input("Shell command: ")
  split
  wincmd w
  enew
  execute 'r!' . cmd
  normal! ggdd
  wincmd w
endfunction
nnoremap ! :call EmulateEmacsMetaExclam()

(Copy the snippet above and paste it into your ~/.vimrc.  Start vim and
press  and ! in this order in normal mode, and you will get the prompt
"Shell command: " on the command line window.
Type the string "seq 1 2000" there and press the return key.)

Is this slow on your machine in comparison with Emacs's M!?

> --
> --
> 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.
>

-- 
-- 
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: Very slow scrolling with gtk3

2016-09-29 Fir de Conversatie Taylor Venable

Thanks, but it seems I have been unclear.

My problem is that, all other things being equal, scrolling through a buffer in 
gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. This is not a 
problem that affects other GTK+ 3 applications. My example using the output of 
seq was only to illustrate how slow the scrolling is. Maybe a better example is:

$ vim -g -u NONE -U NONE /usr/include/stdio.h
--> then hold down the 'j' key

The movement is slow, the display lags, and when you let off 'j' it keeps going 
for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).

Sorry for the confusion before. This is not about how vim reads shell output. 
It's about the display speed under GTK+ 3.

-- 
-- 
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: [vim/vim] Fix systemlist() (#1135)

2016-09-29 Fir de Conversatie h_east

Hi thinca,

2016-9-30(Fri) 1:39:34 UTC+9 thinca:
> :help systemlist() says:
> 
> 
> 
> Output is the same as readfile() will output with {binary} argument
> 
> set to "b".
> 
> 
> 
> And :help readfile() says:
> 
> 
> 
> When {binary} contains "b" binary mode is used:
> 
> 
> When the last line ends in a NL an extra empty list item is
> added.
> No CR characters are removed.
> 
> 
> 
> 
> systemlist() doesn't satisfy the first matter.
> 
> 
> :echo systemlist('echo hello')
> " => ['hello']
> " `echo` command outputs text with NL,
> " so this should be ['hello', '']
> 
> 
> This change fixes the above problem.
> 
> 
> 
> You can view, comment on, or merge this pull request online at:
> 
>   https://github.com/vim/vim/pull/1135
> 
> Commit Summary
> 
>   Fix systemlist()
> 
> 
> File Changes
> 
>   
> M
> src/Makefile
> (1)
>   
>   
> M
> src/evalfunc.c
> (2)
>   
>   
> A
> src/testdir/test_system_func.vim
> (20)
>   
> 
> 
> Patch Links:
> 
>   https://github.com/vim/vim/pull/1135.patch
>   https://github.com/vim/vim/pull/1135.diff

Good patch
Unfortunately, test that your have to add is not running in the Travis CI and 
AppVeyor.
You should modified as follows:
diff -ru vim.orig/src/testdir/Make_all.mak vim/src/testdir/Make_all.mak
--- vim.orig/src/testdir/Make_all.mak   2016-09-29 11:54:58.0 +0900
+++ vim/src/testdir/Make_all.mak2016-09-30 09:26:47.771610300 +0900
@@ -182,6 +182,7 @@
test_stat.res \
test_substitute.res \
test_syntax.res \
+   test_system_func.res \
test_textobjects.res \
test_undo.res \
test_usercommands.res \


If you want to run from test_alot.vim as follows:
diff -ru vim.orig/src/testdir/test_alot.vim vim/src/testdir/test_alot.vim
--- vim.orig/src/testdir/test_alot.vim  2016-09-29 11:54:58.0 +0900
+++ vim/src/testdir/test_alot.vim   2016-09-30 10:00:40.479191900 +0900
@@ -41,6 +41,7 @@
 source test_tagjump.vim
 source test_timers.vim
 source test_true_false.vim
+source test_system_func.vim
 source test_unlet.vim
 source test_window_cmd.vim
 source test_options.vim

-- 
Best regards, 
Hirohito Higashi (a.k.a. h_east) 

-- 
-- 
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: Possible problem when running a job immediately followed by a sleep

2016-09-29 Fir de Conversatie Bram Moolenaar


Daniel Hahler wrote:

> > Thanks, this is useful.  Now we need to find out why we see an error or
> > nothing to read, while reading the pipe/socket should give us the
> > output.  Adding some ch_logs() calls in channel_wait() could help
> > pinpoint it.
> 
> Sorry, I have not patched/debugged Vim, but want to add some findings while 
> trying to make the async support for Vim work in Neomake.
> 
> 
> I think this might also be related to channels only being read from
> when Vim waits for user input, and that the closing callback is being
> invoked nonetheless - but input is discarded?!
> 
> The following will not collect the line (to be run with `vim -Nu t.vim`):
> 
> ```
> call ch_logfile('/tmp/job.log')
> 
> let g:lines = []
> function Callback(channel, data)
>   echom "CALLBACK" string(a:channel) string(a:data)
>   echom "\n"
>   let g:lines += [a:data]
> endfunction
> 
> function Close_cb(channel)
>   let g:lines += ['closed']
>   echom "CLOSE" string(a:channel)
>   echom "\n"
> endfunction
> 
> function Start(nr)
>   return job_start(['sh', '-c', 'echo '.a:nr], {
> \ 'callback': 'Callback',
> \ 'close_cb': 'Close_cb',
> \ })
> endfunction
> 
> call Start(1)
> sleep 1
> echom "lines" string(g:lines)
> ```

When I run this, the output is:
lines []
Press ENTER or type command to continueCALLBACK channel 0 closed '1'^@CLOSE 
channel 0 closed^@

And g:lines contains: ['1', 'closed']

So the output is read correctly, but only after "sleep 1".


> I can make it work when using `call input('continue?')` instead of the sleep.

What do you mean with "can make it work"?

> Is there another workaround / command that can be used to read from
> all channels?
> 
> Callbacks are only called at a "safe" moment, usually when Vim
> is waiting for the user to type a character.  Vim does not use
> multi-threading.
> 
> The workaround I've found to make the tests in Neomake work is appending a 
> "sleep .1" to the job's (shell) command: this makes it apparently stay long 
> enough so that output gets handled.  But I do not think this is a good 
> workaround after all, and it does not work when trying to call "nonexistent".
> 
> 
> For starters: what about handling "sleep" like "call input()"?

Yes, I thought that already happened, apparently not.

> btw: I've found that `ch_read(job, {'timeout': 0})` can be used to read from 
> the channel, but that does not trigger the callbacks, and the following will 
> even deadlock Vim (100%), apparently in "ch_read":
> 
> ```
> let job = Start(1)
> while 1
>   let job_info = job_info(job)
>   if job_info['status'] == 'dead'
> let data = ch_read(job, {'timeout': 0})
> echom "READ DATA" string(data)
>   endif
>   echom string(job_info)
>   echom "."
>   sleep 10m
> endwhile
> echom "lines" string(g:lines)
> ```
> 
> The log for this is:
>   0.40 : Starting job: sh  -c  echo 1
>   0.76 on 0: Created channel
>   0.012068 : looking for messages on channels
>   0.012367 on 0: Job ended
>   0.012836 on 0: Blocking NL read, timeout: 0 msec
>   0.012994 RECV on 0: '1
> '
>   0.013014 on 0: Returning 1 bytes
>   0.023729 : looking for messages on channels
>   0.024069 on 0: Blocking NL read, timeout: 0 msec
>   0.024097 ERR on 0: channel_read_block(): Cannot read from channel, will 
> close it soon
> 
> 
> Sorry for the unstructured comments, but it appears to be really buggy
> in this regard.

Mixing callbacks with reading with ch_read() creates a race condition,
better not do that.

-- 
[clop clop]
ARTHUR:  Old woman!
DENNIS:  Man!
ARTHUR:  Man, sorry.  What knight lives in that castle over there?
DENNIS:  I'm thirty seven.
ARTHUR:  What?
DENNIS:  I'm thirty seven -- I'm not old!
  The Quest for the Holy Grail (Monty Python)

 /// 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: Add ttymouse=xterm support when TERM=tmux

2016-09-29 Fir de Conversatie James McCoy

On Sep 29, 2016 7:12 AM, "Christian Brabandt"  wrote:
> I thought, tmux proposed to use the screen terminal entry?

Staying in 2.1 tmux can be used to differentiate functionality.

https://github.com/tmux/tmux/blob/20598dff258da1e96a060adba95e8e05bfdd8b3b/FAQ#L355-L378

Cheers,
James

-- 
-- 
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: Possible problem when running a job immediately followed by a sleep

Patch 8.0.0018

Re: Very slow scrolling with gtk3

Re: [vim/vim] Fix systemlist() (#1135)

Re: Very slow scrolling with gtk3

Re: update to todo.txt

Re: Very slow scrolling with gtk3

Patch 8.0.0019

Re: Very slow scrolling with gtk3

Re: update to todo.txt

Re: Add ttymouse=xterm support when TERM=tmux

Add ttymouse=xterm support when TERM=tmux

Re: Very slow scrolling with gtk3

Re: Very slow scrolling with gtk3

Re: [vim/vim] Fix systemlist() (#1135)

Re: Possible problem when running a job immediately followed by a sleep

Re: Add ttymouse=xterm support when TERM=tmux

17 matches

Site Navigation

Mail list logo

Footer information