[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