Re: [vim/vim] Vim 7.4.1826 breaks channel feature on GVim (#838)

[Dominique Pellé]

Bram Moolenaar  wrote:

> Shougo wrote:
>
> > After 7.4.1826, GVim freezes if use channel/job feature.
> > I have detected it using "git bisect" command.
> > It cannot reproduce on console Vim.
> > I can reproduce it in Vim 7.4.1848.
> >
> > I think it is the same issue with it.
> > https://groups.google.com/d/msg/vim_dev/LlSrz0w8xzk/tQ4ph8OnHwAJ
>
> Is there a simple way to reproduce this?

I can reproduce it when running tests after changing the
vim/src/testdir/Makefile so that all tests run gvim as follows:


diff --git a/src/testdir/Makefile b/src/testdir/Makefile
index 49a817a..6198ccd 100644
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -52,7 +52,7 @@ $(SCRIPTS) $(SCRIPTS_GUI) $(NEW_TESTS): $(SCRIPTS_FIRST)

 RM_ON_RUN = test.out X* viminfo
 RM_ON_START = tiny.vim small.vim mbyte.vim mzscheme.vim lua.vim
test.ok benchmark.out
-RUN_VIM = VIMRUNTIME=$(SCRIPTSOURCE); export VIMRUNTIME; $(VALGRIND)
$(VIMPROG) -f -u unix.vim $(NO_PLUGIN) -s dotest.in
+RUN_VIM = VIMRUNTIME=$(SCRIPTSOURCE); export VIMRUNTIME; $(VALGRIND)
$(VIMPROG) -f -g -u unix.vim $(NO_PLUGIN) -s dotest.in

 clean:
-rm -rf *.out *.failed *.res *.rej *.orig test.log messages
$(RM_ON_RUN) $(RM_ON_START) valgrind.*
@@ -118,7 +118,7 @@ nolog:
 # New style of tests uses Vim script with assert calls.  These are easier
 # to write and a lot easier to read and debug.
 # Limitation: Only works with the +eval feature.
-RUN_VIMTEST = VIMRUNTIME=$(SCRIPTSOURCE); export VIMRUNTIME;
$(VALGRIND) $(VIMPROG) -f -u unix.vim $(NO_PLUGIN)
+RUN_VIMTEST = VIMRUNTIME=$(SCRIPTSOURCE); export VIMRUNTIME;
$(VALGRIND) $(VIMPROG) -f -g -u unix.vim $(NO_PLUGIN)

 newtests: newtestssilent
@/bin/sh -c "if test -f messages && grep -q 'FAILED' messages;
then cat messages && cat test.log; fi"


The this hangs and shows:

"test_channel.vim" 1311 lines, 36597 characters
Executing Test_call()
Executing Test_channel_handler()


I tried vim-7.4.1748 and vim-7.4.1449 (gtk2) and both hang.


> I sent out 7.4.1849, but I don't know if this fixes the problem.

It does not fix it.


> Another thing, since this apparently only fails in the GUI,
> would be to call channel_gui_unregister() right away, when setting
> ch_to_be_closed. Perhaps you can try this patch:
>
> *** ../vim-7.4.1849/src/channel.c 2016-05-27 19:59:43.823519882 +0200
> --- src/channel.c 2016-05-27 21:34:17.451441836 +0200
> ***
> *** 2868,2873 
> --- 2868,2878 
> * died. Don't close the channel right away, it may be the wrong moment
> * to invoke callbacks. */
> channel->ch_to_be_closed = TRUE;
> +
> + /* Stop listening to GUI events right away. */
> + #ifdef FEAT_GUI
> + channel_gui_unregister(channel);
> + #endif
> }
>
> static void

With that patch, the test no longer hang.
However, when I run all tests, I see this (using
modified src/testdir/Makefile to run all tests with gvim):

=== BEGIN QUOTE ===
>From test_alot.vim:
Found errors in Test_missing_attr():
Caught exception in Test_missing_attr(): Vim(highlight):E416: missing
equal sign: 10 @ function RunTheTest[9]..Test_missing_attr, line 27
TEST FAILURE
make: *** [report] Error 1
=== END QUOTE ===

If I run tests in the terminal  (canceling my change to
src/testdir/Makefile) then all test pass.

Regards
Dominique

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

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

Re: Use 'out_io': 'buffer' with nomodifiable

[Bram Moolenaar]

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

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

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

Patch 7.4.1849

[Bram Moolenaar]

Patch 7.4.1849
Problem:Still trying to read from channel that is going to be closed.
(Ramel Eshed)
Solution:   Check if ch_to_be_closed is set.
Files:  src/channel.c


*** ../vim-7.4.1848/src/channel.c   2016-05-25 21:48:07.397807422 +0200
--- src/channel.c   2016-05-27 19:53:16.391525211 +0200
***
*** 2893,2898 
--- 2893,2902 
  sock_Tfd;
  int   use_socket = FALSE;
  
