emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flymake refactored


From: Mark Oteiza
Subject: Re: Flymake refactored
Date: Fri, 6 Oct 2017 17:22:39 -0400
User-agent: NeoMutt/20170912-97-b97206-dirty

On 06/10/17 at 05:04pm, João Távora wrote:
> Mark Oteiza <address@hidden> writes:
> 
> > - some way (global variable?) to disable checkers.  I for one never want
> >   checkdoc to run automatically
> 
> Are add/remove-hook enough?
> 
>     (add-hook 'emacs-lisp-mode
>        (lambda () (remove-hook 'flymake-diagnostic-functions
>                                'elisp-flymake-checkdoc t)))

It's enough, but it might be nicer to have a single place to blacklist
things:

  (setq flymake-diagnostic-blacklist '(elisp-flymake-checkdoc ...))

It somewhat begs the question whether checkers should be registered
buffer locally or instead put into the global value of
flymake-diagnostic-functions and written like

  (defun gcc-flymake (report-fn &rest _args)
    (when (or (derived-mode-p 'c-mode) (derived-mode-p 'c++-mode))
      (unless (executable-find gcc-program)
        (error "Cannot find a suitable gcc"))
      ...))

but perhaps there is a downside to this beyond possibly needlessly doing
a lot of derived-mode-p checks while running through the hook.

> > - fine control over when checks happen (again a global setting);
> >   for instance, on-the-fly can be troublesome if checking is expensive.
> >   flycheck uses a list: '(save idle-change new-line mode-enabled)
> 
> Global or per-checker? If global, you already have some:
> 
> * flymake-start-syntax-check-on-newline
> * flymake-no-changes-timeout (set to nil to disable automatic idle-checking)
> * flymake-start-syntax-check-on-find-file
> 
> The "on save" behaviour isn't very easy to configure yet.  The names
> aren't brilliant, they're inherited from old Flymake.

Oh ok, thanks.  I missed the latter two variables.

> > - popup a special buffer with all the error/warning/info listed
> 
> I really like that one too, and it seems easy enough to do, but we
> should also think about the the next-error thingy.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]