> 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. [email protected] From: Christian Brabandt Date: 2016-06-09 04:33 To: vim_dev Subject: Re: Any way to scroll quickfix window automatically for long-time-running jobs ? Hi skywind3000! On Do, 09 Jun 2016, [email protected] wrote: > ":cbottom" seems more adaptive than auto scroll 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. Mit freundlichen Grüßen Christian -- Es gibt viele Mittel gegen die Liebe, aber keins ist unfehlbar. -- François Duc de La Rochefoucauld -- -- 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 [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
