3

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.

choeger
  • 191
  • 2
  • 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? – Fermin MF Apr 29 '20 at 11:50

2 Answers2

4

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.

user6234673
  • 41
  • 1
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)
Étienne
  • 93
  • 5