[NonGNU ELPA] New package: sweep

[NonGNU ELPA] New package: sweep

[Eshel Yaron]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

[posting again since the last message didn't seem to reach the list, sorry for the noise if you receive this message twice]


Hello emacs-devel,
Long time listener, first time caller :)


I would like to submit a new package to NonGNU ELPA, called "sweep":

sweep is SWI-Prolog Embedded in Emacs. Quoting from the manual[0]:

> sweep provides an interface for executing Prolog queries and consuming
> their results from Emacs Lisp.  sweep further builds on top of this
> interface and on top of the standard Emacs facilities to provide
> advanced features for developing SWI-Prolog programs in Emacs.

The aim of this package is to provide a fully integrated development
environment for SWI-Prolog[1] in GNU Emacs.  It does so by creating a
dynamic Emacs module that contains the SWI-Prolog runtime, which allows
us to leverage the SWI-Prolog analysis and introspection facilities
directly from Elisp.

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.

sweep is licensed under the BSD-2 license, similarly to the rest of
SWI-Prolog.  Its source code is available at
https://git.sr.ht/~eshel/sweep and at
https://github.com/SWI-Prolog/packages-sweep.

This project is still in active development, any comments or suggestions
will be appreciated!


I'm attaching below the proposed patch to nongnu.git:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-sweep-New-package.patch --]
[-- Type: text/x-patch, Size: 854 bytes --]

From 48c15e1354b7b49028f82369fddc458c40ade5ed Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@eshelyaron.com>
Date: Wed, 14 Sep 2022 23:26:20 +0300
Subject: [PATCH] * elpa-packages (sweep): New package

---
 elpa-packages | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 6ad5f44aee..51816e285c 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -567,6 +567,13 @@
   :lisp-dir "subed"
   :ignored-files "LICENSES/GPL-3.0-or-later.txt")
 
+ ("sweep"               :url "https://github.com/SWI-Prolog/packages-sweep"
+  :ignored-files ("LICENSE"
+                  "sweep.c"
+                  "sweep.pl"
+                  "CMakeLists.txt")
+  :doc "README.org")
+
  ("swift-mode"		:url "https://github.com/swift-emacs/swift-mode"
   :ignored-files ("COPYING" "scripts" "test" "Eldev" "Makefile"))
 
-- 
2.37.3


