Re: Flymake refactored

[joaotavora@gmail.com (João Távora)]

Mark Oteiza <mvoteiza@udel.edu> 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.)

João