[vim/vim] E36 from quickfix list (smaller than 3 lines) with noequalalways and buftype=nofile (#908)
Daniel Hahler
set buftype=nofile
set noequalalways
call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0, 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
copen
resize 1
% vim -u minimal.vim
Now going to the quickfix list (C-w j) and pressing Enter will result in "E36: Not enough room".
This happens because the "nofile" buffer will not be re-used to display the error, and when creating a new split apparently :1sp (or even :0sp?!) will be used.
I see the following issues here:
1. the "nofile" buffer's window could be used directly
2. in case a new split is needed, the height should not be based on the quickfix/location list, since that is typically small
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, .
Daniel Hahler
A similar issue: calling :help from a (quickfix) window with less than 3 lines will also result in E36.
However, when the quickfix window is big enough, the help window is opened, and will have more than just half of the lines from the small (quickfix) window.
Daniel Hahler
I think opening a new window from the quickfix/location list window should result in the same behavior regarding the height as with :help, and both should not trigger the E36 error.
Daniel Hahler
Some dirty workaround:
function! MyQuickfixCR() try call feedkeys("\<CR>", 'nx') catch /:E36:/ set equalalways call feedkeys("\<CR>", 'nx') set noequalalways endtry endfunction autocmd Filetype qf map <buffer> <cr> :call MyQuickfixCR()<cr>
But given how often plugins map <cr> already in quickfix windows, this would need to be enhanced to chain/call any already existing mappings (difficult when looking at what Supertab does in this regard).
And of course setting equalalways (and the new window) will trigger resizing of all (normal) windows..
Yegappan Lakshmanan
vim-dev ML
> set noequalalways
> call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
> copen
> resize 1
> % vim -u minimal.vim
>
> Now going to the quickfix list (C-w j) and pressing Enter will result in
> "E36: Not enough room". This happens because the "nofile" buffer will
> not be re-used to display the error,
>
windows/buffers with 'buftype' set to "nofile" will be skipped. Many plugins
set the 'buftype' to 'nofile' and use the buffer to display some content.
Reusing that window for showing a selected file will impact the plugin.
>
> be used.
>
- Yegappan
>
Christian Brabandt
LCD 47
> Hi,
>
> On Wed, Jul 6, 2016 at 2:18 PM, Daniel Hahler <vim-dev...@256bit.org>
> wrote:
> >
> > set buftype=nofile
> > set noequalalways
> > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
> 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
> > copen
> > resize 1
> > % vim -u minimal.vim
> >
> > Now going to the quickfix list (C-w j) and pressing Enter will
> > result in "E36: Not enough room". This happens because the "nofile"
> > buffer will not be re-used to display the error,
> >
>
> Yes. This is by design.
worked fine for 10+ years? Just wondering.
/lcd
Yegappan Lakshmanan
On Thu, Jul 7, 2016 at 1:09 AM, LCD 47 <lcd...@gmail.com> wrote:
> On 6 July 2016, Yegappan Lakshmanan <yega...@gmail.com> wrote:
>> Hi,
>>
>> On Wed, Jul 6, 2016 at 2:18 PM, Daniel Hahler <vim-dev...@256bit.org>
>> wrote:
>> >
>> > set buftype=nofile
>> > set noequalalways
>> > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
>> 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
>> > copen
>> > resize 1
>> > % vim -u minimal.vim
>> >
>> > Now going to the quickfix list (C-w j) and pressing Enter will
>> > result in "E36: Not enough room". This happens because the "nofile"
>> > buffer will not be re-used to display the error,
>> >
>>
>> Yes. This is by design.
>
> Any particular reason why your designs tend to break things that
> worked fine for 10+ years? Just wondering.
>
reproduce this behavior even in vim 7.0. The recent changes to quickfix
didn't change this behavior.
Can you describe the quickfix functionality that was broken/changed by
the recent changes.
- Yegappan
Daniel Hahler
What about making the opening from a qf/loclist window as smart as with :help?
And why should :help fail when opened from a window with less than 3 lines?
And if you would argue that this is the expected behavior with noequalalways, then it would be a bug that :help uses more space than a :sp does, no?
So please consider re-opening it.
—
You are receiving this because you commented.
Yegappan Lakshmanan
On Thu, Jul 7, 2016 at 7:31 AM, Yegappan Lakshmanan <yega...@gmail.com> wrote:
> Hi,
>
> On Thu, Jul 7, 2016 at 1:09 AM, LCD 47 <lcd...@gmail.com> wrote:
>> On 6 July 2016, Yegappan Lakshmanan <yega...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Wed, Jul 6, 2016 at 2:18 PM, Daniel Hahler <vim-dev...@256bit.org>
>>> wrote:
>>> >
>>> > set buftype=nofile
>>> > set noequalalways
>>> > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
>>> 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
>>> > copen
>>> > resize 1
>>> > % vim -u minimal.vim
>>> >
>>> > Now going to the quickfix list (C-w j) and pressing Enter will
>>> > result in "E36: Not enough room". This happens because the "nofile"
>>> > buffer will not be re-used to display the error,
>>> >
>>>
>>> Yes. This is by design.
>>
>> Any particular reason why your designs tend to break things that
>> worked fine for 10+ years? Just wondering.
>>
>
> This is the behavior of Vim for more than 10 years or so. I am able to
> reproduce this behavior even in vim 7.0. The recent changes to quickfix
> didn't change this behavior.
>
> Can you describe the quickfix functionality that was broken/changed by
>
BTW, the majority of the recent changes related to the quickfix/location list
feature are for adding unit tests. When I developed the location list feature
for Vim 7.0, majority of the quickfix features were not unit tested. The
recent changes addressed this and now around 85% of the quickfix and
location list code is under test.
Let us know if you see any of the recent changes break the previous
quickfix/location list functionality.
- Yegappan
LCD 47
It's still with us. _shrug_
/lcd
Christian Brabandt
> Not recent, but do you remember the problem introduced by 1640?
> It's still with us. _shrug_
crash that you reported some time ago or so about accessing invalid
memory when loading a quickfix item.
Best,
Christian
--
Wenn der Kernel keinen Treiber für das ATAPI-CDROM hat,
wie soll er dann dafür eine SCSI-Emulation machen?
Merke: erst denken, dann posten.
-- Felix von Leitner
LCD 47
> On Fr, 08 Jul 2016, LCD 47 wrote:
>
> > Not recent, but do you remember the problem introduced by 1640?
> > It's still with us. _shrug_
>
> I don't follow. That was a bugfix for a crash and I believe it fixed
> a crash that you reported some time ago or so about accessing invalid
> memory when loading a quickfix item.
crash I reported earlier, by making it illegal to set loclists from
autocmds.
As I explained at the time, that was the wrong fix, and it affected
a few existing plugins. I suggested a different approach, but by then
everybody was too tired of the discussion to try to consider what I was
saying. _shrug_
/lcd
Dominique Pellé
Everybody wants to help, but the problem is, nobody knows
how to reproduce the crash that you describe. Can you post a
script that makes Vim crash? Or can you try to reproduce it with
valgrind to have more information.
Regards
Dominique
LCD 47
for a (now well-understood) crash, not with the crash itself.
/lcd
Daniel Hahler
@chrisbra
Please consider re-opening the issue with regard to my comment above.
—
You are receiving this because you commented.
Christian Brabandt
I don't quite understand. There have been too many problems mentioned here. What exactly is your problem?
—
You are receiving this because you commented.
Daniel Hahler
@chrisbra
Basically the question above:
If you use noequalalways you cannot open entries from a quickfix list when it is smaller than 3 lines, and even it is 3 lines or more, it will only use 1 for the height of the new window then.
set buftype=nofile set noequalalways call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0, 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}]) copen resize 1
Run it with vim -Nu vimrc-e36.vim -c '2wincmd w' and press Enter: E36: Not enough room.
Then do a :3wincmd _ and press Enter again: you get a window but with the height of only 1 line.
I like to use noequalalways, because I do not like the automatic resizing.
While :help also fails from the quickfix window of height 1, it behaves sane when the qf height is 3.
So you are right: there are several issues, but it boils down to:
1. :help should work from a (qf) window with less than 3 lines
2. the quickfix opening should be as sensible as :help is (with 1. being fixed of course).
I think those issues are really related.
Should I separate them?
Besides preferring noequalalways, I also have autocommands that resize the location/quickfix lists to only display as many lines as possible, and that's why I often run into this issue - but in general only if the existing window (besides the qf list is of buftype=nofile, of course).
FWIW here is my current workaround:
function! MyQuickfixCR() let prev_map = "\<Plug>MyQuickfixCRPre" exe 'unmap <buffer> <cr>' try call feedkeys(prev_map, 'x') catch /:E36:/ echom "retry" set equalalways try call feedkeys(prev_map, 'x') finally set noequalalways endtry finally exe 'map <buffer> <cr> :call MyQuickfixCR()<cr>' endtry endfunction function! SetupMyQuickfixCR() let prev_map = maparg('<cr>', 'n') if !len(prev_map) let prev_map = "\<CR>" endif exe 'nmap <buffer> <Plug>MyQuickfixCRPre '.prev_map exe 'map <buffer> <cr> :call MyQuickfixCR()<cr>' endfunction call SetupMyQuickfixCR()
This handles existing mappings from e.g. Vader, and chains/wraps them.
—
You are receiving this because you commented.
Daniel Hahler
> > > set noequalalways
> > > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
> > 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
> > > copen
> > > resize 1
> > > % vim -u minimal.vim
> > >
> > > Now going to the quickfix list (C-w j) and pressing Enter will
> > > result in "E36: Not enough room". This happens because the "nofile"
> > > buffer will not be re-used to display the error,
> >
> > Yes. This is by design.
>
> Any particular reason why your designs tend to break things that
> worked fine for 10+ years? Just wondering.
Sorry, I have not looked into vim_dev since a while and followed this issue only on GitHub, where I've reported it.
1. apparently this is an issue since 10+ years already, and nobody cared enough to report it and/or make a test case for it. It's also worth to mention that 'equalalways' is the default, so I am already in a minority here.
I did not meant to blame it on recent patches, and that's probably also not "This is by design." meant.
I consider it just a bug: `:help` was made in some regard a bit smarter (but still fails from a too narrow window).
2. Why don't you/we use GitHub for replies to issues that have been reported there? I was a bit out of the loop regarding the discussion here, and if you do not like to reply on GitHub, it should be at least CC'ed there (what I've seen to some extend, but not the whole discussion; probably just top-level replies to the issue etc).
Cheers,
Daniel.
Christian Brabandt
On Mo, 26 Sep 2016, Daniel Hahler wrote:
> 2. Why don't you/we use GitHub for replies to issues that have been
> reported there? I was a bit out of the loop regarding the discussion
> here, and if you do not like to reply on GitHub, it should be at least
> CC'ed there (what I've seen to some extend, but not the whole
> discussion; probably just top-level replies to the issue etc).
If I get the issue here and I don't have a browser open (or I am reading
offline), I can answer here and the reply will get mirrored back to
github. Unfortunately, this depends on how you answer. If you reply back
to vim-dev, the answer can't magically get mirrored back to github. Also
it doesn't work well with attaching patches.
So this requires some discipline when answering.
¹ media break in English
Best,
Christian
--
Letzte Worte eines Sportschützen:
"Da klemmt doch was am Abzug."