bug-recutils
[Top][All Lists]
Advanced

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

Re: Flymake recfix linter


From: Antoine Kalmbach
Subject: Re: Flymake recfix linter
Date: Thu, 03 Dec 2020 10:34:07 +0200

Ivan Sokolov <ivan-p-sokolov@ya.ru> writes:

>> Did you intend for this package to be a part of rec-mode?  If so, then I
>> would just merge this into rec-mode.el, and not have a separate package
>> that you can enable, and just do the `add-hook' in the `rec-mode' major
>> mode function, enabling it automatically.  I would prefer to just have
>> rec-mode.el as the single package.  (Note: ob-rec.el should be folded
>> into rec-mode.el).
> Yes. Why do you want to merge all files into one? Are multifile packages
> realy that painful?


For features like these, there is no reason not to.  If one doesn't want
to enable Flymake for rec-mode files, one simply needs to not call
`(flymake-mode)' in their rec-mode hook.

The way rec-mode is going to implement support is just by doing

    (add-hook 'flymake-diagnostic-functions #'rec-mode-flymake-recfix nil t)

in the `rec-mode' major mode function.  To enable Flymake with rec-mode,
a user needs to

    (add-hook 'rec-mode-hook #'flymake-mode)

If the hook isn't added, nothing happens.  So Flymake isn't turned on
automatically, users need to enable them automatically.  This is the
same with many built-in minor modes (e.g. ElDoc, company), if your
package wants to implement support for those, you just register your
function implementing the functionality
(e.g. flymake-diagnostic-functions, eldoc-documentation-function, and so
on.

Basically, if you want to enable support for something built-in, just
implement it directly in the main package itself.  Things like Flymake
are not enabled by default, so having a separate function to enable the
package *support* for it feels a bit counterintuitive.  After all, major
modes contain support code for many features, like imenu, syntax
highlighting, completion, Xref, ElDoc; the design is to just implement
the support via hooks or variables automatically.

Multifile packages make sense when the package is really large (rec-mode
is not yet), and you have tons of functionality to split into many
files.  So if we were to incorporate your patch as a package, I would
just `require' it at the top of rec-mode.el and then register its
function in the major mode.

> As a hypothetical user, who exclusively uses Flycheck, I would prefer
> the Flymake checker to be a separate library.

I don't understand.  If you use Flycheck, why would the Flymake backend
need to be a separate package?  If you don't turn Flymake on for
rec-mode, it won't interfere if there would be a Flycheck backend for
rec-mode.

>> Since rec-mode is distributed via GNU ELPA, big changes like these
>> require copyright assignment to the FSF.  Have you done that?
> No, and to be honest, I am glad I don't have to go on this quest yet.
>

Ok.  If you ever change your mind, fill in the following (between the
-8<- ->8-) and mail to assign@gnu.org with your full name as the subject
line:

---------8<------------
[What is the name of the program or package you're contributing to?]

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]


[Which files have you changed so far, and which new files have you written
so far?]
-------->8--------------

(The program would be GNU Emacs.)

-- 
Antoine Kalmbach



reply via email to

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