Re: Terminal is very slow in the gui

[Ramel Eshed]

On Wednesday, October 11, 2017 at 1:04:50 AM UTC+3, Ken Takata wrote:
> Hi Ramel,
> 
> 2017/10/11 Wed 6:08:33 UTC+9 Ramel Eshed wrote:
> > On Saturday, September 30, 2017 at 5:00:38 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > Running the following script in the gui (:terminal job.sh) takes more
> > > > than 10 seconds. During that time the screen in not updated and vim is
> > > > not responsive. Doing the same in terminal-vim is much faster, but the
> > > > screen is updated only when the job is finished.
> > > > 
> > > > running this script using job_start(), for comparison, is very fast
> > > > and seamless:
> > > > call job_start(['/bin/sh', '-c', 'job.sh'], {'out_io': 'buffer', 
> > > > 'out_buf': 1})
> > > > 
> > > > $ cat job.sh
> > > > #!/bin/bash
> > > > for i in `seq 1 2`;
> > > > do
> > > > echo "$i"
> > > > done
> > > > 
> > > > I'm running the latest Vim (1161) on Ubuntu.
> > > 
> > > Using job_start() is always going to be faster, since with a terminal
> > > window everything goes through the virtual terminal.  That's quite a bit
> > > of overhead.  Partly because it supports colors and other attributes.
> > > 
> > > There is a todo item to make screen updating for the terminal more
> > > efficient, not sure how much it helps in this case, it's mostly to skip
> > > redrawing lines that didn't change.
> > > 
> > > -- 
> > > hundred-and-one symptoms of being an internet addict:
> > > 231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner
> > >  in the front doorway permanently so it always looks like you are
> > >  actually attempting to do something about that mess that has amassed
> > >  since you discovered the Internet.
> > > 
> > >  /// 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
> > > ///
> > 
> > Hi Bram,
> > 
> > I'm trying to understand why running my example script is so slow on gvim's 
> > terminal compared to gnome-terminal and terminal-vim:
> > 
> > gnome-terminal:
> > real0m0.196s
> > user0m0.156s
> > sys 0m0.036s
> > 
> > vim:
> > real0m0.515s
> > user0m0.132s
> > sys 0m0.024s
> > 
> > gvim:
> > real0m7.953s
> > user0m0.120s
> > sys 0m0.036s
> > 
> > I tried to run with profiling but I'm not sure I understand the results.. 
> > (see the attached vim and gvim gprof files).
> > Is there any problem with profiling in the GUI? -because I see the 
> > following comment in the Makefile:
> > 
> > # PROFILING - Uncomment the next two lines to do profiling with gcc and 
> > gprof.
> > # Might not work with GUI or Perl.
> > 
> > Can you learn something from the attached results?
> 
> Does this solve the problem?
> https://github.com/vim/vim/pull/2010#issuecomment-334371470
> 
> I tried this only on Windows, so not sure this applies to Linux.
> 
> Regards,
> Ken Takata

Hi Ken,

This patch works very well in vim - it is faster now, and I don't see the 
screen update issues that I had before.
For gvim it is better, but still takes 4-5 seconds and the cursor is flickering 
at the bottom line of the terminal window.

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.

Scrolling with the mouse-wheel when scrollbind is set

[Ramel Eshed]

I found this in the help for scroll-binding:

"When using the scrollbars, the binding only happens when scrolling the window 
with focus (where the cursor is). You can use this to avoid scroll-binding for 
a moment without resetting options."

Actually, this is also the case for scrolling with the mouse-wheel (also in GTK 
gui, and xterm) which I find not intuitive and annoying for a long time. Is 
there any way to make the scroll-wheel work on all the bonded windows (and yet 
to be able to scroll the window where the mouse is on when 'noscb')?

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.

Terminal is very slow in the gui

[Ramel Eshed]

Hi,

Running the following script in the gui (:terminal job.sh) takes more than 10 
seconds. During that time the screen in not updated and vim is not responsive. 
Doing the same in terminal-vim is much faster, but the screen is updated only 
when the job is finished.

running this script using job_start(), for comparison, is very fast and 
seamless:
call job_start(['/bin/sh', '-c', 'job.sh'], {'out_io': 'buffer', 'out_buf': 1})

$ cat job.sh
#!/bin/bash
for i in `seq 1 2`;
do
echo "$i"
done

I'm running the latest Vim (1161) on Ubuntu.

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.

Problem to restore registers

[Ramel Eshed]

Hi,

Sometimes, there is a need for a mapping to yank something without a trace so 
it has to save and restore the relevant registers.
The problem is that there is no way to set register " without modifying 
register 0. So if, for example, I yanked something and then deleted something 
else and now want to do a yank as part of a mapping, this mapping will have to 
restore register " with the deleted text. But now the original content of 
register 0 (the yanked text) is lost.

Maybe we need to add an option to setreg() to avoid setting register 0 along 
with register ".


Another issue: register 1 contains the last deleted text also when specifying 
another register ("xdd). This is not according to the help and yank behavior:

   "Numbered register 0 contains the text from the most recent yank command, 
unless the command specified another register with ["x].
   Numbered register 1 contains the text deleted by the most recent delete or 
change command, unless the command specified another register"

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.

Another issue when searching with ? and CTRL-G

[Ramel Eshed]

vim -u NONE -N
:set incsearch
iaaa   (insert 3 lines of 'a')

?a  (now line 2 is highlighted)
^G   (now line 3 is highlighted)
 (cursor ends at line 1!)

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.

'~' should be escaped when using search and CTRL-L

[Ramel Eshed]

Hi,

Please have a look:

vim -u NONE -N
:set incsearch
ia~b (insert the text "a~b")
?a^L (search for 'a' and hit CTRL-L and ENTER)

I'm getting E33 because '~' is not escaped.

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: wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

On Friday, May 5, 2017 at 11:23:57 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > > On Sunday, April 30, 2017 at 9:24:13 PM UTC+3, Bram Moolenaar wrote:
> > > > > Ramel Eshed wrote:
> > > > > 
> > > > > > On Sunday, April 30, 2017 at 5:25:08 PM UTC+3, Bram Moolenaar wrote:
> > > > > > > Ramel Eshed wrote:
> > > > > > > 
> > > > > > > > This is not the case with every job, but redirecting the 
> > > > > > > > following
> > > > > > > > script output to a buffer causes messages to disappear from 
> > > > > > > > command
> > > > > > > > line:
> > > > > > > >  
> > > > > > > > -- loop.sh --
> > > > > > > > #!/bin/bash
> > > > > > > > for i in `seq 1 1000`;
> > > > > > > > do
> > > > > > > > echo $i
> > > > > > > > sleep 0.008s
> > > > > > > > done
> > > > > > > > 
> > > > > > > > vim -u NONE -N
> > > > > > > > :call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})
> > > > > > > > 
> > > > > > > > while the numbers are running try to do :pwd -this command's 
> > > > > > > > output
> > > > > > > > will disappear.
> > > > > > > > 
> > > > > > > > Also (not related to this issue), the buffer (which the job 
> > > > > > > > output was
> > > > > > > > redirected to) is only updated in normal and insert mode but 
> > > > > > > > not while
> > > > > > > > typing in command-line mode. Is it possible to update the 
> > > > > > > > buffer also
> > > > > > > > for command-line?
> > > > > > > 
> > > > > > > I suspect these are opposite requests.  Vim can only update the 
> > > > > > > whole
> > > > > > > screen, because the redraw causes any output from commands to be
> > > > > > > cleared. When looking at the output of :pwd, Vim is probably in 
> > > > > > > Normal
> > > > > > > mode, thus redraws to show the new buffer content.
> > > > > >
> > > > > > If I use
> > > > > > :call job_start('ls -lR /', {'out_io': 'buffer', 'out_buf':1})
> > > > > > instead of the above script, I can still see the :pwd command 
> > > > > > output.
> > > > > > How come it's not cleared as well?
> > > > > >
> > > > > > > I could check if we can update the window only. This probably 
> > > > > > > only works
> > > > > > > when the command line has not scrolled.
> > > > > 
> > > > > I have sent out patch 8.0.0592.  This attempts to update the buffer 
> > > > > that
> > > > > shows job output as often as possible.  And it tries to keep the 
> > > > > command
> > > > > line and command output.  Please check it out.  It does update the
> > > > > buffer more often than before, and should keep the output of commands
> > > > > like ":pwd".  It may cause new problems, I only tested a few things.
> > > > > 
> > > > I tested this patch with my plugins and it seems that both issues are
> > > > solved now. There is a minor issue with text and cursor flickering in
> > > > the command line, you can play with the sleep delay in the script
> > > > above and see if there is something you can do.
> > > > Many thanks!
> > > 
> > > It is unlikely the cursor flickering can be fixed.  It has to be
> > > switched off to be able to redraw the window for the modified buffer.
> > > 
> > Besides of the cursor, the part of the command that has already been
> > typed flickers as well, can you see that?
> 
> It might be possible to fix that, if we overwrite the command line and
> clear the rest.  Perhaps someone wants to have a go at that.
> 
> > Also, I found a problem with the command line completion menu - it is
> > cleared while the buffer is updated. You can see that by running my
> > example above after :set wildmode=list. While the buffer is updated
> > try to type :set and then hit tab -the completion menu will be
> > cleared.
> 
> Hmm, perhaps msg_scrolled isn't set in that situation, and we need to
> check another flag.
> 

Did anyone have a chance to look at this? both issues still exist.

-- 
-- 
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] Regularly exiting vim sets xterm in bracketed paste mode (#1671)

[Ramel Eshed]

On Tuesday, June 6, 2017 at 11:58:50 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > Any updates about this issue?
> > I'm using gnome terminal 2.31.3 (which comes with RHEL6) and must set t_BE= 
> > to avoid the corrupted pate issue in the terminal after exiting Vim.
> > 
> > I think that there is no reason to break old behavior, even if there is a 
> > workaround for that.
> 
> The support for bracketed paste was added for good reasons.  That before
> this many terminals that aren't actually an xterm worked fine, even when
> $TERM is set to xterm, doesn't mean this will keep working forever.
> The basic problem is that if a terminal isn't really an xterm, then it
> can break at any time.  That isn't Vim's fault.  We will try to make it
> work even when the user did not setup his system exactly right, but in
> this case I don't see how we can detect a "bad terminal".  I wish every
> terminal had a way to tell us its features instead of relying on setting
> $TERM correctly.
> 
> There should also be a way to separate a term response from what the
> user typed.  Haven't seen any progress on that, unfortunately.
> 

OK, I understand. Thank you for this explanation.

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

[Ramel Eshed]

On Tuesday, June 6, 2017 at 11:25:30 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Monday, June 5, 2017 at 8:32:57 PM UTC+3, Bram Moolenaar wrote:
> > > Patch 8.0.0626
> > > Problem:In the GUI the cursor may flicker.
> > > Solution:   Check the cmd_silent flag before updating the cursor shape.
> > > (Hirohito Higashi, closes #1637)
> > > Files:  src/getchar.c
> > > 
> > > 
> > > *** ../vim-8.0.0625/src/getchar.c 2017-04-08 18:41:07.339941299 +0200
> > > --- src/getchar.c 2017-06-05 19:28:16.696484466 +0200
> > > ***
> > > *** 2913,2920 
> > >   }
> > >   #ifdef FEAT_GUI
> > >   /* may unshow different cursor shape */
> > > ! if (gui.in_use && shape_changed)
> > > ! gui_update_cursor(TRUE, FALSE);
> > >   #endif
> > >   
> > >   --vgetc_busy;
> > > --- 2913,2928 
> > >   }
> > >   #ifdef FEAT_GUI
> > >   /* may unshow different cursor shape */
> > > ! if (gui.in_use)
> > > ! {
> > > ! if (cmd_silent)
> > > ! gui_dont_update_cursor(TRUE);
> > > ! else
> > > ! gui_can_update_cursor();
> > > ! 
> > > ! if (shape_changed)
> > > ! gui_update_cursor(TRUE, FALSE);
> > > ! }
> > >   #endif
> > >   
> > >   --vgetc_busy;
> > > *** ../vim-8.0.0625/src/version.c 2017-06-05 18:46:20.497845949 +0200
> > > --- src/version.c 2017-06-05 19:06:06.449739127 +0200
> > > ***
> > > *** 766,767 
> > > --- 766,769 
> > >   {   /* Add new patch number below this line */
> > > + /**/
> > > + 626,
> > >   /**/
> > > 
> > > -- 
> > > "How is your new girlfriend?"
> > > "90-60-90 man!"
> > > "What, pale purple?"
> > > 
> > >  /// 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
> > > ///
> > 
> > Hi Bram,
> > 
> > This match makes the cursor disappear using the following mapping (tested 
> > on linux):
> > 
> > gvim -u NONE -N
> > :noremap   
> > 
> > now hit  -> no cursor
> 
> Yes, that is wrong.  I was wondering about the conditions anyway.  I
> would think that if shape_changed isn't set then nothing should happen.
> How about this:
> 
> #ifdef FEAT_GUI
> /* may unshow different cursor shape */
> if (gui.in_use && shape_changed && !cmd_silent)
>   gui_update_cursor(TRUE, FALSE);
> #endif
> 
> But then we perhaps get the flicker again?  An alternative is to not
> call gui_update_cursor() for NORMAL mode:
> 
> #ifdef FEAT_GUI
>   /* may show different cursor shape */
>   if (gui.in_use && State != NORMAL && !cmd_silent)
>   {
>   int save_State;
> 
>   save_State = State;
>   State = NORMAL;
>   gui_update_cursor(TRUE, FALSE);
>   State = save_State;
>   shape_changed = TRUE;
>   }
> #endif
> 
> -- 

Both options solved my problem, but I'm not sure about the original denite 
plugin issue.

Thanks

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Regularly exiting vim sets xterm in bracketed paste mode (#1671)

[Ramel Eshed]

Hi All,

Any updates about this issue?
I'm using gnome terminal 2.31.3 (which comes with RHEL6) and must set t_BE= to 
avoid the corrupted pate issue in the terminal after exiting Vim.

I think that there is no reason to break old behavior, even if there is a 
workaround for that.

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: Patch 8.0.0626

[Ramel Eshed]

On Monday, June 5, 2017 at 8:32:57 PM UTC+3, Bram Moolenaar wrote:
> Patch 8.0.0626
> Problem:In the GUI the cursor may flicker.
> Solution:   Check the cmd_silent flag before updating the cursor shape.
> (Hirohito Higashi, closes #1637)
> Files:  src/getchar.c
> 
> 
> *** ../vim-8.0.0625/src/getchar.c 2017-04-08 18:41:07.339941299 +0200
> --- src/getchar.c 2017-06-05 19:28:16.696484466 +0200
> ***
> *** 2913,2920 
>   }
>   #ifdef FEAT_GUI
>   /* may unshow different cursor shape */
> ! if (gui.in_use && shape_changed)
> ! gui_update_cursor(TRUE, FALSE);
>   #endif
>   
>   --vgetc_busy;
> --- 2913,2928 
>   }
>   #ifdef FEAT_GUI
>   /* may unshow different cursor shape */
> ! if (gui.in_use)
> ! {
> ! if (cmd_silent)
> ! gui_dont_update_cursor(TRUE);
> ! else
> ! gui_can_update_cursor();
> ! 
> ! if (shape_changed)
> ! gui_update_cursor(TRUE, FALSE);
> ! }
>   #endif
>   
>   --vgetc_busy;
> *** ../vim-8.0.0625/src/version.c 2017-06-05 18:46:20.497845949 +0200
> --- src/version.c 2017-06-05 19:06:06.449739127 +0200
> ***
> *** 766,767 
> --- 766,769 
>   {   /* Add new patch number below this line */
> + /**/
> + 626,
>   /**/
> 
> -- 
> "How is your new girlfriend?"
> "90-60-90 man!"
> "What, pale purple?"
> 
>  /// 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///

Hi Bram,

This match makes the cursor disappear using the following mapping (tested on 
linux):

gvim -u NONE -N
:noremap   

now hit  -> no cursor

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: wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

On Monday, May 1, 2017 at 3:32:04 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Sunday, April 30, 2017 at 9:24:13 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > On Sunday, April 30, 2017 at 5:25:08 PM UTC+3, Bram Moolenaar wrote:
> > > > > Ramel Eshed wrote:
> > > > > 
> > > > > > This is not the case with every job, but redirecting the following
> > > > > > script output to a buffer causes messages to disappear from command
> > > > > > line:
> > > > > >  
> > > > > > -- loop.sh --
> > > > > > #!/bin/bash
> > > > > > for i in `seq 1 1000`;
> > > > > > do
> > > > > > echo $i
> > > > > > sleep 0.008s
> > > > > > done
> > > > > > 
> > > > > > vim -u NONE -N
> > > > > > :call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})
> > > > > > 
> > > > > > while the numbers are running try to do :pwd -this command's output
> > > > > > will disappear.
> > > > > > 
> > > > > > Also (not related to this issue), the buffer (which the job output 
> > > > > > was
> > > > > > redirected to) is only updated in normal and insert mode but not 
> > > > > > while
> > > > > > typing in command-line mode. Is it possible to update the buffer 
> > > > > > also
> > > > > > for command-line?
> > > > > 
> > > > > I suspect these are opposite requests.  Vim can only update the whole
> > > > > screen, because the redraw causes any output from commands to be
> > > > > cleared. When looking at the output of :pwd, Vim is probably in Normal
> > > > > mode, thus redraws to show the new buffer content.
> > > >
> > > > If I use
> > > > :call job_start('ls -lR /', {'out_io': 'buffer', 'out_buf':1})
> > > > instead of the above script, I can still see the :pwd command output.
> > > > How come it's not cleared as well?
> > > >
> > > > > I could check if we can update the window only. This probably only 
> > > > > works
> > > > > when the command line has not scrolled.
> > > 
> > > I have sent out patch 8.0.0592.  This attempts to update the buffer that
> > > shows job output as often as possible.  And it tries to keep the command
> > > line and command output.  Please check it out.  It does update the
> > > buffer more often than before, and should keep the output of commands
> > > like ":pwd".  It may cause new problems, I only tested a few things.
> > > 
> > I tested this patch with my plugins and it seems that both issues are
> > solved now. There is a minor issue with text and cursor flickering in
> > the command line, you can play with the sleep delay in the script
> > above and see if there is something you can do.
> > Many thanks!
> 
> It is unlikely the cursor flickering can be fixed.  It has to be
> switched off to be able to redraw the window for the modified buffer.
> 
Besides of the cursor, the part of the command that has already been typed 
flickers as well, can you see that?