[-- Attachment #3: Type: text/plain, Size: 94 bytes --]



Thanks,
Eshel Yaron


[0] https://eshelyaron.com/sweep.html
[1] https://www.swi-prolog.org

Re: [NonGNU ELPA] New package: sweep

[Philip Kaludercic]

Eshel Yaron <eshelshay.yaron@gmail.com> writes:

> [posting again since the last message didn't seem to reach the list, sorry for the noise if you receive this message twice]
>
>
> Hello emacs-devel,
> Long time listener, first time caller :)
>
>
> I would like to submit a new package to NonGNU ELPA, called "sweep":

May I ask what the name is supposed to mean?

> sweep is SWI-Prolog Embedded in Emacs. Quoting from the manual[0]:
>
>> sweep provides an interface for executing Prolog queries and consuming
>> their results from Emacs Lisp.  sweep further builds on top of this
>> interface and on top of the standard Emacs facilities to provide
>> advanced features for developing SWI-Prolog programs in Emacs.
>
> The aim of this package is to provide a fully integrated development
> environment for SWI-Prolog[1] in GNU Emacs.  It does so by creating a
> dynamic Emacs module that contains the SWI-Prolog runtime, which allows
> us to leverage the SWI-Prolog analysis and introspection facilities
> directly from Elisp.

This sound very interesting!

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?

> 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?
Also, I am guessing this is the reason you want to add it to NonGNU ELPA
instead of GNU ELPA, right?

> sweep is licensed under the BSD-2 license, similarly to the rest of
> SWI-Prolog.  Its source code is available at
> https://git.sr.ht/~eshel/sweep and at
> https://github.com/SWI-Prolog/packages-sweep.

I see you've added Sourcehut as the "official" URL in the package
header, do you plan to use your mailing list
(https://lists.sr.ht/~eshel/dev) too?  If so, I recommend adding the
mailing list as the "maintainer" email address so that people can easily
send you a "public" message.

> This project is still in active development, any comments or suggestions
> will be appreciated!
>
> I'm attaching below the proposed patch to nongnu.git:
>
> From 48c15e1354b7b49028f82369fddc458c40ade5ed Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Wed, 14 Sep 2022 23:26:20 +0300
> Subject: [PATCH] * elpa-packages (sweep): New package
>
> ---
>  elpa-packages | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 6ad5f44aee..51816e285c 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -567,6 +567,13 @@
>    :lisp-dir "subed"
>    :ignored-files "LICENSES/GPL-3.0-or-later.txt")
>  
> + ("sweep"               :url "https://github.com/SWI-Prolog/packages-sweep"
> +  :ignored-files ("LICENSE"
> +                  "sweep.c"
> +                  "sweep.pl"
> +                  "CMakeLists.txt")
> +  :doc "README.org")
> +
>   ("swift-mode"		:url "https://github.com/swift-emacs/swift-mode"
>    :ignored-files ("COPYING" "scripts" "test" "Eldev" "Makefile"))

Re: [NonGNU ELPA] New package: sweep

[Eshel Yaron]

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".

> This sound very interesting!

Thank you!

> 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 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...

> Also, I am guessing this is the reason you want to add it to NonGNU ELPA
> instead of GNU ELPA, right?

Yes, as I would currently prefer not to require SWI-Prolog contributors
to assign copyrights in order to contribute to this project.

>> sweep is licensed under the BSD-2 license, similarly to the rest of
>> SWI-Prolog.  Its source code is available at
>> https://git.sr.ht/~eshel/sweep and at
>> https://github.com/SWI-Prolog/packages-sweep.
>
> I see you've added Sourcehut as the "official" URL in the package
> header, do you plan to use your mailing list
> (https://lists.sr.ht/~eshel/dev) too?  If so, I recommend adding the
> mailing list as the "maintainer" email address so that people can easily
> send you a "public" message.

Thanks, I'll do that!


Eshel

Re: [NonGNU ELPA] New package: sweep

[Philip Kaludercic]

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.

Re: [NonGNU ELPA] New package: sweep

[Stefan Monnier]

> Yes, as I would currently prefer not to require SWI-Prolog
> contributors to assign copyrights in order to contribute to
> this project.

The best/easiest time to get people to sign copyright paperwork is at the
earliest time.  The more you wait the harder it gets.


        Stefan

Re: [NonGNU ELPA] New package: sweep

[Eshel Yaron]

Philip Kaludercic <philipk@posteo.net> writes:

> 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.

I've given it some thought, and all in all I would like to keep the name
`sweep` for this project.  I do see however why this name may be
unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
are looking for some "cleaning" package...  As a possible solution, I'd
be happy to change the name of the Elisp package to `sweeprolog` while
still referring to the project as a whole as `sweep` (e.g. in the
manual).  Does that sounds alright?


>>> 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.

That makes sense, thanks.  I'll try deriving from `prolog-mode` and if
no unexpected issues come up I'll go with that.

> Is the error self-explanatory, in the sense that a user would be able to
> understand that SWI Prolog is outdated?

Currently it's a generic `file-missing` error, I'll improve on that.

> 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.

Yes, I've also taken notes from the `vterm` package, which seems to take
a rather ad-hoc approach (see e.g. `vterm-module-compile`).


Best,
Eshel

Re: [NonGNU ELPA] New package: sweep

[Eshel Yaron]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, as I would currently prefer not to require SWI-Prolog
>> contributors to assign copyrights in order to contribute to
>> this project.
>
> The best/easiest time to get people to sign copyright paperwork is at the
> earliest time.  The more you wait the harder it gets.

Of course, I see that.

Until the package stabilizes, I'll ask major contributors about the
possibility of assigning copyrights to the FSF, and if that works out
I'd be to happy to contribute this package to GNU ELPA.  For now though
my preference remains with the NonGNU archive for this project.


Thanks,
Eshel

Re: [NonGNU ELPA] New package: sweep

[Philip Kaludercic]

Eshel Yaron <eshelshay.yaron@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> 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.
>
> I've given it some thought, and all in all I would like to keep the name
> `sweep` for this project.  I do see however why this name may be
> unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
> are looking for some "cleaning" package...  As a possible solution, I'd
> be happy to change the name of the Elisp package to `sweeprolog` while
> still referring to the project as a whole as `sweep` (e.g. in the
> manual).  Does that sounds alright?

I think that would be nice, and there shouldn't be a need to rename the
entire project.

>>>> 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.
>
> That makes sense, thanks.  I'll try deriving from `prolog-mode` and if
> no unexpected issues come up I'll go with that.

Great!

>> Is the error self-explanatory, in the sense that a user would be able to
>> understand that SWI Prolog is outdated?
>
> Currently it's a generic `file-missing` error, I'll improve on that.

If you could detect that error and combine it with a version check of
the SWI Prolog installation, I think that you could generate a helpful
message.

>> 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.
>
> Yes, I've also taken notes from the `vterm` package, which seems to take
> a rather ad-hoc approach (see e.g. `vterm-module-compile`).

This ought to be addressed in a more general way at some point.

Re: [NonGNU ELPA] New package: sweep

[Juri Linkov]

>>> 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.
>>
>> I've given it some thought, and all in all I would like to keep the name
>> `sweep` for this project.  I do see however why this name may be
>> unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
>> are looking for some "cleaning" package...  As a possible solution, I'd
>> be happy to change the name of the Elisp package to `sweeprolog` while
>> still referring to the project as a whole as `sweep` (e.g. in the
>> manual).  Does that sounds alright?
>
> I think that would be nice, and there shouldn't be a need to rename the
> entire project.

I wonder where this requirement to put all tags in the package name comes from?
While looking at the long list of package names, it's hard to find a package
whose name immediately hints at what it does.  This is a non-problem
that is solved in all package managers by using tags and full-text search.
And indeed list-package allows both ways, e.g. when someone is interested
in Prolog, then it's easy to type '/ k' (package-menu-filter-by-keyword).
Or try to use '/ d erlang RET' (package-menu-filter-by-description)
and see that almost no package has it in the package name,
yet these packages can be easily found:

 auto-complete-distel    melpa  Erlang/distel completion backend for auto-complete-mode
 company-distel          melpa  Erlang/distel completion backend for company-mode
 company-erlang          melpa  company backend based on ivy-erlang-complete
 distel-completion-lib   melpa  Completion library for Erlang/Distel
 edts                    melpa  Erlang Development Tool Suite
 erlang                  melpa  Erlang major mode
 erlstack-mode           melpa  Minor mode for analysing Erlang stacktraces
 ivy-erlang-complete     melpa  Erlang context sensitive completion at point using ivy
 lfe-mode                melpa  Lisp Flavoured Erlang mode

Re: [NonGNU ELPA] New package: sweep

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eshel Yaron <eshelshay.yaron@gmail.com>,  emacs-devel@gnu.org,  Jan
>  Wielemaker <jan@swi-prolog.org>
> Date: Wed, 28 Sep 2022 20:49:10 +0300
> 
> I wonder where this requirement to put all tags in the package name comes from?

Your examples are all from MELPA.  Why not take a few examples from
Emacs?

Re: [NonGNU ELPA] New package: sweep

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>>> 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.
>>>
>>> I've given it some thought, and all in all I would like to keep the name
>>> `sweep` for this project.  I do see however why this name may be
>>> unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
>>> are looking for some "cleaning" package...  As a possible solution, I'd
>>> be happy to change the name of the Elisp package to `sweeprolog` while
>>> still referring to the project as a whole as `sweep` (e.g. in the
>>> manual).  Does that sounds alright?
>>
>> I think that would be nice, and there shouldn't be a need to rename the
>> entire project.
>
> I wonder where this requirement to put all tags in the package name comes from?
> While looking at the long list of package names, it's hard to find a package
> whose name immediately hints at what it does.  This is a non-problem
> that is solved in all package managers by using tags and full-text search.
> And indeed list-package allows both ways, e.g. when someone is interested
> in Prolog, then it's easy to type '/ k' (package-menu-filter-by-keyword).
> Or try to use '/ d erlang RET' (package-menu-filter-by-description)
> and see that almost no package has it in the package name,
> yet these packages can be easily found:
>
>  auto-complete-distel    melpa  Erlang/distel completion backend for auto-complete-mode
>  company-distel          melpa  Erlang/distel completion backend for company-mode
>  company-erlang          melpa  company backend based on ivy-erlang-complete
>  distel-completion-lib   melpa  Completion library for Erlang/Distel
>  edts                    melpa  Erlang Development Tool Suite
>  erlang                  melpa  Erlang major mode
>  erlstack-mode           melpa  Minor mode for analysing Erlang stacktraces
>  ivy-erlang-complete     melpa  Erlang context sensitive completion at point using ivy
>  lfe-mode                melpa  Lisp Flavoured Erlang mode

The package list does help, but having a name that can be understood on
its own seems like a good thing.  There is no reason to make package
discovery more difficult.

Tough I might be a bit extreme on this topic.  E.g. I remember when
starting out with *nix, not wanting to use grep when searching for a
program to filter a file, just because of the name.

Re: [NonGNU ELPA] New package: sweep

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I've given it some thought, and all in all I would like to keep the name
  > `sweep` for this project.  I do see however why this name may be
  > unhelpful for Emacs users who are not familiar with SWI-Prolog, or who
  > are looking for some "cleaning" package...  As a possible solution, I'd
  > be happy to change the name of the Elisp package to `sweeprolog` while
  > still referring to the project as a whole as `sweep` (e.g. in the
  > manual).  Does that sounds alright?

That would be a distinct improvement.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [NonGNU ELPA] New package: sweep

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

That makes sense.  But I think there is something I don't undersand.
Some of what you said hints that SWEEP has other parts that don't run
in Emacs.  Is that true?  If so, what do they do?

  > 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...

This may try to answer that question, but it takes various things
about SWI-Prolog for granted, which naturally I don't know.

What in the world is "the dynamic module"?  What language is it
written in?  What does it do?  What relation does it have with SWEEP?
What relation does it have with Emacs?

And what does this have to do with copyright assignments for Emacs
Lisp code?

  > > Also, I am guessing this is the reason you want to add it to NonGNU ELPA
  > > instead of GNU ELPA, right?

  > Yes, as I would currently prefer not to require SWI-Prolog contributors
  > to assign copyrights in order to contribute to this project.

When people want to contribute to Emacs, we don't know or ask whether
they are SWI-Prolog contributors or not.  Indeed, it isn't pertinent.
We follow our practices.

If you want to contribute to SWI-Prolog, you should follow the
SWI-Prolog practices.  If you want to contribute to Emacs, you should
follow the Emacs practices.  That way, everything is clear, and each
project is autonomous.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [NonGNU ELPA] New package: sweep

[Eshel Yaron]

Richard Stallman <rms@gnu.org> writes:

>   > 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.
>
> That makes sense.  But I think there is something I don't undersand.
> Some of what you said hints that SWEEP has other parts that don't run
> in Emacs.  Is that true?  If so, what do they do?

No, sweep runs strictly inside Emacs, in the same OS process.  It loads
the SWI-Prolog system into Emacs, so with sweep Emacs is able to
directly execute Prolog code (through an Elisp interface, see
https://eshelyaron.com/sweep.html#querying-prolog).

> What in the world is "the dynamic module"?  What language is it
> written in?  What does it do?  What relation does it have with SWEEP?
> What relation does it have with Emacs?

It is the same dynamic Emacs module I mentioned in my original message:

"The aim of this package is to provide a fully integrated development
environment for SWI-Prolog in GNU Emacs.  It does so by creating a
dynamic Emacs module that contains the SWI-Prolog runtime..."

It's a shared object written in C, also see (info "(Elisp) Dynamic Modules").

>   > Yes, as I would currently prefer not to require SWI-Prolog contributors
>   > to assign copyrights in order to contribute to this project.
>
> When people want to contribute to Emacs, we don't know or ask whether
> they are SWI-Prolog contributors or not.  Indeed, it isn't pertinent.
> We follow our practices.

Yes, but sweep is a development environment for SWI-Prolog, and people
may use it and want to improve it even if they haven't otherwise used
Emacs at all.

> If you want to contribute to SWI-Prolog, you should follow the
> SWI-Prolog practices.  If you want to contribute to Emacs, you should
> follow the Emacs practices.  That way, everything is clear, and each
> project is autonomous.

I think I agree, but I'm not sure what you're referring to here.


Regards,
Eshel

Re: [NonGNU ELPA] New package: sweep

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, emacs-devel@gnu.org, jan@swi-prolog.org
> Date: Wed, 28 Sep 2022 23:02:10 -0400
> 
>   > 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...
> 
> This may try to answer that question, but it takes various things
> about SWI-Prolog for granted, which naturally I don't know.
> 
> What in the world is "the dynamic module"?

Since Emacs 25, Emacs supports loading of modules that extend Emacs
Lisp with additional primitives.  Those modules are shared libraries,
and can be written in any language that is capable of producing shared
libraries.  Loading of such modules by Emacs is subject to checking
the plugin_is_GPL_compatible symbol in the library about to be loaded.

[NonGNU ELPA] New package: sweeprolog

[Eshel Yaron]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]


Following the suggestions on this thread, I've renamed the Elisp package
from `sweep` to `sweeprolog`.

I'm attaching the updated patch to nongnu.git below:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2-0001-elpa-packages-sweeprolog-New-package.patch --]
[-- Type: text/x-patch, Size: 904 bytes --]

From d651ea5d3c4a606b548c3ae498cbfb86edaea779 Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@eshelyaron.com>
Date: Wed, 14 Sep 2022 23:26:20 +0300
Subject: [PATCH v2] * elpa-packages (sweeprolog): New package

---
 elpa-packages | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 6ad5f44aee..5ff9689965 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -567,6 +567,14 @@
   :lisp-dir "subed"
   :ignored-files "LICENSES/GPL-3.0-or-later.txt")
 
+ ("sweeprolog"          :url "https://github.com/SWI-Prolog/packages-sweep"
+  :ignored-files ("LICENSE"
+                  "sweep.c"
+                  "sweep.pl"
+                  "sweeprolog-tests.el"
+                  "CMakeLists.txt")
+  :doc "README.org")
+
  ("swift-mode"		:url "https://github.com/swift-emacs/swift-mode"
   :ignored-files ("COPYING" "scripts" "test" "Eldev" "Makefile"))
 
-- 
2.37.3


[-- Attachment #3: Type: text/plain, Size: 16 bytes --]



Thanks,
Eshel

Re: [NonGNU ELPA] New package: sweeprolog

[Philip Kaludercic]

Eshel Yaron <eshelshay.yaron@gmail.com> writes:

> Following the suggestions on this thread, I've renamed the Elisp package
> from `sweep` to `sweeprolog`.
>
> I'm attaching the updated patch to nongnu.git below:

Looks good, I'd apply it later today if there are no objections.

> From d651ea5d3c4a606b548c3ae498cbfb86edaea779 Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me@eshelyaron.com>
> Date: Wed, 14 Sep 2022 23:26:20 +0300
> Subject: [PATCH v2] * elpa-packages (sweeprolog): New package
>
> ---
>  elpa-packages | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 6ad5f44aee..5ff9689965 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -567,6 +567,14 @@
>    :lisp-dir "subed"
>    :ignored-files "LICENSES/GPL-3.0-or-later.txt")
>  
> + ("sweeprolog"          :url "https://github.com/SWI-Prolog/packages-sweep"
> +  :ignored-files ("LICENSE"
> +                  "sweep.c"
> +                  "sweep.pl"
> +                  "sweeprolog-tests.el"
> +                  "CMakeLists.txt")
> +  :doc "README.org")
> +
>   ("swift-mode"		:url "https://github.com/swift-emacs/swift-mode"
>    :ignored-files ("COPYING" "scripts" "test" "Eldev" "Makefile"))

Re: [NonGNU ELPA] New package: sweep

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I wonder where this requirement to put all tags in the package name comes from?

I said it would be better to give this package a name that would
clearly indicate its purpose.  You seem to be arguing against a very
specific requirement (what exactly is a "tag" in this context?).
Has that been proposed?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [NonGNU ELPA] New package: sweep

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> And indeed list-package allows both ways, e.g. when someone is interested
> in Prolog, then it's easy to type '/ k' (package-menu-filter-by-keyword).
> Or try to use '/ d erlang RET' (package-menu-filter-by-description)

We also have `package-menu-filter-by-name-or-description' (`/ N').

I wish we also had `package-menu-filter-by-name-keyword-description',
perhaps with a shorter name.

Re: [NonGNU ELPA] New package: sweep

[Robert Pluim]

>>>>> On Fri, 30 Sep 2022 01:20:05 -0700, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Juri Linkov <juri@linkov.net> writes:
    >> And indeed list-package allows both ways, e.g. when someone is interested
    >> in Prolog, then it's easy to type '/ k' (package-menu-filter-by-keyword).
    >> Or try to use '/ d erlang RET' (package-menu-filter-by-description)

    Stefan> We also have `package-menu-filter-by-name-or-description' (`/ N').

    Stefan> I wish we also had `package-menu-filter-by-name-keyword-description',
    Stefan> perhaps with a shorter name.

Isnʼt that just /N followed by /k?

Robert
-- 

Re: [NonGNU ELPA] New package: sweeprolog

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Following the suggestions on this thread, I've renamed the Elisp package
  > from `sweep` to `sweeprolog`.

Thank you.  You preserved the joke, and we gained a discoverable package.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)