NonGNU ELPA

NonGNU ELPA

[Stefan Monnier]

>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>> has been weeks since we discussed it and I have not heard that
>> he has moved forward on it.

I have a first cut up now.
The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
and the archive is currently at https://elpa.gnu.org/nongnu/


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-21 22:02]:
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

That is great! Big thank you.

How shall archive name be called in short? nongnu?

Re: NonGNU ELPA

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 21 Nov 2020 14:02:38 -0500
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>
> 
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Great news, thanks!

Re: NonGNU ELPA

[Amin Bandali]

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

Eli Zaretskii writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sat, 21 Nov 2020 14:02:38 -0500
>> Cc: Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>
>> 
>> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>> >> has been weeks since we discussed it and I have not heard that
>> >> he has moved forward on it.
>> 
>> I have a first cut up now.
>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
>> and the archive is currently at https://elpa.gnu.org/nongnu/
>
> Great news, thanks!
>

Great news indeed, many thanks!

Per discussion with rms, I will look into setting up elpa.nongnu.org for
use for NonGNU ELPA.  I believe that constitutes a better canonical
address for it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-21 22:02]:
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

I guess packages are unsigned and I hope they will become signed that
users can get feeling that packages do come from specific entity like
GNU project.

Following packages I propose for nonGNU ELPA:

- markdown-mode
  https://github.com/jrblevin/markdown-mode.git
  
- scad-mode
  https://raw.githubusercontent.com/openscad/openscad/8a905133a2f27e23db07bb424599a242c5d7176d/contrib/scad-mode.el

- scad-preview
  https://github.com/zk-phi/scad-preview.git

- jabber
  https://github.com/legoscia/emacs-jabber.git

- jabber-otr
  https://github.com/legoscia/emacs-jabber-otr.git

- helm
  https://github.com/emacs-helm/helm.git

- wordnut
  https://github.com/gromnitsky/wordnut.git

- sudoku
  https://github.com/zevlg/sudoku.el.git

- selectrum
  https://github.com/raxod502/selectrum.git

- mutt-mode
  https://gitlab.com/flexw/mutt-mode.git

- keycast
  https://github.com/tarsius/keycast.git

- kdeconnect
  https://github.com/carldotac/kdeconnect.el.git

- guide-key
  https://github.com/kai2nenobu/guide-key.git

- gemini-mode
  https://git.carcosa.net/jmcbray/gemini.el.git

- elpher
  git://thelambdalab.xyz/elpher.git

- 2048-game
  https://hg.sr.ht/~zck/game-2048

- sxiv
  https://gitlab.com/contrapunctus/sxiv.el

Re: NonGNU ELPA

[Stefan Monnier]

> I guess packages are unsigned

I would hope you'd take a quick look before assuming the worst,


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-22 00:14]:
> > I guess packages are unsigned
> 
> I would hope you'd take a quick look before assuming the worst,

Maybe archive-contents is unsigned or something else. I have used
`package-check-signature' as it is default in my Emacs and I could not
get the archive, at least not first time.

Then let me blame my bad Internet connection.

Re: NonGNU ELPA

[Stefan Monnier]

>> > I guess packages are unsigned
>> I would hope you'd take a quick look before assuming the worst,
> Maybe archive-contents is unsigned or something else. I have used
> `package-check-signature' as it is default in my Emacs and I could not
> get the archive, at least not first time.
> Then let me blame my bad Internet connection.

Might be a problem on our side.  In any case, if you have problems with
that part, please consider it as a bug, because it's supposed to
work ;-)


        Stefan

Re: NonGNU ELPA

[Stefan Monnier]

> Following packages I propose for nonGNU ELPA:

I think more than suggestions for which packages to include, we're
looking for help in actually including them.


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-04 06:53]:
> > Following packages I propose for nonGNU ELPA:
> 
> I think more than suggestions for which packages to include, we're
> looking for help in actually including them.

Give me assignment to do or tell me method to help.

Re: NonGNU ELPA

[Stefan Monnier]

>> > Following packages I propose for nonGNU ELPA:
>> I think more than suggestions for which packages to include, we're
>> looking for help in actually including them.
> Give me assignment to do or tell me method to help.

The README.org file in nongnu.git aims to do that.  It's still a work in
progress, but please read it.  This should either give you the info
needed for you to do the job, or should bring up new questions which I'd
be happy to answer.


        Stefan

Re: NonGNU ELPA

[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 hard part is making arrangements with the developers of each
package.  We are still trying to figure out exactly how to go about
this.  What we need now is for someone who understands the goal
clearly to give it a try.  Once we have one or two people who
can do this, they can write it down and/pr teach others.

-- 
Dr Richard Stallman
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

[Clément Pit-Claudel]

On 11/21/20 2:02 PM, Stefan Monnier wrote:
>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Great job!  Is the plan to put a copy of all the code in there, not just pointers to repositories?
Does that mean that authors will all have access to the git repo?  Will that access be limited to their individual externals/ branches?
Or will there be a script that pulls repositories into these individual branches?
And won't the repo become gigantic?

Clément.

Re: NonGNU ELPA

[Stefan Monnier]

> Or will there be a script that pulls repositories into these individual branches?

That!  And no, it's not written yet.
Note that this doesn't even have to run on elpa.gnu.org, you all can
participate in this effort ;-)

> And won't the repo become gigantic?

I don't expect it will become significantly larger than the actual ELPA
archive itself:

    % du -sh elpa/.git/ /var/www/html/packages/.
    886M    elpa/.git/
    918M    /var/www/html/packages/.
    % du -sh nongnu/.git/ /var/www/html/nongnu/.


-- Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-22 00:19]:
> > Or will there be a script that pulls repositories into these individual branches?
> 
> That!  And no, it's not written yet.
> Note that this doesn't even have to run on elpa.gnu.org, you all can
> participate in this effort ;-)

Tell me how.

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 4:18 PM, Stefan Monnier wrote:
> I don't expect it will become significantly larger than the actual ELPA
> archive itself:

I think the right metric would be the MELPA archive: I don't know how bit a complete checkout is of all MELPA packages.
The main problem would be cases in which an emacs mode exists as part of a larger repo (like llvm-mode, which is part of llvm — it was removed from MELPA because it took too long just to close the repo).

Re: NonGNU ELPA

[Jean Louis]

* Clément Pit-Claudel <cpitclaudel@gmail.com> [2020-11-22 01:22]:
> On 11/21/20 4:18 PM, Stefan Monnier wrote:
> > I don't expect it will become significantly larger than the actual ELPA
> > archive itself:
> 
> I think the right metric would be the MELPA archive: I don't know how bit a complete checkout is of all MELPA packages.

It is about 14 GB. If I change it slightly to --depth 1 it is about 10-11 GB.

Git is in my opinion not for releasing software, it is for
collaborative development. Releases of any software from git or other
version control systems should be packed and contain only what is
necessary for the user who receives such package. This is also because
authors or maintainers are deciding what is development version and
what is stable version. Git sources need not be stable and they do not
represent "release" and should not be regarded as release how MELPA is
accepting them.

The fact that many git repositories are online accessible does not
make them software releases. Author's opinion on what is release and
what is not shall be respected. But people did start going into
direction that git is automatically stable version which puts many
people and their data at stake.

Beside the git download size, when packages become packages after
building they are not so large, if I remember well just under 600 MB.

I am doing review of MELPA packages. There are many useless packages
and many unsafe and not polished and those repeating functions which
already exists. I would not include such.

There are those where author's name is not known as it is written only
as a nick. For me it would be legal problem as there is no truthful
authentic relation between the author who is not legally named "zack"
(example) and the receiver of software. Receiver would not know from
which entity or person did receive get the license, or both parties
would not have any option of defense or enforcement by the law.

> The main problem would be cases in which an emacs mode exists as
> part of a larger repo (like llvm-mode, which is part of lplvm — it
> was removed from MELPA because it took too long just to close the
> repo).

Isn't it not so that Emacs packages shall be either .el or .tar files?

Those packages that do not provide such releases and are useful can be
anyway packaged in non-GNU ELPA, why not? There is no need to
replicate git repositories, but rather actual packages regardless if
such are part of git repository or not.

Re: NonGNU ELPA

[Stefan Monnier]

> I think the right metric would be the MELPA archive: I don't know how bit
> a complete checkout is of all MELPA packages.

Hmm... wait, after "git gc" the figure is even more favorable:

    % du -sh elpa/.git/. /var/www/html/packages/.
    144M    elpa/.git/.
    918M    /var/www/html/packages/.
    %

IOW, the main problem with size is the ELPA archive itself rather than
the Git repository.

> The main problem would be cases in which an emacs mode exists as part of
> a larger repo (like llvm-mode, which is part of llvm — it was removed from
> MELPA because it took too long just to close the repo).

These need to be solved on a case-by-case basis, yes.


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

>> Or will there be a script that pulls repositories into these individual branches?
>
> That!  And no, it's not written yet.
> Note that this doesn't even have to run on elpa.gnu.org, you all can
> participate in this effort ;-)
>
>> And won't the repo become gigantic?
>
> I don't expect it will become significantly larger than the actual ELPA
> archive itself:

Is there any reason to suspect that this will become an issue?
AFAIK, Git is pretty good at handling large repositories.

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 6:22 PM, Stefan Kangas wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> Or will there be a script that pulls repositories into these individual branches?
>>
>> That!  And no, it's not written yet.
>> Note that this doesn't even have to run on elpa.gnu.org, you all can
>> participate in this effort ;-)
>>
>>> And won't the repo become gigantic?
>>
>> I don't expect it will become significantly larger than the actual ELPA
>> archive itself:
> 
> Is there any reason to suspect that this will become an issue?
> AFAIK, Git is pretty good at handling large repositories.

Cloning large repositories can be quite slow, that's it.  Assuming that no one needs to do this except the build machine, that should be fine, but if we want to push patches (as is sometimes done in ELPA) then it could become an issue?  
Even if it's not cloned often I worry about the time it takes to switch branches if very large external repositories get imported.

Re: NonGNU ELPA

[Stefan Monnier]

> Cloning large repositories can be quite slow, that's it.  Assuming that no
> one needs to do this except the build machine, that should be fine, but if
> we want to push patches (as is sometimes done in ELPA) then it could become
> an issue?

The plan is to try and refrain as much as possible from installing
patches directly into the nongnu.git mirrors.

IOW the complete copies held in nongnu.git are just meant as a kind of
"internal detail" to decouple the step of fetching updates from the step
of building packages.

> Even if it's not cloned often I worry about the time it takes to switch
> branches if very large external repositories get imported.

Every package gets into own branch, and gets its own worktree, so
switching branches should be very unusual there.
Also if having them all in a single repository ever turns out to be
a problem, we're definitely not stuck with this design.


        Stefan

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 7:30 PM, Stefan Monnier wrote:
> Every package gets […] its own worktree

Oh, smart move. 👍

Re: NonGNU ELPA

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

  > Cloning large repositories can be quite slow, that's it.

Putting all the packages into one git repo is ok as an initial
implementation, but it isn't what we really want for NonGNU ELPA.  It
is meant to be a place where we will distribute/release packages side
by side -- not a hosting facility.  I think we will have to change
the structure.

Perhaps it should be a collection of git repos, one for each package,
as subdirectories of the main directory.  WHat else might be good?

-- 
Dr Richard Stallman
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

[Stefan Monnier]

> Putting all the packages into one git repo is ok as an initial
> implementation, but it isn't what we really want for NonGNU ELPA.

With all due respect, Richard, I believe you don't know Git enough to
make this judgment.


        Stefan

Re: NonGNU ELPA

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

  > > Putting all the packages into one git repo is ok as an initial
  > > implementation, but it isn't what we really want for NonGNU ELPA.

  > With all due respect, Richard, I believe you don't know Git enough to
  > make this judgment.

You are probably right -- but I have to judge how this compares with
the plan, and I can only do it based on the knowledge available to me.
Your description didn't add much to my limited background.

Would you please explain to me how your implementation works, so I can
see why I was wrong to worry about this, and other important things?

-- 
Dr Richard Stallman
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

[Stefan Kangas]

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

>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
>
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Excellent news!  Thank you for this work.

Re: NonGNU ELPA

[Stefan Kangas]

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

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

> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

To build it locally, are the instructions in the README from GNU ELPA
the ones to follow?

How easy is it to add a package?  Would pushing the attached patch do
the job?  Is it useful to start adding packages at this stage?

[-- Attachment #2: 0001-externals-list-New-package-magit.patch --]
[-- Type: text/x-diff, Size: 803 bytes --]

From 21294a45866d186259088a72780ab5718fadb50d Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sun, 22 Nov 2020 00:27:10 +0100
Subject: [PATCH] * externals-list: New package `magit`

---
 externals-list | 1 +
 1 file changed, 1 insertion(+)

diff --git a/externals-list b/externals-list
index ba4edbf6..da180492 100644
--- a/externals-list
+++ b/externals-list
@@ -32,6 +32,7 @@
   ;; The version 4.7.1 from Melpa-stable seems to correspond to
   ;; revision a9134009.
   :version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
+ ("magit"		:external "https://github.com/magit/magit")
  ("sly"			:external "https://github.com/joaotavora/sly"
   :version-map (("1.0.0-beta-3" "1.0.0beta3")))
  ("tuareg"		:external "https://github.com/ocaml/tuareg.git")
-- 
2.29.2

Re: NonGNU ELPA

[Stefan Monnier]

> To build it locally, are the instructions in the README from GNU ELPA
> the ones to follow?

Yes and no.

To build the packages, it's much easier:

    git clone .../nongnu.git
    cd nongnu
    make build/sly

or "make build-all"

And the result is put into `archive` (as well as `archive-devel` which
is what you see in https://elpa.gnu.org/nongnu-devel/ and corresponds
to the non-stable Melpa more or less).

To "compile the packages in place", you can do "make" and it should work
more or less like for elpa.git, but it probably has some rough edges
(e.g. a subsequent "make build/sly" might burp because it expects
a clean worktree and it might mess with the .gitignore file or
something.  This part of the code needs to be adapted to the new
context).

If you feel like taking a shot at the README, that would be welcome ;-)