Also, I found a problem with the command line completion menu - it is cleared 
while the buffer is updated. You can see that by running my example above after 
:set wildmode=list. While the buffer is updated try to type :set and then hit 
tab -the completion menu will be cleared.

> -- 
> Veni, Vidi, VW -- I came, I saw, I drove around in a little car.
> 
>  /// 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: wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

On Sunday, April 30, 2017 at 9:24:13 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Sunday, April 30, 2017 at 5:25:08 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > This is not the case with every job, but redirecting the following
> > > > script output to a buffer causes messages to disappear from command
> > > > line:
> > > >  
> > > > -- loop.sh --
> > > > #!/bin/bash
> > > > for i in `seq 1 1000`;
> > > > do
> > > > echo $i
> > > > sleep 0.008s
> > > > done
> > > > 
> > > > vim -u NONE -N
> > > > :call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})
> > > > 
> > > > while the numbers are running try to do :pwd -this command's output
> > > > will disappear.
> > > > 
> > > > Also (not related to this issue), the buffer (which the job output was
> > > > redirected to) is only updated in normal and insert mode but not while
> > > > typing in command-line mode. Is it possible to update the buffer also
> > > > for command-line?
> > > 
> > > I suspect these are opposite requests.  Vim can only update the whole
> > > screen, because the redraw causes any output from commands to be
> > > cleared. When looking at the output of :pwd, Vim is probably in Normal
> > > mode, thus redraws to show the new buffer content.
> >
> > If I use
> > :call job_start('ls -lR /', {'out_io': 'buffer', 'out_buf':1})
> > instead of the above script, I can still see the :pwd command output.
> > How come it's not cleared as well?
> >
> > > I could check if we can update the window only. This probably only works
> > > when the command line has not scrolled.
> 
> I have sent out patch 8.0.0592.  This attempts to update the buffer that
> shows job output as often as possible.  And it tries to keep the command
> line and command output.  Please check it out.  It does update the
> buffer more often than before, and should keep the output of commands
> like ":pwd".  It may cause new problems, I only tested a few things.
> 
I tested this patch with my plugins and it seems that both issues are solved 
now. There is a minor issue with text and cursor flickering in the command 
line, you can play with the sleep delay in the script above and see if there is 
something you can do.
Many thanks!
> -- 
> I just planted an Algebra tree. It has square roots.
> 
>  /// 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: wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

On Sunday, April 30, 2017 at 5:25:08 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > This is not the case with every job, but redirecting the following
> > script output to a buffer causes messages to disappear from command
> > line:
> >  
> > -- loop.sh --
> > #!/bin/bash
> > for i in `seq 1 1000`;
> > do
> > echo $i
> > sleep 0.008s
> > done
> > 
> > vim -u NONE -N
> > :call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})
> > 
> > while the numbers are running try to do :pwd -this command's output
> > will disappear.
> > 
> > Also (not related to this issue), the buffer (which the job output was
> > redirected to) is only updated in normal and insert mode but not while
> > typing in command-line mode. Is it possible to update the buffer also
> > for command-line?
> 
> I suspect these are opposite requests.  Vim can only update the whole
> screen, because the redraw causes any output from commands to be
> cleared. When looking at the output of :pwd, Vim is probably in Normal
> mode, thus redraws to show the new buffer content.
> 
If I use
:call job_start('ls -lR /', {'out_io': 'buffer', 'out_buf':1})
instead of the above script, I can still see the :pwd command output. How come 
it's not cleared as well?
> I could check if we can update the window only. This probably only works
> when the command line has not scrolled.
> 
> -- 
> An indication you must be a manager:
> You give constructive feedback to your dog.
> 
>  /// 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.

wrong command-line redraw when using 'out_io': 'buffer' with job_start()

[Ramel Eshed]

Hi,

This is not the case with every job, but redirecting the following script 
output to a buffer causes messages to disappear from command line:
 
-- loop.sh --
#!/bin/bash
for i in `seq 1 1000`;
do
echo $i
sleep 0.008s
done

vim -u NONE -N
:call job_start('loop.sh', {'out_io': 'buffer', 'out_buf':1})

while the numbers are running try to do :pwd -this command's output will 
disappear.

Also (not related to this issue), the buffer (which the job output was 
redirected to) is only updated in normal and insert mode but not while typing 
in command-line mode. Is it possible to update the buffer also for command-line?

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: Inconsistency between the different insert mode * commands

[Ramel Eshed]

On Wednesday, April 5, 2017 at 9:47:21 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > > vim -u NONE
> > > > 
> > > > ia="b\n"
> > > > 
> > > > results:
> > > > ab
> > > > 
> > > > 
> > > > This should be the expected behavior as I understand. But if I use 
> > > > instead:
> > > > ia="b\n"
> > > > 
> > > > I get:
> > > > b
> > > > a
> > > > 
> > > > Also:
> > > > 
> > > > ia="b\n"
> > > > I get:
> > > > ab^@
> > > > 
> > > > -the ^@ is displayed instead of an empty new line.
> > > > 
> > > > I'm using vim 8.0.540 on RHEL6. Please look into it.
> > > 
> > > Vim offers those different commands to be able to insert different
> > > things.  So it's normal that they work differently.
> > > 
> > > On top of that, it appears that in the second case the register is
> > > recognized as linewise, since the text ends in a NL.
> > > 
> > 
> > Hi Bram,
> > 
> > I'm aware to the differences between these commands. According to the 
> > documentation both  and  insert the text literally and 
> > the only difference is if the formatting options are used or not. I don't 
> > see how formatting is related to my example or why one command uses a 
> > linewise register while the other is not.
> > 
> > Also, I'm not sure if this is related, but I noticed that the results of 
> > the following two sequences are different:
> > 1) ia="b\n"
> > 2) let @b="b\n"
> >iab
> 
> Yes, the first one evaluates an expression and inserts the result.  The
> second one assigns an expression to a register, where the trailing NL
> causes it to become linewise.  An expression itself is just a string,
> a register can be linewise.

Ok, but still why  considers the above b register (let @b="b\n") 
linewise while  not?

-- 
-- 
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: Inconsistency between the different insert mode * commands

[Ramel Eshed]

On Monday, April 3, 2017 at 10:36:06 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > vim -u NONE
> > 
> > ia="b\n"
> > 
> > results:
> > ab
> > 
> > 
> > This should be the expected behavior as I understand. But if I use instead:
> > ia="b\n"
> > 
> > I get:
> > b
> > a
> > 
> > Also:
> > 
> > ia="b\n"
> > I get:
> > ab^@
> > 
> > -the ^@ is displayed instead of an empty new line.
> > 
> > I'm using vim 8.0.540 on RHEL6. Please look into it.
> 
> Vim offers those different commands to be able to insert different
> things.  So it's normal that they work differently.
> 
> On top of that, it appears that in the second case the register is
> recognized as linewise, since the text ends in a NL.
> 

Hi Bram,

I'm aware to the differences between these commands. According to the 
documentation both  and  insert the text literally and the 
only difference is if the formatting options are used or not. I don't see how 
formatting is related to my example or why one command uses a linewise register 
while the other is not.

Also, I'm not sure if this is related, but I noticed that the results of the 
following two sequences are different:
1) ia="b\n"
2) let @b="b\n"
   iab

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

Inconsistency between the different insert mode * commands

[Ramel Eshed]

Hi,

vim -u NONE

ia="b\n"

results:
ab


This should be the expected behavior as I understand. But if I use instead:
ia="b\n"

I get:
b
a

Also:

ia="b\n"
I get:
ab^@

-the ^@ is displayed instead of an empty new line.

I'm using vim 8.0.540 on RHEL6. Please look into it.

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: system() delay

[Ramel Eshed]

On Monday, August 29, 2016 at 8:35:33 AM UTC+3, Dominique Pelle wrote:
> Ramel  wrote:
> 
> > Nice catch!
> > My 'shell' was tcsh and after changing it to /bin/sh (=bash) System() works
> > much better (only ~x2 slower than Job()). I probably wouldn't get into this
> > if I got these results in the first place.. still, I'm going to use the
> > above blocking version of job_start (it is as fast as Job()) since in RHEL
> > everything is slower by a factor of 10(!) anyway.
> >
> > Thanks,
> > Ramel
> 
> Hi Ramel
> 
> Can you provide the timings with at least 3 runs as I did on RHEL?
> 
> And can you attach the output of the strace command on RHEL?
> I.e. run:
> 
> $ strace -r -f -osystem.trace time vim -u NONE -N -S system.vim  -c
> 'call System()|q'
> 
> $ strace -r -f -ojob.trace time vim -u NONE -N -S system.vim  -c
> 'call Job()|q'
> 
> And attach files jobs.trace and system.trace.  Please also indicate
> which version of vim you used.
> 
> Thanks
> Dominique
> 
> PS: please use bottom-post in vim-dev.

Hi Dominique,

Sorry, but the RHEL is at my work and the trace files are relatively big and 
contain confidential details..
You can see the timings below.

Thanks,
Ramel

RHEL 5.5 (using shell=bash)

Job():
aaa:   0.012400
aaa:   0.011879
aaa:   0.012227

System():
aaa:   0.053787
aaa:   0.054384
aaa:   0.053694

Ubuntu 16.04:

Job():
aaa:   0.001710
aaa:   0.001692
aaa:   0.001673

System():
aaa:   0.010966
aaa:   0.010938
aaa:   0.010940

-- 
-- 
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: system() delay

[Ramel Eshed]

On Sunday, August 28, 2016 at 11:36:33 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > Of course, I've measured the time from job_start to close_cb. You can see
> > this comparison in the example I've attached earlier in this thread.
> 
> Hmm, it's possible that detecting that the other end closed the pipe
> happens much sooner than detecting that the child process has ended.
> If that is the case I don't think there is a way around that.
> 
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 96. On Super Bowl Sunday, you followed the score by going to the
> Yahoo main page instead of turning on the TV.
> 
>  /// 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///

Well, I didn't think something like this could work but it did:

func! System(cmd)
let out = []
let job = job_start(['/bin/sh', '-c', a:cmd],
\ {'out_cb': {c, msg -> add(out, msg)}})
let ch = job_getchannel(job)
while ch_status(ch) != 'closed'
sleep 10m
endwhile
return out
endfunc

Maybe it should be done the same way in the C system() implementation...

Thanks anyway,
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: system() delay

[Ramel Eshed]

On Sunday, August 28, 2016 at 5:53:33 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Friday, August 26, 2016 at 7:29:58 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > On Friday, August 26, 2016 at 12:02:38 AM UTC+3, Bram Moolenaar wrote:
> > > > > Ramel Eshed wrote:
> > > > > 
> > > > > > On Thursday, August 11, 2016 at 3:08:01 AM UTC+3, Ramel Eshed wrote:
> > > > > > > On Thursday, August 11, 2016 at 2:19:38 AM UTC+3, Tony Mechelynck 
> > > > > > > wrote:
> > > > > > > > There are other factors which are right there in the help:
> > > > > > > > - job_start() returns a Job object and doesn't wait for the job 
> > > > > > > > to finish
> > > > > > > > - system() waits for the external command to finish and returns 
> > > > > > > > its
> > > > > > > > full stdout output as a string.
> > > > > > > > 
> > > > > > > > I don't know Vim job control really well, but I seem to 
> > > > > > > > understand
> > > > > > > > that in order to compare system() timing and job control timing 
> > > > > > > > you
> > > > > > > > would have to set up callbacks to gather any output from the 
> > > > > > > > channel,
> > > > > > > > and a callback to be called when the job ends (it may still 
> > > > > > > > write to
> > > > > > > > stdout after it exits), and measure the time from just before
> > > > > > > > job_start() to just after making sure that all output has been
> > > > > > > > collected and that the job has ended.
> > > > > > > > 
> > > > > > > > You might even, for testing purposes, try to write a System() 
> > > > > > > > user
> > > > > > > > function to invoke the argument as a job and return its output 
> > > > > > > > as a
> > > > > > > > string, with the disadvantage that you would completely lose job
> > > > > > > > control asynchronism. But it would allow you a better 
> > > > > > > > comparison,
> > > > > > > > namely between old-fashioned system() and this new 
> > > > > > > > job-control-based
> > > > > > > > System().
> > > > > > > > 
> > > > > > > > Best regards,
> > > > > > > > Tony.
> > > > > > > 
> > > > > > > That's exactly what I've did:
> > > > > > > 
> > > > > > > func! Job()
> > > > > > > let s:rt = reltime()
> > > > > > > let g:output = []
> > > > > > > let g:job = job_start(['/bin/sh', '-c', 'cat ' . 
> > > > > > > expand('%')], {'out_cb': function('s:out_cb'), 'close_cb': 
> > > > > > > function('s:close_cb')})
> > > > > > > endfunc
> > > > > > > 
> > > > > > > func! s:out_cb(channel, msg)
> > > > > > > call add(g:output, a:msg)
> > > > > > > endfunc
> > > > > > > 
> > > > > > > func! s:close_cb(channel)
> > > > > > > echo reltimestr(reltime(s:rt))
> > > > > > > "echo g:output
> > > > > > > endfunc
> > > > > > > 
> > > > > > > " compare with:
> > > > > > > 
> > > > > > > func! System()
> > > > > > > let s:rt = reltime()
> > > > > > > let g:output = systemlist('cat ' . expand('%'))
> > > > > > > echo reltimestr(reltime(s:rt))
> > > > > > > endfunc
> > > > > > > 
> > > > > > > """""""""""""
> > > > > > > I checked it now on my Ubuntu at home - I still see the 
> > > > > > > difference but now both are much faster so even the system() 
> > > > > > > delay is not noticeable. Any idea what could cause the delay on 
> > > > > > > my RHEL?
> > > > > > > 
> > 

