[Top][All Lists]

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

Re: Flymake refactored

From: João Távora
Subject: Re: Flymake refactored
Date: Fri, 06 Oct 2017 23:03:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

Mark Oteiza <address@hidden> writes:

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

Yes, it's repeating what mode hooks are supposed to take care of.
Stefan and I discussed it during the initial review.  In the end he
convinced me, and I removed the derived-mode-p in elisp-mode.el

But I can understand the akwardness you are experiencing. It is because
you are forced to use hooks inside hooks.  

A global blacklist is less bizarre but still confusing if you just know
about flymake-diagnostic-functions.  What about taking advantage of the
fact that erroring backends disable themselves with this fun hack?

   (defun blacklist (&rest _args) (error "blacklisted"))
   (advice-add 'elisp-flymake-checkdoc :around 'blacklist)
   (advice-remove 'elisp-flymake-checkdoc 'blacklist) ; regret it

>> * 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.

I thought you were going to ask for per-backend values. In that
hypothetical case, then I guess these varaibles could also take on
functions of a single argument as values. The argument would be the
backend and the return value would be used. Kinda tricky (but not
impossible) for flymake-no-changes-timeout though (perhaps only
nil/non-nil should be allowed for that one.)


reply via email to

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