> How easy is it to add a package?  Would pushing the attached patch do
> the job?

It might, but you'll also need to push the code of Magit to the
`externals/magit` branch, like in elpa.git.

IIUC Magit has various Package-Requires, so you'll have to add those
first since we don't want nongnu.git package to require packages only
found in Melpa.

> Is it useful to start adding packages at this stage?

Yes.


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

> It might, but you'll also need to push the code of Magit to the
> `externals/magit` branch, like in elpa.git.

Will subsequent updates happen automatically, or does it require
manually pushing to that branch like in GNU ELPA?

Re: NonGNU ELPA

[Stefan Monnier]

> Will subsequent updates happen automatically, or does it require
> manually pushing to that branch like in GNU ELPA?

The code to fetch+push is still vaporware, so you have to do it by hand,
like for GNU ELPA.


        Stefan

Re: NonGNU ELPA

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

  > How easy is it to add a package?  Would pushing the attached patch do
  > the job?  Is it useful to start adding packages at this stage?

In general we are not ready to fill it with packages.

First of all, this is a first stab at setting up NonGNU ELPA.  Does it
do the right thing?  Does it need changes?  The message about it was
very terse, and I am not sure what Stefan has implemented.

Aside from the technical structure, we have to develop procedures.
Before we put a package into NonGNU ELPA, we have to look it over and
make sure it follows the rules.  (I posted them here months ago.)
Also make sure there is nothing problematical in it.

Then we have to determine what relationship to have with its
development.  There are three possibilities.

1. Make an arrangement with its developers, then entrust it to them by
automatically copying their new releases.

2. Automatically copy in new releases, but check them to make sure
the code does not become problematical.

3. Manually to check and install new versions occasionally,
carrying forward our small changes as if necessary.

We will need to work out the details of this by doing it.
What we need to do now is add packages carefully, one by one,
paying attention to the arrangements we make for each one.


-- 
Dr Richard Stallman
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

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Before we put a package into NonGNU ELPA, we have to look it over and
> make sure it follows the rules.  (I posted them here months ago.)
> Also make sure there is nothing problematical in it.
>
> Then we have to determine what relationship to have with its
> development.  There are three possibilities.
>
> 1. Make an arrangement with its developers, then entrust it to them by
> automatically copying their new releases.
>
> 2. Automatically copy in new releases, but check them to make sure
> the code does not become problematical.
>
> 3. Manually to check and install new versions occasionally,
> carrying forward our small changes as if necessary.
>
> We will need to work out the details of this by doing it.
> What we need to do now is add packages carefully, one by one,
> paying attention to the arrangements we make for each one.

This implies that we should first contact the package maintainer telling
them that we are interested in adding it to GNU ELPA.  I think that
could be useful, as it's also an opportunity for us to inform the
package maintainer about our plans, to build a relationship and to avoid
surprising anyone.

I have three questions:

Would it be useful to prepare a template for such a communication?

Could we prepare a canonical URL for the GNU ELPA package
requirements/rules outlined in a previous email by Richard?  I assume it
would be placed under https://elpa.nongnu.org/requirements.htm or
something similar, once Amin can get that hostname working.

Should we add a special file to nongnu.git for recording the kind of
arrangement we decide on?  I imagine that our ideal case would be number
one above.  Perhaps we would only need to note anything down when we
have a different arrangement from the first case.

Re: NonGNU ELPA

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-11-24 23:06]:
> I have three questions:
> 
> Would it be useful to prepare a template for such a communication?
> 
> Could we prepare a canonical URL for the GNU ELPA package
> requirements/rules outlined in a previous email by Richard?  I assume it
> would be placed under https://elpa.nongnu.org/requirements.htm or
> something similar, once Amin can get that hostname working.
> 
> Should we add a special file to nongnu.git for recording the kind of
> arrangement we decide on?  I imagine that our ideal case would be number
> one above.  Perhaps we would only need to note anything down when we
> have a different arrangement from the first case.

Some thoughts:

You should take notes by date on the relation with the developers as
that helps greatly other developers to understand what it is. Any
communication with developer as it is public should be quickly
accessible from such notes. If there is specific decision or anything
in the mailing list to be noted, you may insert URL to the message in
such notes.

Note could contain:

- dates of notes
- names and contact information
- sources URLs and changes of such
- references to previous decisive communication objects

Re: NonGNU ELPA

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

  > > We will need to work out the details of this by doing it.
  > > What we need to do now is add packages carefully, one by one,
  > > paying attention to the arrangements we make for each one.

  > This implies that we should first contact the package maintainer telling
  > them that we are interested in adding it to GNU ELPA.  I think that
  > could be useful, as it's also an opportunity for us to inform the
  > package maintainer about our plans, to build a relationship and to avoid
  > surprising anyone.

Yes indeed.

  > I have three questions:

  > Would it be useful to prepare a template for such a communication?

Yes, definitely.

Would you like to write a draft of this, and show it to me and
the other Emacs maintainers?  Privately at first.

  > Could we prepare a canonical URL for the GNU ELPA package
  > requirements/rules outlined in a previous email by Richard?  I assume it
  > would be placed under https://elpa.nongnu.org/requirements.htm or
  > something similar, once Amin can get that hostname working.

Yes, we should do that.  It should state the full rules, which
I've posted here, adding some details from my previous message.
I'll do make that and send it to you.

  > Should we add a special file to nongnu.git for recording the kind of
  > arrangement we decide on?

Yes.  One question is where to put that information:
in one single file with an item for each package, or in a
file for each package in that package's information?

(What is the structure of the archive?
Does each package have a page?
Does each package have a subdirectory?
How are the files presented for download?)

                               I imagine that our ideal case would be number
  > one above.

Yes.

                Perhaps we would only need to note anything down when we
  > have a different arrangement from the first case.

No, that would risk misunderstandings in the harmful direction:
that we would believe the package is being taken care of by someone
else who has not in fact accepted that responsibility.

To avoid this. we should always indicate explicitly who has taken
responsibility for the updating of each package in NonGNU ELPA.



-- 
Dr Richard Stallman
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

[Stefan Monnier]

>   > Could we prepare a canonical URL for the GNU ELPA package
>   > requirements/rules outlined in a previous email by Richard?  I assume it
>   > would be placed under https://elpa.nongnu.org/requirements.htm or
>   > something similar, once Amin can get that hostname working.
>
> Yes, we should do that.  It should state the full rules, which
> I've posted here, adding some details from my previous message.
> I'll do make that and send it to you.

