[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NonGNU ELPA] New package: sweep
From: |
Philip Kaludercic |
Subject: |
Re: [NonGNU ELPA] New package: sweep |
Date: |
Tue, 27 Sep 2022 17:46:31 +0000 |
Eshel Yaron <eshelshay.yaron@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> I would like to submit a new package to NonGNU ELPA, called "sweep":
>>
>> May I ask what the name is supposed to mean?
>
> Of course, but there's not a lot of depth to it, basically its derived
> from "SWI-P(rolog)", with the "I" replaced with two "e"s for
> "Emacs-Embedded". So a possible backronym may be
> "SW(I) Emacs-Embedded Prolog".
I agree with RMS (<E1odDGZ-0005aw-79@fencepost.gnu.org>) that it might
be nice to have a more indicative name, or at least something that
includes "Prolog". Mor eso because "sweep" makes me think of something
that cleans.
>> From briefly skimming through the code I see that you define a new major
>> that doesn't inherit from the default `prolog-mode'. Is there a reason
>> not to do so, or even implement sweep as a minor mode?
>
> I am not opposed to building on top of `prolog-mode`, but since
> `sweep-mode` has access to the actual SWI-Prolog runtime including
> notably its parser, we can (and do) provide better implementations for
> many of the features of `prolog-mode`, at the cost of targeting only
> SWI-Prolog where `prolog-mode` is more implementation agnostic.
> For example, `sweep-mode` defines an `indent-line-function` which takes
> into account the dynamic operator definitions that may occur in Prolog
> code.
>
> So currently I'm not sure what will be the benefits of inheriting
> from `prolog-mode`, but I'll gladly revisit it as missing features in
> `sweep-mode` pop up. Does that make sense?
The main advantage I see would be that anyone who uses `prolog-mode'
could inherit their customisations when using sweep. And it shouldn't
be an issue if sweep-mode overrides most of what `prolog-mode' defines.
>>> The dynamic module ("sweep-module") is distributed and built as part of
>>> the latest SWI-Prolog version, so the only files that need to be
>>> distributed via the ELPA package are the Elisp package sweep.el and the
>>> user manual.
>>
>> What happens if someone doesn't have a recent version of SWI Prolog?
>
> Currently you would get an error while loading `sweep.el` because
> `sweep--ensure-module` is executed on load which tries to find and load
> the dynamic module. This is probably not ideal. I wonder if it would
> be preferable to suggest fetching and building the dynamic module, or
> just to fail more gracefully...
Is the error self-explanatory, in the sense that a user would be able to
understand that SWI Prolog is outdated? There are some packages that
build software themselves (e.g. pdf-tools), but I don't think that issue
has ever been solved in a clean and robust way.
- [NonGNU ELPA] New package: sweep, Eshel Yaron, 2022/09/26
- Re: [NonGNU ELPA] New package: sweep, Philip Kaludercic, 2022/09/26
- Re: [NonGNU ELPA] New package: sweep, Eshel Yaron, 2022/09/27
- Re: [NonGNU ELPA] New package: sweep,
Philip Kaludercic <=
- Re: [NonGNU ELPA] New package: sweep, Eshel Yaron, 2022/09/28
- Re: [NonGNU ELPA] New package: sweep, Philip Kaludercic, 2022/09/28
- Re: [NonGNU ELPA] New package: sweep, Juri Linkov, 2022/09/28
- Re: [NonGNU ELPA] New package: sweep, Eli Zaretskii, 2022/09/28
- Re: [NonGNU ELPA] New package: sweep, Philip Kaludercic, 2022/09/28
- Re: [NonGNU ELPA] New package: sweep, Richard Stallman, 2022/09/29
- Re: [NonGNU ELPA] New package: sweep, Stefan Kangas, 2022/09/30
- Re: [NonGNU ELPA] New package: sweep, Robert Pluim, 2022/09/30
- Re: [NonGNU ELPA] New package: sweep, Richard Stallman, 2022/09/28
- [NonGNU ELPA] New package: sweeprolog, Eshel Yaron, 2022/09/29