Re: system() delay

[Ramel Eshed]

On Friday, August 26, 2016 at 7:29:58 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Friday, August 26, 2016 at 12:02:38 AM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > On Thursday, August 11, 2016 at 3:08:01 AM UTC+3, Ramel Eshed wrote:
> > > > > On Thursday, August 11, 2016 at 2:19:38 AM UTC+3, Tony Mechelynck 
> > > > > wrote:
> > > > > > There are other factors which are right there in the help:
> > > > > > - job_start() returns a Job object and doesn't wait for the job to 
> > > > > > finish
> > > > > > - system() waits for the external command to finish and returns its
> > > > > > full stdout output as a string.
> > > > > > 
> > > > > > I don't know Vim job control really well, but I seem to understand
> > > > > > that in order to compare system() timing and job control timing you
> > > > > > would have to set up callbacks to gather any output from the 
> > > > > > channel,
> > > > > > and a callback to be called when the job ends (it may still write to
> > > > > > stdout after it exits), and measure the time from just before
> > > > > > job_start() to just after making sure that all output has been
> > > > > > collected and that the job has ended.
> > > > > > 
> > > > > > You might even, for testing purposes, try to write a System() user
> > > > > > function to invoke the argument as a job and return its output as a
> > > > > > string, with the disadvantage that you would completely lose job
> > > > > > control asynchronism. But it would allow you a better comparison,
> > > > > > namely between old-fashioned system() and this new job-control-based
> > > > > > System().
> > > > > > 
> > > > > > Best regards,
> > > > > > Tony.
> > > > > 
> > > > > That's exactly what I've did:
> > > > > 
> > > > > func! Job()
> > > > > let s:rt = reltime()
> > > > > let g:output = []
> > > > > let g:job = job_start(['/bin/sh', '-c', 'cat ' . expand('%')], 
> > > > > {'out_cb': function('s:out_cb'), 'close_cb': function('s:close_cb')})
> > > > > endfunc
> > > > > 
> > > > > func! s:out_cb(channel, msg)
> > > > > call add(g:output, a:msg)
> > > > > endfunc
> > > > > 
> > > > > func! s:close_cb(channel)
> > > > > echo reltimestr(reltime(s:rt))
> > > > > "echo g:output
> > > > > endfunc
> > > > > 
> > > > > " compare with:
> > > > > 
> > > > > func! System()
> > > > > let s:rt = reltime()
> > > > > let g:output = systemlist('cat ' . expand('%'))
> > > > > echo reltimestr(reltime(s:rt))
> > > > > endfunc
> > > > > 
> > > > > """""""""""""
> > > > > I checked it now on my Ubuntu at home - I still see the difference 
> > > > > but now both are much faster so even the system() delay is not 
> > > > > noticeable. Any idea what could cause the delay on my RHEL?
> > > > > 
> > > > > BTW, if I remove the comment from the 'echo g:output' line in 
> > > > > close_cb() the message is not displayed (actually, it depends on 
> > > > > which command is running. for the 'cat' command above -there is no 
> > > > > message).
> > > > 
> > > > Hi Bram,
> > > > 
> > > > Is it possible to make system() work the same way job_start (with a
> > > > shell) does?  As I mentioned, I get a noticeable delay with system()
> > > > which I don't get when using job_start(['/bin/sh'...).
> > > 
> > > Not sure if there is anything to improve.  Would require finding out why
> > > it's slower and whether that can be fixed.
> > > 
> > > You could add channel log commands in the code in various places to see
> > > what happens.
> > 
> > My problem is not with the channel, the problem is that system() is
> > slower than the equivalent job_start(). You can run and compare the
> > results of Job() and System() functions in the attach

Re: system() delay

[Ramel Eshed]

On Friday, August 26, 2016 at 12:02:38 AM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Thursday, August 11, 2016 at 3:08:01 AM UTC+3, Ramel Eshed wrote:
> > > On Thursday, August 11, 2016 at 2:19:38 AM UTC+3, Tony Mechelynck wrote:
> > > > There are other factors which are right there in the help:
> > > > - job_start() returns a Job object and doesn't wait for the job to 
> > > > finish
> > > > - system() waits for the external command to finish and returns its
> > > > full stdout output as a string.
> > > > 
> > > > I don't know Vim job control really well, but I seem to understand
> > > > that in order to compare system() timing and job control timing you
> > > > would have to set up callbacks to gather any output from the channel,
> > > > and a callback to be called when the job ends (it may still write to
> > > > stdout after it exits), and measure the time from just before
> > > > job_start() to just after making sure that all output has been
> > > > collected and that the job has ended.
> > > > 
> > > > You might even, for testing purposes, try to write a System() user
> > > > function to invoke the argument as a job and return its output as a
> > > > string, with the disadvantage that you would completely lose job
> > > > control asynchronism. But it would allow you a better comparison,
> > > > namely between old-fashioned system() and this new job-control-based
> > > > System().
> > > > 
> > > > Best regards,
> > > > Tony.
> > > 
> > > That's exactly what I've did:
> > > 
> > > func! Job()
> > > let s:rt = reltime()
> > > let g:output = []
> > > let g:job = job_start(['/bin/sh', '-c', 'cat ' . expand('%')], 
> > > {'out_cb': function('s:out_cb'), 'close_cb': function('s:close_cb')})
> > > endfunc
> > > 
> > > func! s:out_cb(channel, msg)
> > > call add(g:output, a:msg)
> > > endfunc
> > > 
> > > func! s:close_cb(channel)
> > > echo reltimestr(reltime(s:rt))
> > > "echo g:output
> > > endfunc
> > > 
> > > " compare with:
> > > 
> > > func! System()
> > > let s:rt = reltime()
> > > let g:output = systemlist('cat ' . expand('%'))
> > > echo reltimestr(reltime(s:rt))
> > > endfunc
> > > 
> > > """""""""""""
> > > I checked it now on my Ubuntu at home - I still see the difference but 
> > > now both are much faster so even the system() delay is not noticeable. 
> > > Any idea what could cause the delay on my RHEL?
> > > 
> > > BTW, if I remove the comment from the 'echo g:output' line in close_cb() 
> > > the message is not displayed (actually, it depends on which command is 
> > > running. for the 'cat' command above -there is no message).
> > 
> > Hi Bram,
> > 
> > Is it possible to make system() work the same way job_start (with a
> > shell) does?  As I mentioned, I get a noticeable delay with system()
> > which I don't get when using job_start(['/bin/sh'...).
> 
> Not sure if there is anything to improve.  Would require finding out why
> it's slower and whether that can be fixed.
> 
> You could add channel log commands in the code in various places to see
> what happens.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 76. Your ISP regards you as a business partner rather than as a customer.
> 
>  /// 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///

My problem is not with the channel, the problem is that system() is slower than 
the equivalent job_start(). You can run and compare the results of Job() and 
System() functions in the attached file. They are both doing the same thing 
('echo aaa') but System() is ~5 times slower than Job() on Ubuntu and x10 
slower on RHEL5.5. On RHEL System() is extremely slow, it takes about 0.2 
seconds which cause Vim to hang.

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.


system.vim
Description: Binary data

autocommands not triggered for quickfix

[Ramel Eshed]

Hi Bram,

In the autocommand help it is mentioned that only few commands are triggered 
with the quickfix buffer. Is there a reason not to trigger other events? I'd 
expect that BufWinLeave, at least, would be triggered, like BufWinEnter does.

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: gui cursor blinking issues (again)

[Ramel Eshed]

On Friday, August 12, 2016 at 3:08:46 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Thursday, August 11, 2016 at 11:11:08 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > I guess that it depends on the job output characteristics, but I can
> > > > still see cursor blinking issues while using 'out_io': buffer in the
> > > > gui. I don't see it always, but there are cases in which it becomes
> > > > really disturbing. It was so bad that I've tried to disable cursor
> > > > blinking while there is an active job (adding blinkon0 to
> > > > 'guicursor'). It didn't help -the cursor is still unstable even though
> > > > it should not blink at all.
> > > > Please let me know if you need a test case for this and I'll try to
> > > > reproduce this behavior with a simpler job.
> > > 
> > > I'm not surpised this can still happen.  A reproducable test case would
> > > be good.
> > > 
> > > -- 
> > > hundred-and-one symptoms of being an internet addict:
> > > 2. You kiss your girlfriend's home page.
> > > 
> > >  /// 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
> > > ///
> > 
> > Please try this:
> > Put the attached files in your home dir;
> > 
> > gvim -u NONE -N
> > sp job.vim
> > so %
> 
> So, the window is constantly updated and scrolling?  Well, then it's no
> surprise the cursor flickers, since it's undisplayed while redrawing.
> 
> Currently the cursor is switched off when drawing just about anything.
> That's good for a terminal, but in the GUI it is only needed when
> drawing the current window.  I'll see if that helps.
> 
> -- 
> Everybody wants to go to heaven, but nobody wants to die.
> 
>  /// 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///

Yes! it works really great now, thanks. I don't even need to turn off the 
blinking -the cursor keeps its normal blink pace.

One thing I did notice is when you have 'relativenumber' on in the job's window 
the cursor almost disappears. Well, I don't think that anyone wants this option 
on for this kind of windows, but this leads me to a more general question I 
have for a long time: What is the proper way to create a new scratch buffer 
(and window) -with (almost) all options reset to their default values?
I tried :setlocal all& but it does not seem to be working well and I didn't 
find it in the help.

-- 
-- 
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: gui cursor blinking issues (again)

[Ramel Eshed]

On Thursday, August 11, 2016 at 11:11:08 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > I guess that it depends on the job output characteristics, but I can
> > still see cursor blinking issues while using 'out_io': buffer in the
> > gui. I don't see it always, but there are cases in which it becomes
> > really disturbing. It was so bad that I've tried to disable cursor
> > blinking while there is an active job (adding blinkon0 to
> > 'guicursor'). It didn't help -the cursor is still unstable even though
> > it should not blink at all.
> > Please let me know if you need a test case for this and I'll try to
> > reproduce this behavior with a simpler job.
> 
> I'm not surpised this can still happen.  A reproducable test case would
> be good.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 2. You kiss your girlfriend's home page.
> 
>  /// 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///

Please try this:
Put the attached files in your home dir;

gvim -u NONE -N
sp job.vim
so %

-- 
-- 
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.
#!/bin/bash

for i in `seq 1 100`;
do
	echo "$i dflsk ksdjf shdaf sdasdlkfh"
	sleep 80 ms
	echo "kldj fdljkshf kjsdh sdlkfj $i"
	sleep 270 ms
done  


job.vim
Description: Binary data

gui cursor blinking issues (again)

[Ramel Eshed]

Hi Bram,

I guess that it depends on the job output characteristics, but I can still see 
cursor blinking issues while using 'out_io': buffer in the gui. I don't see it 
always, but there are cases in which it becomes really disturbing. It was so 
bad that I've tried to disable cursor blinking while there is an active job 
(adding blinkon0 to 'guicursor'). It didn't help -the cursor is still unstable 
even though it should not blink at all.
Please let me know if you need a test case for this and I'll try to reproduce 
this behavior with a simpler job.

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: system() delay

[Ramel Eshed]

On Thursday, August 11, 2016 at 2:19:38 AM UTC+3, Tony Mechelynck wrote:
> There are other factors which are right there in the help:
> - job_start() returns a Job object and doesn't wait for the job to finish
> - system() waits for the external command to finish and returns its
> full stdout output as a string.
> 
> I don't know Vim job control really well, but I seem to understand
> that in order to compare system() timing and job control timing you
> would have to set up callbacks to gather any output from the channel,
> and a callback to be called when the job ends (it may still write to
> stdout after it exits), and measure the time from just before
> job_start() to just after making sure that all output has been
> collected and that the job has ended.
> 
> You might even, for testing purposes, try to write a System() user
> function to invoke the argument as a job and return its output as a
> string, with the disadvantage that you would completely lose job
> control asynchronism. But it would allow you a better comparison,
> namely between old-fashioned system() and this new job-control-based
> System().
> 
> Best regards,
> Tony.

That's exactly what I've did:

func! Job()
let s:rt = reltime()
let g:output = []
let g:job = job_start(['/bin/sh', '-c', 'cat ' . expand('%')], {'out_cb': 
function('s:out_cb'), 'close_cb': function('s:close_cb')})
endfunc

func! s:out_cb(channel, msg)
call add(g:output, a:msg)
endfunc

func! s:close_cb(channel)
echo reltimestr(reltime(s:rt))
"echo g:output
endfunc

" compare with:

func! System()
let s:rt = reltime()
let g:output = systemlist('cat ' . expand('%'))
echo reltimestr(reltime(s:rt))
endfunc

"
I checked it now on my Ubuntu at home - I still see the difference but now both 
are much faster so even the system() delay is not noticeable. Any idea what 
could cause the delay on my RHEL?

BTW, if I remove the comment from the 'echo g:output' line in close_cb() the 
message is not displayed (actually, it depends on which command is running. for 
the 'cat' command above -there is no message).

-- 
-- 
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: system() delay

[Ramel Eshed]