FWIW, I've put that in the README.org of nongnu.git
(http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
the "Guidance for accepting packages" 


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

> > Yes, we should do that.  It should state the full rules, which
> > I've posted here, adding some details from my previous message.
> > I'll do make that and send it to you.
>
> FWIW, I've put that in the README.org of nongnu.git
> (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> the "Guidance for accepting packages"

Excellent.  Why not export README.org as a HTML file and distribute it
as such on nongnu.elpa.org?  Org-mode already has excellent HTML
exporting capabilities that we could use, and it is trivial to adapt
it to use the existing stylesheet.  We could perhaps do the same with
the link to the README on elpa.gnu.org (where we currently just link
the raw text file on Savannah's gitweb).

I would ideally like to see a menu added to both NonGNU ELPA and GNU
ELPA web pages.  For example, on elpa.gnu.org you can only find
"Contribute" from the very first entry page, which is fine, but to my
mind not ideal.  It should better be shown on every page.  A menu
should make it easier to find information on what NonGNU/GNU ELPA is,
and how to install and submit packages.

I think we could have these menu entries: "Packages", "How to install"
and "Contributing", and perhaps even a brief FAQ.  I could volunteer
to write the text for these pages, but I often find CSS very
frustrating to work with so it takes me a lot of mental willpower to
do even simple things like a menu.  Perhaps someone on this list is
more CSS-capable than me and would be willing to help here.  (I do
have a half-baked attempt lying around that I have lacked the stamina
to complete.)

Re: NonGNU ELPA

[Stefan Monnier]

> Excellent.  Why not export README.org as a HTML file and distribute it
> as such on nongnu.elpa.org?

To most of those questions, the answer is all the same: because noone
did it.  Help very welcome (and if there's any question about how to
get it done, I'd be happy to help as well).


        Stefan

Re: NonGNU ELPA

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 27 Nov 2020 08:56:06 -0500
> Cc: Amin Bandali <bandali@gnu.org>, Richard Stallman <rms@gnu.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > Excellent.  Why not export README.org as a HTML file and distribute it
> > as such on nongnu.elpa.org?
> 
> To most of those questions, the answer is all the same: because noone
> did it.

Indeed, as everything else in Emacs (and in Free Software in general).

> Help very welcome (and if there's any question about how to get it
> done, I'd be happy to help as well).

Indeed, I'd encourage people to offer help in getting this done
instead of asking why wasn't it.  Thanks in advance!

Re: NonGNU ELPA

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-11-27 12:15]:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > > Yes, we should do that.  It should state the full rules, which
> > > I've posted here, adding some details from my previous message.
> > > I'll do make that and send it to you.
> >
> > FWIW, I've put that in the README.org of nongnu.git
> > (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> > the "Guidance for accepting packages"
> 
> Excellent.  Why not export README.org as a HTML file and distribute it
> as such on nongnu.elpa.org?

Not directly related, the SSL certificate is for now not valid on
elpa.nongnu.org

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-26 17:20]:
> > Yes, we should do that.  It should state the full rules, which
> > I've posted here, adding some details from my previous message.
> > I'll do make that and send it to you.
> 
> FWIW, I've put that in the README.org of nongnu.git
> (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> the "Guidance for accepting packages" 

Thank you Stefan.

I may have just few thoughts on README.org and I know it is in
progress to be polished.

- head is missing to explain in brief what is nonGNU ELPA

- Regarding heading "The Emacs maintainers will decide what packages
  to put in NonGNU ELPA." as this heading comes so early in "Guidance
  for accepting packages", I would say that the tone of that heading
  gives on me as non native English speaker somewhat negative or
  little bit unwelcoming impression. Maybe it can be said that
  everybody is welcome to apply to include packages in nonGNU ELPA and
  that Emacs maintainers will have final decision based on various
  GNU free software policies. Something like that should or could be
  the first what users read.

- The Org headings are made so that it is not really heading rather
  begin of a sentence. Heading should be summary of a paragraph
  below. I know this is all in progress.

- I feel this sentence as defensive and reiteration what was
  previously said: "** If an ELisp package follows the rules below, we
  can add it to NonGNU ELPA if we want to." -- Instead one could
  formulate it in some positive manner: "Please review the rules below
  and align your package to conform to it to help maintainers make a
  decision" -- something like that, but maybe better formulated.

- "We may also change the code in NonGNU ELPA for other reasons,
  technical or not.  After all, it is free software." -- that is all
  clear and good, I just feel it is defensive for no apparent
  reason. In my opinion it requires some adaptations similar to above.

- "let's discuss it" should have clear pointers which communication
  lines to use, for example there could be hyperlins to the mailing
  list, or how to subscribe to mailing list, or some other
  communication lines. Among thousands of authors it is so that only
  subset of them is participating in GNU mailing lists. They need not
  know how to contact. Also website should give pointers on how to
  contact Emacs maintainers.

- README.org for nonGNU ELPA once polished could be included in etc/
  in distribution

- "FSF conventions" should be maybe hyperlinked to FSF and conventions
  as this way we give some references for further learning as maybe
  people wish to apply with their packages directly to GNU ELPA as
  well and may wish to contribute to Emacs directly. References and
  pointers to that type of contribution should also be included.

- In general I would myself hyperlink many terms such as GNU operating
  system, GNU/Linux to reference on GNU with differences in terms of
  Linux and GNU

- I would exclude the Savannah rule about advertisement as if it is
  general rule than those who advertise may be later warned why, as if
  it is final decision of Emacs maintainers then maintainers will
  handle those incidents. This paragraph is IMHO not necessary as may
  drive people away. It is easy to warn somebody. Advertising could be
  construed as simple placing of a hyperlink. Or telling "Copyright
  Free Software or ABC Foundation". Or otherwise one should clearly
  define what advertisement means.

  When one say "you may not advertise anything commercial" does it
  mean that some commercially sold free software cannot be placed in
  the repository?

  Then there are exeption cited about fan items that one may sell
  directly to user which is somehow contradictory.

  In general that section should be maybe defined better or removed
  and defined in general Savannah rules. As README.org could be
  eventually distributed or mirrored, it can get wide
  distribution. That is why is better to now revise whatever
  maintainers wish to revise.

- "Adding a package" is there, and fine, but nothing says about how
  authors or other people may propose packages to be included. That is
  missing as first step for people to contribute.

- in general it should be more welcoming for contributors to feel more
  free to apply and contribute and to have references how to apply and
  how to contribute. While this is explained partially, it may need
  more description and clarifications.

- There shall be more references to GNU ELPA, to Emacs Lisp manual and
  section Packaging and GNU website.

Thank you for considerations,
Jean

Re: NonGNU ELPA

[Stefan Monnier]

> I may have just few thoughts on README.org and I know it is in
> progress to be polished.

A patch would be greatly appreciated, yes,


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-27 18:22]:
> > I may have just few thoughts on README.org and I know it is in
> > progress to be polished.
> 
> A patch would be greatly appreciated, yes,

I would gladly, I am not sure if it is appropriate at this moment
yet as I do not know about agreements between people on how it should
all look like.

Please look this README:
http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

In my opinion this README shall be cloned to nonGNU ELPA and then
adapted with points you have there.

Re: NonGNU ELPA

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

> > > I may have just few thoughts on README.org and I know it is in
> > > progress to be polished.
> >
> > A patch would be greatly appreciated, yes,
>
> I would gladly, I am not sure if it is appropriate at this moment
> yet as I do not know about agreements between people on how it should
> all look like.

A patch is appropriate at this time, yes.  It will help us make the
necessary changes and find any points of contention as well.

FWIW, I think all your proposals sound basically good and I don't
expect they should be very controversial.  Perhaps we would need to
adapt this or that detail, but that is done as a matter of course with
any patch.

Re: NonGNU ELPA

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Would it be useful to prepare a template for such a communication?
>
> Yes, definitely.
>
> Would you like to write a draft of this, and show it to me and
> the other Emacs maintainers?  Privately at first.

Yes, I can do that.  I will send it privately when I have prepared it.

>   > Could we prepare a canonical URL for the GNU ELPA package
>   > requirements/rules outlined in a previous email by Richard?  I assume it
>   > would be placed under https://elpa.nongnu.org/requirements.htm or
>   > something similar, once Amin can get that hostname working.
>
> Yes, we should do that.  It should state the full rules, which
> I've posted here, adding some details from my previous message.
> I'll do make that and send it to you.

Thank you.

>   > Should we add a special file to nongnu.git for recording the kind of
>   > arrangement we decide on?
>
> Yes.  One question is where to put that information:
> in one single file with an item for each package, or in a
> file for each package in that package's information?

I have no strong opinion either way.  Perhaps centralizing it in a
single file is easier to maintain.

> Does each package have a page?

Yes, see for example: https://elpa.gnu.org/nongnu/caml.html

> Does each package have a subdirectory?

AFAIU, the answer is no.  They instead each have their own git branch.

> How are the files presented for download?)

They are either .el or .tar files available using the standard M-x
package-list in Emacs, or the individual package page with a web
browser.

>                 Perhaps we would only need to note anything down when we
>   > have a different arrangement from the first case.
>
> No, that would risk misunderstandings in the harmful direction:
> that we would believe the package is being taken care of by someone
> else who has not in fact accepted that responsibility.
>
> To avoid this. we should always indicate explicitly who has taken
> responsibility for the updating of each package in NonGNU ELPA.

OK, that sounds reasonable.

Re: NonGNU ELPA

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

  > > Yes, we should do that.  It should state the full rules, which
  > > I've posted here, adding some details from my previous message.
  > > I'll do make that and send it to you.

  > Thank you.

I've cleaned up the points about what we should do to add a package to
NonGNU ELPA.  Does anyone suggest any further changes?


Before we put a package into NonGNU ELPA, we have to look it over and
make sure it follows the rules.  We also have to check that there is
technically or ethically problematical in it.  If users like the
package and have not complained about it, we can take that as meaning
it is good to use.  But we should also check its namespace usage.

Then we have to determine what relationship to have with its
development.  There are three possibilities.

1. Make an arrangement with its developers, then entrust it to them by
automatically copying their new releases.

2. Automatically copy in new releases, but check them to make sure the
code does not become problematical.  If it does, we could accept the
new version and discuss the matter with the developers, make some changes,
or back up the version in NonGNU ELPA to a previous release.

3. Manually check and install new versions when convenient, carrying
forward our own changes (small, we hope) and occasionally making
more changes.

We will need to work out the details of this by doing it.
What we need to do now is add packages carefully, one by one,
paying attention to the arrangements we make for each one.
-- 
Dr Richard Stallman
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

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> I've cleaned up the points about what we should do to add a package to
> NonGNU ELPA.  Does anyone suggest any further changes?

One small comment:

> Before we put a package into NonGNU ELPA, we have to look it over and
> make sure it follows the rules.  We also have to check that there is
> technically or ethically problematical in it.  If users like the
  ^ "nothing" seems to be missing here

> package and have not complained about it, we can take that as meaning
> it is good to use.  But we should also check its namespace usage.

Otherwise, LGTM.

Re: NonGNU ELPA

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

  > > Before we put a package into NonGNU ELPA, we have to look it over and
  > > make sure it follows the rules.  We also have to check that there is
  > > technically or ethically problematical in it.  If users like the
  >   ^ "nothing" seems to be missing here

You're right.

Any other comments?
-- 
Dr Richard Stallman
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

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

  > > Does each package have a subdirectory?

  > AFAIU, the answer is no.  They instead each have their own git branch.

Could you explain to me what that means?  I know about branches in git.
Normally a branch will contain a modified version of the program
that is in master.  That is not what we want here.

-- 
Dr Richard Stallman
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

[Andrea Corallo via Emacs development discussions.]

Richard Stallman <rms@gnu.org> writes:

[...]

> Could you explain to me what that means?  I know about branches in git.
> Normally a branch will contain a modified version of the program
> that is in master.

This is how is often used, but a git branch does not have to necessarily
share the root commit with master (or any other branch).  I believe this
kind of branch is called 'orphan'.

  Andrea

Re: NonGNU ELPA

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

  > This is how is often used, but a git branch does not have to necessarily
  > share the root commit with master (or any other branch).  I believe this
  > kind of branch is called 'orphan'.

Thanks.

I think this structure be explained in the README file
or some other prominent place.  Is that the case now?

Or
-- 
Dr Richard Stallman
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

[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 repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
  > and the archive is currently at https://elpa.gnu.org/nongnu/

Could you explain how this works?
What role does the repo play,
and what role does the archive play?

-- 
Dr Richard Stallman
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

[Zhu Zihao]

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


Thanks for your work.

Would you mind add a rsync service? This can help mirror providers like
https://elpa.emacs-china.org/ to mirror the NonGNU ELPA more easily.

Stefan Monnier writes:

>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
>
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/
>
>
>         Stefan


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: NonGNU ELPA

[Stefan Monnier]

> Would you mind add a rsync service?

Oh, yes, I forgot to update the rsync service.
It should be fixed now.  Beside `elpa`, there's now `nongnu` and `nongnu-devel`.
Thanks for the reminder,


        Stefan


> This can help mirror providers like
> https://elpa.emacs-china.org/ to mirror the NonGNU ELPA more easily.
>
> Stefan Monnier writes:
>
>>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>>> has been weeks since we discussed it and I have not heard that
>>>> he has moved forward on it.
>>
>> I have a first cut up now.
>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
>> and the archive is currently at https://elpa.gnu.org/nongnu/
>>
>>
>>         Stefan

Re: NonGNU ELPA

[Daniel Martín]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I have a first cut up now.

Thanks for working on this!

> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git

This SSH address does not work here because it requires authentication.
Does it need a Savannah account, by chance?  I simply wanted to clone
the repository anonymously, so I "discovered"
https://git.savannah.gnu.org/cgit/emacs/nongnu.git and issued a

git clone git://git.savannah.gnu.org/emacs/nongnu.git

to make my computer clone the repo.  Sorry if this is a well-known
workflow that is the same as in GNU ELPA, I'm not familiar with Emacs
package repositories.

> and the archive is currently at https://elpa.gnu.org/nongnu/
>

Is there a plan to include this package archive by default in a future
version of Emacs?  That is, something like

(add-to-list 'package-archives '("nongnu" . "https://elpa.gnu.org/nongnu/"))

If so, then I have a potential feature once we have a few language modes
in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
a file with ".md" extension for the first time, Emacs will ask whether
you want to install markdown-mode from NonGNU ELPA, instead of opening
the Markdown file in fundamental-mode.  Does this make sense?  To make
it really useful, as the cadence of Emacs releases and NonGNU ELPA
changes will surely be different, we'd somehow need to implement it in a
way that does not couple the Emacs source code to the language mode
packages available in NonGNU ELPA, if that's possible.

Re: NonGNU ELPA

[Jean Louis]

* Daniel Martín <mardani29@yahoo.es> [2020-12-05 14:46]:
> If so, then I have a potential feature once we have a few language modes
> in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
> a file with ".md" extension for the first time, Emacs will ask whether
> you want to install markdown-mode from NonGNU ELPA, instead of opening
> the Markdown file in fundamental-mode.  Does this make sense?  To make
> it really useful, as the cadence of Emacs releases and NonGNU ELPA
> changes will surely be different, we'd somehow need to implement it in a
> way that does not couple the Emacs source code to the language mode
> packages available in NonGNU ELPA, if that's possible.

That may be useful as option to be decided by the subset of users who
need it.

It better not be by default to nag those who may not need it.

Have been editing markdown since 2004 and just before 1-2 years have
discovered markdown-mode. The only thing I need in that mode is
preview which I can do myself by assigning a key to
function. Markdown's goal was always simplicity and being able to edit
with any editor. That is just to tell you of my user experience and
habit.

Re: NonGNU ELPA

[Stefan Monnier]

>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> This SSH address does not work here because it requires authentication.

Indeed, that's the URL to use if you want write access.
For read-only access you have to use:

> git clone git://git.savannah.gnu.org/emacs/nongnu.git

;-)

>> and the archive is currently at https://elpa.gnu.org/nongnu/
> Is there a plan to include this package archive by default in a future
> version of Emacs?

Yes (tho with a slightly different URL with `elpa.nongnu.org`).

> If so, then I have a potential feature once we have a few language modes
> in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
> a file with ".md" extension for the first time, Emacs will ask whether
> you want to install markdown-mode from NonGNU ELPA, instead of opening
> the Markdown file in fundamental-mode.  Does this make sense?

We already have that for those packages in GNU ELPA if you install the
`gnu-elpa` package (which I still hope we'll be able to bundle within
the tarball of Emacs-28).
We could easily extend it to the NonGNU archive, indeed.


        Stefan

Re: NonGNU ELPA

[Daniel Martín]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> We already have that for those packages in GNU ELPA if you install the
> `gnu-elpa` package (which I still hope we'll be able to bundle within
> the tarball of Emacs-28).
> We could easily extend it to the NonGNU archive, indeed.
>

Ah, I didn't know about the gnu-elpa package.  I haven't tested it yet,
but it looks like it already implements the feature I suggested.  Good
thing it is considered for inclusion with Emacs 28.

Re: NonGNU ELPA

[Stefan Monnier]

>> We already have that for those packages in GNU ELPA if you install the
>> `gnu-elpa` package (which I still hope we'll be able to bundle within
>> the tarball of Emacs-28).
>> We could easily extend it to the NonGNU archive, indeed.
> Ah, I didn't know about the gnu-elpa package.  I haven't tested it yet,
> but it looks like it already implements the feature I suggested.

It's quite young and would benefit from feedback from users, BTW.

> Good thing it is considered for inclusion with Emacs 28.

Not sure it's considered yet, to be honest.  I'd like it, but it's not
my decision.


        Stefan

How do I go about debugging my Elisp code?

[Davin Pearson]

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

I sent this email to gnu.emacs.help but got no reply :-(

When it comes up with a back trace it notifies you of the
problematic line of code but doesn't tell you which line the
error comes from.

What I have to do with this is to put debugger checkpoints on
every second line of Elisp code.  At least that gives you the
location of the error message, by looking at the *Messages*
buffer you can see the last checkpoint before the debugger
was entered...

See the file at the following location for an example.
In this file debug lines are commented out like so
;;(message "#cream:[0-9]+:")

http://davinpearson.nz/binaries/dmp-padderise.el

Executing the command in this file called dmp-padderise.el:
dmp-padderise--uncomment-hash-lines makes all the debug lines
visible to the Elisp system.  Executing the following command:
dmp-padderise--comment-hash-lines comments out the debug lines.

Is there a better way to hunt down error messages?

Could someone email me a hyperlink to a superior debugging
system?

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]

Fwd: How do I go about debugging my Elisp code?

[Davin Pearson]

---------- Forwarded message ---------
From: Davin Pearson <davin.pearson@gmail.com>
Date: Sat, 8 Jan 2022 at 18:20
Subject: How do I go about debugging my Elisp code?
To: emacs-devel <emacs-devel@gnu.org>

I sent this email to the google group
gnu.emacs.help but got no reply :-(

My problem is with the GNU Elisp Debugger...
When it comes up with a back trace it notifies you of the
problematic line of code but doesn't tell you which line or file
the error comes from.

What I have to do with this is to put debugger checkpoints on
every second line of Elisp code.  At least that gives you the
location of the error message, by looking at the *Messages*
buffer you can see the last checkpoint before the debugger
was entered...

See the file at the following URL location for an example.
In this file debug lines are commented out like so
;;(message "#Monkey-Man:123:")

http://davinpearson.nz/binaries/dmp-padderise2.el
<http://davinpearson.nz/binaries/dmp-padderise.el>

Here is my choice of syntax highlighting so that
my checkpoints appear in a dimmer face so they
don't unnecessarily clutter up the screen.

http://davinpearson.nz/binaries/screenshot.png

Executing the command in this file called dmp-padderise2.el:
M-x dmp-padderise--uncomment-hash-lines makes all the debug lines
visible to the Elisp system.  Executing the following command:
M-x dmp-padderise--comment-hash-lines comments out the debug lines.

Is there a better way to hunt down error messages?

Could someone email me a hyperlink to a superior debugging
system?

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
> http://davinpearson.nz/binaries/dmp-padderise2.el

After the first review of that file, I can see "Copyright" related to
your name. However, that makes the software proprietary. Because it
does change the Emacs, such software is incompatible with the Emacs
License. If it would be internal only, that would be fine. But as soon
as you publish it, you would need to comply to the license so that
your software becomes compatible legally.

One good way to comply is the package I made for friend from Sweden:

your hjälpsam Package Header Assistant
https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html

You may as well look into almost every ELPA package to find how
package header should look like.

Another way to understand it is to invoke C-h C-c and search for terms
"How to Apply These Terms to Your New Programs" as that is the Emacs
license.

Thanks for your patience and I hope for your insight into this matter.

In relation to technical assistance and related to your package, you
wrote "bugs: none" but I am not sure about it. Don't rush. Bugs they
come.

I have done M-x emacs-lisp-byte-compile on your file and result is
below. I recommend looking into those warnings. And I can assure you
that file may be compiled without any warnings. So try to minimize
those warnings.

\f
Compiling file /home/data1/protected/tmp/mozilla_admin0/dmp-padderise2.el at Fri Jan 14 16:39:25 2022

In zippy:
dmp-padderise2.el:44:5: Warning: reference to free variable ‘calamansi’

In dmp-padderise--inside-comment-or-string-p:
dmp-padderise2.el:63:51: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--inside-comment-p:
dmp-padderise2.el:86:15: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--deletes-comment-lines:
dmp-padderise2.el:153:31: Warning: assignment to free variable
    ‘dmp-comment-line-regexp’
dmp-padderise2.el:153:13: Warning: reference to free variable
    ‘dmp-comment-line-regexp’

In dmp-padderise--deletes-hash-lines:
dmp-padderise2.el:176:25: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In dmp-padderise--comment-hash-lines:
dmp-padderise2.el:204:56: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:212:15: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:216:15: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:218:24: Warning: reference to free variable ‘p0’
dmp-padderise2.el:218:27: Warning: reference to free variable ‘p1’

In dmp-padderise--uncomment-hash-lines:
dmp-padderise2.el:230:11: Warning: assignment to free variable ‘count’
dmp-padderise2.el:234:135: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:247:4: Warning: reference to free variable ‘condition-case’
dmp-padderise2.el:247:19: Warning: reference to free variable ‘err4’
dmp-padderise2.el:250:18: Warning: reference to free variable ‘old-ptr’
dmp-padderise2.el:250:26: Warning: reference to free variable ‘new-ptr’
dmp-padderise2.el:251:18: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:253:48: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:255:32: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:255:48: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-gulp-code--safe:
dmp-padderise2.el:264:21: Warning: reference to free variable ‘old-ptr’
dmp-padderise2.el:264:29: Warning: reference to free variable ‘new-ptr’
dmp-padderise2.el:268:51: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--inside-symbol:
dmp-padderise2.el:286:38: Warning: ‘block’ is an obsolete alias (as of 27.1);
    use ‘cl-block’ instead.
dmp-padderise2.el:314:24: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:305:36: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:312:22: Warning: ‘return’ is an obsolete alias (as of 27.1);
    use ‘cl-return’ instead.
dmp-padderise2.el:318:20: Warning: ‘return’ is an obsolete alias (as of 27.1);
    use ‘cl-return’ instead.

In dmp-padderise--turn-one-line-to-many-lines:
dmp-padderise2.el:328:43: Warning: reference to free variable
    ‘*dmp-defun-outer-regexp*’
dmp-padderise2.el:331:30: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:331:30: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--wrap-spaces-around-inner-sexps:
dmp-padderise2.el:416:53: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:442:27: Warning: assignment to free variable
    ‘keyword-symbol’
dmp-padderise2.el:447:20: Warning: reference to free variable ‘keyword-symbol’

In dmp-padderise--re-search-forward:
dmp-padderise2.el:735:25: Warning: assignment to free variable ‘done’
dmp-padderise2.el:487:47: Warning: reference to free variable
    ‘*dmp-defun-outer-regexp*’
dmp-padderise2.el:532:41: Warning: reference to free variable ‘points-list’
dmp-padderise2.el:558:37: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:632:36: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:661:23: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:665:23: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:667:49: Warning: reference to free variable ‘p0’
dmp-padderise2.el:667:52: Warning: reference to free variable ‘p1’
dmp-padderise2.el:669:35: Warning: assignment to free variable ‘str’
dmp-padderise2.el:669:35: Warning: reference to free variable ‘str’
dmp-padderise2.el:745:25: Warning: reference to free variable ‘done’

In dmp-padderise--adder-whitespace-before-symbol:
dmp-padderise2.el:773:55: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:785:30: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’

In dmp-splat-symbol-sexp:
dmp-padderise2.el:807:23: Warning: ‘end-of-buffer’ is for interactive use
    only; use ‘(goto-char (point-max))’ instead.

In dmp-padderise--king-splodge:
dmp-padderise2.el:828:17: Warning: assignment to free variable ‘ket’
dmp-padderise2.el:836:19: Warning: assignment to free variable ‘bra’
dmp-padderise2.el:837:21: Warning: reference to free variable ‘bra’
dmp-padderise2.el:837:25: Warning: reference to free variable ‘ket’

In dmp-padderise--create-hashcodes:
dmp-padderise2.el:889:12: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:887:82: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In dmp-padderise--add-gaps-to-m4-stuff:
dmp-padderise2.el:954:8: Warning: ‘beginning-of-buffer’ is for interactive use
    only; use ‘(goto-char (point-min))’ instead.
dmp-padderise2.el:995:17: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:995:17: Warning: ‘beginning-of-buffer’ is for interactive
    use only; use ‘(goto-char (point-min))’ instead.

In dmp-padderise--bra+ket:
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.

In dmp-padderise--skip-based-on-keyword--defun:
dmp-padderise2.el:1055:17: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:1078:16: Warning: reference to free variable ‘p0’
dmp-padderise2.el:1116:17: Warning: assignment to free variable ‘endy’
dmp-padderise2.el:1061:37: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:1063:24: Warning: assignment to free variable ‘skip’
dmp-padderise2.el:1066:17: Warning: reference to free variable ‘skip’
dmp-padderise2.el:1066:17: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1106:15: Warning: assignment to free variable ‘count’
dmp-padderise2.el:1112:17: Warning: reference to free variable ‘count’

In dmp-padderise--doit:
dmp-padderise2.el:1130:11: Warning: assignment to free variable ‘ptr2’
dmp-padderise2.el:1139:11: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1139:16: Warning: ‘remove-if-not’ is an obsolete function
    (as of 27.1); use ‘cl-remove-if-not’ instead.
dmp-padderise2.el:1146:23: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1156:13: Warning: assignment to free variable ‘*file-name*’

In dmp-padderise--endy:
dmp-padderise2.el:1201:6: Warning: dmp-padderise--re-search-forward called
    with 3 arguments, but accepts only 1

In dmp-padderise--split-el-files:
dmp-padderise2.el:1209:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1213:25: Warning: reference to free variable ‘ptr’

In dmp-padderise--scan-for-vspaces:
dmp-padderise2.el:1296:20: Warning: assignment to free variable
    ‘dmp-padderise--listing*’
dmp-padderise2.el:1268:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1270:22: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1300:53: Warning: assignment to free variable ‘buf’
dmp-padderise2.el:1296:10: Warning: reference to free variable ‘buf’
dmp-padderise2.el:1274:18: Warning: reference to free variable
    ‘*dmp-padderise--listing*’
dmp-padderise2.el:1292:49: Warning: assignment to free variable ‘p’
dmp-padderise2.el:1290:32: Warning: reference to free variable ‘p’
dmp-padderise2.el:1302:17: Warning: assignment to free variable ‘str’
dmp-padderise2.el:1302:17: Warning: reference to free variable
    ‘dmp-padderise--listing*’
dmp-padderise2.el:1300:41: Warning: reference to free variable ‘str’

In dmp-padderise--delete-hash-comments:
dmp-padderise2.el:1321:16: Warning: ‘remove-if’ is an obsolete function (as of
    27.1); use ‘cl-remove-if’ instead.
dmp-padderise2.el:1333:42: Warning: assignment to free variable ‘regexp-inner’
dmp-padderise2.el:1333:42: Warning: reference to free variable ‘regexp-inner’
dmp-padderise2.el:1355:35: Warning: assignment to free variable ‘regexp-outer’
dmp-padderise2.el:1373:22: Warning: reference to free variable ‘regexp-outer’
dmp-padderise2.el:1375:10: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In buffer->sexp:
dmp-padderise2.el:1446:13: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1442:21: Warning: assignment to free variable ‘done’
dmp-padderise2.el:1442:21: Warning: reference to free variable ‘done’
dmp-padderise2.el:1436:48: Warning: assignment to free variable ‘str’
dmp-padderise2.el:1436:65: Warning: assignment to free variable ‘form’
dmp-padderise2.el:1443:17: Warning: reference to free variable ‘str’
dmp-padderise2.el:1444:17: Warning: reference to free variable ‘form’
dmp-padderise2.el:1446:27: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1453:67: Warning: assignment to free variable ‘result-pairs’
dmp-padderise2.el:1453:27: Warning: reference to free variable ‘result-pairs’
dmp-padderise2.el:1453:44: Warning: assignment to free variable
    ‘output-of-string->sexp’
dmp-padderise2.el:1453:8: Warning: assignment to free variable
    ‘result-delve-deep’

In delve-deep:
dmp-padderise2.el:1460:10: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1462:20: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1469:33: Warning: assignment to free variable ‘car’
dmp-padderise2.el:1469:33: Warning: reference to free variable ‘car’
dmp-padderise2.el:1465:15: Warning: assignment to free variable ‘comment’
dmp-padderise2.el:1469:15: Warning: assignment to free variable ‘code’
dmp-padderise2.el:1472:34: Warning: reference to free variable ‘code’
dmp-padderise2.el:1472:11: Warning: assignment to free variable ‘result’
dmp-padderise2.el:1476:8: Warning: assignment to free variable ‘result’

In delve-deep-str:
dmp-padderise2.el:1491:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1495:22: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1501:9: Warning: assignment to free variable
    ‘**dmp-padderise--bra-less-bra-ket**’
dmp-padderise2.el:1502:9: Warning: assignment to free variable
    ‘**dmp-padderise--bra-plus-bra-ket**’
dmp-padderise2.el:1503:9: Warning: assignment to free variable
    ‘**dmp-padderise--ket**’
dmp-padderise2.el:1504:37: Warning: reference to free variable
    ‘**dmp-padderise--bra-less-bra-ket**’
dmp-padderise2.el:1513:25: Warning: assignment to free variable ‘sexp’
dmp-padderise2.el:1512:8: Warning: reference to free variable ‘sexp’
dmp-padderise2.el:1545:36: Warning: assignment to free variable
    ‘dmp-padderise--list’
dmp-padderise2.el:1536:19: Warning: assignment to free variable ‘p-0’
dmp-padderise2.el:1540:19: Warning: assignment to free variable ‘p-1’
dmp-padderise2.el:1542:21: Warning: reference to free variable ‘p-0’
dmp-padderise2.el:1542:25: Warning: reference to free variable ‘p-1’
dmp-padderise2.el:1554:33: Warning: reference to free variable
    ‘dmp-padderise--list’
dmp-padderise2.el:1556:51: Warning: assignment to free variable ‘popped’
dmp-padderise2.el:1556:51: Warning: reference to free variable ‘popped’
dmp-padderise2.el:1556:51: Warning: ‘decf’ is an obsolete alias (as of 27.1);
    use ‘cl-decf’ instead.
dmp-padderise2.el:1571:7: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:1579:15: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1595:16: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1602:30: Warning: assignment to free variable ‘match’
dmp-padderise2.el:1602:30: Warning: reference to free variable ‘match’
dmp-padderise2.el:1614:18: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:1618:18: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:1620:22: Warning: reference to free variable ‘p0’
dmp-padderise2.el:1620:25: Warning: reference to free variable ‘p1’

In dmp-padderise--doit:
dmp-padderise2.el:1640:8: Warning: function ‘dmp-padderise--doit’ defined
    multiple times in this file
dmp-padderise2.el:1747:3: Error: Invalid read syntax: ")", 1747, 3


To run that file alone is impossible as it gives me error:

cons: Symbol’s function definition is void: dmp-canonicalise

I am invoking your file M-x eval-buffer as there is no other
recommended way.

You have (progn) statement at beginning, and I recommend putting that
statement in a function, and that function to become (interactive) so
that it may be invoked. 

Recommended reading and recommended to apply:
(info "(elisp) Packaging Basics") <---- evaluate here to reach to info
file.

Some other notes related to your package:
;; Keywords: Cull Size Quota

Keywords cannot be just any keywords, those shall be keywords as
listed by function M-x finder-list-keywords, such as following:

abbrev	      abbreviation handling, typing shortcuts, and macros
bib	      bibliography processors
c	      C and related programming languages
calendar      calendar and time management tools
comm	      communications, networking, and remote file access
convenience   convenience features for faster editing
data	      editing data (non-text) files
docs	      Emacs documentation facilities
emulations    emulations of other editors
extensions    Emacs Lisp language extensions
faces	      fonts and colors for text
files	      file editing and manipulation
frames	      Emacs frames and window systems
games	      games, jokes and amusements
hardware      interfacing with system hardware
help	      Emacs help systems
hypermedia    links between text or other media types
i18n	      internationalization and character-set support
internal      code for Emacs internals, build process, defaults
languages     specialized modes for editing programming languages
lisp	      Lisp support, including Emacs Lisp
local	      code local to your site
maint	      Emacs development tools and aids
mail	      email reading and posting
matching      searching, matching, and sorting
mouse	      mouse support
multimedia    images and sound
news	      USENET news reading and posting
outlines      hierarchical outlining and note taking
processes     processes, subshells, and compilation
terminals     text terminals (ttys)
tex	      the TeX document formatter
tools	      programming tools
unix	      UNIX feature interfaces and emulators
vc	      version control
wp	      word processing


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> * Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
>> http://davinpearson.nz/binaries/dmp-padderise2.el
>
> After the first review of that file, I can see "Copyright" related to
> your name. However, that makes the software proprietary.

Nonsense.  It is perfectly fine to have individual authors and
contributors as copyright holders.  Only if a package wants to become
part of emacs (GNU ELPA), one has to assign the copyright to the FSF.
But it would still be fine for NonGNU ELPA if it had a proper license
statement (which is the actual missing part).

However, that file is basically a demo for debugging by adding a printed
message after each line with no intention of becoming part of emacs, so
¯\_(ツ)_/¯.

Bye,
Tassilo

NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tassilo Horn wrote:

> But it would still be fine for NonGNU ELPA if it had
> a proper license statement (which is the actual missing
> part).

What's this NonGNU ELPA I keep hearing about lately?

I only have GNU ELPA and MELPA and GNU ELPA is added by
default so I have just done

  (push '("melpa" . "https://melpa.org/packages/") package-archives)

so far.

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-15 02:32]:
> Tassilo Horn wrote:
> 
> > But it would still be fine for NonGNU ELPA if it had
> > a proper license statement (which is the actual missing
> > part).
> 
> What's this NonGNU ELPA I keep hearing about lately?

Maybe winter sleep took you too long.

NonGNU Emacs Lisp Package Archive is the answer to issues otherwise
not handled on MELPA, for example, this repository will include any
kind of packages but not steer users to vague licensed packages or
proprietary software.

More information: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org

* Guidance for accepting packages

** We don't ask for copyright assignments to include packages in NonGNU ELPA.

** The Emacs maintainers will decide what packages to put in NonGNU ELPA.

** If an ELisp package follows the rules below,
  we can add it to NonGNU ELPA if we want to.  If the code doesn't
  follow them, we can change the code to follow them.  We may also
  change the code in NonGNU ELPA for other reasons, technical or not.
  After all, it is free software.

** For practical reasons, we usually refrain from making local changes
  to NonGNU ELPA packages, in order to simplify integration of future
  changes from the upstream version.

** The package's developers don't have an obligation to maintain the
  NonGNU ELPA version, but we would like to invite them to do that, or
  to cooperate and coordinate with us in doing that.  If you are the
  developer of a NonGNU ELPA package, or a package that might be added
  to NonGNU ELPA, and you're interested in maintaining it there, let's
  discuss it.

** Rules for a package to be acceptable in NonGNU ELPA

*** A NonGNU ELPA package must display its copyright notices and license
   notices clearly on each nontrivial file.  The notices do not have to
   follow the FSF conventions about their presentation.

   Software files need to carry a free license that is compatible with the
   GNU GPL version 3-or-later.  Which licenses qualify is stated in
   https://gnu.org/licenses/license-list.html.

   Manuals need to be under a free license that is compatible
   with the GNU FDL version 1.4-or-later.  Which licenses qualify is
   stated in https://gnu.org/licenses/license-list.html.

   All other documentation files, for users (manuals, help files, man
   pages, and so on), and for developers (program logic, change logs,
   and so on), can be under a license acceptable for manuals or a
   license acceptable for software files (see above).  We can agree
   with the package developers to include documentation published under
   other free licenses.

   Trivial files of just a few lines don't need to state a copyright or
   a license.

   Normally we don't include material other than software or
   documentation, but we can agree with the developers to include
   specific material.  If the material in question is an educational
   resource, then it can have a license compatible with GNU FDL version
   1.4 or one of the free Creative Commons licenses (CC-BY-SA, CC-BY or
   CC-0), or another free license at our discretion.  If the material is
   not an educational resource, it can instead be licensed under
   CC-BY-ND.

*** The package need not follow the GNU Coding Standards or the GNU
   Maintainers Guide, except for a few specific points as stated below.

*** The package must follow the rules in
   https://www.gnu.org/prep/standards/, node References.  This means it
   may not refer users to any nonfree software or nonfree
   documentation, except as stated there.  Leading users to run a
   program, and suggesting they run it, or depending on it to be
   installed, are forms of referring users to it.

*** Aside from packages obtained from GNU ELPA and NonGNU ELPA,
   a package may not run code that it has fetched over the internet.

   In particular, the package may install other packages in GNU ELPA and
   NonGNU ELPA, but not any other software.

   We will consider exceptions to that rule, but we will need to
   consider them carefully, to make sure that the practices are
   safe for Emacs users, not just in one package but when used in
   many packages.  Each time we approve such an exception, we will
   say so in comments in the package, with an explanation of our reasoning.

*** The package must deliver its full functionality and convenience on a
   completely free platform based on the GNU operating system (in
   practice, GNU/Linux), working exclusively with other free software.
   Otherwise, it would act as an inducement to install nonfree systems
   or other nonfree software, and that would work against our cause.

   However, as an exception it is ok for a package to provide, on some
   non-GNU operating systems, features that the rest of Emacs (plus GNU
   ELPA and NonGNU ELPA) already supports on GNU.

   This is a moral issue.  See https://www.gnu.org/prep/standards/,
   node System Portability.  The reason for this rule is that at no
   time, in no way, should a NonGNU ELPA package put users who defend
   their freedom at a disadvantage compared with those who surrender
   their freedom.

*** The package may communicate with a class of remote services, either
   using a standard interface or using an ad-hoc interface for each
   service, or a combination, *provided* that these services' jobs
   consist of either communication or lookup of published data.

   The package may not use remote services to do the user's own
   computational processing.  "Your own computational processing" means
   anything you could _in principle_ do in your own computers by
   installing and running suitable software, without communicating with
   any other computers.

*** A general Savannah rule about advertisements

   In general, you may not advertise anything commercial with material
   in the NonGNU ELPA package or this repository.  However, as
   exceptions, you can point people to commercial support offerings for
   the package, and you can mention fan items that you sell directly to
   the users.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> What's this NonGNU ELPA I keep hearing about lately?
>
> Maybe winter sleep took you too long.
>
> NonGNU Emacs Lisp Package Archive is the answer to issues
> otherwise not handled on MELPA, for example, this repository
> will include any kind of packages but not steer users to
> vague licensed packages or proprietary software.

Okay, sounds good, maybe I should put my stuff there?

Since maybe GNU ELPA has too high standards ... (for all
of it? depressing if so)

And MELPA - I actually tried - but couldn't figure out the
submit process and lost interest ...

Here are 9 Elisp packs (including 1 major mode for editing
code)

  https://dataswamp.org/~incal/emacs-packs/

I think we did this at least once before so the packs should
be ready formally, however if they aren't do tell and I'll be
happy to use the hjälpsam assistant :)

Please check them out and tell me how to submit them, if you
know how ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-17 06:49]:
> Here are 9 Elisp packs (including 1 major mode for editing
> code)
> 
>   https://dataswamp.org/~incal/emacs-packs/

Call it "packages" please.

> I think we did this at least once before so the packs should
> be ready formally, however if they aren't do tell and I'll be
> happy to use the hjälpsam assistant :)

Hjälpsam was written especially for you. 😛

> Please check them out and tell me how to submit them, if you
> know how ...

Of course, you write email to emacs-devel@gnu.org with the subject:
[ELPA] new package buc.el

and then make sure you submit papers to assign copyrights to FSF, they
will protect it hopefully, even if you become unavailable in some far
Asian country.

Now for review:

- xsel.el -- it does not have proper headers, you only mentioned
  license by its abbreviation, but that is not recommended. Sorry if I
  mixed something, though this is how it should look like.

Example header for xsel.el:
--------------------------

;;; xsel.el --- use the X clipboard -*- lexical-binding: t -*-

;; Copyright (C) 2021 by Emanuel Berg (incal) <moasenwood@zoho.eu>

;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
;; Version: 2.3.7.
;; Package-Requires:
;; Keywords: unix
;; URL: https://dataswamp.org/~incal/emacs-packs/buc.el

;; This file is not part of GNU Emacs.

;; This program is free software: you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation, either version 3 of the
;; License, or (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;;; This gives you access to the X clipboard from a Linux
;;; VT/console/tty Emacs instance (or any Emacs, possibly).
;;; Set and/or Insert the X clipboard at point.
;;;
;;; DWIM: If there is a region, replace it with the
;;; X clipboard.
;;;
;;; Feature: Set the X clipboard programmatically in Elisp or
;;; set it interactively to the contents of the region (if
;;; there is one), otherwise set it to the most recent
;;; Emacs kill.
;;;
;;; Use $DISPLAY or ":0" with xsel(1x).
;;;

;;; Change Log:

;;; Code:



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

> ;;; This gives you access to the X clipboard from a Linux
> ;;; VT/console/tty Emacs instance (or any Emacs, possibly).
> ;;; Set and/or Insert the X clipboard at point.

ELisp convention is to use ";;;" (and more) for section headers.
So please use just ";;" for normal comments.

> ;;; DWIM: If there is a region, replace it with the
> ;;; X clipboard.
> ;;;
> ;;; Feature: Set the X clipboard programmatically in Elisp or
> ;;; set it interactively to the contents of the region (if
> ;;; there is one), otherwise set it to the most recent
> ;;; Emacs kill.
> ;;;
> ;;; Use $DISPLAY or ":0" with xsel(1x).

Sounds similar to GNU ELPA's `xclip.el`.
Any chance the two could be merged?


        Stefan

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> ;;; DWIM: If there is a region, replace it with the
>> ;;; X clipboard.
>> ;;;
>> ;;; Feature: Set the X clipboard programmatically in Elisp or
>> ;;; set it interactively to the contents of the region (if
>> ;;; there is one), otherwise set it to the most recent
>> ;;; Emacs kill.
>> ;;;
>> ;;; Use $DISPLAY or ":0" with xsel(1x).
>
> Sounds similar to GNU ELPA's `xclip.el`.
> Any chance the two could be merged?

Don't know but if you say so ... so, okay?

Don't know if/how much the base shell tools differ either,
xclip(1) and xsel(1x), maybe the Elisp solutions are
interface-exchangeable even.

$ sudo aptitude more xclip xsel
i   xclip - command line interface to X selections
i   xsel  - command-line tool to access X clipboard a

$ xclip -version
  xclip version 0.13
  Copyright (C) 2001-2008 Kim Saunders et al.
  Distributed under the terms of the GNU GPL

$ xsel --version
  xsel version 1.2.0 by Conrad Parker <conrad@vergenet.net>

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Sounds similar to GNU ELPA's `xclip.el`.
>> Any chance the two could be merged?
>
> Don't know but if you say so ... so, okay?

Obviously you won't know before you actually look at it.

> Don't know if/how much the base shell tools differ either,
> xclip(1) and xsel(1x), maybe the Elisp solutions are
> interface-exchangeable even.

I strongly recommend looking at `xclip.el` before going any further,
because opinions derived just from the name of a package tend to be
rather ... brittle.


        Stefan

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> Don't know if/how much the base shell tools differ either,
>> xclip(1) and xsel(1x), maybe the Elisp solutions are
>> interface-exchangeable even.
>
> I strongly recommend looking at `xclip.el` before going any
> further, because opinions derived just from the name of
> a package tend to be rather ... brittle.

:)

But this is an interesting situation. There are two Linux
tools. Should there be one Elisp package that works with
either, or should there be one for each?

Yeah, I'll look into it ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

Emanuel Berg via Users list for the GNU Emacs text editor [2022-01-21 22:32:42] wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
>> I strongly recommend looking at `xclip.el` before going any
>> further, because opinions derived just from the name of
>> a package tend to be rather ... brittle.
> :)
> But this is an interesting situation. There are two Linux
> tools. Should there be one Elisp package that works with
> either, or should there be one for each?

