[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NonGNU ELPA] New package: flymake-guile
From: |
Distopico |
Subject: |
Re: [NonGNU ELPA] New package: flymake-guile |
Date: |
Fri, 01 Sep 2023 08:58:49 -0500 |
On 2023-09-01, Philip Kaludercic <philipk@posteo.net> wrote:
> Distopico <distopico@riseup.net> writes:
>
>> On 2023-08-31, Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>> Distopico <distopico@riseup.net> writes:
>>>
>>>> On 2023-08-31, Philip Kaludercic <philipk@posteo.net> wrote:
>>>>
>>>>> Distopico <distopico@riseup.net> writes:
>>>>>
>>>>>> Hi all!
>>>>>>
>>>>>> I'm the author of a new package `flymake-guile` and I
>>>>>> would like to include it in Nongnu ELPA.
>>>>>
>>>>> Just to be sure, you are sure you don't want to include your package in
>>>>> GNU ELPA?
>>>>>
>>>>>> Here the repo: https://framagit.org/flymake-backends/flymake-guile
>>>>>
>>>>> I am not familiar with the "flymake-quickdef" package, but it doesn't
>>>>> seem to be much shorter than just defining a regular flymake backend.
>>>>> As there have been some discussions wrt providing a kind of DSL for
>>>>> Flymake backends, I am not sure if adding flymake-quickdef would be that
>>>>> constructive at this point. Would you consider updating your package to
>>>>> not use the dependency? You can check out other flymake-... modes in
>>>>> GNU and NonGNU ELPA for inspiration.
>>>>>
>>>> Thank you for your feedback, For now I'm fine sending it to NonGNU ELPA,
>>>> and for now I would like to keep `flymake-quickdef`, I have plans to
>>>> write other backend and I don't wanna repeat the same validations and
>>>> code over and over, I'll switch to the DLS when it is implemented.
>>>
>>> FWIW it already exists in this form
>>> https://github.com/mohkale/flymake-collection.
>>>
>>> And just to make sure, you are certain you want to implement this on top
>>> of a DSL? I have to admit that I am really not a fan of the way that
>>> flymake-quickdef is implemented, but one redeeming feature appears to be
>>> that you could macroexpand it away, then clean the code up.
>>>
>>
>> flymake-collection use an adaptation of flymake-quickdef[1], that is
>> a macro similar to the quickdef one[2], could be use quickdef a blocker
>> to add the package on NonGNU ELPA?
>
> I am afraid I don't understand your question.
My Question is if remove flymake-quickdef as dependency is a requirement
to merge flymake-guile package into NonGNU ELPA or it's just a
recommendation?
signature.asc
Description: PGP signature
- Re: [NonGNU ELPA] New package: flymake-guile, Philip Kaludercic, 2023/09/01
- Re: [NonGNU ELPA] New package: flymake-guile, Dr. Arne Babenhauserheide, 2023/09/01
- Re: [NonGNU ELPA] New package: flymake-guile,
Distopico <=
- Re: [NonGNU ELPA] New package: flymake-guile, Philip Kaludercic, 2023/09/01
- Re: [NonGNU ELPA] New package: flymake-guile, Distopico, 2023/09/04
- Re: [NonGNU ELPA] New package: flymake-guile, Philip Kaludercic, 2023/09/05
- Re: [NonGNU ELPA] New package: flymake-guile, Distopico, 2023/09/05
- Re: [NonGNU ELPA] New package: flymake-guile, Philip Kaludercic, 2023/09/05
- Re: [NonGNU ELPA] New package: flymake-guile, Distopico, 2023/09/05