On Thursday, August 11, 2016 at 12:57:27 AM UTC+3, Dominique Pelle wrote:
> Ramel Eshed ]wrote:
> 
> > Hi Bram,
> >
> > I noticed that using system() function has an overhead of 0.2 seconds 
> > (checked on RHEL 5.5) while using job_start() is 10 times faster (from 
> > job_start to close_cb). Is this because of system() is using temp files 
> > instead of pipes? This is a noticeable delay.
> >
> > Thanks,
> > Ramel
> 
> I'm guessing that system() is slower because it starts a shell process
> and that shell process parses and runs the command. The shell may
> even run some file like .profile (not sure) before running your command.
> 
> Whereas job_start() is I suppose doing a fork() + exec()  (i.e. no shell
> process) so it is faster.
> 
> To have more comparable speed, you'd need to measure something like:
> 
> - job_start(["/bin/sh", "-c" "date")
> - system('date')
> 
> Dominique

Hi Dominique,

job_start(["/bin/sh", "-c" "date") takes almost the same as when using 'date' 
directly (maybe few ms more).

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.

system() delay

[Ramel Eshed]

Hi Bram,

I noticed that using system() function has an overhead of 0.2 seconds (checked 
on RHEL 5.5) while using job_start() is 10 times faster (from job_start to 
close_cb). Is this because of system() is using temp files instead of pipes? 
This is a noticeable delay.

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: request: word motions enhancement

[Ramel Eshed]

On Thursday, July 21, 2016 at 6:59:14 PM UTC+3, Ramel Eshed wrote:
> Hi,
> 
> I always felt that Vim's (actually Vi) word motions design is a bit awkward. 
> Let's say that the cursor is on the word 'self' in the following line:
> 
> if self.words.list[i/(j+1)] == ''
> 
> If I want to take the naive way (without counting words or think of other 
> commands combinations) and move the cursor to the word 'list' I'll need to 
> type w 4 times. This is very annoying especially when using word motions 
> inside file paths which will require x2 hits than what's actually needed. 
> Also, changing 'self.words.list' is c5w and not c3w -this is very confusing 
> and not intuitive.
> A simple solution might be to add an option that will indicate a list of 
> characters that will be treated as white spaces. There might be a problem 
> though with characters like '/' which should be treated as white space for 
> unix file paths and as a word for expressions like x/y. Maybe the option 
> should take regular expression instead of using 'iskeyword' like format.
> 
> Also, I think that the format of 'iskeyword' is not flexible enough. Starting 
> from the beginning of the above line (the word 'if') and hitting w several 
> times will bring you to:
> s, ., w, ., l, [, i, /, j, +, 1, ), =, '
> 
> while I'd expect it to jump to:
> 
> s, w, l, [, i, /, (, j, +, 1, ), ], =, '
> 
> This makes sense to me more than grouping every sequence of non 'iskeyword' 
> characters together.
> 
> What do you think?
> 
> Ramel

Another example is editing a file path in the command line -the only way I know 
to go up in the hierarchy is to press CTRL-W few times until you get to the 
common ancestor directory you need. but you'll need to press CTRL-W twice for 
each directory because Vim treats the '/' separator as word.

Am I the only one who finds this behavior annoying?

-- 
-- 
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: Using file name with quickfix commands

[Ramel Eshed]

On Thursday, July 14, 2016 at 11:34:36 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > Strange.  Oh, perhaps it's because this "mybuf" is near the start of the
> > > buffer list?  I reversed the search order, thinking that there is a
> > > higher chance of searching for a newer buffer.
> > > 
> > > You can try changing buflist_findname_stat() from:
> > > 
> > > for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> > > 
> > > To:
> > > 
> > > for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> > > 
> > > You can also try adding a new buffer after filling the quickfix list and
> > > calling setbufvar() on that one.
> > > 
> > > Anyway, how relevant is calling setbufvar() 4 times?
> > > Can you use a buffer number instead of a name (would be more reliable
> > > anyway)?
> > > 
> > When adding the buffer after filling the quickfix list it takes 3.7s
> > instead of 6.5. When using buffer number it takes 0.15s if the buffer
> > is the last one, but it's still slow (3.1s) if the buffer was created
> > before the list.
> >
> > I not sure if this specific use case is relevant (It was relevant to
> > me, before I made some optimizations to my script...), but I'm sure
> > that there are many other operations which involve searching in the
> > buffers list that can slow down Vim when there are many quickfix
> > items.
> 
> Please try this again after patch 7.4.2036.  The lookup of a buffer by
> number should be a lot faster.

Yes. It is very fast now.

> 
> > Anyway, I don't think that saving all the buffers of the search
> > results by default is a good idea. This way you can easily find
> > yourself dealing with 4 digits buffer numbers while you have only few
> > that you're actually working on.
> 
> A user is not really expected to deal with buffer numbers, there are
> many other ways to find the right buffer.
> 
> In the other thread the discussion about the disadvantages of not
> storing a file as a buffer were relevant.  Also, adding an option to all
> quickfix commands that add an entry is not nice.
> 
> There are other ways to end up with lots of buffers, it is good to make
> that fast anyway.
> 
> 
> -- 
> GALAHAD: No, please.  Please! I can defeat them!  There's only a hundred.
> GIRLS:   He will beat us easily.  We haven't a chance.
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
> 
>  /// 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.

request: word motions enhancement

[Ramel Eshed]

Hi,

I always felt that Vim's (actually Vi) word motions design is a bit awkward. 
Let's say that the cursor is on the word 'self' in the following line:

if self.words.list[i/(j+1)] == ''

If I want to take the naive way (without counting words or think of other 
commands combinations) and move the cursor to the word 'list' I'll need to type 
w 4 times. This is very annoying especially when using word motions inside file 
paths which will require x2 hits than what's actually needed. Also, changing 
'self.words.list' is c5w and not c3w -this is very confusing and not intuitive.
A simple solution might be to add an option that will indicate a list of 
characters that will be treated as white spaces. There might be a problem 
though with characters like '/' which should be treated as white space for unix 
file paths and as a word for expressions like x/y. Maybe the option should take 
regular expression instead of using 'iskeyword' like format.

Also, I think that the format of 'iskeyword' is not flexible enough. Starting 
from the beginning of the above line (the word 'if') and hitting w several 
times will bring you to:
s, ., w, ., l, [, i, /, j, +, 1, ), =, '

while I'd expect it to jump to:

s, w, l, [, i, /, (, j, +, 1, ), ], =, '

This makes sense to me more than grouping every sequence of non 'iskeyword' 
characters together.

What do you think?

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: Using file name with quickfix commands

[Ramel Eshed]

On Monday, July 11, 2016 at 12:33:28 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, Bram Moolenaar wrote:
> > > Lcd wrote:
> > > 
> > > > [...]
> > > > > > Currently an error item from loclist looks like this:
> > > > > > 
> > > > > > {
> > > > > > 'lnum': 148,
> > > > > > 'bufnr': 1,
> > > > > > 'col': 7,
> > > > > > 'valid': 1,
> > > > > > 'vcol': 0,
> > > > > > 'nr': -1,
> > > > > > 'type': 'W',
> > > > > > 'pattern': ',
> > > > > > 'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs 
> > > > > > used (See page 20 of PBP)'
> > > > > > }
> > > > > > 
> > > > > > If I want to place a sign at the file, I can do this:
> > > > > > 
> > > > > > sign place 12345 line=148 name=SyntasticError buffer=1
> > > > > > 
> > > > > > This works regardless if the fuffer is hidden or not, and can be
> > > > > > done before the user jumps to the error.
> > > > > >
> > > > > > How would I do the same starting only with a filename, assuming
> > > > > > the user hasn't jumped to the error yet, or opened the file?
> > > > >
> > > > > Yeah, when using getqflist() or getloclist() we currently only get the
> > > > > "bufnr".  This I would think, by default the file name is changed to
> > > > > a buffer at that point.  Since this can be expensive, we could add an
> > > > > argument to return the file name instead of a buffer number.
> > > > >
> > > > > So we have a dilemma: For the plugin that intentionally avoids
> > > > > creating a buffer for every error, it can have these extra options
> > > > > to make it (a lot) faster.  But as soon as another plugin comes into
> > > > > play, which depends on the buffer, things fall back to how they were.
> > > > > I think that is unavoidable.
> > > > 
> > > > So functions that create qflists and loclists (make, cgetexpr etc.)
> > > > would create them with filenames, and it would be up to getqflist()
> > > > and getloclist() to request the corresponding files to be loaded
> > > > into buffers (with the default being to load files, for backwards
> > > > compatibility).  Also, the results could be cached.  That would work
> > > > nicely, and it wouldn't be slower for plugins that want old-style
> > > > qflists and loclists.
> > > 
> > > I have optimized the quickfix code with the last few patches.  It's a
> > > lot faster now, especially when there are several matches in the same
> > > file.  Let's see if Ramel thinks this is good enough, then we don't need
> > > to add the workaround.
> > > 
> > I've checked 2 test cases:
> > 
> > 1) Adding many (80,000+) entries to quickfix list: here I see huge 
> > improvement -from 6.76 seconds to 0.38 (!!).
> 
> Glad to hear my changes were effective.
> 
> > 2) The following script:
> > 
> > func! Setbv()
> > let rt = reltime()
> > for i in range (1, 4)
> > call setbufvar('mybuf', 'myvar', 2)
> > endfor
> > echo reltimestr(reltime(rt))
> > endfunc
> > 
> > Before setting any quickfix list it takes 0.22s. After setting a
> > quickfix list with 8 entries it takes 6.5 seconds, which is
> > actually worse than how it was before the last patches (it took then
> > 3.56s).
> 
> Strange.  Oh, perhaps it's because this "mybuf" is near the start of the
> buffer list?  I reversed the search order, thinking that there is a
> higher chance of searching for a newer buffer.
> 
> You can try changing buflist_findname_stat() from:
> 
> for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> 
> To:
> 
> for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> 
> You can also try adding a new buffer after filling the quickfix list and
> calling setbufvar() on that one.
> 
> Anyway, how relevant is calling setbufvar() 4 times?
> Can you use a buffer number instead of a name (would be more reliable
> anyway)?
> 
When adding the buffer after filling th

Re: Patch 7.4.1890

[Ramel Eshed]

On Monday, July 11, 2016 at 12:13:40 AM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > I'm not sure if this patch was supposed to fix the issue completely, but 
> > there are still issues with the gui cursor.
> > 
> > 1) When job output is redirected to a buffer:
> > 
> > vim -u NONE -N
> > :new
> > :call job_start(['/bin/sh', '-c', 'ls -R / | head -50'], { 'out_io': 
> > 'buffer', 'out_buf': 1 })
> > 
> > -The cursor disappears from the upper window (most of the time). Also, when 
> > the window is not scrolled (if you insert 2 letters before the :new) the 
> > cursor doesn't blink normally.
> 
> It appears in this case that Vim is 100% busy, there is no time to
> update the screen.  I added a flush and that helps a little bit.  But I
> don't see how this can be fixed.  Even the timer isn't called at the
> right time.  Intentionally delaying the read from the channel doesn't
> seem like a good solution.
> 
I don't see the first issue now (cursor disappears from the upper window). The 
cursor still doesn't blink normally though. It doesn't happen in the terminal.
> 
> > 2) When updating the status line:
> > 
> > source the following script:
> > 
> > set laststatus=2
> > let tcount = 0
> > 
> > func! Timer_cb(timer)
> > let g:tcount += 1
> > call setbufvar(1, '', g:tcount)
> > endfunc
> > 
> > call timer_start(50, 'Timer_cb', {'repeat': 100})
> > 
> > Both behave very well in the terminal.
> 
> I should be able to fix this.
>
Looks good now. Thanks! 

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

skipped echo after setbufvar()

[Ramel Eshed]

Hi Bram,

Please check this:

vim -u NONE -N

:new mybuf
:let b:myvar = 1
:set hidden
:q
:call setbufvar('mybuf', 'myvar', 2) | echo 'done'

I don't see the 'done' message. I can see it only when mybuf is displayed in a 
window.

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: Using file name with quickfix commands

[Ramel Eshed]

On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, Bram Moolenaar wrote:
> Lcd wrote:
> 
> > [...]
> > > > Currently an error item from loclist looks like this:
> > > > 
> > > > {
> > > > 'lnum': 148,
> > > > 'bufnr': 1,
> > > > 'col': 7,
> > > > 'valid': 1,
> > > > 'vcol': 0,
> > > > 'nr': -1,
> > > > 'type': 'W',
> > > > 'pattern': ',
> > > > 'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs used 
> > > > (See page 20 of PBP)'
> > > > }
> > > > 
> > > > If I want to place a sign at the file, I can do this:
> > > > 
> > > > sign place 12345 line=148 name=SyntasticError buffer=1
> > > > 
> > > > This works regardless if the fuffer is hidden or not, and can be
> > > > done before the user jumps to the error.
> > > >
> > > > How would I do the same starting only with a filename, assuming
> > > > the user hasn't jumped to the error yet, or opened the file?
> > >
> > > Yeah, when using getqflist() or getloclist() we currently only get the
> > > "bufnr".  This I would think, by default the file name is changed to
> > > a buffer at that point.  Since this can be expensive, we could add an
> > > argument to return the file name instead of a buffer number.
> > >
> > > So we have a dilemma: For the plugin that intentionally avoids
> > > creating a buffer for every error, it can have these extra options
> > > to make it (a lot) faster.  But as soon as another plugin comes into
> > > play, which depends on the buffer, things fall back to how they were.
> > > I think that is unavoidable.
> > 
> > So functions that create qflists and loclists (make, cgetexpr etc.)
> > would create them with filenames, and it would be up to getqflist()
> > and getloclist() to request the corresponding files to be loaded
> > into buffers (with the default being to load files, for backwards
> > compatibility).  Also, the results could be cached.  That would work
> > nicely, and it wouldn't be slower for plugins that want old-style
> > qflists and loclists.
> 
> I have optimized the quickfix code with the last few patches.  It's a
> lot faster now, especially when there are several matches in the same
> file.  Let's see if Ramel thinks this is good enough, then we don't need
> to add the workaround.
> 
I've checked 2 test cases:

1) Adding many (80,000+) entries to quickfix list: here I see huge improvement 
-from 6.76 seconds to 0.38 (!!).

2) The following script:

func! Setbv()
let rt = reltime()
for i in range (1, 4)
call setbufvar('mybuf', 'myvar', 2)
endfor
echo reltimestr(reltime(rt))
endfunc

Before setting any quickfix list it takes 0.22s. After setting a quickfix list 
with 8 entries it takes 6.5 seconds, which is actually worse than how it 
was before the last patches (it took then 3.56s).

-- 
-- 
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: Using file name with quickfix commands

[Ramel Eshed]

Hi Bram,