It's even more twisted than that: according to
http://elpa.gnu.org/packages/xclip.html, `xclip.el` already supports
four of those two GNU/Linux tools.


        Stefan

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>> I strongly recommend looking at `xclip.el` before going any
>>> further, because opinions derived just from the name of
>>> a package tend to be rather ... brittle.
>>
>> :)
>>
>> But this is an interesting situation. There are two Linux
>> tools. Should there be one Elisp package that works with
>> either, or should there be one for each?
>
> It's even more twisted than that: according to
> http://elpa.gnu.org/packages/xclip.html, `xclip.el` already
> supports four of those two GNU/Linux tools.

Hahaha :D

Now I really must check it out ...

But - a distant bell rings - I heard somewhere that these not
exactly hackish workarounds - or actually they are
clever hacks! - I heard they were not needed since Emacs
provided this out of the box. I remember I tested, but it
didn't work.

Maybe that is because of the configuration option
--with-x-toolkit=no (actually I don't know when I started with
that, I remember the emacs-nox package ... - that's "no X" -
but now comes yet another twist, I, who configure/compile like
that since I just use Emacs in a Linux VT/tty/console with no
need for that it would seem, I use that stuff (xsel.el) every
day.

Literally! It isn't really necessary for life/work, the 19/20
use case is to watch some video material I find on the net or
someone tells me to check out so I get a sneak peak with mp3
before I decide to download it or not.

So maybe I and people with similar "habits" should compile
with the X stuff?

But if everyone does, what is the deal with xclip.el and
xsel.el ? Can everyone stop using them if everyone just
compiled with the X stuff?

Here, no sneak peak, _instant download_. Gigi Hadid and
progressive trance (progressive trance = repeats the same
pattern also in long loops, but all the while force and
intensity is increased. can you tell there is something fishy
going on?)

  https://dataswamp.org/~incal/vidz/fighting-fit-new-school.mp4
  
-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

The situation doesn't make any sense, I also use it from
Emacs-w3m where I save the URL of a YouTube song/music video
in Emacs-w3m [1] then I download it with a zsh function [2]
but, if we increase our altitude and look down on what then
happens, the Emacs-w3m stuff happens in the Emacs instance in
/dev/tty1 and the zsh stuff happens in tmux on top of
/dev/tty2 ... and the bridge is xsel.el [3] but X isn't even
visited or involved.

(Except it doesn't work if it isn't on.)

I can even play it in the console with mpv [4]

That song is "The Climb" by No Doubt BTW ... [5]

Which I proudly quote here [6]

If you think I'm running out of footnotes this way,
think again! Hey, it's FOSS. The plethora, annoying as it may,
is actually the strength, right?

:)

