Any way to scroll quickfix window automatically for long-time-running jobs ?

[skywi...@163.com]

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 ?

---

skywi...@163.com

[Bram Moolenaar]

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 -- Br...@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 ///

[skywi...@163.com]

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 ? 

---

skywi...@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+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Yegappan Lakshmanan]

Hi,

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

[skywi...@163.com]

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 . 

---

skywi...@163.com

[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

[skywi...@163.com]

":cbottom" seems more adaptive than auto scroll

It can be much easier for me if ":cbottom" could be added.

From my iPhone



发自我的 iPhone

[Christian Brabandt]

Hi skywind3000!

On Do, 09 Jun 2016, skywi...@163.com 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

[Marius Gedminas]

On Wed, Jun 08, 2016 at 10:33:55PM +0200, Christian Brabandt wrote:
> Hi skywind3000!
>
> On Do, 09 Jun 2016, skywi...@163.com 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.

How about a compromise: any build/grep/etc. plugin that adds new lines
to the end of the quickfix should autoscroll if and only the bottom line
was already visible.

This way if the user switched to the quickfix window and started
studying the 1st error or whatnot, they won't be distracted by
autoscrolling. And if the user just wants to see how the build is
progressing, they don't need to do anything special.

Now implementation-wise maybe it's best to have a way for vimscript to
determine if the bottom quickfix row is visible or not, before adding
new lines, and then the script can call the suggested :cbottom depending
on the saved result.

Marius Gedminas
--
UNIX is user friendly. It's just selective about who its friends are.

[Bram Moolenaar]

This doesn't work if the window starts (almost) empty, then the last
line is always visible. And then you can't avoid the scrolling. Would
have to go to the window and scroll it down a bit, that's not nice.

--
hundred-and-one symptoms of being an internet addict:

78. You find yourself dialing IP numbers on the phone.

[skywi...@163.com]

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

---

skywi...@163.com

 

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 ?