The window to be chosen for quickfix

150 views
Skip to first unread message

nekneknek...@gmail.com

unread,
Dec 1, 2014, 10:20:55 PM12/1/14
to vim...@googlegroups.com
Hi, I've encountered a weird behaviour of quickfix so let me ask a few questions.

When I open a quickfix window with :copen, the quickfix window is opened at the bottom right and the corresponding source code is opened at the just upper window. The source code window seems to be opened at the right most, even when I have vertically splitted windows!
For example, I vetically split the window with :vnew twice. I have three vertically splitted windows and the cursor at the left most window. I open the quickfix window with :copen. Then the quickfix window is opened at the most bottom right and the corresponding source code is opened at the right most window. I want it to be opened at the active window.
I actually asked at another place and I got an answer. Just open the quickfix with :leftabove copen. Then the current window is used and all things are happy.

The question is
1. Why the quickfix window is always opened at most right bottom? Why the corresponding code is opened at the right-most window? When vertically splitted, it's more reasonable to be opened at the current window, isn't it? Is this a bug or a documented behaviour?
2. Why does :leftabove fix the behaviour? Is this a reasonable solution? Is there any other answer?
3. Can you open a quickfix window with full width (just like :botright copen) while the corresponding code is opened at the active window? This is the most preferable behaviour that I want.

Thanks in advance.
Regards
itchyny

Marcin Szamotulski

unread,
Dec 3, 2014, 10:15:03 AM12/3/14
to vim...@googlegroups.com
Ad. 1) This is explicitly mentioned in the doc's just below the description of
:lwindow command.

Ad. 2) When you open quick fix window it is always docked at the bottom, that's
why `:lefta cope` will open it on the left but below.

I didn't understood what do you want to achieve in 3.

Best regards,
Marcin
signature.asc

Gary Johnson

unread,
Dec 3, 2014, 1:40:14 PM12/3/14
to vim...@googlegroups.com, Marcin Szamotulski
On 2014-12-02, Marcin Szamotulski wrote:
For 3, I think itchyny means the following.

The user is editing in the left window of a split display.

+-----------+-----------+
| active | |
| window | |
| | |
| | |
| | |
| | |
+-----------+-----------+

The user then executes :copen. The quickfix window should open at
the bottom and be full-width.

+-----------+-----------+
| | |
| | |
| | |
| | |
+-----------+-----------+
| quickfix window |
+-----------+-----------+

Further, hitting Enter on any line in the quickfix window should
open that target in the window that was active at the time the
:copen command was executed. In this case, that would be the left
window.

Regards,
Gary

Christian Brabandt

unread,
Dec 3, 2014, 1:52:49 PM12/3/14
to vim...@googlegroups.com, Marcin Szamotulski
Hi Gary!
I think :botright copen does this (at least it does here). I think,
there was a patch to fix this behaviour.

> Further, hitting Enter on any line in the quickfix window should
> open that target in the window that was active at the time the
> :copen command was executed. In this case, that would be the left
> window.

That is a personal annoyance of me as well. I do not know a fix for
this.

Best,
Christian
--
Mann, wir Schwatten müssen doch zusammenhalten!
-- Anthony Baffoe (nach gelber Karte zum Schiri)

Gary Johnson

unread,
Dec 3, 2014, 2:34:17 PM12/3/14
to vim...@googlegroups.com, Marcin Szamotulski
I have a fix for that. I had forgotten about it. I got the idea
from yssl's QFEnter.vim plugin,
http://vim.sourceforge.net/scripts/script.php?script_id=4778. I
thought that implementation was overly complicated for what I
needed, so I just extracted and simplified part of it. When jumping
to items from the quickfix window, this opens them in the previous
window instead of the window above the quickfix window.

nnoremap <buffer> <CR> :call QfEnter()<CR>

function! QfEnter()
let l:lnum = line('.')
wincmd p
exe 'cc' l:lnum
endfunction

I put that in ~/.vim/after/ftplugin/qf.vim. The map will therefor
apply only to the quickfix window.

Someone commented in another thread a while back that the quickfix
error number was not always the same as the quickfix window line
number, but that assumption has always worked for me.

Regards,
Gary

nekneknek...@gmail.com

unread,
Dec 3, 2014, 9:39:23 PM12/3/14
to vim...@googlegroups.com
Hi, thank you all for the posts.
(Sorry for not folding the original text. I'm very sorry.)


On Thursday, December 4, 2014 12:15:03 AM UTC+9, coot_. wrote:
> Ad. 1) This is explicitly mentioned in the doc's just below the description of
> :lwindow command.
>
> Ad. 2) When you open quick fix window it is always docked at the bottom, that's
> why `:lefta cope` will open it on the left but below.


Thank you Marcin. You're right, that section of help mentions the position of
the quickfix window. As to (2), I do not completely understood but thanks for
mention that the quickfix window is always docked at the bottom.