[1] https://dataswamp.org/~incal/emacs-init/w3m/w3m-url.el
    (hm ... seemingly strange that isn't this file:
     https://dataswamp.org/~incal/emacs-init/w3m/w3m-download.el )
[2] https://dataswamp.org/~incal/conf/.zsh/dl
[3] https://dataswamp.org/~incal/emacs-init/xsel.el
[4] https://dataswamp.org/~incal/#mpv
[5] https://www.youtube.com/watch?v=G0E1khrhE3c
[6] https://dataswamp.org/~incal/blog/tree-house/tree-house-rooftop.html

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:


> But - a distant bell rings - I heard somewhere that these not
> exactly hackish workarounds - or actually they are
> clever hacks! - I heard they were not needed since Emacs
> provided this out of the box. I remember I tested, but it
> didn't work.
>
> Maybe that is because of the configuration option
> --with-x-toolkit=no (actually I don't know when I started with
> that, I remember the emacs-nox package ... - that's "no X" -
> but now comes yet another twist, I, who configure/compile like
> that since I just use Emacs in a Linux VT/tty/console with no
> need for that it would seem, I use that stuff (xsel.el) every
> day.
>
> Literally! It isn't really necessary for life/work, the 19/20
> use case is to watch some video material I find on the net or
> someone tells me to check out so I get a sneak peak with mp3
> before I decide to download it or not.
>
> So maybe I and people with similar "habits" should compile
> with the X stuff?
>
> But if everyone does, what is the deal with xclip.el and
> xsel.el ? Can everyone stop using them if everyone just
> compiled with the X stuff?
>
> Here, no sneak peak, _instant download_. Gigi Hadid and
> progressive trance (progressive trance = repeats the same
> pattern also in long loops, but all the while force and
> intensity is increased. can you tell there is something fishy
> going on?)

I don't really understand what you're saying here, but introducing a
compile-time option that lets Emacs open an X display connection to
access selections without being able to create frames would be extremely
pointless, since if you can access selections, you already have
everything you need to create frames.

So the clean solution for accessing X selections is either to run Emacs
under X, or to use something like xclip.el.

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Po Lu wrote:

> I don't really understand what you're saying here

1) Think
2) Ask a friend
3) Ask the teacher