On Thursday, July 7, 2016 at 10:24:49 PM UTC+3, Bram Moolenaar wrote:
> There has been a request that when adding items to the quickfix list, no
> buffer is created to hold the file name.
> 
> The reason is that when there are many different file names this causes
> the buffer list to get very long, which then causes various operations
> to become slow.  Including finding the buffer for a file name.
> 
> Instead of using a buffer, where the file name is stored, and then using
> the buffer number, the file name itself could be remembered.
> 
> Since there are so many quickfix commands, adding a flag to every one of
> them would be creating quite a mess.  We could add an option, but
> that has the danger of forgetting to reset the option after the
> operation.  And it requires three more statements (save current value,
> set the option, restore th option).  So I was thinking of using a command
> modifier:
> 
>   :usefname caddexpr {expr}
> 
> How about that?
> 
Sounds good. Maybe we could also have an option only for search commands like 
:grep since this mode is most useful there? (Actually, this was one of the 
reasons which convinced me that quickfix is not the right tool to use for 
searches. See https://github.com/ramele/agrep).
> 
> Storing the file name instead of a buffer number has a few
> disadvantages:
> - When inserting or deleting lines in the file the position of the
>   quickfix items is not adjusted.
> - Using more memory to store a copy of the file name.
> - Changing directory can make the file name invalid.  We could store the
>   full path, but creating that also adds overhead.  Hmm, perhaps we
>   could store the full path the moment the directory is changed.

Can't we just save the original working directory used when the quickfix list 
was created and use it when jumping to files stored with a relative path?

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

runtime/ftplugin/perl.vim is not up to date

[Ramel Eshed]

Hi,

There were few updates to this file in 
https://github.com/vim-perl/vim-perl/blob/master/ftplugin/perl.vim since Jul 
2013.
The version distributed with Vim sets the global value of iskeyword. It already 
fixed in Oct 2013.

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: Patch 7.4.1890

[Ramel Eshed]

On Saturday, June 4, 2016 at 5:24:42 PM UTC+3, Bram Moolenaar wrote:
> Patch 7.4.1890
> Problem:GUI: When channel data is received the cursor blinking is
> interrupted.  (Ramel Eshed)
> Solution:   Don't update the cursor when it is blinking.
> Files:  src/screen.c, src/gui_gtk_x11.c, src/proto/gui_gtk_x11.pro,
> src/gui_mac.c, src/proto/gui_mac.pro, src/gui_photon.c,
> src/proto/gui_photon.pro, src/gui_w32.c, src/proto/gui_w32.pro,
> src/gui_x11.c, src/proto/gui_x11.pro
> 
> 
> *** ../vim-7.4.1889/src/screen.c  2016-05-24 10:51:26.543537913 +0200
> --- src/screen.c  2016-06-04 15:53:40.674214953 +0200
> ***
> *** 432,438 
>   #ifdef FEAT_GUI
>   if (gui.in_use)
>   {
> ! gui_update_cursor(TRUE, FALSE);
>   gui_mch_flush();
>   }
>   #endif
> --- 432,441 
>   #ifdef FEAT_GUI
>   if (gui.in_use)
>   {
> ! /* Don't update the cursor while it is blinking, it will get
> !  * updated soon and this avoids interrupting the blinking. */
> ! if (!gui_mch_is_blinking())
> ! gui_update_cursor(FALSE, FALSE);
>   gui_mch_flush();
>   }
>   #endif
> *** ../vim-7.4.1889/src/gui_gtk_x11.c 2016-06-02 14:29:59.132661030 +0200
> --- src/gui_gtk_x11.c 2016-06-04 16:03:17.514207018 +0200
> ***
> *** 810,815 
> --- 810,821 
>   }
>   #endif
>   
> + int
> + gui_mch_is_blinking(void)
> + {
> + return blink_state != BLINK_NONE;
> + }
> + 
>   void
>   gui_mch_set_blinking(long waittime, long on, long off)
>   {
> *** ../vim-7.4.1889/src/proto/gui_gtk_x11.pro 2016-01-19 13:21:55.837334377 
> +0100
> --- src/proto/gui_gtk_x11.pro 2016-06-04 15:42:58.986223780 +0200
> ***
> *** 1,6 
> --- 1,7 
>   /* gui_gtk_x11.c */
>   void gui_mch_prepare(int *argc, char **argv);
>   void gui_mch_free_all(void);
> + int gui_mch_is_blinking(void);
>   void gui_mch_set_blinking(long waittime, long on, long off);
>   void gui_mch_stop_blink(void);
>   void gui_mch_start_blink(void);
> *** ../vim-7.4.1889/src/gui_mac.c 2016-06-02 22:27:04.256267269 +0200
> --- src/gui_mac.c 2016-06-04 16:03:02.278207227 +0200
> ***
> *** 5114,5119 
> --- 5114,5124 
>   #endif
>   }
>   
> + int
> + gui_mch_is_blinking(void)
> + {
> + return FALSE;
> + }
>   
>   /*
>* Cursor blink functions.
> *** ../vim-7.4.1889/src/proto/gui_mac.pro 2016-01-30 13:28:23.925007165 
> +0100
> --- src/proto/gui_mac.pro 2016-06-04 16:02:58.858207274 +0200
> ***
> *** 14,19 
> --- 14,20 
>   void gui_mac_focus_change(EventRecord *event);
>   void gui_mac_update(EventRecord *event);
>   short gui_mch_get_mac_menu_item_index(vimmenu_T *menu, vimmenu_T *parent);
> + int gui_mch_is_blinking(void);
>   void gui_mch_set_blinking(long wait, long on, long off);
>   void gui_mch_stop_blink(void);
>   void gui_mch_start_blink(void);
> *** ../vim-7.4.1889/src/gui_photon.c  2016-04-26 20:59:24.728486510 +0200
> --- src/gui_photon.c  2016-06-04 16:04:51.706205722 +0200
> ***
> *** 2232,2237 
> --- 2232,2243 
>   DRAW_END;
>   }
>   
> + int
> + gui_mch_is_blinking(void)
> + {
> + return blink_state != BLINK_NONE;
> + }
> + 
>   void
>   gui_mch_set_blinking(long wait, long on, long off)
>   {
> *** ../vim-7.4.1889/src/proto/gui_photon.pro  2016-01-19 13:21:55.837334377 
> +0100
> --- src/proto/gui_photon.pro  2016-06-04 16:05:13.258205426 +0200
> ***
> *** 39,44 
> --- 39,45 
>   void gui_mch_draw_string(int row, int col, char_u *s, int len, int flags);
>   void gui_mch_draw_hollow_cursor(guicolor_T color);
>   void gui_mch_draw_part_cursor(int w, int h, guicolor_T color);
> + int gui_mch_is_blinking(void);
>   void gui_mch_set_blinking(long wait, long on, long off);
>   void gui_mch_start_blink(void);
>   void gui_mch_stop_blink(void);
> *** ../vim-7.4.1889/src/gui_w32.c 2016-06-02 15:49:33.008595362 +0200
> --- src/gui_w32.c 2016-06-04 16:05:47.706204952 +0200
> ***
> *** 540,545 
> --- 540,551 
>   static long_u   blink_offtime = 250;
>   static UINT blink_timer = 0;
>   
> + int
> + gui_mch_is_blinking(void)
> + {
> + return blink_state != BLINK_NONE;
> + }
> + 
>   void
>   gui_mch_set_blinking(long wait, long on, long off)
>   {
> *** ../vim-7.4.1889/src/proto/gui_w32.pro 2016-01-29 21:11:20.967061365 
> +0100
> --- src/proto/gui_w32.pro 2016-06-04 16:05:52.486204886 +0200
> ***
> **

Re: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

On Thursday, June 9, 2016 at 6:53:06 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > > 1) Actually, there is a bug here which is not exactly what I've
> > > > described earlier. The issue is that :call setqflist([]), instead of
> > > > adding one more list after the last list, will clear the next list and
> > > > delete the ones after. For example: let's say I used :grep 4 times so
> > > > I have now 4 lists. Now, if I do :colder 3, the first list becomes the
> > > > current list. :call setqflist([]) will empty list 2, and delete lists
> > > > 3 and 4.
> > > 
> > > We do remove newer lists when adding a new list before the end, but in
> > > this case it should not happen.
> > I'm not sure I understand. Is removing all the newer lists are the
> > expected behavior? why? and why is it different here?
> 
> Removing newer lists is what happens when inserting a list.  But you are
> not inserting here, you are clearing it.
I'm using setqflist([]) with no 'r' flag. Doesn't it suppose to insert a list?
Anyway, is there a reason to delete the newer lists?
> 
> > > > 2) Although quickfix performance got much better, I'm afraid there is
> > > > more to do:
> > > > a) It takes me about 9 seconds(!) to add 68,505 entries to the qf
> > > > list (using simple :grep command. Time was measured from after the
> > > > grep command output finished, of course). Yegappan's test takes
> > > > only 2 seconds because all the results are from the same file. Try
> > > > to add the loop variable to the file name in his test and see what
> > > > happens...
> > > > 
> > > > This is the profiler log of the search I did:
> > > > 
> > > >   %   cumulative   self  self total   
> > > >  time   seconds   secondscalls  ms/call  ms/call  name
> > > >  40.63  1.69 1.6968510 0.02 0.02  buf_valid
> > > >  21.88  2.60 0.9168505 0.01 0.02  
> > > > buflist_findname_stat
> > > >  12.38  3.12 0.52 127664549 0.00 0.00  otherfile_buf
> > > >   4.81  3.32 0.20 4345 0.05 0.05  buflist_findnr
> > > 
> > > Well, when adding an entry a buffer is created, so that we keep track of
> > > the actual name when doing ":cd".  And it avoids duplicates.
> > > buf_valid() is often needed to check if an autocommand didn't delete a
> > > buffer.  Both of these are hard to get rid of.
> > This can really slow down Vim. I'm not sure if my test cases here are
> > realistic, but I'm sure that if you keep Vim session active for enough
> > time you'll probably get thousands of unlisted buffers which will slow
> > down everything.
> > In this case, if there is nothing else can be done (like using another
> > data structure for qf entries) I think that command for deleting
> > quickfix list is necessary. As I mentioned earlier, :call
> > setqflist([], 'r') is not good enough and it also doesn't free the
> > associated buffers.
> > Maybe a simple mechanism for search, which does not use hidden marks,
> > should be considered. When you're starting a search command you don't
> > really know how many results you'll get so the last thing you want to
> > do is to add 10 results to the qf list. You need to be able to
> > review the results, maybe filter them, and then add them to the
> > quickfix if needed (in many cases it is not needed, like when you only
> > want to review the code without changing anything). Actually, this is
> > what I've done in the Agrep plugin..
> 
> The only way to avoid creating buffers is by intentionally dropping some
> functionality and only keeping the file name.  Perhaps we can still
> expand it to a full path (that's also not a cheap operation, but at
> least it's only once per entry).
I'm not sure, but maybe something like file inode index number can be used for 
that and will be faster?

> 
> The file name would be turned into a buffer only when jumping to the
> location then.
> 
> I suppose this is a property of the quickfix list.  Perhaps with a
> function like "setqfflag()"?  Would not work with commands like :cfile
> though.
Sounds good to me, although I didn't understand the :cfile problem you 
mentioned.
> 
> > > >   b) I remember you did 2 things in order to avoid the line
> > > >   adjustments when it's not necessary: check first if the buffer has a
> > > >   quickfix entry and don't call line adjustment 

Re: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

On Thursday, June 9, 2016 at 11:52:41 AM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > 1) Actually, there is a bug here which is not exactly what I've
> > described earlier. The issue is that :call setqflist([]), instead of
> > adding one more list after the last list, will clear the next list and
> > delete the ones after. For example: let's say I used :grep 4 times so
> > I have now 4 lists. Now, if I do :colder 3, the first list becomes the
> > current list. :call setqflist([]) will empty list 2, and delete lists
> > 3 and 4.
> 
> We do remove newer lists when adding a new list before the end, but in
> this case it should not happen.
I'm not sure I understand. Is removing all the newer lists are the expected 
behavior? why? and why is it different here?
> 
> > 2) Although quickfix performance got much better, I'm afraid there is
> > more to do:
> > a) It takes me about 9 seconds(!) to add 68,505 entries to the qf
> > list (using simple :grep command. Time was measured from after the
> > grep command output finished, of course). Yegappan's test takes
> > only 2 seconds because all the results are from the same file. Try
> > to add the loop variable to the file name in his test and see what
> > happens...
> > 
> > This is the profiler log of the search I did:
> > 
> >   %   cumulative   self  self total   
> >  time   seconds   secondscalls  ms/call  ms/call  name
> >  40.63  1.69 1.6968510 0.02 0.02  buf_valid
> >  21.88  2.60 0.9168505 0.01 0.02  buflist_findname_stat
> >  12.38  3.12 0.52 127664549 0.00 0.00  otherfile_buf
> >   4.81  3.32 0.20 4345 0.05 0.05  buflist_findnr
> 
> Well, when adding an entry a buffer is created, so that we keep track of
> the actual name when doing ":cd".  And it avoids duplicates.
> buf_valid() is often needed to check if an autocommand didn't delete a
> buffer.  Both of these are hard to get rid of.
This can really slow down Vim. I'm not sure if my test cases here are 
realistic, but I'm sure that if you keep Vim session active for enough time 
you'll probably get thousands of unlisted buffers which will slow down 
everything.
In this case, if there is nothing else can be done (like using another data 
structure for qf entries) I think that command for deleting quickfix list is 
necessary. As I mentioned earlier, :call setqflist([], 'r') is not good enough 
and it also doesn't free the associated buffers.
Maybe a simple mechanism for search, which does not use hidden marks, should be 
considered. When you're starting a search command you don't really know how 
many results you'll get so the last thing you want to do is to add 10 
results to the qf list. You need to be able to review the results, maybe filter 
them, and then add them to the quickfix if needed (in many cases it is not 
needed, like when you only want to review the code without changing anything). 
Actually, this is what I've done in the Agrep plugin..
>  
> >   b) I remember you did 2 things in order to avoid the line
> >   adjustments when it's not necessary: check first if the buffer has a
> >   quickfix entry and don't call line adjustment when adding a line at
> >   the end.
> >   
> >   I still see that adding to a buffer when there are many qf entries
> >   is very slow. After I had the 68505 results of the :grep command,
> >   adding ~84000 lines to a buffer (from channel output) became really
> >   slow. This is the profiler log:
> 
> How are the lines added?
The lines are added by using 'out_io': 'buffer'. Without having many (4000) 
unlisted buffers adding 8 lines takes about 1.2 seconds. The unlisted 
buffers slow this down to ~6 seconds. If, in addition, I add an out_cb to this 
job which calls setbufvar() it can take even 15 seconds.
> 
> > Each sample counts as 0.01 seconds.
> >   %   cumulative   self  self total   
> >  time   seconds   secondscalls   s/call   s/call  name
> >  31.46  6.98 6.98   149100 0.00 0.00  buf_valid
> >  29.20 13.46 6.4880590 0.00 0.00  buflist_findpat
> >  26.66 19.38 5.9284950 0.00 0.00  buflist_findnr
> >   3.56 20.17 0.7968507 0.00 0.00  buflist_findname_stat
> >   2.28 20.67 0.51 127673186 0.00 0.00  otherfile_buf
> > 
> > It seems like checking the buffer each time alone takes a lot of time.
> > Is there any way to optimize the above functions?
> > Also, why I still see all these buffer functions even though all the
> > lines were added at the end of th

Re: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

On Friday, June 3, 2016 at 7:54:12 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Friday, June 3, 2016 at 12:17:15 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > 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?
> > > 
> > > No, this is needed.  But why is a buffer changed?  I thought you were
> > > adding quickfix entries, which doesn't trigger adjusting marks.  Only
> > > inserting/deleting a line in a buffer triggers this.
> > 
> > Because of adding quickfix entries was slow I've created my own buffer
> > to display the search results (you can see an animated gif here:
> > http://i.imgur.com/epffEDH.gif).
> > I need to perform some manipulations on the grep results in order to
> > get the column numbers and to highlight the matching text. Currently,
> > this is done in the out_cb function which sends the modified line to
> > my special buffer via a separate 'cat' job (this is the workaround I
> > found as a replacement to setbufline() :)).
> 
> So this buffer that's changing does not have entries in the quickfix
> list, right?  I think I can add a trick to skip buffers that don't have
> any quickfix entries.  That should solve your problem and is fairly
> simple to implement.
> 
> > > The reason this is needed, is that when you have a list of errors in
> > > various files, which are at specific line numbers, and you make changes
> > > in files, the line numbers need to be adjusted.
> > > 
> > > Since the qf_last change helped a lot, I susped just going through all
> > > the quickfix entries is making it slow.  We would need to use another
> > > data structure, which lists all the quickfix entries related to a
> > > buffer.  Then we only need to look at the ones that might actually
> > > change.  Keeping that list updated will be extra work though.  In
> > > different circumstances it may actually make it slower.
> >
> > I think that in cases like this -when lines are appended to a buffer
> > b

Re: Patch 7.4.1891

[Ramel Eshed]

On Tuesday, June 7, 2016 at 12:14:25 AM UTC+3, Bram Moolenaar wrote:
> Xavier de Gaye wrote:
> 
> > On 06/05/2016 04:11 PM, Bram Moolenaar wrote:
> >  >> Xavier de Gaye wrote:
> >  >>
> >  >>> Two pyclewn tests fail after patch 7.4.1891. It seems that not all 
> > 'insert'
> >  >>> function messages are matched with a reply from Vim after this patch.
> >  >>> This happens with a test that sends 50 'insert' of 353 bytes in a row
> >  >>> interleaved with about the same amount of 'remove' and only 5 of these
> >  >>> are acknowledged with a reply.
> >  >>
> >  >> Can you debug to find out what happens?
> >  >>
> >  >> To narrow down the problem, you could change this TRUE to FALSE:
> >  >>
> >  >>  if (channel_collapse(nb_channel, PART_SOCK, TRUE) == FAIL)
> >  >>
> >  >> This is in netbeans.c
> >  >>
> >  >
> >  > Never mind.  I thought this was covered by a test but it wasn't.  Now
> >  > that I add a test for collapsing I can see the error.
> > 
> > 
> > Not sure if v7.4.1902 is supposed to fix this, anyway it still fails with 
> > this
> > last change.
> > 
> >  >> Or how could I reproduce this myself?
> > 
> > Install pyclewn and run in the distribution directory:
> 
> What is the distribution directory?  I looked in 
> /usr/local/lib/python2.7/dist-packages/clewn
> but there is no setup.py there.
> 
> >  EDITOR=vim python setup.py test --test=simple -d -p test_014
> > 
> > The ./logfile file traces the netbeans messages.
> > 
> > I will be able to debug this problem by the end of this week.
> 
> -- 
> Over the years, I've developed my sense of deja vu so acutely that now
> I can remember things that *have* happened before ...
> 
>  /// 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///

I can reproduce this using:

vim -u NONE -N
:call job_start('ls -R /', {'out_io': 'buffer', 'out_buf': 1})

I get only 405 lines in response.

-- 
-- 
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: Conceal highlight is not fully concealed

[Ramel Eshed]

On Friday, June 3, 2016 at 6:53:52 PM UTC+3, Christian Brabandt wrote:
> Hi Ramel!
> 
> On Fr, 03 Jun 2016, Ramel Eshed wrote:
> 
> > When there are concealed syntax elements in a line and 'wrap' is on the 
> > line will be wrapped in the wrong place.
> > 
> > For example, look at line 12 in help.txt (:h). It actually has 75 virtual 
> > columns if we don't count the two concealed bars. But if you set vim window 
> > width to 75 columns (:set columns=75) the last '.' will be appeared in the 
> > next display line.
> > 
> > It bothers me because I want to use the Conceal highlight in my scripts to 
> > hide relatively long parts in a buffer and I get wrapped lines although 
> > there is plenty of room left in the display line.
> 
> That is a known issue and won't be changed.
> https://github.com/vim/vim/issues/260
> 
> 
> Best,
> Christian
> -- 
> Ein Glück für die Despoten, daß die eine Hälfte der Menschen nicht
> denkt und die andere nicht fühlt.
>   -- Johann Gottfried Seume

Oh, too bad.. It could be very useful for many things and also I think that 
this should be the correct behavior.

Thanks anyway,
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.

Conceal highlight is not fully concealed

[Ramel Eshed]

When there are concealed syntax elements in a line and 'wrap' is on the line 
will be wrapped in the wrong place.

For example, look at line 12 in help.txt (:h). It actually has 75 virtual 
columns if we don't count the two concealed bars. But if you set vim window 
width to 75 columns (:set columns=75) the last '.' will be appeared in the next 
display line.

It bothers me because I want to use the Conceal highlight in my scripts to hide 
relatively long parts in a buffer and I get wrapped lines although there is 
plenty of room left in the display line.

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

[Ramel Eshed]

On Friday, June 3, 2016 at 12:17:15 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > 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?
> 
> No, this is needed.  But why is a buffer changed?  I thought you were
> adding quickfix entries, which doesn't trigger adjusting marks.  Only
> inserting/deleting a line in a buffer triggers this.

Because of adding quickfix entries was slow I've created my own buffer to 
display the search results (you can see an animated gif here: 
http://i.imgur.com/epffEDH.gif).
I need to perform some manipulations on the grep results in order to get the 
column numbers and to highlight the matching text. Currently, this is done in 
the out_cb function which sends the modified line to my special buffer via a 
separate 'cat' job (this is the workaround I found as a replacement to 
setbufline() :)).

> The reason this is needed, is that when you have a list of errors in
> various files, which are at specific line numbers, and you make changes
> in files, the line numbers need to be adjusted.
> 
> Since the qf_last change helped a lot, I susped just going through all
> the quickfix entries is making it slow.  We would need to use another
> data structure, which lists all the quickfix entries related to a
> buffer.  Then we only need to look at the ones that might actually
> change.  Keeping that list updated will be extra work though.  In
> different circumstances it may actually make it slower.
>
I think that in cases like this -when lines are appended to a buffer by a job 
(using 'out_io': 'buffer') we don't need to adjust the quickfix marks since the 
target buffer is probably not included in any quickfix list. Is there a 
corresponding option to the :lockmarks command (like 'eventignore' and 
:noautocmd)?

Because of the serious performance impact of many quickfix entries, I think we 
should have a built in command for freeing a quickfix list. I guess I can use 
:call setqflist([], 'r'), but it'll leave an empty list and it'd be nicer to 
remove the list completely.
Also, I noticed that using :call setqflist([]) while there is only one list 
will add a new empty list, and will delete the last list when there is more 
than one list. According to the help it should behave like setqflist([], 'r'):

If you supply an empty {list}, the quickfix list will be
cleared.

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

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: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

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: Use 'out_io': 'buffer' with nomodifiable

[Ramel Eshed]

On Sunday, May 29, 2016 at 4:44:12 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > In every Vim plugin that I've used (which are not too many though)
> > there was a protection on the general-purpose buffers (done by setting
> > and resetting 'modifiable').
> > The concern, I guess, is not to prevent the user from changing the
> > buffer deliberately rather then to protect from stupid mistakes. Here,
> > when the buffer changed asynchronously it is even more dangerous. For
> > example: what if the user by mistake will press 'p' while the buffer
> > is being updated? -In other cases a simple undo will help but here it
> > is likely that before the user will press 'u' there will be many new
> > lines added by the job output so undo will delete them instead.
> > Is it possible to add an option to the job that will let it override
> > 'modifiable' just for the out_io?
> 
> If you try it out, you will see that currently there is an error
> message, but the lines are appended to the buffer anyway.  Probably the
> worst that could happen.
> 
> I'm a bit careful to just append lines to a nomodifiable buffer.
> Could cause trouble when picking the wrong buffer.
> 
> We could add an option: 'modifiable': 0
> 
> -- 
> How To Keep A Healthy Level Of Insanity:
> 5. Put decaf in the coffee maker for 3 weeks. Once everyone has gotten
>over their caffeine addictions, switch to espresso.
> 
>  /// 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///

Great!!. Thanks for this patch.

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

On Monday, May 30, 2016 at 5:11:57 AM UTC+3, yega...@gmail.com wrote:
> Hi,
> 
> On Sat, May 7, 2016 at 2:42 PM, Ramel Eshed <rame...@gmail.com> 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.
> >
> 
> > 2. Quickfix issues
> > a.As long as there are not too many matches and
> > the quickfix window is closed you can fire up a search and start
> > jumping to the available matches while the search is still running
> > using the quickfix navigation commands (:cn, for example). The problem
> > is when the quickfix window is opened while the search is active –
> > here there is a serious performance issue, and Vim hangs for a while.
> > You can see this by running :copen and then :Agrep. Choose a search
> > that will generate many results (> 1000).
> >
> > b.As the matches rate becomes higher, Vim will become
> > unresponsive. It may happen for short intervals or it can hangs for a
> > while (for very high rate). By “rate” I simply mean to
> > number_of_matches / sec. To compare, the performance is much better
> > with the agrep window.
> >
> > As I understand (and please correct me if I’m wrong) when using
> > setqflist() to create a new list or add items to the current list, Vim
> > reads all the buffers (as an unlisted buffers) in order to set the
> > hidden marks. I think that this is the reason of the slowness I’m
> > experiencing. If I'm right, maybe the way Vim loads the buffers of the
> > qf list should be changed so buffers will be loaded only when they're
> > been accessed and not when they're added to the list. What do you
> > think?
> >
> 
> When adding a new entry to the quickfix list, a search is made to locate
> the last entry. I think, this is the reason for the long processing time.
> To confirm this, I created a test script to add 10 entries to the
> quickfix list. It took almost 120 seconds to complete. After I changed
> the quickfix code to keep track of the last entry, this reduced to 2 seconds.
> Can you try using the attached patch?
> 
> - Yegappan

Hi Yegappan,

Thanks for checking this. I didn't see a noticeable improvement, at least 
regarding to my second issue (b) - The cursor is still not fully responsive in 
my test case (search which returns 1 results and add each one to the qf 
list on the fly). It also does not solve the first issue.

Also, I noticed a very strange issue (which also exists without your patch, but 
I think that your patch makes it even worse):
When I run my search command without using the quickfix list I get the 1 
results in about 2.2 seconds (and it's also non blocking of course -pretty nice 
:)). But -when I run this search after using the quickfix list the performance 
(of my search command, which is not related to the quickfix mechanism) becomes 
very bad. Actually, the performance degrades in a correlation with how many 
times I used the quickfix before. Example:

:Agrep -r  

- This is my search command. It returns all the results in 2.2 seconds (no 
quickfix list here).

But:

:grep -r   " regular grep that uses the quickfix list
and then -
:Agrep -r  

- Here, my Agrep command takes ~4 seconds

And
:grep -r  
:grep -r  
:grep -r  
:Agrep -r  

- Now Agrep takes ~7 seconds.

Any idea what is going on here?

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

On Sunday, May 29, 2016 at 4:44:12 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > I tried the patch from shougo's thread and it solved my problem. thanks!
> 
> So the current Vim works for you?
Yes.
> 
> > There is another (minor) issue I noticed; Because I had problems with
> > the close_cb (I got out-callbacks after it was called) I started a
> > timer to 200ms so I'll be able to know when it's safe to cleanup. I'm
> > not sure if it is still needed, however I see that when running in the
> > terminal the timer callback is called almost immediately as expected,
> > but in the gui it takes more than 2 seconds from when the timer starts
> > until I get the callback. Any idea why?
> 
> I did a simple timer setup and in my GUI it works like in the terminal.
> This is on Unix.
> 
>   function! Done(timer)
> echomsg "Done"
>   endfunction
> 
>   call timer_start(200, 'Done')
> 
Please try this:

func! Close_cb(channel)
let g:rt = reltime()
call timer_start(200, 'Timer_cb')
endfunc

func! Timer_cb(timer)
echo reltime(g:rt)
endfunc

call job_start('ls', {'close_cb': 'Close_cb'})

> 
> > Also, did you have a chance to check the two quickfix issues from the
> > first message?
> 
> Which ones are that?  This thread has gotten a bit long.  Is this about
> parsing errors line by line?  I was wondering if ":caddexpr" comes
> close.  Perhaps we should have a function for this.
> 
In my plugin I'm doing the message parsing manually, then I'm using setqflist() 
to add the results to the list. The problems I mentioned are quoted in 
Yegappan's response.

> -- 
> How To Keep A Healthy Level Of Insanity:
> 4. Put your garbage can on your desk and label it "in".
> 
>  /// 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: Use 'out_io': 'buffer' with nomodifiable

[Ramel Eshed]

On Friday, May 27, 2016 at 10:38:00 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Wednesday, May 25, 2016 at 11:49:48 PM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > Is there any way to use a nomodifiable buffer as an output buffer for
> > > > a job? If not, I think that it could be very useful.
> > > 
> > > The idea of making a buffer nomodifiable is that it's read-only, the
> > > contents is not supposed to change.  That conflicts with writing to the
> > > buffer.
> > > 
> > > -- 
> > > hundred-and-one symptoms of being an internet addict:
> > > 11. You find yourself typing "com" after every period when using a word
> > > processor.com
> > > 
> > >  /// 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
> > > ///
> > 
> > Hi Bram,
> > 
> > It seems to me that in most cases plugins developers will want to
> > protect the job's output buffer from being modified by the user. I
> > know that in all the use cases I can think about now I want to set
> > this buffer to be read-only or at least to be able to control when the
> > user can modify it. A few examples might be: Live log file viewer,
> > some sort of console, display search results (like I did in the plugin
> > I mentioned in the other thread).
> 
> Well, running a plugin is also triggered by the user, thus it's a subtle
> difference.
> 
> In most cases the user will know not to modify a buffer that is used by
> a plugin.  Just like you would not change a log file, etc.
> 
> Perhaps you can guard modifications, and set/reset 'modifiable' at the
> right moment.  Directly redirecting to the buffer doesn't work then
> though.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 23. You can't call your mother...she doesn't have a modem.
> 
>  /// 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///

In every Vim plugin that I've used (which are not too many though) there was a 
protection on the general-purpose buffers (done by setting and resetting 
'modifiable').
The concern, I guess, is not to prevent the user from changing the buffer 
deliberately rather then to protect from stupid mistakes. Here, when the buffer 
changed asynchronously it is even more dangerous. For example: what if the user 
by mistake will press 'p' while the buffer is being updated? -In other cases a 
simple undo will help but here it is likely that before the user will press 'u' 
there will be many new lines added by the job output so undo will delete them 
instead.
Is it possible to add an option to the job that will let it override 
'modifiable' just for the out_io?

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

On Friday, May 27, 2016 at 9:00:03 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > > > I'm not sure what exactly you've done in the last few patches, but it
> > > > seems like the SEGV issue is solved now, Thanks.
> > > 
> > > Glad to hear that.
> > > 
> > > > Unfortunately, I have
> > > > a different issue now when using the gui; Sometimes, when I perform a
> > > > large search (~9000 results) Vim hangs and never restored. I enabled
> > > > the channel log and I see the following Netbeans messages even though
> > > > I'm not using the Netbeans protocol: 
> > > > 
> > > > ERR on 1: messageFromNetbeans(): Cannot read from channel, will close 
> > > > it soon
> > > 
> > > That's just an old name for what is now a generic function.
> > > 
> > > > When running Vim in a terminal everything works fine, but for some
> > > > reason I still see errors in the channel's log. The terminal error is:
> > > > 
> > > > ERR on 1: channel_select_check(): Cannot read from channel, will close 
> > > > it soon
> > > > 
> > > > Any idea what went wrong?
> > > 
> > > Not really.  It's possible the job just finished.  Do you have a way to
> > > check for that?
> > > 
> > > > The gui issue doesn't seem deterministic, so I can't give a way to
> > > > reproduce it, but you can download my plugin and play with it a bit
> > > > (It takes me no more than 10 searches in the linux kernel code base
> > > > until I see the issue).
> > > 
> > > Let's first find out if the output is truncated or not.  You could run
> > > the same command and redirect the output to a file, then check the
> > > channel log to see what's the last thing that Vim received.
> > 
> > You're right. I checked and it seems like the job is finished, I can
> > see that Vim got all the job's output. That's however what I see at
> > the end of the log (the first line is the last line of the grep
> > process):
> > 
> > /home/ramele/linux-4.6-rc5/block/blk-mq-sysfs.c:457:blk_mq_enable_h 
> > [01m [Kotp [m [Klug();
> > '
> >   3.396833 : looking for messages on channels
> >   3.396842 on 0: Invoking channel callback Agrep_cb
> >   3.397006 on 0: Invoking channel callback Agrep_cb
> >   3.397174 on 0: Invoking channel callback Agrep_cb
> >   3.397333 on 0: Invoking channel callback Agrep_cb
> >   3.397424 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397433 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397445 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397451 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397462 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397467 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397478 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   3.397484 ERR on 0: channel_read_fd(): Cannot read from channel, will 
> > close it soon
> >   .
> >   .
> >   .
> > 
> > It seems that Vim hangs in an infinite loop here. For some reason I
> > didn't see it in the previous log, not sure why (maybe it's related to
> > some changes I made to simplify the debug).
> > 
> > I hope that helps you. Let me know if you want me to chack further.
> 
> Thanks for finding this.  I can avoid giving the error more than once by
> not trying to read if the channel is about to be closed.
> 
> However, I still wonder why this happens.  Is this only with gvim or
> also in a terminal?
> 
> Simplest would be if you could run Vim in a debugger and set a
> breakpoint where the error is reported a second time.
> 
> Anyway, I'll make a patch to avoid giving the error multiple times, that
> might already help, since it will skip trying to read.
> 
> -- 
> When a fly lands on the ceiling, does it do a half roll or
> a half loop?
> 
>  /// 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///

I tried the patch from shougo's thread and it solved my problem. thanks!

There is an

Re: Navigate in Vim messages bug

[Ramel Eshed]

On Thursday, May 26, 2016 at 6:03:25 PM UTC+3, h_east wrote:
> Hi Bram, Ramel and developers,
> 
> 2016-5-25(Wed) 23:16:51 UTC+9 h_east:
> > Hi Ramel,
> > 
> > 2016-5-25(Wed) 22:02:46 UTC+9 Ramel Eshed:
> > > Hi All,
> > > 
> > > Please check this:
> > > 
> > > vim -u NONE -N
> > > :for i in range(1, 200) | echoerr 'mes ' . i | endfor
> > > G " - go to the bottom of the list
> > > 
> > > Now, type k several times; instead of moving one line back each time, I 
> > > get extra 'Press ENTER or type command to continue' messages.
> > 
> > I can reproduce it.
> > This behavior is related to the following patch and thread.
> > 
> > Patch 7.4.1603
> > https://groups.google.com/d/msg/vim_dev/ULVcOTWfV6k/pexQ-XSSGQAJ
> > 
> > Patch 7.4.1594 (I reported many wrong redraw behavior)
> > https://groups.google.com/d/msg/vim_dev/MnIeBK-XLgc/eEuAUfaIGQAJ
> > 
> > 
> > Perhaps, this if statement is causing this problem.
> > https://github.com/vim/vim/blame/master/src/message.c#L2477-L2482
> > 
> > Thanks for reporting this.
> 
> I wrote a patch that fixes this issue.  It's ad hoc.
> Please check this.
> 
> Ultimately, we must fix correctly, including output from the timer handler.
> 
> Sample 1:
> $ cat sss.vim
> let g:tt_cnt = 0
> func MyHandler(timer)
> let g:tt_cnt += 1
> echo g:tt_cnt
> endfunc
> let timer = timer_start(500, 'MyHandler', {'repeat': -1})
> 
> $ vim -Nu NONE -S sss.vim
> :!ls
> 
> 
> Sample 2:
> $ cat sss.vim
> let g:tt_cnt = 0
> func MyHandler(timer)
> let g:tt_cnt += 1
> echo g:tt_cnt
> endfunc
> let timer = timer_start(500, 'MyHandler', {'repeat': -1})
> 
> $ vim -Nu NONE -S sss.vim
> :for i in range(1, 200) | echoerr 'mes ' . i | endfor
> G
> 
> 
> --
> Best regards,
> Hirohito Higashi (a.k.a. h_east)

Hi Hirohito,

I checked your patch and it solved my problem.

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

[Ramel Eshed]

On Wednesday, May 25, 2016 at 10:48:32 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > I'm not sure what exactly you've done in the last few patches, but it
> > seems like the SEGV issue is solved now, Thanks.
> 
> Glad to hear that.
> 
> > Unfortunately, I have
> > a different issue now when using the gui; Sometimes, when I perform a
> > large search (~9000 results) Vim hangs and never restored. I enabled
> > the channel log and I see the following Netbeans messages even though
> > I'm not using the Netbeans protocol: 
> > 
> > ERR on 1: messageFromNetbeans(): Cannot read from channel, will close it 
> > soon
> 
> That's just an old name for what is now a generic function.
> 
> > When running Vim in a terminal everything works fine, but for some
> > reason I still see errors in the channel's log. The terminal error is:
> > 
> > ERR on 1: channel_select_check(): Cannot read from channel, will close it 
> > soon
> > 
> > Any idea what went wrong?
> 
> Not really.  It's possible the job just finished.  Do you have a way to
> check for that?
> 
> > The gui issue doesn't seem deterministic, so I can't give a way to
> > reproduce it, but you can download my plugin and play with it a bit
> > (It takes me no more than 10 searches in the linux kernel code base
> > until I see the issue).
> 
> Let's first find out if the output is truncated or not.  You could run
> the same command and redirect the output to a file, then check the
> channel log to see what's the last thing that Vim received.
> 
> -- 
> Everybody wants to go to heaven, but nobody wants to die.
> 
>  /// 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're right. I checked and it seems like the job is finished, I can see that 
Vim got all the job's output. That's however what I see at the end of the log 
(the first line is the last line of the grep process):

/home/ramele/linux-4.6-rc5/block/blk-mq-sysfs.c:457:blk_mq_enable_h [01m 
[Kotp [m [Klug();
'
  3.396833 : looking for messages on channels
  3.396842 on 0: Invoking channel callback Agrep_cb
  3.397006 on 0: Invoking channel callback Agrep_cb
  3.397174 on 0: Invoking channel callback Agrep_cb
  3.397333 on 0: Invoking channel callback Agrep_cb
  3.397424 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397433 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397445 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397451 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397462 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397467 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397478 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  3.397484 ERR on 0: channel_read_fd(): Cannot read from channel, will close it 
soon
  .
  .
  .

It seems that Vim hangs in an infinite loop here. For some reason I didn't see 
it in the previous log, not sure why (maybe it's related to some changes I made 
to simplify the debug).

I hope that helps you. Let me know if you want me to chack further.

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: Use 'out_io': 'buffer' with nomodifiable

[Ramel Eshed]

On Wednesday, May 25, 2016 at 11:49:48 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > Is there any way to use a nomodifiable buffer as an output buffer for
> > a job? If not, I think that it could be very useful.
> 
> The idea of making a buffer nomodifiable is that it's read-only, the
> contents is not supposed to change.  That conflicts with writing to the
> buffer.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 11. You find yourself typing "com" after every period when using a word
> processor.com
> 
>  /// 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///

Hi Bram,

It seems to me that in most cases plugins developers will want to protect the 
job's output buffer from being modified by the user. I know that in all the use 
cases I can think about now I want to set this buffer to be read-only or at 
least to be able to control when the user can modify it. A few examples might 
be: Live log file viewer, some sort of console, display search results (like I 
did in the plugin I mentioned in the other thread).

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

Navigate in Vim messages bug

[Ramel Eshed]

Hi All,

Please check this:

vim -u NONE -N
:for i in range(1, 200) | echoerr 'mes ' . i | endfor
G " - go to the bottom of the list

Now, type k several times; instead of moving one line back each time, I get 
extra 'Press ENTER or type command to continue' messages.

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.

Use 'out_io': 'buffer' with nomodifiable

[Ramel Eshed]

Hi,

Is there any way to use a nomodifiable buffer as an output buffer for a job? If 
not, I think that it could be very useful.

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

[Ramel Eshed]

On Sunday, May 8, 2016 at 8:50:30 PM UTC+3, Ramel Eshed wrote:
> On Sunday, May 8, 2016 at 2:26:05 PM UTC+3, Bram Moolenaar wrote:
> > Ramel Eshed wrote:
> > 
> > > On Sunday, May 8, 2016 at 8:59:24 AM UTC+3, Bram Moolenaar wrote:
> > > > Ramel Eshed wrote:
> > > > 
> > > > > 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 
> > > > > 
> > > > > 1. Stability:
> > > > > Currently (7.4.1819) when :Agrep returns high number of results
> > > > > (~2800. So we get similar number of callbacks in a time frame of ~2:45
> > > > > seconds) Vim crashes with:
> > > > > 
> > > > > Caught deadly signal SEGV
> > > > > Vim: Finished.
> > > > > Segmentation fault (core dumped)
> > > > 
> > > > What system are you using?  If on Windows, what compiler?
> > > > 
> > > This plugin is for Linux. I'm using Ubuntu 16.04 (and tested it also on 
> > > RHEL 5.5).
> > > 
> > > > > This is more likely to happen when using the quickfix list. But it
> > > > > happens sometimes with agrep window as well. I never see this when I
> > > > > change the out_cb to only process the msg without adding the results
> > > > > to neither agrep window or qf list (-with lines 108-118 commented
> > > > > out).
> > > > > 
> > > > > 2. Quickfix issues
> > > > > a.As long as there are not too many matches and the quickfix
> > > > > window is closed you can fire up a search and start jumping to the
> > > > > available matches while the search is still running using the quickfix
> > > > > navigation commands (:cn, for example). The problem is when the
> > > > > quickfix window is opened while the search is active – here there is a
> > > > > serious performance issue, and Vim hangs for a while. You can see this
> > > > > by running :copen and then :Agrep. Choose a search that will generate
> > > > > many results (> 1000).
> > > > 
> > > > You could use the channel log to find out where Vim spends time.  You
> > > > may need to add more log statements in the code and recompile.
> > > >
> > > I think that this is a quickfix issue rather than channels. I don't see 
> > > that problem when running with agrep window or even with quickfix without 
> > > the qf window opened (there is also the other issue (see #b below) but 
> > > this one is much more serious). The channels code does exactly the same, 
> > > no matter which mode we're using to display the results.
> > >  
> > > > > b.As the matches rate becomes higher, Vim will become
> > > > > unresponsive. It may happen for short intervals or it can hangs for a
> > > > > while (for very high rate). By “rate” I simply mean to
> > > > > number_of_matches / sec. To compare, the performance is much better
> > > > > with the agrep window.
> > > > > 
> > > > > As I understand (and please correct me if I’m wrong) when using
> > > > > setqflist() to create a new list or add items to the current list, Vim
> > > > > reads all the buffers (as an unlisted buffers) in order to set the
> > > > > hidden marks. I think that this is the reason of the slowness I’m
> > > > > experiencing. If I'm right, maybe the way Vi

Re: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

On Sunday, May 8, 2016 at 2:26:05 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Sunday, May 8, 2016 at 8:59:24 AM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > 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 
> > > > 
> > > > 1. Stability:
> > > > Currently (7.4.1819) when :Agrep returns high number of results
> > > > (~2800. So we get similar number of callbacks in a time frame of ~2:45
> > > > seconds) Vim crashes with:
> > > > 
> > > > Caught deadly signal SEGV
> > > > Vim: Finished.
> > > > Segmentation fault (core dumped)
> > > 
> > > What system are you using?  If on Windows, what compiler?
> > > 
> > This plugin is for Linux. I'm using Ubuntu 16.04 (and tested it also on 
> > RHEL 5.5).
> > 
> > > > This is more likely to happen when using the quickfix list. But it
> > > > happens sometimes with agrep window as well. I never see this when I
> > > > change the out_cb to only process the msg without adding the results
> > > > to neither agrep window or qf list (-with lines 108-118 commented
> > > > out).
> > > > 
> > > > 2. Quickfix issues
> > > > a.As long as there are not too many matches and the quickfix
> > > > window is closed you can fire up a search and start jumping to the
> > > > available matches while the search is still running using the quickfix
> > > > navigation commands (:cn, for example). The problem is when the
> > > > quickfix window is opened while the search is active – here there is a
> > > > serious performance issue, and Vim hangs for a while. You can see this
> > > > by running :copen and then :Agrep. Choose a search that will generate
> > > > many results (> 1000).
> > > 
> > > You could use the channel log to find out where Vim spends time.  You
> > > may need to add more log statements in the code and recompile.
> > >
> > I think that this is a quickfix issue rather than channels. I don't see 
> > that problem when running with agrep window or even with quickfix without 
> > the qf window opened (there is also the other issue (see #b below) but this 
> > one is much more serious). The channels code does exactly the same, no 
> > matter which mode we're using to display the results.
> >  
> > > > b.As the matches rate becomes higher, Vim will become
> > > > unresponsive. It may happen for short intervals or it can hangs for a
> > > > while (for very high rate). By “rate” I simply mean to
> > > > number_of_matches / sec. To compare, the performance is much better
> > > > with the agrep window.
> > > > 
> > > > As I understand (and please correct me if I’m wrong) when using
> > > > setqflist() to create a new list or add items to the current list, Vim
> > > > reads all the buffers (as an unlisted buffers) in order to set the
> > > > hidden marks. I think that this is the reason of the slowness I’m
> > > > experiencing. If I'm right, maybe the way Vim loads the buffers of the
> > > > qf list should be changed so buffers will be loaded only when they're
> > > > been accessed and not when they're added to the list. What do you
> > > > think?
> > > 
> > > Then it would also be slow if you add all the matches at once.  Does
> > > that happen?
> > >  
> > You're right, I forgot to mention that. It is noticeable also whe

Re: Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

On Sunday, May 8, 2016 at 8:59:24 AM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > 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 
> > 
> > 1. Stability:
> > Currently (7.4.1819) when :Agrep returns high number of results
> > (~2800. So we get similar number of callbacks in a time frame of ~2:45
> > seconds) Vim crashes with:
> > 
> > Caught deadly signal SEGV
> > Vim: Finished.
> > Segmentation fault (core dumped)
> 
> What system are you using?  If on Windows, what compiler?
> 
This plugin is for Linux. I'm using Ubuntu 16.04 (and tested it also on RHEL 
5.5).

> > This is more likely to happen when using the quickfix list. But it
> > happens sometimes with agrep window as well. I never see this when I
> > change the out_cb to only process the msg without adding the results
> > to neither agrep window or qf list (-with lines 108-118 commented
> > out).
> > 
> > 2. Quickfix issues
> > a.As long as there are not too many matches and the quickfix
> > window is closed you can fire up a search and start jumping to the
> > available matches while the search is still running using the quickfix
> > navigation commands (:cn, for example). The problem is when the
> > quickfix window is opened while the search is active – here there is a
> > serious performance issue, and Vim hangs for a while. You can see this
> > by running :copen and then :Agrep. Choose a search that will generate
> > many results (> 1000).
> 
> You could use the channel log to find out where Vim spends time.  You
> may need to add more log statements in the code and recompile.
>
I think that this is a quickfix issue rather than channels. I don't see that 
problem when running with agrep window or even with quickfix without the qf 
window opened (there is also the other issue (see #b below) but this one is 
much more serious). The channels code does exactly the same, no matter which 
mode we're using to display the results.
 
> > b.As the matches rate becomes higher, Vim will become
> > unresponsive. It may happen for short intervals or it can hangs for a
> > while (for very high rate). By “rate” I simply mean to
> > number_of_matches / sec. To compare, the performance is much better
> > with the agrep window.
> > 
> > As I understand (and please correct me if I’m wrong) when using
> > setqflist() to create a new list or add items to the current list, Vim
> > reads all the buffers (as an unlisted buffers) in order to set the
> > hidden marks. I think that this is the reason of the slowness I’m
> > experiencing. If I'm right, maybe the way Vim loads the buffers of the
> > qf list should be changed so buffers will be loaded only when they're
> > been accessed and not when they're added to the list. What do you
> > think?
> 
> Then it would also be slow if you add all the matches at once.  Does
> that happen?
>  
You're right, I forgot to mention that. It is noticeable also when adding many 
results at once (you can see this by running :Agrepsetqf after you have a long 
list of results).

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

Asynchronous grep plugin - thoughts and issues

[Ramel Eshed]

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 

1. Stability:
Currently (7.4.1819) when :Agrep returns high number of results (~2800. So we 
get similar number of callbacks in a time frame of ~2:45 seconds) Vim crashes 
with:

Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)

This is more likely to happen when using the quickfix list. But it happens 
sometimes with agrep window as well. I never see this when I change the out_cb 
to only process the msg without adding the results to neither agrep window or 
qf list (-with lines 108-118 commented out).

2. Quickfix issues
a.As long as there are not too many matches and the quickfix window is 
closed you can fire up a search and start jumping to the available matches 
while the search is still running using the quickfix navigation commands (:cn, 
for example). The problem is when the quickfix window is opened while the 
search is active – here there is a serious performance issue, and Vim hangs for 
a while. You can see this by running :copen and then :Agrep. Choose a search 
that will generate many results (> 1000).

b.As the matches rate becomes higher, Vim will become unresponsive. It may 
happen for short intervals or it can hangs for a while (for very high rate). By 
“rate” I simply mean to number_of_matches / sec. To compare, the performance is 
much better with the agrep window.

As I understand (and please correct me if I’m wrong) when using setqflist() to 
create a new list or add items to the current list, Vim reads all the buffers 
(as an unlisted buffers) in order to set the hidden marks. I think that this is 
the reason of the slowness I’m experiencing. If I'm right, maybe the way Vim 
loads the buffers of the qf list should be changed so buffers will be loaded 
only when they're been accessed and not when they're added to the list. What do 
you think?

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.

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?

I think I'll stop here for now. I'm looking forward to get your feedback.

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: Adding to quickfix list issue

[Ramel Eshed]

On Monday, April 18, 2016 at 9:39:15 AM UTC+3, Bram Moolenaar wrote:
> Yegappan Lakshmanan wrote:
> 
> > On Sun, Apr 17, 2016 at 11:38 AM, Yegappan Lakshmanan
> > <yegapp...@gmail.com> wrote:
> > > Hi,
> > >
> > > On Sun, Apr 17, 2016 at 3:35 AM, Ramel Eshed <rame...@gmail.com> wrote:
> > >> On Sunday, April 17, 2016 at 3:12:55 AM UTC+3, yega...@gmail.com wrote:
> > >>> Hi,
> > >>>
> > >>> On Sat, Apr 16, 2016 at 3:43 PM, Yegappan Lakshmanan
> > >>> <yegapp...@gmail.com> wrote:
> > >>> > Hi,
> > >>> >
> > >>> > On Sat, Apr 16, 2016 at 12:52 PM, Ramel Eshed <rame...@gmail.com> wro=
> > te:
> > >>> >> Adding an item to the current quickfix list causes a jump to the fir=
> > st item rather than keeping the current context:
> > >>> >>
> > >>> >> Download the attached file;
> > >>> >> vim -u NONE -N
> > >>> >> :source qf_test.vim
> > >>> >>
> > >>> >> -After adding 2 items, :cn, adding one more item and another :cn we =
> > are in (2 of 3) instead of (3 of 3).
> > >>> >>
> > >>> >
> > >>> > The setqflist() function resets the index of the quickfix list so tha=
> > t it
> > >>> > points to the first entry (even if entries are appended to the list).
> > >>> >
> > >>> > Due to a bug in the set_errorlist() function, the index is set to 1 i=
> > nstead
> > >>> > of zero. That is why, you saw 2 of 3 instead of 1 of 3.
> > >>> >
> > >>>
> > >>> The quickfix index is 1 based and not zero based. The current code corr=
> > ectly
> > >>> sets the index to 1. So there is no bug in the current code.
> > >>>
> > >>> The documentation for the setqflist() function needs to be updated to
> > >>> state that it will reset to the first valid entry.
> > >>>
> > >>> - Yegappan
> > >>
> > >> Is there any reason to reset the pointer each time? I think that it is
> > >> more reasonable to leave the pointer as it when adding to the list so
> > >> it=E2=80=99d be possible to work with the list and adding new items to i=
> > t when
> > >> they=E2=80=99re available without losing the context.
> > >>
> > >
> > > Agreed. I will send out a patch later today for this.
> > 
> > A patch with tests is attached.
> 
> Thanks!
> 
> -- 
> I'd like to meet the man who invented sex and see what he's working on now.
> 
>  /// 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///

Thanks for the patch, it solved the issues I had.

I wrote a simple async grep plugin and I'm able to update the quickfix list on 
the fly now, but I ran into some performance issues which are probably caused 
by the internal quickfix implementation. I'll try to elaborate more on this 
tomorrow.

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 screen update

[Ramel Eshed]

On Monday, April 18, 2016 at 8:35:18 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > On Sunday, April 17, 2016 at 11:33:50 AM UTC+3, Bram Moolenaar wrote:
> > > Ramel Eshed wrote:
> > > 
> > > > When using “out_io”: “buffer” in the job options there are some issues
> > > > with the screen rendering. The first one is when I try to edit the
> > > > command line while the job’s buffer is being updated; As long as there
> > > > is room in the job’s window the only problem is that I don’t see the
> > > > cursor in the command-line. When Vim starts scrolling the job’s window
> > > > the entire content of the command-line disappears with every screen
> > > > update.
> > > 
> > > So we need to skip the display update if the screen is scrolled.
> > > And put the cursor in the command line.
> > > 
> > > > - Another issue which is easier to notice on GVim is the toggling of
> > > > the cursor between the job’s buffer and the current buffer. I’m not
> > > > familiar with the implementation, but I guess that in order to update
> > > > the job’s buffer Vim needs to actually move to that buffer. I remember
> > > > a discussion about adding a proper setbufline() function. I think that
> > > > it might be very useful, especially now when combined with the new
> > > > async features.
> > > > 
> > > > To reproduce:
> > > > Save the attached file in your home directory.
> > > > 
> > > > vim –u NONE -N
> > > > :new
> > > > :let job = job_start(['/bin/tcsh', '-c', '~/async_test.csh'], 
> > > > {'out_io': 'buffer', 'out_buf':1})
> > > > 
> > > > Now try to type in the command line.
> > > > Do the same with GVim to see the cursor toggling issue.
> > > > 
> > > > I'm using Vim 7.4.1747 on RHEL 5.5.
> > > 
> > > What do you mean with "cursor toggling issue"?
> >
> > It looks like the cursor is in some sort of superposition –In my example
> > there are 2 windows; The upper window is the one I'm working in and the
> > bottom window is being updated with the job’s output constantly. The cursor
> > keeps jumping between the two windows so it’s hard to keep working like 
> > that.
> > When running Vim inside a terminal this isn’t very noticeable, so it almost
> > looks like the cursor stays in the upper buffer, which I think should be the
> > correct behavior. Now, the feeling is not so "asynchronous", because the
> > job's buffer updates interfere with the normal work in the other window.
> 
> Can you check if patch 7.4.1750 fixed this problem as well?
> 
> -- 
> You got to work at a mill?  Lucky!  I got sent back to work in the
> acid-mines for my daily crust of stale bread... which not even the
> birds would eat.
> 
>  /// 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///

Hi Bram,

It looks great in the terminal now and it really gives you the "asynchronous" 
feel. The gui is also much better now, but the cursor blinking pace is 
irregular (sometimes it blinks rapidly or doesn't blink at all). It could be 
disturbing for long periods.

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: Adding to quickfix list issue

[Ramel Eshed]

On Monday, April 18, 2016 at 1:43:19 AM UTC+3, yega...@gmail.com wrote:
> Hi,
> 
> On Sun, Apr 17, 2016 at 11:38 AM, Yegappan Lakshmanan
> <yegapp...@gmail.com> wrote:
> > Hi,
> >
> > On Sun, Apr 17, 2016 at 3:35 AM, Ramel Eshed <rame...@gmail.com> wrote:
> >> On Sunday, April 17, 2016 at 3:12:55 AM UTC+3, yega...@gmail.com wrote:
> >>> Hi,
> >>>
> >>> On Sat, Apr 16, 2016 at 3:43 PM, Yegappan Lakshmanan
> >>> <yegapp...@gmail.com> wrote:
> >>> > Hi,
> >>> >
> >>> > On Sat, Apr 16, 2016 at 12:52 PM, Ramel Eshed <rame...@gmail.com> wrote:
> >>> >> Adding an item to the current quickfix list causes a jump to the first 
> >>> >> item rather than keeping the current context:
> >>> >>
> >>> >> Download the attached file;
> >>> >> vim -u NONE -N
> >>> >> :source qf_test.vim
> >>> >>
> >>> >> -After adding 2 items, :cn, adding one more item and another :cn we 
> >>> >> are in (2 of 3) instead of (3 of 3).
> >>> >>
> >>> >
> >>> > The setqflist() function resets the index of the quickfix list so that 
> >>> > it
> >>> > points to the first entry (even if entries are appended to the list).
> >>> >
> >>> > Due to a bug in the set_errorlist() function, the index is set to 1 
> >>> > instead
> >>> > of zero. That is why, you saw 2 of 3 instead of 1 of 3.
> >>> >
> >>>
> >>> The quickfix index is 1 based and not zero based. The current code 
> >>> correctly
> >>> sets the index to 1. So there is no bug in the current code.
> >>>
> >>> The documentation for the setqflist() function needs to be updated to
> >>> state that it will reset to the first valid entry.
> >>>
> >>> - Yegappan
> >>
> >> Is there any reason to reset the pointer each time? I think that it is
> >> more reasonable to leave the pointer as it when adding to the list so
> >> it’d be possible to work with the list and adding new items to it when
> >> they’re available without losing the context.
> >>
> >
> > Agreed. I will send out a patch later today for this.
> >
> 
> A patch with tests is attached.
> 
> - Yegappan
> 
> >
> >>
> >> What I’m trying to do is to start a job that will search in a large
> >> code base and to be able to work with the available results as they
> >> appear. I don’t want to wait for the entire search to complete. Now,
> >> when trying to call setqflist(…, ‘a’) from the job’s callback I can’t
> >> really work with the results that already arrived.
> >>
> >
> > Makes sense.
> >

Great! Thanks Yegappan, this is a really nice feature I've been waiting to see 
for years.

There is one more minor issue though, with the quickfix window. Each addition 
puts the cursor at the line of the current item so it is not possible to 
navigate inside the quickfix window while the results are being added (with 
hjkl, for example. only :cn is working). Could you please fix that as well?

-- 
-- 
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: Adding to quickfix list issue

[Ramel Eshed]

On Sunday, April 17, 2016 at 3:12:55 AM UTC+3, yega...@gmail.com wrote:
> Hi,
> 
> On Sat, Apr 16, 2016 at 3:43 PM, Yegappan Lakshmanan
> <yegapp...@gmail.com> wrote:
> > Hi,
> >
> > On Sat, Apr 16, 2016 at 12:52 PM, Ramel Eshed <rame...@gmail.com> wrote:
> >> Adding an item to the current quickfix list causes a jump to the first 
> >> item rather than keeping the current context:
> >>
> >> Download the attached file;
> >> vim -u NONE -N
> >> :source qf_test.vim
> >>
> >> -After adding 2 items, :cn, adding one more item and another :cn we are in 
> >> (2 of 3) instead of (3 of 3).
> >>
> >
> > The setqflist() function resets the index of the quickfix list so that it
> > points to the first entry (even if entries are appended to the list).
> >
> > Due to a bug in the set_errorlist() function, the index is set to 1 instead
> > of zero. That is why, you saw 2 of 3 instead of 1 of 3.
> >
> 
> The quickfix index is 1 based and not zero based. The current code correctly
> sets the index to 1. So there is no bug in the current code.
> 
> The documentation for the setqflist() function needs to be updated to
> state that it will reset to the first valid entry.
> 
> - Yegappan

Is there any reason to reset the pointer each time? I think that it is more 
reasonable to leave the pointer as it when adding to the list so it’d be 
possible to work with the list and adding new items to it when they’re 
available without losing the context.
What I’m trying to do is to start a job that will search in a large code base 
and to be able to work with the available results as they appear. I don’t want 
to wait for the entire search to complete. Now, when trying to call 
setqflist(…, ‘a’) from the job’s callback I can’t really work with the results 
that already arrived.

-- 
-- 
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 screen update

[Ramel Eshed]

On Sunday, April 17, 2016 at 11:33:50 AM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
> 
> > When using “out_io”: “buffer” in the job options there are some issues
> > with the screen rendering. The first one is when I try to edit the
> > command line while the job’s buffer is being updated; As long as there
> > is room in the job’s window the only problem is that I don’t see the
> > cursor in the command-line. When Vim starts scrolling the job’s window
> > the entire content of the command-line disappears with every screen
> > update.
> 
> So we need to skip the display update if the screen is scrolled.
> And put the cursor in the command line.
> 
> > - Another issue which is easier to notice on GVim is the toggling of
> > the cursor between the job’s buffer and the current buffer. I’m not
> > familiar with the implementation, but I guess that in order to update
> > the job’s buffer Vim needs to actually move to that buffer. I remember
> > a discussion about adding a proper setbufline() function. I think that
> > it might be very useful, especially now when combined with the new
> > async features.
> > 
> > To reproduce:
> > Save the attached file in your home directory.
> > 
> > vim –u NONE -N
> > :new
> > :let job = job_start(['/bin/tcsh', '-c', '~/async_test.csh'], {'out_io': 
> > 'buffer', 'out_buf':1})
> > 
> > Now try to type in the command line.
> > Do the same with GVim to see the cursor toggling issue.
> > 
> > I'm using Vim 7.4.1747 on RHEL 5.5.
> 
> What do you mean with "cursor toggling issue"?
> 
> -- 
>An extraordinary TALL KNIGHT in all black (possibly John with Mike on his
>shoulders) walks out from the dark trees.  He is extremely fierce and
>gruesome countenance.  He walks towards KING ARTHUR and PATSY, who are
>wazzing like mad.  (Salopian slang, meaning very scared.  almost to the
>point of wetting oneself, e.g. before an important football match or
>prior to a postering.  Salopian slang meaning a beating by the school
>praeposters.  Sorry about the Salopian slant to this stage direction - Ed.)
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
> 
>  /// 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///

It looks like the cursor is in some sort of superposition –In my example there 
are 2 windows; The upper window is the one I'm working in and the bottom window 
is being updated with the job’s output constantly. The cursor keeps jumping 
between the two windows so it’s hard to keep working like that. When running 
Vim inside a terminal this isn’t very noticeable, so it almost looks like the 
cursor stays in the upper buffer, which I think should be the correct behavior. 
Now, the feeling is not so "asynchronous", because the job's buffer updates 
interfere with the normal work in the other window.

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

Adding to quickfix list issue

[Ramel Eshed]

Adding an item to the current quickfix list causes a jump to the first item 
rather than keeping the current context:

Download the attached file;
vim -u NONE -N
:source qf_test.vim

-After adding 2 items, :cn, adding one more item and another :cn we are in (2 
of 3) instead of (3 of 3).

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.


qf_test.vim
Description: Binary data

Asynchronous screen update

[Ramel Eshed]

Hi Bram,

When using “out_io”: “buffer” in the job options there are some issues with the 
screen rendering. The first one is when I try to edit the command line while 
the job’s buffer is being updated; As long as there is room in the job’s window 
the only problem is that I don’t see the cursor in the command-line. When Vim 
starts scrolling the job’s window the entire content of the command-line 
disappears with every screen update.

- Another issue which is easier to notice on GVim is the toggling of the cursor 
between the job’s buffer and the current buffer. I’m not familiar with the 
implementation, but I guess that in order to update the job’s buffer Vim needs 
to actually move to that buffer. I remember a discussion about adding a proper 
setbufline() function. I think that it might be very useful, especially now 
when combined with the new async features.

To reproduce:
Save the attached file in your home directory.

vim –u NONE -N
:new
:let job = job_start(['/bin/tcsh', '-c', '~/async_test.csh'], {'out_io': 
'buffer', 'out_buf':1})

Now try to type in the command line.
Do the same with GVim to see the cursor toggling issue.

I'm using Vim 7.4.1747 on RHEL 5.5.

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.
#!/bin/tcsh
foreach x (`seq 1 500`)
echo $x
sleep 0.2s
end