unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Eshel Yaron <eshelshay.yaron@gmail.com>
Cc: emacs-devel@gnu.org,  Jan Wielemaker <jan@swi-prolog.org>
Subject: Re: [NonGNU ELPA] New package: sweep
Date: Tue, 27 Sep 2022 17:46:31 +0000	[thread overview]
Message-ID: <874jwsn214.fsf@posteo.net> (raw)
In-Reply-To: <m15yh8eq1d.fsf@esmac.lan> (Eshel Yaron's message of "Tue, 27 Sep 2022 19:32:46 +0300")

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.



  reply	other threads:[~2022-09-27 17:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 11:29 [NonGNU ELPA] New package: sweep Eshel Yaron
2022-09-26 19:32 ` Philip Kaludercic
2022-09-27 16:32   ` Eshel Yaron
2022-09-27 17:46     ` Philip Kaludercic [this message]
2022-09-28  6:46       ` Eshel Yaron
2022-09-28  7:27         ` Philip Kaludercic
2022-09-28 17:49           ` Juri Linkov
2022-09-28 18:41             ` Eli Zaretskii
2022-09-28 18:56             ` Philip Kaludercic
2022-09-30  2:38             ` Richard Stallman
2022-09-30  8:20             ` Stefan Kangas
2022-09-30  9:45               ` Robert Pluim
2022-09-29  2:59         ` Richard Stallman
2022-09-29 16:53           ` [NonGNU ELPA] New package: sweeprolog Eshel Yaron
2022-09-29 16:59             ` Philip Kaludercic
2022-10-01  2:01             ` Richard Stallman
2022-09-27 18:49     ` [NonGNU ELPA] New package: sweep Stefan Monnier
2022-09-28  7:15       ` Eshel Yaron
2022-09-29  3:02     ` Richard Stallman
2022-09-29  5:04       ` Eshel Yaron
2022-09-29  6:17       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2022-09-26 10:22 Eshel Yaron
2022-09-26 17:41 ` Stefan Monnier
2022-09-27 15:19   ` Eshel Yaron
2022-09-30  2:36     ` Richard Stallman
2022-09-27 16:17 ` Richard Stallman
2022-09-27 18:47   ` Juri Linkov
2022-09-28  5:40     ` Andrea G. Monaco
2022-09-30  2:36     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jwsn214.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=eshelshay.yaron@gmail.com \
    --cc=jan@swi-prolog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).