> but introducing a compile-time option that lets Emacs open
> an X display connection to access selections without being
> able to create frames would be extremely pointless, since if
> you can access selections, you already have everything you
> need to create frames.

Frames? You mean like web pages had in the 90s?

> So the clean solution for accessing X selections is either
> to run Emacs under X, or to use something like xclip.el.

This must be the cleanest, compile Emacs without X, use
xsel.el [1] to communicate from Emacs to X, and from X to
Emacs (it is a theoretical possibility not observed in the
wild), _and_ from Emacs to the other ttys - without passing X,
which still has to run for it to work.

Remember the SEGA slogan - "Beat us. If you can"

Same then. As now.

BTW xclip.el was written by Leo Liu ... I'll CC him.
Probably a cool guy. Developer.

[1] https://dataswamp.org/~incal/emacs-init/xsel.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Frames? You mean like web pages had in the 90s?

See the node "Frames and Graphical Displays" in the Emacs manual.

> This must be the cleanest, compile Emacs without X, use
> xsel.el [1] to communicate from Emacs to X, and from X to
> Emacs (it is a theoretical possibility not observed in the
> wild), _and_ from Emacs to the other ttys - without passing X,
> which still has to run for it to work.

If you're running Emacs under X (which most people should be doing
anyway), then the best solution would certainly to use the built-in X
selection support.

xsel.el is only clean if you're running Emacs without X for whatever
reason.

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Po Lu wrote:

>> This must be the cleanest, compile Emacs without X, use
>> xsel.el [1] to communicate from Emacs to X, and from X to
>> Emacs (it is a theoretical possibility not observed in the
>> wild), _and_ from Emacs to the other ttys - without passing
>> X, which still has to run for it to work.
>
> If you're running Emacs under X (which most people should be
> doing anyway), then the best solution would certainly to use
> the built-in X selection support.

1) Read
2) Think
3) ...

> xsel.el is only clean if you're running Emacs without X for
> whatever reason.

Recommended move:

  https://en.wikipedia.org/wiki/Clueless

Alicia Silverstone.

That's right! Positive thinking, man ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> 1) Read
> 2) Think
> 3) ...

[...]

> Recommended move:
>
>   https://en.wikipedia.org/wiki/Clueless
>
> Alicia Silverstone.
>
> That's right! Positive thinking, man ...

I have no idea what you are trying to get across.

Re: NonGNU ELPA

[Jean Louis]

* Po Lu <luangruo@yahoo.com> [2022-01-22 09:34]:
> If you're running Emacs under X (which most people should be doing
> anyway), then the best solution would certainly to use the built-in X
> selection support.

I have set Emacs to duplicate any selection so that I can re-use it
from terminal to Emacs and vice versa. It works well, I cannot be
sure, but it may be this option below:

Hide Select Enable Clipboard: Boolean: Toggle  on (non-nil)
    State : STANDARD.
   Non-nil means cutting and pasting uses the clipboard. Hide
   This can be in addition to, but in preference to, the primary selection,
   if applicable (i.e. under X11).
Groups: Killing



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> I have set Emacs to duplicate any selection so that I can re-use it
> from terminal to Emacs and vice versa. It works well, I cannot be
> sure, but it may be this option below:
>
> Hide Select Enable Clipboard: Boolean: Toggle  on (non-nil)
>     State : STANDARD.
>    Non-nil means cutting and pasting uses the clipboard. Hide
>    This can be in addition to, but in preference to, the primary selection,
>    if applicable (i.e. under X11).
> Groups: Killing

That has been enabled by default for a while now.  Basically it resolves
the problem where Emacs was the last program to not adopt the "standard"
interpretation of how the various X selections should be used.

Re: NonGNU ELPA

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-22 08:41]:
> > but introducing a compile-time option that lets Emacs open
> > an X display connection to access selections without being
> > able to create frames would be extremely pointless, since if
> > you can access selections, you already have everything you
> > need to create frames.
> 
> Frames? You mean like web pages had in the 90s?

Not those frames... 😅


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> but introducing a compile-time option that lets Emacs open
>>> an X display connection to access selections without being
>>> able to create frames would be extremely pointless, since
>>> if you can access selections, you already have everything
>>> you need to create frames.
>> 
>> Frames? You mean like web pages had in the 90s?
>
> Not those frames... 😅

The diamond frame?

  https://dataswamp.org/~incal/work-photos/fixie.jpg

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-22 16:49]:
> Jean Louis wrote:
> 
> >>> but introducing a compile-time option that lets Emacs open
> >>> an X display connection to access selections without being
> >>> able to create frames would be extremely pointless, since
> >>> if you can access selections, you already have everything
> >>> you need to create frames.
> >> 
> >> Frames? You mean like web pages had in the 90s?
> >
> > Not those frames... 😅
> 
> The diamond frame?
> 
>   https://dataswamp.org/~incal/work-photos/fixie.jpg

Heh, that is a good function.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

> So the clean solution for accessing X selections is either to run Emacs
> under X, or to use something like xclip.el.

Indeed `xclip.el` already covers the case where you want to use of
Emacs's own X code to access the X selection when Emacs itself is "only"
running in a tty (i.e. `xclip.el` internally creates a hidden frame on
the X display).

The question w.r.t `xsel.el` is whether the functionality it offers via
`xsel` is different from that offered by `xclip.el` (eithef via `xsel`
or via other means), and if so whether the two shoud be combined/merged
or kept separate (like `gpastel.el` is currently kept separate).


        Stefan

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> The question w.r.t `xsel.el` is whether the functionality it
> offers via `xsel` is different from that offered by
> `xclip.el` (eithef via `xsel` or via other means), and if so
> whether the two shoud be combined/merged or kept separate
> (like `gpastel.el` is currently kept separate).

xsel.el is only 85 lines (including the bulk of standard
documentation) so please find out ...

It is a getter, a setter, two Emacs-specific applications and
a shorthand.

Very basic one would think?

;;; xsel.el --- use the X clipboard -*- lexical-binding: t -*-
;;;
;;; Commentary:
;;;
;;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
;;; Created: 2021-05-04
;;; Keywords: unix
;;; License: GPL3+
;;; URL: https://dataswamp.org/~incal/emacs-init/xsel.el
;;; Version: 2.3.7
;;;
;;; This gives you access to the X clipboard from a Linux
;;; VT/console/tty Emacs instance (or any Emacs, possibly).
;;; Set and/or Insert the X clipboard at point.
;;;
;;; DWIM: If there is a region, replace it with the
;;; X clipboard.
;;;
;;; Feature: Set the X clipboard programmatically in Elisp or
;;; set it interactively to the contents of the region (if
;;; there is one), otherwise set it to the most recent
;;; Emacs kill.
;;;
;;; Use $DISPLAY or ":0" with xsel(1x).
;;;
;;; Code:

(let ((xsel-x-display (or (getenv "DISPLAY") ":0")))
  (defun insert-x-clipboard ()
    "Insert the X clipboard at point using xsel(1x).
If there is a region it is overwritten."
    (interactive)
    (when (use-region-p)
      (delete-region (region-beginning) (region-end)) )
    (shell-command
     (format "xsel --display \"%s\" --clipboard -o" xsel-x-display)
     1) ; insert in current buffer
    (goto-char (mark)) )
  (declare-function insert-x-clipboard nil)

  (defun set-x-clipboard (str)
    "Set the X clipboard to STR. When used interactively, STR
is either what is in the region, if available, if not the most
recent Emacs kill is used."
    (interactive
     (list (if (use-region-p)
               (buffer-substring-no-properties (region-beginning) (region-end))
             (encode-coding-string (current-kill 0 t) 'utf-8-unix) )))
    (shell-command
     (format "echo -n %s | xsel --display %s -b -i"
             (shell-quote-argument str)
             xsel-x-display) ))
  (declare-function set-x-clipboard nil) )

(defun x-copy (&optional beg end)
  "Copy the buffer text from BEG to END to the X clipboard.
Unless optional arguments are provided the whole buffer text is used."
  (interactive (when (use-region-p)
                 (list (region-beginning) (region-end)) ))
  (let ((b (or beg (point-min)))
        (e (or end (point-max))) )
    (set-x-clipboard (buffer-substring b e) )))

(defun x-copy-symbol (sym)
  "Copy the value of SYM to the X clipboard."
  (interactive "S Symbol: ")
  (let*((val (symbol-value sym))
        (str (format "%s" val)) )
    (set-x-clipboard str) ))
;; (progn (x-copy-symbol 'fill-column)         (insert-x-clipboard))
;; (progn (call-interactively #'x-copy-symbol) (insert-x-clipboard))

(defun x-clipboard-dwim ()
  "If the region is active, set the X clipboard, if not, insert it."
  (interactive)
  (call-interactively
   (if (use-region-p)
       #'set-x-clipboard
     #'insert-x-clipboard) ))

(defalias 'x  #'x-clipboard-dwim)
(defalias 'xo #'insert-x-clipboard)

(provide 'xsel)
;;; xsel.el ends here

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>> I strongly recommend looking at `xclip.el` before going
>>> any further, because opinions derived just from the name
>>> of a package tend to be rather ... brittle.
>>
>> :)
>>
>> But this is an interesting situation. There are two Linux
>> tools. Should there be one Elisp package that works with
>> either, or should there be one for each?
>
> It's even more twisted than that: according to
> http://elpa.gnu.org/packages/xclip.html, `xclip.el` already
> supports four of those two GNU/Linux tools.

But ... the correct way is to merge, right, because the
solution should be in terms of the problem, not what
technology happens to make it possible?

The more the merrier! Emacs, Linux (GNU/Linux) and zsh, all
maximalist projects, like that song. I wouldn't go so far as
to say she is the minimalized interface - rather a power
player in her on right.

So bring everything in and have the interface sort it out ...

"What you once feared, now makes you free"

https://dataswamp.org/~incal/vidz/fighting-fit-new-school.mp4

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

> The more the merrier! Emacs, Linux (GNU/Linux) and zsh, all
> maximalist projects, like that song. I wouldn't go so far as
> to say she is the minimalized interface - rather a power
> player in her on right.

    <incal> ,, hist Emacs, GNU Emacs, XEmacs, zsh, Linux
    
      <sth> Emacs 1976 TECO EMACS Editor MACroS, keyboard
            shortcuts and Lisp. MIT
            
      <sth> GNU Emacs 1984 GNU Emacs. The first, and still
            poster project, of GNU
            
      <sth> XEmacs 1991 fork/split derived from GNU Emacs
            version 18
      
      <sth> zsh 1990 shell with many features
      
      <sth> Linux 1991 Monolithic Unix by enthusiasts/zealots

Should add XEmacs is finito ...

https://dataswamp.org/~incal/#bot

  B/W (1986):
  https://dataswamp.org/~incal/pimgs/dark-castle.png

Runs with the Mac Plus x86 Linux emulator.

Keep it real ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> ELisp convention is to use ";;;" (and more) for section
> headers. So please use just ";;" for normal comments.

Yeah ... correct.

-- 
underground experts united
https://dataswamp.org/~incal

NonGNU ELPA and release frequency

[Antoine Kalmbach]

Given that the details of NonGNU ELPA are still being fleshed out, has
there been any discussion on how often NonGNU ELPA packages are
released into the package repository?

Suppose I am a package author upstream on a package that isn't in GNU
ELPA.  This package is maintained in an external repository somewhere on
the net.  I release a new version, pushing the commit into the
repository.  Now the following things are unclear:

  1. If I want my changes to appear in NonGNU ELPA, should I:

     a. Send a patch with the changes to the appropriate mailing lists
        (emacs-devel or bug-gnu-emacs?)
     b. Send a request to pull the changes to ibid.
     c. Push changes to some reference
     d. Email a mailing list announcing the changes and wait for someone
        to update the package

  2. How often would NonGNU packages be updated? Will it be up to each
     individual package, or would there be recurring (e.g. monthly)
     "distributions" of the whole package set, so that a package and all
     its dependents would effectively be "frozen" until a regular
     update?

  3. Would NonGNU ELPA have some sort of automated build system for
     checking that packages meet some sort of quality checks, for
     instance, checking that packages can be byte compiled without
     errors, checking documentation using checkdoc, and verifying the
     license is appropriate, etc.

Do any of those questions make sense? Lately on several forums there has
been much discussion about MELPA and other third-party repositories, and
the nature of those discussions strongly indicates that NonGNU ELPA is
necessary and requires attention.

-- 
Antoine Kalmbach

Re: NonGNU ELPA and release frequency

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

  > Given that the details of NonGNU ELPA are still being fleshed out, has
  > there been any discussion on how often NonGNU ELPA packages are
  > released into the package repository?

That is not a meaningful question.  There is no place in the plan
for the sort of schedule that those words imply.

NonGNU ELPA would contain many packages, each managed in its own way.
Whoever has charge of any given package for NonGNU ELPA purposes will
be able to operate on it at any time.

    > 1. If I want my changes to appear in NonGNU ELPA, should I:

Your changes would be in some package.  The answer would depend on how
we are handling that package for NonGNU ELPA and what your
relationship to it is.

    > 3. Would NonGNU ELPA have some sort of automated build system for
    >    checking that packages meet some sort of quality checks, for
    >    instance, checking that packages can be byte compiled without
    >    errors, checking documentation using checkdoc, and verifying the
    >    license is appropriate, etc.

This remains to be decided.  We don't need to think about this
just for setting up NonGNU ELPA.

We would like people to volunteer to start setting it up.

-- 
Dr Richard Stallman
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 and release frequency

[Jean Louis]

My proposals for plan of action for ELPA on nongnu.org are following,
and they are not in any order:

- [ ] establish goals purposes for non-GNU ELPA.

  My proposal for purpose is to provide useful GNU Emacs packages as
  free software meant for inclusion into fully free and FSF endorsed
  free system distributions. Guidelines for free software system
  distributions on
  https://www.gnu.org/distros/free-system-distribution-guidelines.html
  should apply for non-GNU ELPA and for GNU ELPA as well.

- [ ] set up the mailing list for non GNU ELPA. My proposal would be:
  nongnu-elpa-devel@nongnu.org as maybe it would be good not to mix it
  with emacs-devel

- [ ] Find contact information of many developers and invite
  developers personally to contribute their packages, they can start
  contributing already by using the mailing list and collaborating
  with others.

- [ ] discuss the set of policies or principles for non-GNU ELPA. For
  example do we really want to see Python packages wrapped inside of
  the GNU Emacs package? I don't. 

- [ ] obtain server space for hosting of a website

- [ ] decide on sub domain or URL, it could for example
  https://elpa.nongnu.org

- [ ] replicate GNU ELPA website in similar fashon on ELPA on
  nongnu.org without changing much, keep informing public on the
  website of the project's progress

- [ ] provide hosting and shell access to set up git and free code
  hosting platform familiar to many developers using Github. Such free
  code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
  would prefer first. It looks similar to Github, look here:
  https://gitea.com/gitea/gitea-vet and there is problem with one
  Javascript, they have to be asked to publish the license properly.

- [ ] install such git hosting, install Gitea or Gitlab or other web based
  git whatever be decided as best

- [ ] use already made software for GNU ELPA to develop in same
  fashion for elpa.nongnu.org, as not to change drastically well
  established workflows

- [ ] propose improvements to workflows both on GNU ELPA and non-GNU
  ELPA, and collaborate with emacs-devel
  
- [ ] start distributing few packages, and keep including other
  packages

- [ ] when time seem right, include the package repository
  specification in GNU Emacs

- [ ] welcome and invite developers to switch to free hosting at
  nongnu.org

- [ ] welcome and invite developers to contribute their packages to
  GNU ELPA and transition their package. Futurem may become blended.

- [ ] keep doing all well established actions just as GNU ELPA is
  doing to provide more free software for purpose of expansion of
  fully free operating systems.

- [ ] add additional scripts or support to help various other
  GNU/Linux distributions to easily package both GNU ELPA and non-GNU
  ELPA packages

Jean

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 10:08:04 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> 
> My proposals for plan of action for ELPA on nongnu.org are following,
> and they are not in any order:

Would you like to volunteer to do some or all of this?

Some of what you mention was already done, look in the past
discussions here.  Examples:

> - [ ] establish goals purposes for non-GNU ELPA.

Done.

> - [ ] discuss the set of policies or principles for non-GNU ELPA.

Done.

>   For example do we really want to see Python packages wrapped
>   inside of the GNU Emacs package? I don't.

That's not policy, those are very low-level details.  (And I don't see
why Python should not be allowed.)

> - [ ] decide on sub domain or URL, it could for example
>   https://elpa.nongnu.org

Already done.

> - [ ] replicate GNU ELPA website in similar fashon on ELPA on
>   nongnu.org without changing much, keep informing public on the
>   website of the project's progress

Already decided.

Re: NonGNU ELPA and release frequency

[Jean Louis]

On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > 
> > My proposals for plan of action for ELPA on nongnu.org are following,
> > and they are not in any order:
> 
> Would you like to volunteer to do some or all of this?

I am ready.

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 05:06:25 -0700
> From: Jean Louis <bugs@rcdrun.com>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > > 
> > > My proposals for plan of action for ELPA on nongnu.org are following,
> > > and they are not in any order:
> > 
> > Would you like to volunteer to do some or all of this?
> 
> I am ready.

Thank you; please go ahead.

Re: NonGNU ELPA and release frequency

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-24 15:55]:
> > Date: Sat, 24 Oct 2020 05:06:25 -0700
> > From: Jean Louis <bugs@rcdrun.com>
> > Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> > 
> > On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > > > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > > > 
> > > > My proposals for plan of action for ELPA on nongnu.org are following,
> > > > and they are not in any order:
> > > 
> > > Would you like to volunteer to do some or all of this?
> > 
> > I am ready.
> 
> Thank you; please go ahead.

Tell me next steps.

On my side I am already making my personal review of packages and
making list of those wrapping non-free packages, and sorting them,
looking inside, compiling and looking which are useful. I will come up
with my list soon.

So far there is about 20 that are made for non-free software or that
would drive users to non-free, but I have just started reviewing it.

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 17:12:13 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> > > > Would you like to volunteer to do some or all of this?
> > > 
> > > I am ready.
> > 
> > Thank you; please go ahead.
> 
> Tell me next steps.

You had it all in your list of the tasks to be done, I think.  Just
pick up one of them, preferably near the beginning, and start working
on it.  When it's done, continue to the next one in the list.

We are here to help if you have questions.

> On my side I am already making my personal review of packages and
> making list of those wrapping non-free packages, and sorting them,
> looking inside, compiling and looking which are useful. I will come up
> with my list soon.
> 
> So far there is about 20 that are made for non-free software or that
> would drive users to non-free, but I have just started reviewing it.

Thanks, but I think the steps that set up the infrastructure should
come first.  We already have a few packages we know we'd like to have
there, so once the repository is ready, it won't be left empty for
long.

Re: NonGNU ELPA

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-24 17:17]:
> You had it all in your list of the tasks to be done, I think.  Just
> pick up one of them, preferably near the beginning, and start working
> on it.  When it's done, continue to the next one in the list.

My proposal is to have separate mailing list, I am not admin for
that. Is that fine to set, what do you think?

> Thanks, but I think the steps that set up the infrastructure should
> come first.  We already have a few packages we know we'd like to have
> there, so once the repository is ready, it won't be left empty for
> long.

Alright. When?

And which sub-domain or URL is destined for non-GNU ELPA? Is it maybe
elpa.nongnu.org ?

Re: NonGNU ELPA

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 17:21:38 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-10-24 17:17]:
> > You had it all in your list of the tasks to be done, I think.  Just
> > pick up one of them, preferably near the beginning, and start working
> > on it.  When it's done, continue to the next one in the list.
> 
> My proposal is to have separate mailing list, I am not admin for
> that. Is that fine to set, what do you think?

I don't think a separate mailing list is necessary at this time.
Let's see if the traffic related to this repository becomes
significant, and decide then.

> > Thanks, but I think the steps that set up the infrastructure should
> > come first.  We already have a few packages we know we'd like to have
> > there, so once the repository is ready, it won't be left empty for
> > long.
> 
> Alright. When?

Now?

> And which sub-domain or URL is destined for non-GNU ELPA? Is it maybe
> elpa.nongnu.org ?

Yes, I think that's what we wanted.

Re: NonGNU ELPA and release frequency

[Antoine Kalmbach]

Jean Louis <bugs@gnu.support> writes:

> - [ ] provide hosting and shell access to set up git and free code
>   hosting platform familiar to many developers using Github. Such free
>   code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
>   would prefer first. It looks similar to Github, look here:
>   https://gitea.com/gitea/gitea-vet and there is problem with one
>   Javascript, they have to be asked to publish the license properly.
>
> - [ ] install such git hosting, install Gitea or Gitlab or other web based
>   git whatever be decided as best
>

Is providing hosting necessary at this point? GNU already offers
Savannah. I think offering hosting in general is a good idea, but I am
wondering if this is necessary to get user traction for NonGNU ELPA. At
the very least, we should look at the infrastructure issues first.

GNU seems to be running Gitlab already at http://emba.gnu.org. It is
used to run CI tests for Emacs. I think it would be a good idea for
NonGNU ELPA (and ELPA as well) to have CI tests that do the following:

  * Run checkdoc on all files in the package
  * Try running `package-install-file' on every one of them
    (dependencies towards other (Non)GNU ELPA need to be figured out -
    if package A depends on B, we must run those tests first on B, etc.)
  * [NonGNU ELPA only] If package-lint[1] can be added to NonGNU ELPA
    that can also be run on the files

That way with running CI jobs we would make sure all packages there
work. That is, they work in the sense that `M-x package-install'ing them
will work.

Perhaps the Gitlab instance used at emba.gnu.org could also be used for
(Non)GNU ELPA CI tests at some point?

[1] https://github.com/purcell/package-lint

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Jean Louis]

* Antoine Kalmbach <ane@iki.fi> [2020-10-24 17:25]:
> Is providing hosting necessary at this point? GNU already offers
> Savannah.

That is what I meant.

And Gitlab or Gitea is convenient, and if such exists already it is
good. But that one responds on gnu.org domain, so people could mistake
it for being GNU software, which those packages are not yet.

-- 
Jean Louis

Re: NonGNU ELPA

[Antoine Kalmbach]

Jean Louis <bugs@gnu.support> writes:

> And Gitlab or Gitea is convenient, and if such exists already it is
> good. But that one responds on gnu.org domain, so people could mistake
> it for being GNU software, which those packages are not yet.

Ah, I only propose using the emba.gnu.org instance for CI tests, not
for hosting packages. The CI runs are just something that runs to verify
each update to (non)gnu elpa does not introduce broken pacakges. But this
Gitlab instance, due to the reason you state, is not suitable for
hosting non-GNU packages.

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Michael Albinus]

Antoine Kalmbach <ane@iki.fi> writes:

> Ah, I only propose using the emba.gnu.org instance for CI tests, not
> for hosting packages. The CI runs are just something that runs to verify
> each update to (non)gnu elpa does not introduce broken pacakges. But this
> Gitlab instance, due to the reason you state, is not suitable for
> hosting non-GNU packages.

An emba.nongnu.org gitlab instance (or whatever name) could be settled
up easily. The more interesting task it what to run in its CI.

Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
very similar tasks for GNU ELPA and NonGNU ELPA. Could you show a
respective .gitlab-ci.yml?

Best regards, Michael.

Re: NonGNU ELPA

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
> very similar tasks for GNU ELPA and NonGNU ELPA.

Indeed.  It would be good if someone could start implementing this.

Re: NonGNU ELPA

[Antoine Kalmbach]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
>> very similar tasks for GNU ELPA and NonGNU ELPA.
>
> Indeed.  It would be good if someone could start implementing this.

I think the gist of the ELPA CI would be something like:

  1. Clone the repository and emacs.git
  2. Build the package archive

These steps already have automation in place, since that's what is done
for building the ELPA index. Then, for the CI run,

  3. Start a batch Emacs instance and replace `package-archives' with
     (("elpa-test" . "/path/to/built/archive")) where that path points
     to the built package archive in step 2.

  4. Loop through each package and run `package-install` on it. 
  5. Optionally run also some linters etc., like checkdoc.

The good part about this is that it's essentially just taking existing
automation one step further, i.e. verifying each package in the
repository can actually be installed.  I have no idea what's going to
happen with cyclic dependencies though.  I suppose package.el can handle
all that.

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Michael Albinus]

Antoine Kalmbach <ane@iki.fi> writes:

Hi Antoine,

> I think the gist of the ELPA CI would be something like:
>
>   1. Clone the repository and emacs.git

Well, emacs.git is already cloned and compiled on emba.gnu.org
regularly. I guess we could use the artifacts of such a build for a
running Emacs.

And this step shall also take into account the external packages.

>   2. Build the package archive

Depends how it is called. If it is called for every push to the elpa
repository, it might not be wise to build always a whole archive. Just
the package in question shall be built.

> These steps already have automation in place, since that's what is done
> for building the ELPA index. Then, for the CI run,
>
>   3. Start a batch Emacs instance and replace `package-archives' with
>      (("elpa-test" . "/path/to/built/archive")) where that path points
>      to the built package archive in step 2.

The GNUmakefile knows already the target archive.

>   4. Loop through each package and run `package-install` on it.

Or do it for the package in question.

>   5. Optionally run also some linters etc., like checkdoc.

Yep. Some packages come with ERT tests, they could run.

> The good part about this is that it's essentially just taking existing
> automation one step further, i.e. verifying each package in the
> repository can actually be installed.  I have no idea what's going to
> happen with cyclic dependencies though.  I suppose package.el can handle
> all that.

Could you write an initial .gitlab-ci.yml? You might look at the
respective file in the Emacs repo (which also needs some improvements).

Thanks, and best regards, Michael.

Re: NonGNU ELPA

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Antoine,

> Could you write an initial .gitlab-ci.yml? You might look at the
> respective file in the Emacs repo (which also needs some improvements).

Sorry to urge you. This thread is about NonGNU ELPA, and I don't know
whether you intend to sign FSF legal papers.

Best regards, Michael.

Re: NonGNU ELPA

[Antoine Kalmbach]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Could you write an initial .gitlab-ci.yml? You might look at the
>> respective file in the Emacs repo (which also needs some improvements).
>
> Sorry to urge you. This thread is about NonGNU ELPA, and I don't know
> whether you intend to sign FSF legal papers.
>
> Best regards, Michael.

Paperwork is in progress, awaiting countersignature from FSF. I think it
will be done next week.

I'll try to have try at the .gitlab-ci.yml soon..ish.

-- 
Antoine Kalmbach

Re: NonGNU ELPA and release frequency

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

  > - [ ] replicate GNU ELPA website in similar fashon on ELPA on
  >   nongnu.org without changing much, keep informing public on the
  >   website of the project's progress

Maybe that would be a good way to start, but
we don't want NonGNU ELPA to work like GNU ELPA.

  > - [ ] provide hosting and shell access to set up git and free code
  >   hosting platform familiar to many developers using Github. Such free
  >   code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
  >   would prefer first.

One of the inconveniences with GNU ELPA is that it is a single repo.
Everyone who maintains a package in GNU ELPA needs write-access to the
whole repo.

In NonGNU ELPA, we want each package to have, effectively, its own
repo.  We want to distribute all the packages from a single place in
one single way, but no packages will be developed _in_ that place.
Each package will be developed in a repo somewhere else.  Some will be
on Savannah.  Some will be elsewhere (but insisting that maintenance
not require running nonfree JS code).

The Emacs maintainers will have full control over the NonGNU ELPA
web site, including deciding which packages to distribute, and
which repo to get each package from.

-- 
Dr Richard Stallman
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 and release frequency

[Ivan Yonchovski]

Richard Stallman writes:

> Each package will be developed in a repo somewhere else.  Some will be
> on Savannah.  Some will be elsewhere (but insisting that maintenance
> not require running nonfree JS code).

So, if someone wants to be in NonGNU elpa should not be using github? If
this is the case then why it is fine for ELPA package to be in github
but it won't be fine for NonGNU ELPA?

Thanks,
Ivan

Re: NonGNU ELPA and release frequency

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

  > So, if someone wants to be in NonGNU elpa should not be using github? If
  > this is the case then why it is fine for ELPA package to be in github
  > but it won't be fine for NonGNU ELPA?

I haven't come to a conclusion about that.  I see a few possibilities.

* If the Emacs maintainers who work on this package have Github accounts,
in principle we could deal with it on GitHub.

* We could make a repo on Savannah that has a more-or-less copy of the
GitHub repo, and our maintainers could when necessary make their
changes there.

It depends on whether the package maintainer is cooperating with us.
If so, the first option is possible.  If not, we would certainly do
the latter.

One question is, when we need to make our own changes in a package,
should we do those changes in NonGNU ELPA's repo itself,
or should we make a separate Savannah repo for our version of the package
so that NonGNU ELPA's is never anything but a mirror?

-- 
Dr Richard Stallman
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

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-26 07:11]:
> One question is, when we need to make our own changes in a package,
> should we do those changes in NonGNU ELPA's repo itself,
> or should we make a separate Savannah repo for our version of the package
> so that NonGNU ELPA's is never anything but a mirror?

- if there is emergency for change, such should be made first non
  NonGNU ELPA, and followed by notice or issue to the original
  author. As each package is supposed to have name and maybe email
  address, that should be preferred way, rather than asking users to
  sign up on Github through non-free Javascript. Emergency can be if
  the packages breaks some other packages or some safety reasons, as
  many users would be eventually accessing the NonGNU ELPA.

- if there is no emergency, changes shall be collaborated with the
  author, if there is no author, then maintainer

- if there is no way to neither collaborate with the author, or
  maintainer, then comes the change in the NonGNU ELPA

Re: NonGNU ELPA

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

  > - if there is emergency for change, such should be made first non
  >   NonGNU ELPA, and followed by notice or issue to the original
  >   author.

  > - if there is no emergency, changes shall be collaborated with the
  >   author, if there is no author, then maintainer

If we put a package into NonGNU ELPA without knowing what sort of
cooperation we could have with its current maintainers, we would have
to go through options like these at the time of making a change.

What I have in mind is that we would determine, before putting a
package into NonGNU ELPA, where we stand vis-a-vis the maintainers.
We would set up the handling of the package according to that.  Thus,
on encountering a problem that suggests changing the package, we would
know in advance how to handle the issue.

-- 
Dr Richard Stallman
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

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

No progress is happening on NonGNU ELPA.  We need someone who would
like to implement it.  Would someone like to do that?

-- 
Dr Richard Stallman
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

[Tim Van den Langenbergh]

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

On Friday, 11 September 2020 06:21:20 CEST Richard Stallman wrote:
> [[[ 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. ]]]
>
> No progress is happening on NonGNU ELPA.  We need someone who would
> like to implement it.  Would someone like to do that?
>
>

For other interested parties:
I seem to remember there being discussion about NonGNU ELPA needing a
repository system. Would it be sufficient to use git submodules for packages
that are in git source control and basic shell scripts for packages distributed
through Emacs Wiki?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: NonGNU ELPA

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

  > repository system. Would it be sufficient to use git submodules
  > for packages that are in git source control and basic shell
  > scripts for packages distributed through Emacs Wiki?

Here's the general plan.

    The basic idea is to set up a site for distribution of packages.
    It will not host development -- rather, each package will be developed
    somewhere else.  We should have a system to copy the package sources
    automatically from somewhere else.  What exactly it should do
    is one of the questions that needs deciding.

    Sometimes "somewhere else" will be the repo used by the package developers.
    We can do that when the developers are cooperating with us and we
    have confidence in them.

    Sometimes it will be a repo we set up on Savannah.  We will do this
    when (1) the developers cooperate with us and would like us to provide
    a repo to use, (2) the developers don't cooperate with us and we must
    not release their changes without checking them, or (3) we make our
    own changes in the package.  In cases of type (1), we will be able to
    give write access to each package to the developers of that package.

I don't know what git submodules do.  Maybe we could get the job done
using them, but I have the feeling it would be kludgy.

I know what shell scripts are but "basic shell scripts" doesn't
describe a method.  It seems reckless to mirror code from a wiki.


-- 
Dr Richard Stallman
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

[Göktuğ Kayaalp]

On 2020-09-14 06:50 +03, Richard Stallman <rms@gnu.org> wrote:
> Here's the general plan.
[... snip ...]

Wouldn’t this be just another MELPA, essentially?

-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: NonGNU ELPA

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

  > Wouldn’t this be just another MELPA, essentially?

Nothing like it.  We will decide which packages to put in
NonGNU ELPA, and we can modify the code if necessary.

THe plan was published here a few weeks ago.

-- 
Dr Richard Stallman
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

[Mingde (Matthew) Zeng]

>   > Wouldn’t this be just another MELPA, essentially?
>
> Nothing like it.  We will decide which packages to put in
> NonGNU ELPA, and we can modify the code if necessary.

Is the modification going to be sent to package upstream as well? If yes, what if the package author doesn't like the changes?

>
> THe plan was published here a few weeks ago.

Link to the plan to save people time searching for it: https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00152.html

I see how it differs from MELPA, but I still don't quite understand why would an user want to use this instead of MELPA, which is more popular, less strict than ELPA and doesn't require a copyright assignment.


--
Mingde (Matthew) Zeng

Re: NonGNU ELPA

[Vasilij Schneidermann]

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

> I see how it differs from MELPA, but I still don't quite understand
> why would an user want to use this instead of MELPA, which is more
> popular, less strict than ELPA and doesn't require a copyright
> assignment.

There won't be a copyright assignment part, see the original proposal
you've linked to.  However the package will still need to adhere to
certain rules to ensure the user freedoms, something that far from all
MELPA packages do.

Vasilij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: NonGNU ELPA

[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 see how it differs from MELPA, but I still don't quite
  > understand why would an user want to use this instead of MELPA,

One reason is that Emacs will inform users about NonGNU ELPA
and encourage their use of it.

-- 
Dr Richard Stallman
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

[Thomas Fitzsimmons]

Hi,

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > Wouldn’t this be just another MELPA, essentially?
>
> Nothing like it.  We will decide which packages to put in
> NonGNU ELPA, and we can modify the code if necessary.
>
> THe plan was published here a few weeks ago.

The published plan doesn't mention: will NonGNU ELPA archive(s) be
included in the package-archives variable by default?

Thomas

Re: NonGNU ELPA

[Stefan Monnier]

> Will NonGNU ELPA archive(s) be included in the package-archives
> variable by default?

Yes, that's the whole point ;-)


        Stefan

Re: NonGNU ELPA

[Thomas Fitzsimmons]

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

>> Will NonGNU ELPA archive(s) be included in the package-archives
>> variable by default?
>
> Yes, that's the whole point ;-)

Yeah, I assumed so; I just found it strange that the published plan
didn't mention this prominently, since this is a user-visible advantage
of NonGNU ELPA vs MELPA -- that it doesn't require package-archives
fiddling prior to installing the packages it provides.

Thomas