1

So I am using flycheck for my C++ projects with this setup:

;; Require flycheck to be present
(require 'flycheck)
;; Force flycheck to always use c++11 support. We use
;; the clang language backend so this is set to clang
(add-hook 'c++-mode-hook
          (lambda () (setq flycheck-clang-language-standard "c++14")))
;; Turn flycheck on everywhere
(global-flycheck-mode)
;; Use flycheck-pyflakes for python. Seems to work a little better.
(require 'flycheck-pyflakes)

And integrate it into irony like so:

(eval-after-load 'flycheck
  '(add-hook 'flycheck-mode-hook #'flycheck-irony-setup))

Now when my irony setup is off and several includes cannot be found, flycheck will open a new buffer after a short delay and that buffer is full of error messages. That buffer then steals the focus. This is annoying and I wonder how I can get rid of that behavior without cancelling my irony experiments.

First of all, who is responsible in such a case? Flycheck or irony? Second, how does one debug such an issue?

I am using prelude and all packages are installed from melpa if that matters.

  • What checker are you using for the c++ buffer? The c++14 standard is for the c/c++-clang checker, the setup irony is adding the irony checker, is it compatible with that standard? – f-sasa Apr 29 at 11:50
1

I recently experienced the same problem while editing Haskell and Typescript code, so I don't think irony-mode is at fault here. According to the documentation, I understand this is an expected behavior :

By default Flycheck shows the error messages in the minibuffer or in a separate buffer if the minibuffer is too small to hold the whole error message but this behaviour is entirely customisable:

https://www.flycheck.org/en/latest/user/error-interaction.html#display-errors

This can be handled with the flycheck-display-errors-function. Flycheck provides two built-ins function to handle how the error messages will be displayed. They both use display-message-or-buffer internally, which pops a new buffer if the error message to display is too big. From there I see two possible solution :

  • Disable the display of error messages completely with (setq flycheck-display-errors-function nil), and rely on the error message list (C-! l) or the mouse tooltip if you use Emacs in GUI mode.

  • Provide a custom function to flycheck-display-errors-function. I'm not a lisper, but I cobbled one together based on the builtin flycheck-display-error-messages. Here it is, with the relevant Flycheck setting :

(defun flycheck-display-error-messages-truncated (errors)
  (when (and errors (flycheck-may-use-echo-area-p))
    (let ((messages (seq-map #'flycheck-error-format-message-and-id errors)))
      (message (string-join messages "\n\n") ;; here is the relevant modification
               flycheck-error-message-buffer)
      ;; We cannot rely on `display-message-or-buffer' returning the right
      ;; window. See URL `https://github.com/flycheck/flycheck/issues/1643'.
      (-when-let ((buf (get-buffer flycheck-error-message-buffer)))
        (with-current-buffer buf
          (unless (derived-mode-p 'flycheck-error-message-mode)
            (flycheck-error-message-mode)))))))

(use-package flycheck
  :ensure t
  :init (global-flycheck-mode)
  :config
  (setq flycheck-check-syntax-automatically '(save))
  (setq flycheck-display-errors-function #'flycheck-display-error-messages-truncated))

This works for me for now but again, this is a quick hack and might not handle well some corner cases. The message is only displayed in the echo area, and if I really want to see it in is entirety I'll switch to the error message list.

| improve this answer | |
0

It would be intersting if you can give us the « new buffer » content or at least its name. Without that, we can only do some basic guessing and it won't be very efficient.

To improve error output, you can try M-x toggle-debug-on-error which will open a specific buffer with an error stack trace if there is an error. It will help us to find the source of the problem.

However, my guess here, is that flycheck-irony-setup belongs to flycheck-irony, which may not be started in your config. I would try the following config in your case:

;; Require flycheck to be present
;; if you install flycheck with package, you don't need that line. See bellow why.
;; But it's not wrong to keep it either.
(require 'flycheck) 

(with-eval-after-load 'flycheck
  (require 'flycheck-irony)
  (add-hook 'flycheck-mode-hook #'flycheck-irony-setup)
  ;; Force flycheck to always use c++11 support. We use
  ;; the clang language backend so this is set to clang
  (setq flycheck-clang-language-standard "c++14")
  ;; Use flycheck-pyflakes for python. Seems to work a little better.
  (require 'flycheck-pyflakes))

;; Turn flycheck on everywhere
;; No need to explicitly require flycheck as the following function auto-load it.
(global-flycheck-mode)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.