+ /* If we detected a read error don't try reading again. */
+ if (channel->ch_to_be_closed)
+   return;
+ 
  fd = channel->ch_part[part].ch_fd;
  if (fd == INVALID_FD)
  {
***
*** 3193,3198 
--- 3197,3206 
  
  for (channel = first_channel; channel != NULL; channel = channel->ch_next)
  {
+   /* If we detected a read error don't try reading again. */
+   if (channel->ch_to_be_closed)
+   continue;
+ 
/* check the socket and pipes */
for (part = PART_SOCK; part <= PART_ERR; ++part)
{
*** ../vim-7.4.1848/src/version.c   2016-05-26 22:09:56.088600919 +0200
--- src/version.c   2016-05-27 19:54:47.207523962 +0200
***
*** 755,756 
--- 755,758 
  {   /* Add new patch number below this line */
+ /**/
+ 1849,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
20. When looking at a pageful of someone else's links, you notice all of them
are already highlighted in 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///

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

[Bram Moolenaar]

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

-- 
-- 
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: lambda again

[Ken Takata]

Hi mattn,

2016/4/18 Mon 0:30:19 UTC+9 mattn wrote:
> Hi, Bram and list.
> 
> Updated lambda patch to be applied for latest code.
> 
> https://gist.github.com/mattn/5bc8ded21e1033c9c0ea8cd5ecbbce11
> 
> This include examples for timer on help file. I'm thinking lambda() have 
> cooperative to work with job/timer/channel.
> 
> So I hope to add this into vim8. How do you think?
> 
> Thanks to k-takata, haya14busa, and all of members on vim-jp.

I have tested the lambda patch with the latest Vim and I found two problems.

  1. garbagecollect_for_testing() was renamed.
  2. Test_lambda_with_timer() fails on Cygwin. It seems that we need margins
 as we do in test_timers.vim.

Please check attached patch.

I hope that the lambda patch will be merged in Vim 8.0.
This makes filter(), map() and sort() easy to use.
It also works nicely with job/channel/timer features.

Regards,
Ken Takata

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

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

diff --git a/src/testdir/test_lambda.vim b/src/testdir/test_lambda.vim
--- a/src/testdir/test_lambda.vim
+++ b/src/testdir/test_lambda.vim
@@ -235,12 +235,15 @@ function! Test_lambda_with_timer()
   endfunction
 
   call s:Foo()
-  sleep 100ms
+  sleep 200ms
   " do not collect lambda nor l:n in lambda
-  call garbagecollect_for_testing()
-  sleep 100ms
+  call test_garbagecollect_now()
+  let m = s:n
+  sleep 200ms
   call timer_stop(s:timer_id)
-  call assert_true(s:n > 3)
+  call assert_true(m > 1)
+  call assert_true(s:n > m + 1)
+  call assert_true(s:n < 9)
 endfunction
 
 function! Test_lambda_with_partial()

Re: distribute my unicode plugin with vim?

[Christian Brabandt]

On Sa, 21 Mai 2016, BPJ wrote:

> fredag 20 maj 2016 skrev Christian Brabandt :
> 
> > Hi,
> > as some of you may know, I am maintaining a little unicode plugin
> > https://github.com/chrisbra/unicode.vim
> >
> > Now I got an issue, that asks if it would be possible to distribute this
> > plugin with Vim, so I am asking here for feedback. Would such a plugin
> > or package be considered generally useful to be distributed with Vim or
> > should I continue to maintain it as separate plugin?
> >
> > Feedback is welcome.
> >
> 
> I for one use your Unicode plugin constantly. Mostly the UnicodeName
> command, but also Unicode completion. I might have discovered the plugin
> sooner if it had been distributed with Vim, but there is no guarantee as it
> took me some time to discover those plugins which are distributed with Vim.
> However I think that the Unicode plugin deserves to be discovered and used
> by everyone who does multilingual text entry in Vim (I sure hope I'm not
> one of a very few! :-) For ordinary typing I prefer keymaps, but the plugin
> is very useful for writing keymaps too! One functionality which i miss or
> haven't found is the ability to define digraphs by hex number or Unicode
> name for the cases when I need to define a digraph on the fly for
> occasional use in a document. A while back you (Christian) showed a trick
> to define a digraph by hex number in a mail to this list. I immediately
> turned it into a command, and I think such a command would be a valuable
> addition to the Unicode plugin.

Thanks for the feedback. I just updated your issue on the plugin list.

Waiting for Brams opinion, whether he thinks it could be distributed 
together with Vim.

Best,
Christian
-- 
Vom Verdienste fordert man Bescheidenheit; aber diejenigen, die 
unbescheiden das Verdienst schmälern, werden mit Behagen angehört.
-- Goethe, Maximen und Reflektionen, Nr. 665

-- 
-- 
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: distribute my unicode plugin with vim?

[Christian Brabandt]

Hi Enno!

On Fr, 20 Mai 2016, Enno wrote:

> Le vendredi 20 mai 2016 14:08:12 UTC+2, Christian Brabandt a écrit :
> > Hi, as some of you may know, I am maintaining a little unicode
> > plugin https://github.com/chrisbra/unicode.vim
> > 
> > Now I got an issue, that asks if it would be possible to distribute
> > this plugin with Vim, so I am asking here for feedback. Would such a
> > plugin or package be considered generally useful to be distributed
> > with Vim or should I continue to maintain it as separate plugin?
> > 
> > Feedback is welcome.
> > 
> > Here is the description of the plugin, taken from
> > https://github.com/chrisbra/unicode.vim/blob/master/README.md which
> > also contains a little screencast:
> > 
> > This plugin aims to make the handling of unicode and digraphs chars
> > in Vim easier. It serves 3 purposes:
> > 
> > Complete Characters Identify Characters Ease the use of Digraphs
> > 
> > Complete Characters
> > 
> > A custom completion function is available to complete characters
> > using their Unicode name or Codepoint. If a digraph exists for that
> > character, it will be displayed in paranthesis. Press Ctrl-X Ctrl-Z
> > to trigger this completion from insert mode. Also a new custom
> > completion for digraph chars is available. Press Ctrl-X Ctrl-G to
> > trigger this completion. It will display all digraphs, that are
> > reachable from the previous typed letter.
> > 
> > Identify Characters
> > 
> > The :UnicodeName command can be used to identify the character under
> > the cursor. This works similar to the builtin ga command (in fact,
> > the help also states a possibility to map this command to the ga
> > builtin command), but it also displays the digraph character (if it
> > exists) and the HTML entity.
> > 
> > The :SearchUnicode command can be used to search in the unicode
> > character table to search for a certain unicode character with a
> > given name or value.
> > 
> > The :UnicodeTable can be used to generate an Unicode table,
> > including HTML entity names and Digraph chars. The UnicodeTable will
> > be nicely syntax highlighted.
> > 
> > Ease the use of Digraphs
> > 
> > Use the :Digraphs command to search for an digraph with the given
> > name (e.g. :Digraphs copy will display all digraphs that will create
> > a character name which contains copy in its name). You can also
> > search for the decimal value. This plugin also maps the key 
> > that will allow to transform 2 given normal chars into their digraph
> > char.
> > 
> > See also the following screencast, that shows several features
> > available: screencast of the plugin
> > 
> > Installation
> > 
> > Use the plugin manager of your choice. Or download the stable
> > version of the plugin, edit it with Vim (vim unicode-XXX.vmb) and
> > simply source it (:so %). Restart and take a look at the help (:h
> > unicode-plugin) Usage
> > 
> > Once installed, take a look at the help at :h unicode-plugin
> > 
> > Here is a short overview of the functionality provided by the
> > plugin: Ex commands:
> > 
> > :Digraphs- Search for specific digraph char :SearchUnicode
> > - Search for specific unicode char :UnicodeName - Identify
> > character under cursor (like ga command) :UnicodeTable- Print
> > Unicode Table in new window :DownloadUnicode - Download (or update)
> > Unicode data
> > 
> > Normal mode commands:
> > 
> >   - Complete Digraph char   - Complete Unicode
> > char - Combine characters into digraphs
> > 
> > Scripting Functions:
> > 
> > unicode#FindUnicodeBy() - Find unicode characters
> > unicode#FindDigraphBy() - Find Digraph char unicode#Digraph()
> > - Returns digraph char unicode#UnicodeName()   - Identifies unicode
> > character (by value)
> > 
> > License & Copyright
> > 
> > © 2009-2014 by Christian Brabandt. The Vim License applies. See :h
> > license
> > 
> > NO WARRANTY, EXPRESS OR IMPLIED. USE AT-YOUR-OWN-RISK
> > 
> > 
> > Best, Christian -- Hoffentlich werden wir so alt wie wir aussehen.
> 
> Hello Christian,
> 
> the request on GitHub (by me) was specifically about the
> `:UnicodeName` command (and mapping it to `ga`) as a better
> alternative to the built-in `ga`. It could come coupled with
> `:DownloadUnicode` to download the latest Unicode data on demand.

Yeah I suppose that could be useful, although I would have to split and 
refactor the existing plugin. I would only do it, once we agree it 
should be distributed with Vim.

However, since most functionality builds around new custom commands, it 
might make sense to distribute as package so it can be enabled on demand 
by users and they can then use whatever they like.

Best,
Christian
-- 
Frau: Liebling, wo willst du nächstes Jahr Urlaub machen?
Mann: Am liebsten dort, wo ich noch nie war.
Frau: Ja prima, wie wär's dann mit der Küche.

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

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.