On Thursday, December 4, 2014 3:40:14 AM UTC+9, Gary Johnson wrote:
>
> For 3, I think itchyny means the following.
>
> The user is editing in the left window of a split display.
>
> +-----------+-----------+
> | active | |
> | window | |
> | | |
> | | |
> | | |
> | | |
> +-----------+-----------+
>
> The user then executes :copen. The quickfix window should open at
> the bottom and be full-width.
>
> +-----------+-----------+
> | | |
> | | |
> | | |
> | | |
> +-----------+-----------+
> | quickfix window |
> +-----------+-----------+
>
> Further, hitting Enter on any line in the quickfix window should
> open that target in the window that was active at the time the
> :copen command was executed. In this case, that would be the left
> window.
>

Yes! Gary, thank you so much for following up. That's exactly what I mean.
I should have explain with such pictures. I hope this behaviour will be fixed
in the upstream of the Vim source.


Regards,
itchyny

h_east

unread,
Dec 4, 2014, 3:17:50 AM12/4/14
to vim...@googlegroups.com
Hi itchyny,

2014/12/4(Thu) 11:39:23 UTC+9 nekneknek...@gmail.com:
(snip)
> On Thursday, December 4, 2014 3:40:14 AM UTC+9, Gary Johnson wrote:
> >
> > For 3, I think itchyny means the following.
> >
> > The user is editing in the left window of a split display.
> >
> > +-----------+-----------+
> > | active | |
> > | window | |
> > | | |
> > | | |
> > | | |
> > | | |
> > +-----------+-----------+
> >
> > The user then executes :copen. The quickfix window should open at
> > the bottom and be full-width.
> >
> > +-----------+-----------+
> > | | |
> > | | |
> > | | |
> > | | |
> > +-----------+-----------+
> > | quickfix window |
> > +-----------+-----------+
> >
> > Further, hitting Enter on any line in the quickfix window should
> > open that target in the window that was active at the time the
> > :copen command was executed. In this case, that would be the left
> > window.
> >
>
> Yes! Gary, thank you so much for following up. That's exactly what I mean.
> I should have explain with such pictures. I hope this behaviour will be fixed
> in the upstream of the Vim source.

How about this?
:copen|wincmd J


Best regards,
Hirohito Higashi (a.k.a h_east)

nekneknek...@gmail.com

unread,
Dec 4, 2014, 6:03:17 AM12/4/14
to vim...@googlegroups.com
Thanks for reply h_east. But after opening quickfix with `:copen | wincmd J`,
hitting enter opens the corresponding code at the right window. I expect
to be opened at the left window (which was active before opening the quickfix window).

Christian Brabandt

unread,
Dec 4, 2014, 1:58:33 PM12/4/14
to vim...@googlegroups.com
Hi Gary!

On Mi, 03 Dez 2014, Gary Johnson wrote:

> nnoremap <buffer> <CR> :call QfEnter()<CR>
>
> function! QfEnter()
> let l:lnum = line('.')
> wincmd p
> exe 'cc' l:lnum
> endfunction
>
> I put that in ~/.vim/after/ftplugin/qf.vim. The map will therefor
> apply only to the quickfix window.

Thanks for that.

>
> Someone commented in another thread a while back that the quickfix
> error number was not always the same as the quickfix window line
> number, but that assumption has always worked for me.

I suppose this could happen for multi-line errorlists? But I have never
used them, so it should be okay for me.

Best,
Christian
--
Gewalt ist die letzte Zuflucht des Unfähigen.
-- Isaac Asimov

Gary Johnson

unread,
Dec 4, 2014, 2:26:00 PM12/4/14
to vim...@googlegroups.com
On 2014-12-04, Christian Brabandt wrote:
> Hi Gary!
>
> On Mi, 03 Dez 2014, Gary Johnson wrote:
>
> > nnoremap <buffer> <CR> :call QfEnter()<CR>
> >
> > function! QfEnter()
> > let l:lnum = line('.')
> > wincmd p
> > exe 'cc' l:lnum
> > endfunction
> >
> > I put that in ~/.vim/after/ftplugin/qf.vim. The map will therefor
> > apply only to the quickfix window.
>
> Thanks for that.
>
> >
> > Someone commented in another thread a while back that the quickfix
> > error number was not always the same as the quickfix window line
> > number, but that assumption has always worked for me.
>
> I suppose this could happen for multi-line errorlists? But I have never
> used them, so it should be okay for me.

I don't know. I don't currently use a compiler that generates
multi-line errors.

I think it may be because I always put %-G%.%# at the end of
'errorformat' and 'grepformat' so that the number of errors reported
by :grep or :make always agrees with the number of lines in the
quickfix list.

Regards,
Gary

Ben Fritz

