Re: Asynchronous balloonexpr handling
> 在 2017年2月1日，22:12，Christian Brabandt 写道： > >> On Mi, 01 Feb 2017, Bram Moolenaar wrote: >> Another thing that would be nice: Also make this work in the terminal. >> Could be implemented like we have the popup menu. Should be as simple >> as balloon_show(). For completenes we could add balloon_hide(). >> Perhaps you could implement that? > > While at it, could we have a key combination for triggering the display > of balloons? > > Best, > Christian > -- > Erfahrungen sind Maßarbeit. Sie passen nur dem, der sie macht. >-- Carlo Levi > > -- > -- > 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. or，a vim api balloon_show ？You can trigger the balloon whenever you want （received data from chanel，pressed a key，in a timer，in an autocmd） -- -- 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.
Syntax highlight error in .vim ??
Reproduce:
1. vim abc.vim:
2. add this line:
let my_dict = { "key1":"val1", "key2": "val2", "key3": "val3", "key4":"val4" }
Issue:
highlight color is incorrect for my_dict,
screen capture:
skywind3...@163.com
--
--
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.
What does 'DRAFT' means in channel.txt ?
I believe many people like me who are using async jobs in their plugins are afraid to publish their plugins because of the word 'DRAFT' in channel.txt. what does 'draft' mean ? - architecture of jobs/channels may change in the future ? - interfaces may change in the future ? - parameters or return codes may change in the future ? - or just internal implementation may change without modify interfaces ? and there are some more questions about it: - need we get ready to change our plugin implementation in any time because it is a draft ? - when could we publish our plugin and get more feedback from users ? - when is the word 'draft' going to be removed in channel.txt ? skywind3...@163.com -- -- 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: Re: Patch 7.4.1996
the report said version 7.4.1999 could not pass test 101 in mac is this the same problem in win32 gvim ? could win32 gvim version just ignore 7.4.1999 and just build 7.4.1998 ? skywind3...@163.com From: Ken Takata Date: 2016-07-08 12:29 To: vim_dev CC: skywind3000 Subject: Re: Re: Patch 7.4.1996 Hi, 2016/7/8 Fri 12:38:35 UTC+9 skywi...@163.com wrote: > Christian, > > Would you please have a look at the gvim daily build ? > Binaries are missing and it has only imported a tag of 7.4.1999. It is because the build failed. You can see a badge on the top page of vim-win32-installer. Currently the badge says "build failing" with red color. You can also see the detail build log at here: https://ci.appveyor.com/project/chrisbra/vim-win32-installer It seems that the error is the same as the following report: https://groups.google.com/d/topic/vim_dev/5asiN6qpwpc/discussion 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.
Re: Re: Patch 7.4.1996
Christian,
Would you please have a look at the gvim daily build ?
Binaries are missing and it has only imported a tag of 7.4.1999.
skywind3...@163.com
From: Christian Brabandt
Date: 2016-07-08 03:36
To: vim_dev
Subject: Re: Patch 7.4.1996
Hi Bram!
On Do, 07 Jul 2016, Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
> > On Do, 07 Jul 2016, Bram Moolenaar wrote:
> >
> > >
> > > Patch 7.4.1996
> > > Problem:Capturing the output of a command takes a few commands.
> > > Solution: Add evalcmd().
> > > Files: src/eval.c, runtime/doc/eval.txt, src/testdir/test_alot.vim,
> > > src/Makefile, src/testdir/test_evalcmd.vim
> >
> > Does that work recursively? e.g. what happens, if you do
> > :echo evalcmd(':redir =>a|syn|redir end')
>
> Nope. The help for :redir says:
>
> Only one ":redir" can be active at a time.
Sorry, but in that case, I don't see how the evalcmd() is helping much.
I would have rather seen a fixed :redir command. Perhaps make use of
Neovims capture() function?
https://github.com/neovim/neovim/pull/4697
Best,
Christian
--
Alles im Leben hat seinen Preis; auch die Dinge, von denen man sich
einbildet, man kriegt sie geschenkt.
-- Theodor Fontane
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1997
Thanks very much !
>From my iPhone
> 2016年7月8日，00:59，Bram Moolenaar :
>
>
> Patch 7.4.1997
> Problem:Cannot easily scroll the quickfix window.
> Solution: Add ":cbottom".
> Files: src/ex_cmds.h, src/quickfix.c, src/proto/quickfix.pro,
>src/ex_docmd.c, src/testdir/test_quickfix.vim,
>runtime/doc/quickfix.txt
>
>
> *** ../vim-7.4.1996/src/ex_cmds.h2016-06-12 21:20:50.941837428 +0200
> --- src/ex_cmds.h2016-07-07 18:19:22.888573565 +0200
> ***
> *** 259,264
> --- 259,267
> EX(CMD_cbuffer,"cbuffer",ex_cbuffer,
> BANG|RANGE|NOTADR|WORD1|TRLBAR,
> ADDR_LINES),
> + EX(CMD_cbottom,"cbottom",ex_cbottom,
> +TRLBAR,
> +ADDR_LINES),
> EX(CMD_cc,"cc",ex_cc,
> RANGE|NOTADR|COUNT|TRLBAR|BANG,
> ADDR_LINES),
> *** ../vim-7.4.1996/src/quickfix.c2016-07-02 15:41:41.586523202 +0200
> --- src/quickfix.c2016-07-07 18:47:44.182954704 +0200
> ***
> *** 2808,2813
> --- 2808,2848
> }
>
> /*
> + * Move the cursor in the quickfix window to "lnum".
> + */
> + static void
> + qf_win_goto(win_T *win, linenr_T lnum)
> + {
> + win_T*old_curwin = curwin;
> +
> + curwin = win;
> + curbuf = win->w_buffer;
> + curwin->w_cursor.lnum = lnum;
> + curwin->w_cursor.col = 0;
> + #ifdef FEAT_VIRTUALEDIT
> + curwin->w_cursor.coladd = 0;
> + #endif
> + curwin->w_curswant = 0;
> + update_topline();/* scroll to show the line */
> + redraw_later(VALID);
> + curwin->w_redr_status = TRUE;/* update ruler */
> + curwin = old_curwin;
> + curbuf = curwin->w_buffer;
> + }
> +
> + /*
> + * :cbottom command.
> + */
> + void
> + ex_cbottom(exarg_T *eap UNUSED)
> + {
> + win_T *win = qf_find_win(&ql_info);
> +
> + if (win != NULL && win->w_cursor.lnum !=
> win->w_buffer->b_ml.ml_line_count)
> +qf_win_goto(win, win->w_buffer->b_ml.ml_line_count);
> + }
> +
> + /*
> * Return the number of the current entry (line number in the quickfix
> * window).
> */
> ***
> *** 2844,2870
> && qf_index <= win->w_buffer->b_ml.ml_line_count
> && old_qf_index != qf_index)
> {
> -win_T*old_curwin = curwin;
> -
> -curwin = win;
> -curbuf = win->w_buffer;
> if (qf_index > old_qf_index)
> {
> !curwin->w_redraw_top = old_qf_index;
> !curwin->w_redraw_bot = qf_index;
> }
> else
> {
> !curwin->w_redraw_top = qf_index;
> !curwin->w_redraw_bot = old_qf_index;
> }
> !curwin->w_cursor.lnum = qf_index;
> !curwin->w_cursor.col = 0;
> !update_topline();/* scroll to show the line */
> !redraw_later(VALID);
> !curwin->w_redr_status = TRUE;/* update ruler */
> !curwin = old_curwin;
> !curbuf = curwin->w_buffer;
> }
> return win != NULL;
> }
> --- 2879,2895
> && qf_index <= win->w_buffer->b_ml.ml_line_count
> && old_qf_index != qf_index)
> {
> if (qf_index > old_qf_index)
> {
> !win->w_redraw_top = old_qf_index;
> !win->w_redraw_bot = qf_index;
> }
> else
> {
> !win->w_redraw_top = qf_index;
> !win->w_redraw_bot = old_qf_index;
> }
> !qf_win_goto(win, qf_index);
> }
> return win != NULL;
> }
> *** ../vim-7.4.1996/src/proto/quickfix.pro2016-01-19 13:21:55.845334290
> +0100
> --- src/proto/quickfix.pro2016-07-07 18:45:33.744948691 +0200
> ***
> *** 9,14
> --- 9,15
> void ex_cwindow(exarg_T *eap);
> void ex_cclose(exarg_T *eap);
> void ex_copen(exarg_T *eap);
> + void ex_cbottom(exarg_T *eap);
> linenr_T qf_current_entry(win_T *wp);
> int bt_quickfix(buf_T *buf);
> int bt_nofile(buf_T *buf);
> *** ../vim-7.4.1996/src/ex_docmd.c2016-06-12 21:20:50.941837428 +0200
> --- src/ex_docmd.c2016-07-07 18:23:05.425238053 +0200
> ***
> *** 129,134
> --- 129,135
> # define ex_ccloseex_ni
> # define ex_copenex_ni
> # define ex_cwindowex_ni
> + # define ex_cbottomex_ni
> #endif
> #if !defined(FEAT_QUICKFIX) || !defined(FEAT_EVAL)
> # define ex_cexprex_ni
> *** ../vim-7.4.1996/src/testdir/test_quickfix.vim2016-07-02
> 21:22:46.848282547 +0200
> --- src/testdir/test_quickfix.vim2016-07-07 18:56:27.686962935 +0200
> ***
> *** 1414,1416
> --- 1414,1429
>call delete('Xone', 'rf')
>call delete('Xtwo', 'rf')
> endfunc
> +
> + function Test_cbottom()
> + call setqflist([{'filename': 'foo', 'lnum': 42}])
> + copen
> + let wid = win_getid()
> + call assert_equal(1, line('.'))
> + wincmd w
> + call setqflist([{'filename': 'var', 'lnum': 24}], 'a')
> + cbottom
> + call win_gotoid(wid)
> + call assert_equal(2, line('.'))
> + cclose
> + endfunc
> *** ../vim-7.4.1996/runtime/
Re: Re: Will there be 8.0 after 7.4.1999 ?
I have no idea about packages but I have been using job/channel/timer for more than two month. it seems more stable now. skywind3...@163.com From: Rui Afonso Pereira Date: 2016-06-27 06:55 To: vim_dev CC: vim-dev; skywind3000 Subject: Re: Will there be 8.0 after 7.4.1999 ? On Sunday, June 26, 2016 at 5:47:12 AM UTC+1, skywi...@163.com wrote: > Since everything in version8.txt have been implemented for a while, > will there be 8.0 after 7.4.1999 ? > > > > > > > skywi...@163.com Hi, Is there anywhere we can check the current status/roadmap of version 8? For instance, is the package support already implemented? 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. -- -- 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: Re: Will there be 8.0 after 7.4.1999 ?
Thanks, Some linux distributions have freezed vim version to 7.4.*, they will not upgrade vim to 8.0 in a short time. Maybe we have to wait for more than 2 years to get 8.0 packages upgraded in all the linux distributions. But it seems that they are glad to upgrade a patch version like 7.4.* as soon as possible. So, I wonder if the quickfix improvements which referenced in todo.txt (:cbottom, etc) could be introduced in 7.4.* before 8.0 ?? skywind3...@163.com From: Bram Moolenaar Date: 2016-06-27 02:39 To: skywind3...@163.com CC: vim-dev Subject: Re: Will there be 8.0 after 7.4.1999 ? skywind3000 wrote: > Since everything in version8.txt have been implemented for a while, > will there be 8.0 after 7.4.1999 ? Yes, after some time. -- Drink wet cement and get really stoned. /// 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. -- -- 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.
Will there be 8.0 after 7.4.1999 ?
Since everything in version8.txt have been implemented for a while, will there be 8.0 after 7.4.1999 ? skywind3...@163.com -- -- 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: Re: Any way to scroll quickfix window automatically for long-time-running jobs ?
> Why? I think it has been shown, that depending on the use case auto > scroll does not make sense always. So it's not that hard, to simply > scroll manually, whenever you need. I am not sure, an extra :cbottom > command is really needed, but I am not against it. Let's talk about building vim, the output of 'make' is something like this: Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src && make first make[1]: Entering directory '/home/skywind/software/vim/src' CC="gcc -Iproto -DHAVE_CONFIG_H " srcdir=. sh ./osdef.sh gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/blowfish.o blowfish.c gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/charset.o charset.c gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/crypt.o crypt.c . cd xxd; CC="gcc" CFLAGS=" -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1" LDFLAGS="-L/usr/local/lib -Wl,--as-needed" \ make -f Makefile make[2]: Entering directory '/home/skywind/software/vim/src/xxd' gcc -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -L/usr/local/lib -Wl,--as-needed -DUNIX -o xxd xxd.c make[2]: Leaving directory '/home/skywind/software/vim/src/xxd' make[1]: Leaving directory '/home/skywind/software/vim/src' -- If you are using traditional ':make' command in vim to build the source, you can see: 1. Vim GUI will switch off to the previous console screen. 2. run '&makeprg' and output the text. 3. after it finished, vim prompts 'Press ENTER or type command to continue' 4. return to Vim GUI again. In this work flow, you can clearly indicate the building result and figure out if there is an error. There is a distinct between 'building' state and 'editing' state. But if you are building vim in async mode without a autoscroll in quickfix window. You may get these 6 lines in quickfix window while your are editing (quickfix window height is 6): Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src && make first make[1]: Entering directory '/home/skywind/software/vim/src' CC="gcc -Iproto -DHAVE_CONFIG_H " srcdir=. sh ./osdef.sh gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c As the async-build is going on without autoscroll, I will always be confused that: 1. How can I tell if the job is finished ? Because I am editing at the same time, All I can see is the first 6 lines of gnumake's output in quickfix. - Must I check the newest quickfix text manually every 10 seconds ? - or echo a "job finished" at the bottom of vim in 'close_cb' ? echo in a background callback is really not a good idea, sometimes, texts output by echo will get vim gui scrolled, which will interrupt my editing. and sometimes the output text will be overrided by a new echo (a lot of plugins use echo to output some status both in insert and normal mode that will override the previous output immediately). - or run 'afplay' to play a wav file to notify me that it is finished in 'close_cb' ? - or change the text in status bar ? None of these is perfect, because there is not a distinct state switching (eg. "Press ENTER or type command to continue") when I am building my project in an asynchronous job. 2. How can I tell if the building job is succeed while I am editing without autoscroll ? Since the top 6 lines of 'make' output are always occupying the quickfix window, I can't figure out if there is an error in the future output without autoscroll. Must I use ':cnext' in vim repeatly to check while I am editing or navigating the source code ? If there is an autoscroll feature in quickfix window (or using ':cbottom' to simulate it), life will be much easier: - While I am editing/navigating, I find job succeeded I will do nothing except continue editing. - While I am editing/navigating, I find job failed, I will stop editing and then check the quickfix window. Checking errors in quickfix window is unnecessary in the first condition if I can easily figure out it succeeded, most of the time, editing will not be interrupted, I can continue edit-compile-edit cycle rapidly. It is only necessary to stop and check the quickfix if I find it failed. skywind3...@163.com From: Christian Brabandt Date: 2016-06-09 04:33 To: vim_dev Subject: Re:
Re: Any way to scroll quickfix window automatically for long-time-running jobs ?
":cbottom" seems more adaptive than auto scroll It can be much easier for me if ":cbottom" could be added. >From my iPhone 发自我的 iPhone > 在 2016年6月9日，03:31，Bram Moolenaar 写道： > > > skywind3000 wrote: > >> It may be distracting the grep workflow. But how about building jobs ? It is >> completely different from grep: >> 1. the output of building jobs contains not only error location, but also >> building progress (which file is being compiled now). >> 2. The most important output for a building job is the last 1 or 3 lines, >> which indicate the building result: success or failed . >> 3. the output of building jobs contains warnings too, which I can simply >> ignore . >> >> So, people always care about the building result at first, if building >> job succeeded, there is no need to rewind >> the output text to the head. That's the main difference from grep to >> build, especially async build. >> >> People care about building progress too, they just need to read the >> latest output of gnumake, and get known >> how many files are there to be compiled. In this circumstance, there >> is also no need to rewind the quickfix window. >> >> Getting the job output autoscroll is a basic feature for many editors, >> just like: >> - Gedit's output window has autoscroll feature. >> - EditPlus/UltraEdit/NotePad++'s output window has autoscroll feature. >> - Eclipse/Visual Studio's output window has autoscroll feature. >> . >> >> It is better to provide user an option to get quickfix autoscroll >> rather than force them using quickfix as an old >> synchronizing location and force them treating the complex building >> jobs as a simply grep . > > If you are added lines to the quickfix list one by one, it's not too > difficult to also have a command to scroll the quickfix window. > > How about adding the ":cbottom" command: if the quickfix window is > visible it will scroll to make the last line displayed. > > A separate command also allows for some optimizations, e.g. only scroll > when an error was detected. > > -- > hundred-and-one symptoms of being an internet addict: > 72. Somebody at IRC just mentioned a way to obtain full motion video without >a PC using a wireless protocol called NTSC, you wonder how you never >heard about it > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: Any way to scroll quickfix window automatically for long-time-running jobs ?
It may be distracting the grep workflow. But how about building jobs ? It is
completely different from grep:
1. the output of building jobs contains not only error location, but also
building progress (which file is being compiled now).
2. The most important output for a building job is the last 1 or 3 lines, which
indicate the building result: success or failed .
3. the output of building jobs contains warnings too, which I can simply ignore
.
So, people always care about the building result at first, if building job
succeeded, there is no need to rewind
the output text to the head. That's the main difference from grep to build,
especially async build.
People care about building progress too, they just need to read the latest
output of gnumake, and get known
how many files are there to be compiled. In this circumstance, there is also no
need to rewind the quickfix window.
Getting the job output autoscroll is a basic feature for many editors, just
like:
- Gedit's output window has autoscroll feature.
- EditPlus/UltraEdit/NotePad++'s output window has autoscroll feature.
- Eclipse/Visual Studio's output window has autoscroll feature.
.
It is better to provide user an option to get quickfix autoscroll rather than
force them using quickfix as an old
synchronizing location and force them treating the complex building jobs as a
simply grep .
skywind3...@163.com
From: Yegappan Lakshmanan
Date: 2016-06-07 23:28
To: vim_dev
Subject: Re: Re: Any way to scroll quickfix window automatically for
long-time-running jobs ?
Hi,
On Mon, Jun 6, 2016 at 10:15 PM, skywind3...@163.com
wrote:
> You mean 'G' command ?
>
> I write a single script to get quickfix autoscroll, problem seems have been
> solved
> by 'normal G' with 'windo'.but the cursor seems a little strange:
> 1. blinks in a strange frequency: sometimes fast and sometimes slow
> 2. 'moving cursor to quickfix window and back' is noticeable, especially in
> gvim
> 3. sometimes cursor moves to ex-command area and stays 1 second and returns
> to the previous window
>
> version: 7.4.1902
>
> quickfix_autoscroll.vim
> --
> " scroll down
> function! Quickfix_Scroll()
> if getbufvar('%', '&buftype') == 'quickfix'
> normal G
> endif
> endfunc
>
> " find quickfix window and scroll to the bottom then return last window
> function! Quickfix_AutoScroll()
> let l:winnr = winnr()
> windo call Quickfix_Scroll()
> exec ''.l:winnr.'wincmd w'
> endfunc
>
> " timer callback: simulate a long-time-running job
> function! Callback(id)
> if !exists('s:index')
> let s:index = 0
> else
> let s:index = s:index + 1
> endif
> caddexpr "output ".s:index
> call Quickfix_AutoScroll()
> endfunc
>
> let s:index = 0
> let s:id = timer_start(1000, 'Callback', {'repeat':30})
>
> cexpr ""
> copen 5
> wincmd k
>
>
> Quickfix seems to be designed for the old synchronizing usage (make/grep)
>
> But after job/channel have been implemented, quickfix should be widely used
> to display realtime output of the background process .
>
You can use a normal buffer to redirect the output from the background
process instead of using quickfix. Depending on the user/use-case, it
may not be preferable to scroll the quickfix window when a new entry is
added to the quickfix list.
For example, let us say the redirected output is from grep (that takes a
long time to complete). The user is browsing through the matches while
grep is adding to the quickfix list in the background. If the quickfix
window is scrolled every time a new entry is added, then it will be
distracting the browsing work flow.
- Yegappan
>
> When background process takes a long time (eg. rebuilding vim source code),
> autoscroll
> enables me to watch the building progress and the output while I am editing
> / navigating the source files
> just like what I do in visual studio.
>
> Auto scroll can be simulated by using the script above, but is this a
> appropriate way ? (cursor problem, etc)
> Is it possible to do this in a more graceful/easier method ?
>
>
> skywind3...@163.com
>
>
> From: Bram Moolenaar
> Date: 2016-06-07 03:38
> To: skywind3...@163.com
> CC: vim-dev
> Subject: Re: Any way to scroll quickfix window automatically for
> long-time-running jobs ?
>
> skywind wrote:
>
>> Since redirecting the job output to quickfix, I need quickfix window
>> can scroll to the last line when a new text line added to quickfix.
>>
>> So I can always see the latest output of a long time running job in
>> realtime.
&g
Re: Re: Any way to scroll quickfix window automatically for long-time-running jobs ?
You mean 'G' command ?
I write a single script to get quickfix autoscroll, problem seems have been
solved
by 'normal G' with 'windo'.but the cursor seems a little strange:
1. blinks in a strange frequency: sometimes fast and sometimes slow
2. 'moving cursor to quickfix window and back' is noticeable, especially in gvim
3. sometimes cursor moves to ex-command area and stays 1 second and returns to
the previous window
version: 7.4.1902
quickfix_autoscroll.vim
--
" scroll down
function! Quickfix_Scroll()
if getbufvar('%', '&buftype') == 'quickfix'
normal G
endif
endfunc
" find quickfix window and scroll to the bottom then return last window
function! Quickfix_AutoScroll()
let l:winnr = winnr()
windo call Quickfix_Scroll()
exec ''.l:winnr.'wincmd w'
endfunc
" timer callback: simulate a long-time-running job
function! Callback(id)
if !exists('s:index')
let s:index = 0
else
let s:index = s:index + 1
endif
caddexpr "output ".s:index
call Quickfix_AutoScroll()
endfunc
let s:index = 0
let s:id = timer_start(1000, 'Callback', {'repeat':30})
cexpr ""
copen 5
wincmd k
Quickfix seems to be designed for the old synchronizing usage (make/grep)
But after job/channel have been implemented, quickfix should be widely used to
display
realtime output of the background process .
When background process takes a long time (eg. rebuilding vim source code),
autoscroll
enables me to watch the building progress and the output while I am editing /
navigating the source files
just like what I do in visual studio.
Auto scroll can be simulated by using the script above, but is this a
appropriate way ? (cursor problem, etc)
Is it possible to do this in a more graceful/easier method ?
skywind3...@163.com
From: Bram Moolenaar
Date: 2016-06-07 03:38
To: skywind3...@163.com
CC: vim-dev
Subject: Re: Any way to scroll quickfix window automatically for
long-time-running jobs ?
skywind wrote:
> Since redirecting the job output to quickfix, I need quickfix window
> can scroll to the last line when a new text line added to quickfix.
>
> So I can always see the latest output of a long time running job in
> realtime.
>
> Previously I used `clast` after `caddexpr` in the job callback to
> scroll quickfix but it alway open the last error in the new tab.
>
> Is there a way I can just only scroll quickfix without open the last error ?
You can use
:copen
$
{jump back to original window}
Note that recent changes were made to avoid updating the screen each
time, because it was slow. These commands will make it slow again.
You could use a timer to postpone the scrolling or only update once in
so many times.
--
hundred-and-one symptoms of being an internet addict:
56. You leave the modem speaker on after connecting because you think it
sounds like the ocean wind...the perfect soundtrack for "surfing the net".
/// 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.
--
--
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.
Any way to scroll quickfix window automatically for long-time-running jobs ?
Since redirecting the job output to quickfix, I need quickfix window can scroll to the last line when a new text line added to quickfix. So I can always see the latest output of a long time running job in realtime. Previously I used `clast` after `caddexpr` in the job callback to scroll quickfix but it alway open the last error in the new tab. Is there a way I can just only scroll quickfix without open the last error ? skywind3...@163.com -- -- 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.
Win32-binary lost for the latest gvim (7.4.1842)
Win32-binary (7.4.1842) cannot be located in the gvim release: https://github.com/vim/vim-win32-installer/releases: only find x64 binary and pdb. win32 is very important for many people whose toolchains (python/lua) or os is 32-bit Will the maintainer of gvim give up 32 bit version ? skywind3...@163.com -- -- 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: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
I checked the windows task manager and found that it was really hanging. skywind3...@163.com From: Bram Moolenaar Date: 2016-05-20 00:25 To: skywind3...@163.com CC: vim-dev Subject: Re: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs) Skywind wrote: > >> 'close_cb' and 'exit_cb' will not be invoked if I stop the job by > >> job_stop(s:job_obj, 'int') in windows. > > > This is because on Windows we don't know the effect of sending 'int'. > > It basically sends a CTRL-C key. The process may do nothing with it. > > thanks for reply, but in windows child process has already been stopped by > 'int' signal, > but the following 'close_cb' or 'exit_cb' has never been invocated. > > Seems vim doesn't know the child process has already been exited in windows > and still "looking for messages on channels" > > here is my channel log: > > start log session > 16.528877 : Starting job: cmd.exe /C d:\acm\github\vim\tools\win32/vimmake.6 > 16.529539 on 0: Created channel > 16.597577 : looking for messages on channels > 16.800522 RECV on 0: '[0]: stdout > ' > 16.800562 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 16.925442 : looking for messages on channels > 17.748489 RECV on 0: '[1]: stderr > ' > 17.748529 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 17.793600 : looking for messages on channels > 18.727212 RECV on 0: '[2]: stdout > ' > 18.727251 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 18.753327 : looking for messages on channels > 19.745455 RECV on 0: '[3]: stderr > ' > 19.745493 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 19.781825 : looking for messages on channels > 20.753949 RECV on 0: '[4]: stdout > ' > 20.753980 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 20.818269 : looking for messages on channels > 21.751584 RECV on 0: '[5]: stderr > ' > 21.751617 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 21.865572 : looking for messages on channels > 22.731953 RECV on 0: '[6]: stdout > ' > 22.732024 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 22.850624 : looking for messages on channels > 23.772697 RECV on 0: '[7]: stderr > ' > 23.772735 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 23.889643 : looking for messages on channels > 24.785400 RECV on 0: '[8]: stdout > ' > 24.785437 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 24.851843 : looking for messages on channels > 25.058043 on 0: Stopping job with 'int' > 25.078212 RECV on 0: 'Traceback (most recent call last): > File "d:\acm\github\vim\tools\test.py", line 11, in > time.sleep(1) > KeyboardInterrupt > ' > 25.078232 : looking for messages on channels > 25.078273 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 25.089159 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 25.099039 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 25.104338 on 0: Invoking channel callback g:Vimmake_Build_OnCallback > 25.211838 RECV on 0: 'Terminate batch job (Y/N)? ' > 25.211873 : looking for messages on channels > > > that's all of the channel log, cannot find any 'close_cb' and 'exit_cb' in 10 > minutes after job stopped. Isn't that because the process is hanging in that Y/N prompt? How do you know the process finished and exited? -- Westheimer's Discovery: A couple of months in the laboratory can frequently save a couple of hours in the library. /// 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. -- -- 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: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
the source of vimmake.6.cmd:
---
@echo off
python d:\acm\github\vim\tools\test.py
---
and the source of test.py:
--
import sys
for i in xrange(30):
if i % 2 == 0:
sys.stdout.write('[%d]: stdout\n'%i)
sys.stdout.flush()
else:
sys.stderr.write('[%d]: stderr\n'%i)
sys.stderr.flush()
import time
time.sleep(1)
------
skywind3...@163.com
From: skywind3...@163.com
Date: 2016-05-19 22:11
To: Bram Moolenaar
CC: vim-dev
Subject: Re: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
>> 'close_cb' and 'exit_cb' will not be invoked if I stop the job by
>> job_stop(s:job_obj, 'int') in windows.
> This is because on Windows we don't know the effect of sending 'int'.
> It basically sends a CTRL-C key. The process may do nothing with it.
thanks for reply, but in windows child process has already been stopped by
'int' signal,
but the following 'close_cb' or 'exit_cb' has never been invocated.
Seems vim doesn't know the child process has already been exited in windows
and still "looking for messages on channels"
here is my channel log:
start log session
16.528877 : Starting job: cmd.exe /C d:\acm\github\vim\tools\win32/vimmake.6
16.529539 on 0: Created channel
16.597577 : looking for messages on channels
16.800522 RECV on 0: '[0]: stdout
'
16.800562 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
16.925442 : looking for messages on channels
17.748489 RECV on 0: '[1]: stderr
'
17.748529 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
17.793600 : looking for messages on channels
18.727212 RECV on 0: '[2]: stdout
'
18.727251 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
18.753327 : looking for messages on channels
19.745455 RECV on 0: '[3]: stderr
'
19.745493 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
19.781825 : looking for messages on channels
20.753949 RECV on 0: '[4]: stdout
'
20.753980 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
20.818269 : looking for messages on channels
21.751584 RECV on 0: '[5]: stderr
'
21.751617 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
21.865572 : looking for messages on channels
22.731953 RECV on 0: '[6]: stdout
'
22.732024 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
22.850624 : looking for messages on channels
23.772697 RECV on 0: '[7]: stderr
'
23.772735 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
23.889643 : looking for messages on channels
24.785400 RECV on 0: '[8]: stdout
'
24.785437 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
24.851843 : looking for messages on channels
25.058043 on 0: Stopping job with 'int'
25.078212 RECV on 0: 'Traceback (most recent call last):
File "d:\acm\github\vim\tools\test.py", line 11, in
time.sleep(1)
KeyboardInterrupt
'
25.078232 : looking for messages on channels
25.078273 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.089159 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.099039 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.104338 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.211838 RECV on 0: 'Terminate batch job (Y/N)? '
25.211873 : looking for messages on channels
that's all of the channel log, cannot find any 'close_cb' and 'exit_cb' in 10
minutes after job stopped.
skywind3...@163.com
From: Bram Moolenaar
Date: 2016-05-19 20:58
To: skywind3...@163.com
CC: vim-dev
Subject: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
Skywind wrote:
> -- BUG 1 -
> job_stop will not actually stop the process in windows unless I unlet the job
> variable
>
> step to reproduct (windows gvim 7.4.1832):
> 1. start a background python job (output a single line and sleep 1 second,
> repeat 30 times)
> 2. redirect stdout/stderr into quickfix window by 'callback'
> 3. call job_stop with 'term' or 'kill' and ** DO NOT unlet job object **
> 4. check job_status and it changed from 'run' to 'dead'
> 5. ERROR: but the job is still running, still output text to quickfix window
> 6. when it actually exit by it self (after repeat itself 30 times) 'close_cb'
> and 'exit_cb' were invoked
>
> and if I unlet job object after job_stop, everything seems okay, the job can
> actually be stopped
> but job object can not be unleted after job_stop, because sometimes child
> process will stop signal from
> being terminated (ignore TERM etc) in this circumstance, if I im
Re: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
>> 'close_cb' and 'exit_cb' will not be invoked if I stop the job by >> job_stop(s:job_obj, 'int') in windows. > This is because on Windows we don't know the effect of sending 'int'. > It basically sends a CTRL-C key. The process may do nothing with it. thanks for reply, but in windows child process has already been stopped by 'int' signal, but the following 'close_cb' or 'exit_cb' has never been invocated. Seems vim doesn't know the child process has already been exited in windows and still "looking for messages on channels" here is my channel log: start log session 16.528877 : Starting job: cmd.exe /C d:\acm\github\vim\tools\win32/vimmake.6 16.529539 on 0: Created channel 16.597577 : looking for messages on channels 16.800522 RECV on 0: '[0]: stdout ' 16.800562 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 16.925442 : looking for messages on channels 17.748489 RECV on 0: '[1]: stderr ' 17.748529 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 17.793600 : looking for messages on channels 18.727212 RECV on 0: '[2]: stdout ' 18.727251 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 18.753327 : looking for messages on channels 19.745455 RECV on 0: '[3]: stderr ' 19.745493 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 19.781825 : looking for messages on channels 20.753949 RECV on 0: '[4]: stdout ' 20.753980 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 20.818269 : looking for messages on channels 21.751584 RECV on 0: '[5]: stderr ' 21.751617 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 21.865572 : looking for messages on channels 22.731953 RECV on 0: '[6]: stdout ' 22.732024 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 22.850624 : looking for messages on channels 23.772697 RECV on 0: '[7]: stderr ' 23.772735 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 23.889643 : looking for messages on channels 24.785400 RECV on 0: '[8]: stdout ' 24.785437 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 24.851843 : looking for messages on channels 25.058043 on 0: Stopping job with 'int' 25.078212 RECV on 0: 'Traceback (most recent call last): File "d:\acm\github\vim\tools\test.py", line 11, in time.sleep(1) KeyboardInterrupt ' 25.078232 : looking for messages on channels 25.078273 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 25.089159 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 25.099039 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 25.104338 on 0: Invoking channel callback g:Vimmake_Build_OnCallback 25.211838 RECV on 0: 'Terminate batch job (Y/N)? ' 25.211873 : looking for messages on channels that's all of the channel log, cannot find any 'close_cb' and 'exit_cb' in 10 minutes after job stopped. skywind3...@163.com From: Bram Moolenaar Date: 2016-05-19 20:58 To: skywind3...@163.com CC: vim-dev Subject: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs) Skywind wrote: > -- BUG 1 - > job_stop will not actually stop the process in windows unless I unlet the job > variable > > step to reproduct (windows gvim 7.4.1832): > 1. start a background python job (output a single line and sleep 1 second, > repeat 30 times) > 2. redirect stdout/stderr into quickfix window by 'callback' > 3. call job_stop with 'term' or 'kill' and ** DO NOT unlet job object ** > 4. check job_status and it changed from 'run' to 'dead' > 5. ERROR: but the job is still running, still output text to quickfix window > 6. when it actually exit by it self (after repeat itself 30 times) 'close_cb' > and 'exit_cb' were invoked > > and if I unlet job object after job_stop, everything seems okay, the job can > actually be stopped > but job object can not be unleted after job_stop, because sometimes child > process will stop signal from > being terminated (ignore TERM etc) in this circumstance, if I immediately > unlet job object after > a no-effect job_stop calling my script will fail into an error environment. > > This is only in windows, in linux everything is fine, I can clean the job > object in exit_cb/close_cb as my wish. > and job_stop doesn't require a unlet in linux too. I'll put this in the todo list. It would be useful to have a channel log for this example. > -- BUG 2 - > 'close_cb' and 'exit_cb' will not be invoked if I stop the job by > job_stop(s:job_obj, 'int
job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
-- BUG 1 - job_stop will not actually stop the process in windows unless I unlet the job variable step to reproduct (windows gvim 7.4.1832): 1. start a background python job (output a single line and sleep 1 second, repeat 30 times) 2. redirect stdout/stderr into quickfix window by 'callback' 3. call job_stop with 'term' or 'kill' and ** DO NOT unlet job object ** 4. check job_status and it changed from 'run' to 'dead' 5. ERROR: but the job is still running, still output text to quickfix window 6. when it actually exit by it self (after repeat itself 30 times) 'close_cb' and 'exit_cb' were invoked and if I unlet job object after job_stop, everything seems okay, the job can actually be stopped but job object can not be unleted after job_stop, because sometimes child process will stop signal from being terminated (ignore TERM etc) in this circumstance, if I immediately unlet job object after a no-effect job_stop calling my script will fail into an error environment. This is only in windows, in linux everything is fine, I can clean the job object in exit_cb/close_cb as my wish. and job_stop doesn't require a unlet in linux too. -- BUG 2 - 'close_cb' and 'exit_cb' will not be invoked if I stop the job by job_stop(s:job_obj, 'int') in windows. if 'term', 'kill' were used to stop the child process (s:job_obj must be unlet after it due to bug 1), 'close_cb' and 'exit_cb' will be invoked correctly. But 'close_cb' and 'exit_cb' can be lost if 'term', 'kill' has been replaced to 'int'. These two bugs are ONLY in windows (gvim 7.4.1832), skywind3...@163.com -- -- 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.
The order issue of 'exit_cb' and 'close_cb' in job-options
Trying to make a async building system with +jobs in latest vim, I find sometimes 'exit_cb' in invoked after 'close_cb' but sometimes 'close_cb' is invoked after 'exit_cb': That's what I done in my plugin: 1. output text to quickfix window when 'callback' / 'out_cb' / 'err_cb' happen 2. output "(close)" to quickfix window when 'close_cb' happen, and flush all the text in channel to quickfix. 3. output "[Finished in xx seconds]" to quickfix when 'exit_cb' happen and clean my job state. Sometimes I get this in quickfix: hello.c:1: x -> from 'callback' hello.c:2: x -> from 'callback' hello.c:3: x -> from 'callback' hello.c:4: x -> from 'callback' (close) -> from 'close_cb' [Finished in 2 seconds] -> from 'exit_cb' but sometimes I get this: hello.c:1: x -> from 'callback' hello.c:2: x -> from 'callback' hello.c:3: x -> from 'callback' [Finished in 2 seconds] -> from 'exit_cb' hello.c:4: x -> from 'callback' (close) -> from 'close_cb' I just can't figure out which one will happened at last ? 'close_cb' or 'exit_cb' ? and which one should I rely to do the clean stuff ? If I reset my building state in 'close_cb' (reset variables and unlet job object and output 'finished') when 'exit_cb' comes after 'close_cb' the environment is already destroyed. And if I reset my building state in 'exit_cb' when 'close_cb' comes after 'exit_cb' the environment is already destroyed too. I have created a similar plugin for atom text editor ( https://atom.io/packages/atom-shell-commands ) with javascript by using a 'child_process' module in node.js. The "process exit callback" in always invoked after all pipe callbacks, so I can simply delete the child-process object and do the destruction things in "process exit callback" without worry about any other callbacks will come after that. Is this possible to guarantee that 'exit_cb' will alway be invoked after all other callbacks (close_cb/out_cb/err_cb etc) ? If so, it will be much easier for me to write my async building plugin for vim. skywind3...@163.com -- -- 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.
