NonGNU ELPA

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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

> I guess packages are unsigned

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


        Stefan

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

[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

[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

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

[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

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

> 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

[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

[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

[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

[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

[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

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

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

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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

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

  > 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

[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

[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

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

[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

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]

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]

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]

* 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

[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

[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