unread,
Dec 5, 2014, 10:11:40 AM12/5/14
to vim...@googlegroups.com
On Thursday, December 4, 2014 12:58:33 PM UTC-6, Christian Brabandt wrote:
> Hi Gary!
>
> On Mi, 03 Dez 2014, Gary Johnson wrote:
>
> > nnoremap <buffer> <CR> :call QfEnter()<CR>
> >
> > function! QfEnter()
> > let l:lnum = line('.')
> > wincmd p
> > exe 'cc' l:lnum
> > endfunction
> >
> > I put that in ~/.vim/after/ftplugin/qf.vim. The map will therefor
> > apply only to the quickfix window.
>
> Thanks for that.
>
> >
> > Someone commented in another thread a while back that the quickfix
> > error number was not always the same as the quickfix window line
> > number, but that assumption has always worked for me.
>
> I suppose this could happen for multi-line errorlists? But I have never
> used them, so it should be okay for me.
>


Unfortunately, I often have quickfix lists with "cruft" lines, from my gcc-based compiler. Probably the cause is actually my makefile echoing out each command that runs. Example:

|| gcc -c -O2 -fno-builtin -Wall -s -UVARIOUS_UNDEFINED_THINGS -DVARIOUS_DEFINED_THINGS -I./various/include/paths src/main.c -o src/main.o
|| src/main.c: In function `ProcessIO':
src/main.c|363 warning| unused variable `CurrentTime'
src/main.c|355 warning| unused variable `CurrentTimeInMs'
src/main.c|354 warning| unused variable `NextBroadcastTime'
|| src/main.c: In function `main':
src/main.c|1545 warning| implicit declaration of function `set_callback'
|| gcc -c -O2 -fno-builtin -Wall -s -UWIN_AGS -D__true_false_are_keywords -DM145 -UDEBUG -DWRAPPER_DEBUG_DISABLED -UCANNED_DATA -UTEST_STUB -M -I./various/include/paths src/main.c > src/main.d.tmp
|| sed -e 's|.*:|src/main.o:|' < src/main.d.tmp > src/main.d
|| sed -e 's/.*://' -e 's/\\$//' < src/main.d.tmp | \
|| sed -e 's/\(.\)$/\1:/' >> src/main.d
|| rm -f src/main.d.tmp

Only the lines not starting with "||" are actually error list positions.

I do have a ftplugin set up to add the error number of the cursor line to the statusline...I'll see if I can use that for a similar mapping and post the result.

Ben Fritz

unread,
Dec 5, 2014, 10:47:31 AM12/5/14
to vim...@googlegroups.com
Oops, forgot to clean up the second defines list. How embarrassing.

Anyway...I actually experimented, and for this error list, :1cc tries jumping to the first "cruft" line, :2cc to the 2nd, etc. So actually in this case, the line number DOES correspond to the error number.

If you use getloclist(0) or getqflist() then each item returned has a "valid" field; the cruft lines have valid set false, but they ARE in the error list. So I don't actually know when the error list entries don't correspond to the line numbers, if that is ever the case.

I'm putting that mapping in my vim config now, thanks a ton! I only modified it slightly to also work with the location list. Here is something I do when setting filetype to quickfix, to detect whether it's a location list or a quickfix list:

if &buftype=='quickfix'
if v:version >= 700
if !exists('s:processing')
let listbufnr = bufnr("%")
let numwindows = winnr('$')
let curwin = winnr()
let s:processing = 1
copen
call setbufvar(listbufnr, 'errorlist_type', (curwin == winnr() ? 'quickfix' : 'location'))
" close the quickfix list if it was closed when we began
if numwindows != winnr('$')
cclose
endif
" return to quickfix/location list
exe curwin 'wincmd w'

It works by using "copen" to jump to the quickfix list, and if the current window changed then we must have been in the location list before.

Now I can use this as the map function:

function! QfEnter()
let l:lnum = line('.')
if b:errorlist_type == 'location'
let l:cmd = 'll'
else
let l:cmd = 'cc'
endif
wincmd p
exe l:cmd l:lnum
endfunction

nekneknek...@gmail.com

unread,
Dec 5, 2014, 9:07:59 PM12/5/14
to vim...@googlegroups.com, msz...@gmail.com, gary...@spocom.com
> Regards,
> Gary

Thank you so much all and Gary's solution seems to be the best answer. Thank
you, Gary. Now I define some more mappings inside quickfix buffer so that I can
open the code as I like.

augroup vimrc-quickfix
autocmd!
autocmd FileType qf call s:quickfix_setting()
augroup END
function! s:quickfix_setting()
wincmd J
nnoremap <buffer><silent> <CR> :<C-u>call <SID>qfenter('wincmd p')<CR>
nnoremap <buffer><silent> <C-t> :<C-u>call <SID>qfenter('tabnew')<CR>
nnoremap <buffer><silent> <C-v> :<C-u>call <SID>qfenter('wincmd p <bar> vnew')<CR>
endfunction
function! s:qfenter(cmd)
let lnum = line('.')
silent! execute a:cmd
silent! execute 'cc' lnum
endfunction

Now I'm very happy with the behaviour. The quickfix window is opened with the full
width. And the code is opened at the place I hit :copen. I can open the code at
new tab or in a vertically splitted new window. Maybe my code will be better by
fixing the cc command to switching cc/ll as Ben suggested. Thank you for sharing
your configuration, Ben

Regards,
itchyny
Reply all
Reply to author
Forward
0 new messages