Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QuickFix does not open after an error any more? #169

Closed
symbolix opened this issue Apr 10, 2016 · 9 comments
Closed

QuickFix does not open after an error any more? #169

symbolix opened this issue Apr 10, 2016 · 9 comments

Comments

@symbolix
Copy link

Hi,

I am editing a simple C++ file. And before, the quickfix would pop-up in case of errors after running :Make. Now I need to run Copen after running :Make to view the errors and I am loosing the focus of my code buffer. Has anything changed? Is there a way to fix this? Thanks.

@tpope
Copy link
Owner

tpope commented Apr 10, 2016

Nothing should have changed, no. Are you sure the error format is matching something?

@symbolix
Copy link
Author

I am sure nothing has changed on my side. Will investigate further. So the intended behaviour is that the quickfix window would open after a :Make command in case there are errors, and will stay silent in case the process is error free? Thanks.

@tpope
Copy link
Owner

tpope commented Apr 10, 2016

Yes, where error means "errorformat matched" or "nonzero exit status".

@symbolix
Copy link
Author

I can confirm now that Quickfix List will not open automatically on a :Make call after the errors are generated (that used to be the case).

I have started a minimal VIM session with vim-dispatch being the only installed plugin and no extra settings being applied.

set runtimepath+=/Users/me/repos/github.com/tpope/vim-dispatch/

My VIM version is: MacVim 7.4 (1-1553) I have heard that the VIM people have recently released a significant change that influenced the Quickfix List and the LocationList behaviours? It is known as patch 1592 maybe this is changing things?

However (After further testing):
I can confirm that theQuickfix List functionality is working as intended when MacVim is directly running in a tmux session and started with the mvim -v command (Non-GUI).

I can confirm that theQuickfix List functionality is working as intended when VIM is started directly from a tmux session by running the /Applications/MacVim.app/Contents/MacOS/Vim command (once again Non-GUI).

It seems like only the GUI versions is affected. In my case, launching MacVim from a tmux session, but as GUI application, with the mvim command. Once :Make is invoked, I can see the extra tmux buffer flashing, the process is done, the errors are there, but I need to run :Copen to bring up the Quickfix List.

@symbolix symbolix reopened this Apr 11, 2016
@symbolix
Copy link
Author

I have found out that when the GUI MacVim is started from a tmux session. The Quickfix List is NOT working as intended (it used to work just fine before). However, when started from a plain iterm2 tab, the Quickfix List is working as intended. Has something changed in the tmux adapter?

@symbolix
Copy link
Author

Ok, apologies for the messy reporting, I managed to track down the issue. So here are my findings:

  1. Inside tmux (no tmux panes) >> mvim (GUI MacVim) >> Quickfix List works
  2. Inside tmux (one extra tmux pane) >> mvim (GUI MacVim) >> Quickfix List NOT working
  3. Inside tmux (no tmux panes) >> mvim -v (Non-GUI MacVim) >> Quickfix List works
  4. Inside tmux (one extra tmux pane) >> mvim -v (Non-GUI MacVim) >> Quickfix List works
  5. Inside iterm2 (no iterm2 splits) >> mvim (GUI MacVim) >> Quickfix List works
  6. Inside iterm2 (with an iterm2 split) >> mvim (GUI MacVim) >> Quickfix List NOT working
  7. Inside iterm2 (no iterm2 splits) >> mvim -v (Non-GUI MacVim) >> Quickfix List works
  8. Inside iterm2 (with an iterm2 split) >> mvim -v (Non-GUI MacVim) >> Quickfix List works

So it seems like the GUI Vim is hit in cases where there are extra iTerm2 splits or tmux splits. The NON-GUI Vim works in all cases.

@symbolix
Copy link
Author

This is getting really confusing. I have restarted iTerm2 and tmux. Now Quickfix List works as intended in all of the cases with the :Make command. I cannot reproduce the issues described above any more. Maybe it has something to do with the number of open splits and tabs etc. I tried opening up quite a lot of iterm2 tabs and quite a lot of tmux windows with panes, every time the Quickfix List worked with the :Make command on both GUI and Non-GUI vim sessions.

One thing I can confirm though is, If I run MacVim (GUI) by running the mvim command in an iterm2 split, I get a new tab, called Shell and the Quickfix List will not pup-up after the :Make command and I can see the text !make (iterm/?) in the status. But when I run :Make for the second time. The Quickfix List pops-up.

Sorry about the confusion, there is certainly something fishy going on in there, but it is hard to reproduce.

@tpope
Copy link
Owner

tpope commented Apr 11, 2016

I can confirm that last one. Not surprised that there are issues with iTerm
splits.

On Mon, Apr 11, 2016 at 11:43 AM symbolix notifications@github.com wrote:

This is getting really confusing. I have restarted iTerm2 and tmux.
Now Quickfix List works as intended in all of the cases with the :Make
command. I cannot reproduce the issues described above any more. Maybe it
has something to do with the number of open splits and tabs etc. I tried
opening up quite a lot of iterm2 tabs and quite a lot of tmux windows with
panes, every time the Quickfix List worked with the :Make command on both
GUI and Non-GUI vim sessions.

One thing I can confirm though is, If I run MacVim (GUI) by running the
mvim command in an iterm2 split, I get a new tab, called Shell and the Quickfix
List will not pup-up after the :Make command and I can see the text !make
(iterm/?) in the status. But when I run :Make for the second time. The Quickfix
List pops-up.

Sorry about the confusion, there is certainly something fishy going on in
there, but it is hard to reproduce.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#169 (comment)

@symbolix
Copy link
Author

Thanks. I shall close this now. I will re-open or start a new one if I manage to reproduce the problem. One last thing to mention though, while I was stress-testing vim-dispatch I got a function error with an <SID> ... in there, and then an error about not being able to write a tmp file (all messages related to vim-dispatch). Unfortunately I lost that session, and I do not have further evidence. But I will post them here if I come across this issue again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants