[NonGNU ELPA] New package: sweep

[NonGNU ELPA] New package: sweep

[Eshel Yaron]

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


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: 93 bytes --]



Thanks,
Eshel Yaron


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

Re: [NonGNU ELPA] New package: sweep

[Stefan Monnier]

Hi,

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

According to `git log` you're basically the sole author of this package
(beside a few contributions from James Cash which are small enough not
to be a problem).  Would you be willing to sign the copyright paperwork
that would allow us to add the package to GNU ELPA instead?
That would be even better.

If that's OK with you, then please fill the form below and email it as
instructed to the FSF so they can send you the relevant paperwork.
Thanks,


        Stefan


Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[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?]

Re: [NonGNU ELPA] New package: sweep

[Eshel Yaron]

Hello,

>> I would like to submit a new package to NonGNU ELPA, called "sweep":
>
> According to `git log` you're basically the sole author of this package
> (beside a few contributions from James Cash which are small enough not
> to be a problem).  Would you be willing to sign the copyright paperwork
> that would allow us to add the package to GNU ELPA instead?
> That would be even better.

Thanks for looking into it.  Its true that I've authored most of this
package up to this point, but this project is still in its early days
and I hope that going forward it will receive contributions from the
(SWI-)Prolog community (including more help from James :) as you noted).

For that reason I would prefer to target NonGNU ELPA, at least for the
time being.  


Regards,
Eshel

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

  > Thanks for looking into it.  Its true that I've authored most of this
  > package up to this point, but this project is still in its early days
  > and I hope that going forward it will receive contributions from the
  > (SWI-)Prolog community (including more help from James :) as you noted).

If the package is a success, it surely will get contributions from
some of them.

But I don't follow the rest -- it seems to skip over something:

  > For that reason I would prefer to target NonGNU ELPA, at least for the
  > time being.  

I don't see any reason for that preference.  Perhaps you left out a
crucial link between the two parts.





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

  > The aim of this package is to provide a fully integrated development
  > environment for SWI-Prolog[1] in GNU Emacs.

May I suggest using a name which is more descriptive than "Sweep"?
A person who doesn't already know that it has to do with SWI-Prolog
would never guess that.

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

[Juri Linkov]

>   > The aim of this package is to provide a fully integrated development
>   > environment for SWI-Prolog[1] in GNU Emacs.
>
> May I suggest using a name which is more descriptive than "Sweep"?
> A person who doesn't already know that it has to do with SWI-Prolog
> would never guess that.

Isn't "sweep" pronounced [swi:p]?

Re: [NonGNU ELPA] New package: sweep

[Andrea G. Monaco]

What about "Epilog"?  It's a pun on prolog and contains the E of emacs.
You could also make it a convoluted acronym.



Andrea Monaco

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

  > > May I suggest using a name which is more descriptive than "Sweep"?
  > > A person who doesn't already know that it has to do with SWI-Prolog
  > > would never guess that.

  > Isn't "sweep" pronounced [swi:p]?

Yes, but that sound would never have led me to think of "SWI" or "Prolog"
if I had not already been informed.

We call Emacs the "self-documenting" text editor.  But packages are
not effectively self-documenting if their names don't give you at
least a glimmer of an idea of whether they are worth your finding out
more about.

Calling this package "SWEEP", pure and simple, would be a form of
"inside joke".  If you use a "SWEEP" package with SWI-Prolog, you
would see the relationship of names, and might find it amusing.  For
everyone else, it would be a confusing disguise for the package.

The change we seem to have decided will make this SWI Prolog package
somewhat discoverable.  But we have many other package names that are
unhelpful, such as eww, or so clever that they mislead, such as
company.

It's fine for a package name to be clever, but the first priority in
choosing the name should be to make the package discoverable.

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

[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

[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

[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 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: 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

[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]

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

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