[ELPA] New package: plz

[ELPA] New package: plz

[Adam Porter]

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

Hi Stefan, et al,

I'd like to submit plz.el [0] to GNU ELPA.  It's an HTTP library that 
uses Curl as a backend.  I started work on it a few years ago, and I've 
been using it in my Matrix client, Ement.el [1], since then.  It seems 
to work reliably for myself and other users, and it seems like the time 
has come to make an official release and submit to ELPA.

Please see the attached patch to elpa-packages.

Thanks,
Adam

0: https://github.com/alphapapa/plz.el
1. https://github.com/alphapapa/ement.el

[-- Attachment #2: 0001-elpa-packages-plz-New-package.patch --]
[-- Type: text/x-patch, Size: 708 bytes --]

From d7ec5692547885f155007e7978d161aba3c3ad52 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Mon, 9 May 2022 11:17:02 -0500
Subject: [PATCH] * elpa-packages (plz): New package

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

diff --git a/elpa-packages b/elpa-packages
index 51c17bc..65bb6a0 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -487,6 +487,9 @@
   :auto-sync nil
   )
  ("pinentry"		:url "https://github.com/ueno/pinentry-el.git")
+ ("plz"                 :url "https://github.com/alphapapa/plz.el.git"
+  :doc "plz.info"
+  :auto-sync t)
  ("poke"		:url "git://git.sv.gnu.org/poke/poke-el.git"
   :doc "poke-el.texi"
   :ignored-files ("COPYING")
-- 
2.7.4

Re: [ELPA] New package: plz

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> From d7ec5692547885f155007e7978d161aba3c3ad52 Mon Sep 17 00:00:00 2001
> From: Adam Porter <adam@alphapapa.net>
> Date: Mon, 9 May 2022 11:17:02 -0500
> Subject: [PATCH] * elpa-packages (plz): New package
>
> ---
>  elpa-packages | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 51c17bc..65bb6a0 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -487,6 +487,9 @@
>    :auto-sync nil
>    )
>   ("pinentry"		:url "https://github.com/ueno/pinentry-el.git")
> + ("plz"                 :url "https://github.com/alphapapa/plz.el.git"
> +  :doc "plz.info"

How is plz.info generated?  From what I see the content is the same as
README.org, right?  Unless something special is going on you should be
able to let ELPA generate the file for you, instead of tracking the
generated file in your repository.

> +  :auto-sync t)
>   ("poke"		:url "git://git.sv.gnu.org/poke/poke-el.git"
>    :doc "poke-el.texi"
>    :ignored-files ("COPYING")

Re: [ELPA] New package: plz

[Adam Porter]

Hi Philip,

On 5/9/22 14:50, Philip Kaludercic wrote:
> Adam Porter <adam@alphapapa.net> writes:
> 
>>  From d7ec5692547885f155007e7978d161aba3c3ad52 Mon Sep 17 00:00:00 2001
>> From: Adam Porter <adam@alphapapa.net>
>> Date: Mon, 9 May 2022 11:17:02 -0500
>> Subject: [PATCH] * elpa-packages (plz): New package
>>
>> ---
>>   elpa-packages | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/elpa-packages b/elpa-packages
>> index 51c17bc..65bb6a0 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -487,6 +487,9 @@
>>     :auto-sync nil
>>     )
>>    ("pinentry"		:url "https://github.com/ueno/pinentry-el.git")
>> + ("plz"                 :url "https://github.com/alphapapa/plz.el.git"
>> +  :doc "plz.info"
> 
> How is plz.info generated?  From what I see the content is the same as
> README.org, right?  Unless something special is going on you should be
> able to let ELPA generate the file for you, instead of tracking the
> generated file in your repository.

It's generated the same way as the taxy.info file is for taxy, by the 
after-save-hook in the README.org file when I save it.

I'm not opposed to letting ELPA generate it for me, but I don't know if 
the output would be exactly the same.  And despite my best efforts, I 
haven't been able to use the ELPA Makefiles to fetch and build packages 
locally (various errors about missing ".tmp.setdiff" files, directories 
that shouldn't exist but do, directories that should exist but don't, 
invalid git object names, invalid branches, forbidden git repos, unknown 
git options...it's hard to know where to begin debugging it), so I can't 
check its output myself.

Re: [ELPA] New package: plz

[Adam Porter]

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

By the way, I think I'd prefer to keep generating the info file myself so
that users can install development versions from source with Quelpa and
still get the manual installed.

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

Re: [ELPA] New package: plz

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hi Philip,
>
> On 5/9/22 14:50, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>> 
>>>  From d7ec5692547885f155007e7978d161aba3c3ad52 Mon Sep 17 00:00:00 2001
>>> From: Adam Porter <adam@alphapapa.net>
>>> Date: Mon, 9 May 2022 11:17:02 -0500
>>> Subject: [PATCH] * elpa-packages (plz): New package
>>>
>>> ---
>>>   elpa-packages | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/elpa-packages b/elpa-packages
>>> index 51c17bc..65bb6a0 100644
>>> --- a/elpa-packages
>>> +++ b/elpa-packages
>>> @@ -487,6 +487,9 @@
>>>     :auto-sync nil
>>>     )
>>>    ("pinentry"		:url "https://github.com/ueno/pinentry-el.git")
>>> + ("plz"                 :url "https://github.com/alphapapa/plz.el.git"
>>> +  :doc "plz.info"
>> How is plz.info generated?  From what I see the content is the same
>> as
>> README.org, right?  Unless something special is going on you should be
>> able to let ELPA generate the file for you, instead of tracking the
>> generated file in your repository.
>
> It's generated the same way as the taxy.info file is for taxy, by the
> after-save-hook in the README.org file when I save it.
>

[...]


Adam Porter <adam@alphapapa.net> writes:

> By the way, I think I'd prefer to keep generating the info file myself so
> that users can install development versions from source with Quelpa and
> still get the manual installed.

OK, in that case it better remain.

Re: [ELPA] New package: plz

[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'd like to submit plz.el [0] to GNU ELPA.  It's an HTTP library that 
  > uses Curl as a backend.

I know what HTTP is and what Curl does, but I can't guess what plz.el
does.  Could you please describe that in a few lines?

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

Re: [ELPA] New package: plz

[Adam Porter]

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

plz.el is a library to make HTTP requests using curl, akin to url.el and
request.el.  It attempts to provide a better API and avoid some of the
problems found in the other libraries, such as with callbacks.

On Wed, May 11, 2022, 04:03 Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > I'd like to submit plz.el [0] to GNU ELPA.  It's an HTTP library that
>   > uses Curl as a backend.
>
> I know what HTTP is and what Curl does, but I can't guess what plz.el
> does.  Could you please describe that in a few lines?
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

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

Re: [ELPA] New package: plz

[Filipp Gunbin]

On 11/05/2022 05:19 -0500, Adam Porter wrote:

> plz.el is a library to make HTTP requests using curl, akin to url.el and
> request.el.  It attempts to provide a better API and avoid some of the
> problems found in the other libraries, such as with callbacks.

It would be great to be able to add "backends" to url.el, like for
example curl-based one...  So you don't have several similar APIs
around.

Re: [ELPA] New package: plz

[Adam Porter]

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

On Wed, May 11, 2022, 08:42 Filipp Gunbin <fgunbin@fastmail.fm> wrote:

On 11/05/2022 05:19 -0500, Adam Porter wrote:

> plz.el is a library to make HTTP requests using curl, akin to url.el and
> request.el.  It attempts to provide a better API and avoid some of the
> problems found in the other libraries, such as with callbacks.

It would be great to be able to add "backends" to url.el, like for
example curl-based one...  So you don't have several similar APIs
around.


You're welcome to explore that possibility. In the meantime, there are
reasons that an alternative has been needed. You can find some discussions
about them here, on the bug tracker, and on various other package
repositories.

I would like to get plz.el on ELPA soon so I can submit Ement.el next.
Thanks.

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

Re: [ELPA] New package: plz

[Daniel Martín]

Adam Porter <adam@alphapapa.net> writes:

> plz.el is a library to make HTTP requests using curl, akin to url.el and
> request.el.  It attempts to provide a better API and avoid some of the
> problems found in the other libraries, such as with callbacks.
>

Thanks for writing this package.  I remember there's been a lot of
discussion in emacs-devel about improving url.el, the Emacs core library
to fetch from URLs.  If your library improves on the pain points of
url.el, I think it can be a candidate for inclusion in core Emacs, once
it's stable enough.  Because of that, I think it's wise to rename the
library to something more descriptive before people start writing
packages using it.  It will be much harder to rename the library later.

Re: [ELPA] New package: plz

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: rms@gnu.org,  emacs-devel <emacs-devel@gnu.org>
> Date: Wed, 11 May 2022 16:22:26 +0200
> 
> Adam Porter <adam@alphapapa.net> writes:
> 
> > plz.el is a library to make HTTP requests using curl, akin to url.el and
> > request.el.  It attempts to provide a better API and avoid some of the
> > problems found in the other libraries, such as with callbacks.
> >
> 
> Thanks for writing this package.  I remember there's been a lot of
> discussion in emacs-devel about improving url.el, the Emacs core library
> to fetch from URLs.  If your library improves on the pain points of
> url.el, I think it can be a candidate for inclusion in core Emacs, once
> it's stable enough.

A significant disadvantage of using an external program for such a
core feature is that everyone has to have this program installed.  And
since we cannot rely on that, we will have to preserve the support for
url.el everywhere where fetching URLs is required.  So adding this to
core actually increases the maintenance burden.

Re: [ELPA] New package: plz

[Philip Kaludercic]

Daniel Martín <mardani29@yahoo.es> writes:

> Adam Porter <adam@alphapapa.net> writes:
>
> [...], I think it's wise to rename the library to something
> more descriptive before people start writing packages using it.  It
> will be much harder to rename the library later.

I would agree, but I know that Adam and I have different opinions on the
matter.

Re: [ELPA] New package: plz

[Adam Porter]

On 5/11/22 13:55, Philip Kaludercic wrote:
> Daniel Martín <mardani29@yahoo.es> writes:
> 
>> Adam Porter <adam@alphapapa.net> writes:
>>
>> [...], I think it's wise to rename the library to something
>> more descriptive before people start writing packages using it.  It
>> will be much harder to rename the library later.
> 
> I would agree, but I know that Adam and I have different opinions on the
> matter.

I've often advocated for descriptive names when reviewing MELPA 
submissions, but I've also come to appreciate concise, distinctive 
names.  In this case, as I wrote in the commentary, there are already 
packages named url.el, request.el, and http.el (the latter of which 
serves a different purpose altogether).

And I think it doesn't matter here: if someone wonders what plz.el does, 
they can "C-h P plz RET" and find out.  And if someone is looking for an 
HTTP library, they can "M-x list-packages RET / d http RET" and find some.

The prefix "plz" is concise, which is valuable in code.  And a bit of 
mild humor is...well, software can be very dry, and Lisp is supposed to 
be fun, so I like it.  :)  (Also, naming things is hard.)

As to inclusion in core, as Eli said, that wouldn't be appropriate as 
long as it requires curl.  As well, while I've been using it 
successfully for a couple of years now, and, as I wrote in the readme, 
it's generally useful for most HTTP needs, with regard to HTTP features 
it's far from complete.  It needs to be used more widely and tested more 
thoroughly, and being on ELPA would be a good step toward that.

Having said that, if it were to eventually mature to the point where it 
didn't require curl and were suitable for core, renaming it would be 
appropriate, and I think it wouldn't be a problem to do so then.

Thanks for the feedback.

Re: [ELPA] New package: plz

[Stefan Monnier]

> I'd like to submit plz.el [0] to GNU ELPA.

Thanks, added.

> It's an HTTP library that uses Curl as a backend.

I hope we can consolidate this with `request.el` and `url.el` sooner
rather than later.  As others mentioned, adding a backend to plz which
uses url.el (or at least doesn't require `curl` to be installed) would
be great.

The way HTTP is evolving, I suspect we're going to need to rely on
C libraries (as opposed to url.el's "it's all ELisp" approach) in the
not too distant future, tho.


        Stefan

Re: [ELPA] New package: plz

[Adam Porter]

On 5/11/22 16:36, Stefan Monnier wrote:
>> I'd like to submit plz.el [0] to GNU ELPA.
> 
> Thanks, added.

Thanks, Stefan.

>> It's an HTTP library that uses Curl as a backend.
> 
> I hope we can consolidate this with `request.el` and `url.el` sooner 
> rather than later.

I'm not sure what that would entail.  Each library is very different
from the others, both in terms of API and--especially--internally.

plz.el was inspired by Chris Wellons's elfeed-curl.el library: after
consulting with him extensively, he recommended writing a new,
curl-based library as an alternative to url.el and request.el.  He had
had unsolvable problems with both (as had I), leading him to write his
own, simple library just for Elfeed.  He didn't have the time to factor
it out and maintain it separately, so he suggested that I do so.
Perhaps foolishly, I decided to try.  :)

> As others mentioned, adding a backend to plz which uses url.el (or at
> least doesn't require `curl` to be installed) would be great.

Using url.el internally would inherit its problems, defeating the
purpose of plz.el.  But it could develop its own, non-curl-based backend...

> The way HTTP is evolving, I suspect we're going to need to rely on C
> libraries (as opposed to url.el's "it's all ELisp" approach) in the 
> not too distant future, tho.

Yes, I'm afraid you're right about that.

Re: [ELPA] New package: plz

[Stefan Monnier]

>>> It's an HTTP library that uses Curl as a backend.
>> I hope we can consolidate this with `request.el` and `url.el` sooner
>> rather than later.
> I'm not sure what that would entail.  Each library is very different
> from the others, both in terms of API and--especially--internally.

E.g.:
- wrappers that provide request.el's API while using plz internally.
- A `url.el` backend for plz.
- A plz backend the `url-retrieve`.

>> As others mentioned, adding a backend to plz which uses url.el (or at
>> least doesn't require `curl` to be installed) would be great.
> Using url.el internally would inherit its problems, defeating the
> purpose of plz.el.

I don't think so.  It would mean only that you'd suffer from those
problems if `curl` is not installed, while still benefiting from
a better API.

`url.el` has its share of problems, but let's not forget that it works
well enough in many cases.  A `url.el` backend doesn't involve fixing
its limitations.  It just means that code can use the plz API (and
presumably benefit from the more reliable behavior when `curl` is
available) while still working as well as before when `curl` is
not installed.

> But it could develop its own, non-curl-based backend...

I assumed that reusing url.el code should be easier than rewriting all
of it from scratch, but yes, the most important thing is to match
`url.el`s current killer feature which is that it works well enough in
many important cases without relying on any third party application.


        Stefan

Re: [ELPA] New package: plz

[Filipp Gunbin]

On 11/05/2022 14:29 -0500, Adam Porter wrote:

> On 5/11/22 13:55, Philip Kaludercic wrote:
>> Daniel Martín <mardani29@yahoo.es> writes:
>> 
>>> Adam Porter <adam@alphapapa.net> writes:
>>>
>>> [...], I think it's wise to rename the library to something
>>> more descriptive before people start writing packages using it.  It
>>> will be much harder to rename the library later.
>> I would agree, but I know that Adam and I have different opinions on
>> the
>> matter.
>
> I've often advocated for descriptive names when reviewing MELPA
> submissions, but I've also come to appreciate concise, distinctive
> names.  In this case, as I wrote in the commentary, there are already
> packages named url.el, request.el, and http.el (the latter of which
> serves a different purpose altogether).
>
> And I think it doesn't matter here: if someone wonders what plz.el
> does, they can "C-h P plz RET" and find out.  And if someone is
> looking for an HTTP library, they can "M-x list-packages RET / d http
> RET" and find some.

Why not just curl.el ?  I doubt that plz.el is very discoverable for a
http library :-)

Filipp

Re: [ELPA] New package: plz

[Alan Mackenzie]

Hello, Adam.

On Wed, May 11, 2022 at 14:29:22 -0500, Adam Porter wrote:
> On 5/11/22 13:55, Philip Kaludercic wrote:
> > Daniel Martín <mardani29@yahoo.es> writes:

> >> Adam Porter <adam@alphapapa.net> writes:

> >> [...], I think it's wise to rename the library to something
> >> more descriptive before people start writing packages using it.  It
> >> will be much harder to rename the library later.

> > I would agree, but I know that Adam and I have different opinions on the
> > matter.

> I've often advocated for descriptive names when reviewing MELPA 
> submissions, but I've also come to appreciate concise, distinctive 
> names.  In this case, as I wrote in the commentary, there are already 
> packages named url.el, request.el, and http.el (the latter of which 
> serves a different purpose altogether).

> And I think it doesn't matter here: if someone wonders what plz.el does, 
> they can "C-h P plz RET" and find out.  And if someone is looking for an 
> HTTP library, they can "M-x list-packages RET / d http RET" and find some.

> The prefix "plz" is concise, which is valuable in code.  And a bit of 
> mild humor is...well, software can be very dry, and Lisp is supposed to 
> be fun, so I like it.  :)  (Also, naming things is hard.)

Totally off topic here, but PLZ in German is the standard abbreviation
for Postleitzahl, or postcode in English.  (I believe it's called a
zipcode in the USA.)  Surely this isn't a bad name for something which
gets you something at a particular "place".  :-)

> As to inclusion in core, as Eli said, that wouldn't be appropriate as 
> long as it requires curl.  As well, while I've been using it 
> successfully for a couple of years now, and, as I wrote in the readme, 
> it's generally useful for most HTTP needs, with regard to HTTP features 
> it's far from complete.  It needs to be used more widely and tested more 
> thoroughly, and being on ELPA would be a good step toward that.

> Having said that, if it were to eventually mature to the point where it 
> didn't require curl and were suitable for core, renaming it would be 
> appropriate, and I think it wouldn't be a problem to do so then.

> Thanks for the feedback.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [ELPA] New package: plz

[Stefan Monnier]

> Totally off topic here, but PLZ in German is the standard abbreviation
> for Postleitzahl, or postcode in English.  (I believe it's called a
> zipcode in the USA.)  Surely this isn't a bad name for something which
> gets you something at a particular "place".  :-)

I read it as "PLeaZe fetch this for me" :-)


        Stefan

Re: [ELPA] New package: plz

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

  > plz.el is a library to make HTTP requests using curl, akin to url.el and
  > request.el.  It attempts to provide a better API and avoid some of the
  > problems found in the other libraries, such as with callbacks.

That's concise and clear.  Thanks.

This raises a question: does plz.el potentially subsume url.el
request.el?  Would it make sense to replace those with interfaces to
plz.el?  Perhaps not now, but in a few months once plz.el is
perfected?

I don't know the answer, but it would be advantageous to have only
one such package to recommend and document.

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

Re: [ELPA] New package: plz

[Adam Porter]

On 5/13/22 10:09, Richard Stallman wrote:

>    > plz.el is a library to make HTTP requests using curl, akin to url.el and
>    > request.el.  It attempts to provide a better API and avoid some of the
>    > problems found in the other libraries, such as with callbacks.
> 
> That's concise and clear.  Thanks.
> 
> This raises a question: does plz.el potentially subsume url.el
> request.el?  Would it make sense to replace those with interfaces to
> plz.el?  Perhaps not now, but in a few months once plz.el is
> perfected?
> 
> I don't know the answer, but it would be advantageous to have only
> one such package to recommend and document.

Well, as Eli pointed out, as long as plz.el requires curl, it couldn't 
replace any Elisp-only libraries.  Providing an all-Elisp backend to 
replace usage of curl is an idea I might look into, but probably not 
anytime soon.

Besides that, as I admit in the readme, plz.el is still a young project. 
  url.el and request.el are much more feature-complete and mature.  So 
far I've added the features I've needed to use it in Ement.el; I'm 
hoping that, being on ELPA now, it will be used and tested more widely, 
and the needs of other users will help drive plz.el's development.

And while I prefer plz.el's API (of course), I wouldn't presume to say 
that it's necessarily better than theirs, so I wouldn't propose plz.el 
to subsume them.

Finally, I've encountered some rare process-related bugs in Emacs when 
testing plz.el, e.g.

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50166

So far, it only seems to manifest when running plz.el's ERT tests in 
rapid succession, not when using plz.el "in anger."  Even when Ement.el 
makes tens of requests with plz.el in rapid succession, like when 
downloading Matrix room avatar images upon initial connection, it seems 
to work perfectly.  And it's defied all of my attempts to debug the 
problem at a deeper level.

So while I don't think that problem should discourage others from using 
plz.el, and url.el and request.el can have similar issues at times 
(probably due to issues in process.c--"there be dragons," it seems), I'm 
hesitant to push it too strongly as an alternative yet.

Thanks,
Adam

Re: [ELPA] New package: plz

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

It seems that these packages differ in both
(1) how they connect to the web site (the "back end"), and
(2) the Lisp interface for calling them.

Is that right?

If so, it seems that the clean way is to offer the same interface for
all the back ends, perhaps selecting the back end at run time for each
use.  And support legacy interfaces by making them call the preferred
interface.

Why not?

Each Lisp interface can also select a back-end method by default,
with various global variables to specify selective overrides.

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

Re: [ELPA] New package: plz

[Stefan Monnier]

> It seems that these packages differ in both
> (1) how they connect to the web site (the "back end"), and
> (2) the Lisp interface for calling them.
>
> Is that right?

Yup.

> If so, it seems that the clean way is to offer the same interface for
> all the back ends, perhaps selecting the back end at run time for each
> use.  And support legacy interfaces by making them call the preferred
> interface.

Yup.

> Why not?

Various reasons:

1- Someone™ has to do it.
2- I don't think we're quite sure which interface is "the preferred"
   one yet.

I hope someone will rise up to the challenge to clean this up soonish.


        Stefan

Re: [ELPA] New package: plz

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

  > And I think it doesn't matter here: if someone wonders what plz.el does, 
  > they can "C-h P plz RET" and find out.  And if someone is looking for an 
  > HTTP library, they can "M-x list-packages RET / d http RET" and find some.

That is true -- but that only goes one way, from thinking about the
name "plz" to trying to use it.  It does not help people go in the
other direction, from an idea of doing something to thinking about using
this one library.

The number of unclear package names in Emacs is a big problem (epa,
eww, mml are a few examples out of many).  They are neither helpful
nor funny, and they make those pakages undiscoverable.

Let's not add any more of those.

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

Re: [ELPA] New package: plz

[Adam Porter]

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

On Sat, May 14, 2022, 18:58 Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > And I think it doesn't matter here: if someone wonders what plz.el
> does,
>   > they can "C-h P plz RET" and find out.  And if someone is looking for
> an
>   > HTTP library, they can "M-x list-packages RET / d http RET" and find
> some.
>
> That is true -- but that only goes one way, from thinking about the
> name "plz" to trying to use it.  It does not help people go in the
> other direction, from an idea of doing something to thinking about using
> this one library.
>

I meant that searching the packages list by description would find
libraries related to HTTP.  I think this is okay, because purely
descriptive names tend to get long and unwieldy. They also tend to be less
memorable and distinctive in the long run.

>
The number of unclear package names in Emacs is a big problem (epa,
> eww, mml are a few examples out of many).  They are neither helpful
> nor funny, and they make those pakages undiscoverable.
>
> Let's not add any more of those.
>

I wouldn't propose merging a library into emacs.git with a cutesy name. I
agree that the names of core libraries should generally be descriptive and
straightforward.

OTOH, naming things is hard, and in this case, the obvious, descriptive
names are already taken. So I think that a longer, drier, purely
descriptive name would be less desirable for an ELPA package.

If I may say so, I also think that having lightly opinionated packages with
distinctive identities, and sometimes with mildly amusing names, can help
authors feel a sense of pride in their work, which can be motivating,
resulting in more and higher quality work, which ultimately benefits the
users. Of course, there is much value in having code in core rather than in
add-on packages, but at the same time, something can be lost when a project
is absorbed into a larger whole. A balance to be struck; a time for
everything; etc.

My two cents. :)

>

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

Wrong default-directory in shell buffer

[Matthias Meulien]

With a recent build from master branch, I sometime have a wrong value
("/../" to be precise) for the default-directory variable associated to
shell buffers.  I create shell buffers with project-shell, the
default-directory value is the expected one, the wrong value appears
after I've executed some commands.

(As a consequence all project-* commands fail to recognize current
project and I am asked to select a project which is really annoying.)

I have not found a recipe to reproduce; But I've found that I've
executed commands containing the string "/../" in a shell buffer with
the problem:

cd ../../
pushd ../../
xdg-open ../../

(Trailing slashes added by the completion framework, company).

I also executed commands like meson build which outputs strings
containing the "/../" string:

[2/3] /usr/bin/meson --internal msgfmthelper ../data/app.argos.Argos.desktop.in data/app.argos.Argos.desktop desktop ../data/../po

I didn't find any related bug report in debbugs.  Am I the only one
experiencing such a regression?  

I am using GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.24, cairo version 1.16.0) build from master on 2022-04-18, and I
keep shell-mode rather unchanged:

(add-hook 'shell-mode-hook
          (lambda ()
             (setq shell-font-lock-keywords nil)
             (goto-address-mode)))

(define-abbrev-table 'shell-mode-abbrev-table '(("null" "&> /dev/null")))
-- 
Matthias

Re: Wrong default-directory in shell buffer

[Stefan Monnier]

> With a recent build from master branch, I sometime have a wrong value
> ("/../" to be precise) for the default-directory variable associated to
> shell buffers.  I create shell buffers with project-shell, the
> default-directory value is the expected one, the wrong value appears
> after I've executed some commands.
>
> (As a consequence all project-* commands fail to recognize current
> project and I am asked to select a project which is really annoying.)
>
> I have not found a recipe to reproduce; But I've found that I've
> executed commands containing the string "/../" in a shell buffer with
> the problem:
>
> cd ../../
> pushd ../../
> xdg-open ../../

Could it be related to "directory tracking", then?

There are several different "solutions" to have shell buffers's
`default-directory` track the PWD of the shell, so I'm not sure which
one might be at fault here (if any).


        Stefan

Re: Wrong default-directory in shell buffer

[Matthias Meulien]

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

> Could it be related to "directory tracking", then?

I guess so.

> There are several different "solutions" to have shell buffers's
> `default-directory` track the PWD of the shell, so I'm not sure which
> one might be at fault here (if any).

I see that shell-dirtrack-verbose is t, and dirtrack-mode is nil. Thus I
guess emacs is using the default cd, pushd and popd tracking.

I'll study this implementation.
-- 
Matthias

Re: Wrong default-directory in shell buffer

[Matthias Meulien]

Matthias Meulien <orontee@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Could it be related to "directory tracking", then?
>
> I guess so.
>
>> There are several different "solutions" to have shell buffers's
>> `default-directory` track the PWD of the shell, so I'm not sure which
>> one might be at fault here (if any).
>
> I see that shell-dirtrack-verbose is t, and dirtrack-mode is nil. Thus I
> guess emacs is using the default cd, pushd and popd tracking.
>
> I'll study this implementation.

It's simply that when the input is:

  mkdir builddir && cd builddir

the function shell-directory-tracker fails to see the cd command.

I recently develop the habit to call successively:

  mkdir builddir && cd builddir
  # do some work
  cd ..
  rm -rf builddir

repeatedly. If initial value of the default-directory variable is
/home/matthias/Projets/argos then after 4 iterations it will have been
updated to /, and with the fifth it will be /..

I observed the same behavior with Emacs 27.1.  No regression!

Comments in shell.el says of directory tracking that: "This is basically
a fragile hack".  Confirmed.
-- 
Matthias

plz -> curl?

[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 have arrived at a deep and fundamental disagreement about what it
means to make a program clear.  I have pointed out that the name "plz"
gives no information about what the package does.  It is totally
unhelpful.

You contend that an arbitrary and unhelpful name is just as good as a
helpful name.  The argument is that we have commands to do searches
from the name to its purpose and from words in its purpose to the
name.

Those commands are helpful, but using them is laborious by comparison
woth the simple verbalconnection.

For the packages feature, I am a beginner.  I don't know those
commands.  I will learn these commands if I start using packages more,
but there will always be many users who are beginners in this.

Whenever we add a new package, we should consider whether to change
its name first.  But plz has not been installed for long.  Giving it a
clear, meaningful name now won't cause any pain.

A clear meaningful name does not have to be long.  Someone suggested
`curl' -- meaningful, and quite short.  Perhaps `curl-url' would be
even more helpful, to the many who who don't use curl -- and it is
still short.

If no one has a better idea, let's rename it that way now.

It would still be a good thing to design a uniform interface for
fetching a page through any of the various methods Emacs supports.
But that may or may not get written, so let's DTRT for this package
now.

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

Re: [ELPA] New package: plz

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

  > 1- Someone™ has to do it.
  > 2- I don't think we're quite sure which interface is "the preferred"
  >    one yet.

  > I hope someone will rise up to the challenge to clean this up soonish.

Someone™ could start by implementing a generalization of the interface
of url.el first, with ways to request the other features,
and making it work with all three back-ends.

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

Re: plz -> curl?

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> We have arrived at a deep and fundamental disagreement about what it
> means to make a program clear.  I have pointed out that the name "plz"
> gives no information about what the package does.  It is totally
> unhelpful.
>
> You contend that an arbitrary and unhelpful name is just as good as a
> helpful name.  The argument is that we have commands to do searches
> from the name to its purpose and from words in its purpose to the
> name.
>
> Those commands are helpful, but using them is laborious by comparison
> woth the simple verbalconnection.
>
> For the packages feature, I am a beginner.  I don't know those
> commands.  I will learn these commands if I start using packages more,
> but there will always be many users who are beginners in this.
>
> Whenever we add a new package, we should consider whether to change
> its name first.  But plz has not been installed for long.  Giving it a
> clear, meaningful name now won't cause any pain.

I agree completely.  There are many unhelpful package names, such as
"corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
be renamed "lsp-client", which tells the user exactly what it does.

> A clear meaningful name does not have to be long.  Someone suggested
> `curl' -- meaningful, and quite short.  Perhaps `curl-url' would be
> even more helpful, to the many who who don't use curl -- and it is
> still short.
>
> If no one has a better idea, let's rename it that way now.

curl is already taken.  `curl-url' would work, but so would
`curl-http-client', which I think is relatively more meaningful.

Re: plz -> curl?

[Adam Porter]

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

On Mon, May 16, 2022, 19:50 Po Lu <luangruo@yahoo.com> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> > We have arrived at a deep and fundamental disagreement about what it
> > means to make a program clear.  I have pointed out that the name "plz"
> > gives no information about what the package does.  It is totally
> > unhelpful.
> >
> > You contend that an arbitrary and unhelpful name is just as good as a
> > helpful name.


No, that is not my contention at all. I tried to explain my position as
clearly as I could in my last messages.

The argument is that we have commands to do searches
> > from the name to its purpose and from words in its purpose to the
> > name.
> >
> > Those commands are helpful, but using them is laborious by comparison
> > woth the simple verbalconnection.
> >
> > For the packages feature, I am a beginner.  I don't know those
> > commands.  I will learn these commands if I start using packages more,
> > but there will always be many users who are beginners in this.
>

Users who don't know how to use the package system will not be installing
the package in the first place.

>
> > Whenever we add a new package, we should consider whether to change
> > its name first.  But plz has not been installed for long.  Giving it a
> > clear, meaningful name now won't cause any pain.
>
> I agree completely.  There are many unhelpful package names, such as
> "corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
> be renamed "lsp-client", which tells the user exactly what it does.
>

Those packages have distinctive identities to those who use them. Giving
them generic names does not help the user remember them; it has the
opposite effect.

>
> > A clear meaningful name does not have to be long.  Someone suggested
> > `curl' -- meaningful, and quite short.


As I said, I don't want to use that name, because it implies more
comprehensive support for curl than I intend to provide in the library.  As
well, there are other packages that provide a front end to curl.

Perhaps `curl-url' would be
> > even more helpful, to the many who who don't use curl -- and it is
> > still short.
>

Thanks, but no.

> If no one has a better idea, let's rename it that way now.
>
> curl is already taken.  `curl-url' would work, but so would
> `curl-http-client', which I think is relatively more meaningful.
>

As I've said, long, purely descriptive package names like that are less
useful in the long run, as well as simply being too long.

At this time, I don't intend to rename the library.  Were it to be proposed
for merging into core someday, that would be different--but as has been
said, that won't be the case anytime soon, if ever.

>

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

Re: plz -> curl?

[Eli Zaretskii]

> From: Adam Porter <adam@alphapapa.net>
> Date: Mon, 16 May 2022 21:13:51 -0500
> Cc: Richard Stallman <rms@gnu.org>, Philip Kaludercic <philipk@posteo.net>,
>  mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org>
> 
>  > For the packages feature, I am a beginner.  I don't know those
>  > commands.  I will learn these commands if I start using packages more,
>  > but there will always be many users who are beginners in this.
> 
> Users who don't know how to use the package system will not be installing the package in the first place.

Please don't make such an assumption.  I routinely install packages
"by hand", by downloading its Tar file from ELPA and unpacking the
archive in a place of my choice.  It's not only possible, it's
actually very easy.

> At this time, I don't intend to rename the library.

FWIW, I think it's unfortunate that you refuse to consider a different
name.

Re: plz -> curl?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Adam Porter <adam@alphapapa.net>,  philipk@posteo.net,
>  mardani29@yahoo.es,  emacs-devel@gnu.org
> Date: Tue, 17 May 2022 08:50:23 +0800
> 
> I agree completely.  There are many unhelpful package names, such as
> "corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
> be renamed "lsp-client", which tells the user exactly what it does.

Eglot is not arbitrary, AFAIK it comes from Emacs + polyglot.

Re: plz -> curl?

[Po Lu]

Adam Porter <adam@alphapapa.net> writes:

> Users who don't know how to use the package system will not be
> installing the package in the first place.

It is better for a package name to be helpful than for it to be merely
possible for the user to install it.

> Those packages have distinctive identities to those who use
> them. Giving them generic names does not help the user remember them;
> it has the opposite effect.

A package on ELPA or NonGNU ELPA doesn't exist so that they can have a
distinctive identity, it exists to be helpful to users.  Giving a
package a name that fails to describe what it does is not helpful,
especially one as cryptic as "plz" or "eglot".

If you ask for the apropos of "language server" or "lsp" with Eglot
installed, there are no results.  Browsing the package list is also less
useful, since there are many packages and reading the descriptions for
each one of them sometimes takes too long.

> As I said, I don't want to use that name, because it implies more
> comprehensive support for curl than I intend to provide in the
> library.  As well, there are other packages that provide a front end
> to curl.

Then how about "external-http-client"?  That says it is a client for
HTTP using an external program, but doesn't mention curl by name.

> As I've said, long, purely descriptive package names like that are
> less useful in the long run, as well as simply being too long.

That simply doesn't make sense.  A package with a descriptive name will
be more useful in the long run, because users will find it easier to
remember, and its purpose will be obvious to anyone reading code that
uses it.

I think we should simply not accept packages with nondescript names in
ELPA or NonGNU ELPA in the future, since listing them is a disservice
and serves to encourage the practice of naming packages confusingly.

Re: plz -> curl?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Eglot is not arbitrary, AFAIK it comes from Emacs + polyglot.

It could still be more obvious, and right now nothing comes up in the
apropos of "lsp" and "language server" with it installed.

Re: plz -> curl?

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>> Whenever we add a new package, we should consider whether to change
>> its name first.  But plz has not been installed for long.  Giving it
>> a clear, meaningful name now won't cause any pain.

For me as a German guy, it's totaly obvious it has something to do with
Postleitzahlen (zip codes). ;-)

> I agree completely.  There are many unhelpful package names, such as
> "corfu", "cape", "eglot", "marginalia" and "mcd".

Well, all but marginalia are abbreviations.

corfu: Completion Overlay Region FUnction
cape: Completion At Point Extensions
eglot: Emacs + polyglot (as Eli mentioned)
marginalia: Additional information written in a book's margin
mct: Minibuffer and Completions in Tandem

> At least eglot could be renamed "lsp-client", which tells the user
> exactly what it does.

I think that would make it very easy to confuse with lsp-mode, i.e., it
would look as if lsp-client (eglot) was a part of lsp-mode (which
already has a large set of lsp-* addon-packages).  Probably that was the
initial reason why its name is the way it is.

Also, with overly descriptive names such as lsp-client, what if that
package is superseded by some alternative package.  The obviously best
(most descriptive) name is already taken!

In any case, I'm not against descriptive names but can also understand
when developers chose a name which sounds nice and is more memorable.
And especially for the packages with "unhelpful names" you've cited, the
purpose is pretty clear from their package description.  So maybe it
would be worthwhile to have some apropos-like command which searches
available packages so that LSP or "language server" would suggest eglot,
etc.

Bye,
Tassilo

Re: plz -> curl?

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Those packages have distinctive identities to those who use them. Giving
> them generic names does not help the user remember them; it has the
> opposite effect.

[...]

> As I've said, long, purely descriptive package names like that are less
> useful in the long run, as well as simply being too long.
>
> At this time, I don't intend to rename the library.  Were it to be proposed
> for merging into core someday, that would be different--but as has been
> said, that won't be the case anytime soon, if ever.

It might be useful to clarify this point, because it seems unintuitive
to me -- setting aside whether or not this package should be renamed.

When considering a desktop environment like GNOME, most applications are
presented using their generic names ("Text editor" instead of Gedit,
"PDF Viewer" instead of Evince).  This seems to make sense to me,
because most user is interested in the functionality not the
implementation.

When considering a library, this calculus might change a bit.  Yet it is
still nice for a user to have some idea of what dependencies a package
is pulling in.

I think it would be nice to have guidelines for new packages, also to
help contributors when coming up with a name, if anything just to bring
some consistency into the naming schemes.

Re: plz -> curl?

[Alan Mackenzie]

Hello, Richard.

On Mon, May 16, 2022 at 19:25:41 -0400, 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. ]]]

> We have arrived at a deep and fundamental disagreement about what it
> means to make a program clear.  I have pointed out that the name "plz"
> gives no information about what the package does.  It is totally
> unhelpful.

The abbreviation PLZ is instantly recognisable to a German speaker.  It
means "postcode"/"zipcode", something not entirely irrelevant here, if
perhaps coincidental.

> You contend that an arbitrary and unhelpful name is just as good as a
> helpful name.  The argument is that we have commands to do searches
> from the name to its purpose and from words in its purpose to the
> name.

For that matter, the name Emacs is just as unhelpful to somebody who
doesn't know the program.  There's likely nobody reading this group who
has any difficulty typing in xkcd to get to the source of wit and
wisdom.

> Those commands are helpful, but using them is laborious by comparison
> woth the simple verbal connection.

Commands need to be typed into the minibuffer.  A short prefix is easier
to type than a long one.  plz- is, for example, easier to type than
byte-compile-.

> For the packages feature, I am a beginner.  I don't know those
> commands.  I will learn these commands if I start using packages more,
> but there will always be many users who are beginners in this.

As am I.

> Whenever we add a new package, we should consider whether to change
> its name first.  But plz has not been installed for long.  Giving it a
> clear, meaningful name now won't cause any pain.

If by that is meant a long name, it will cause pain.  See above.

> A clear meaningful name does not have to be long.  Someone suggested
> `curl' -- meaningful, and quite short.  Perhaps `curl-url' would be
> even more helpful, to the many who who don't use curl -- and it is
> still short.

It's medium lnog.

> If no one has a better idea, let's rename it that way now.

I think it better to leave the name as it is, if for no better reason
than respect for the wishes of its author.

> It would still be a good thing to design a uniform interface for
> fetching a page through any of the various methods Emacs supports.
> But that may or may not get written, so let's DTRT for this package
> now.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: plz -> curl?

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I agree completely.  There are many unhelpful package names, such as
> "corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
> be renamed "lsp-client", which tells the user exactly what it does.

People will choose the names they want for their packages, and that's
fine -- it's a free world, and aggressively trying to make people change
the names of their packages isn't only rude, it's counter productive.

The GNU ELPA administrator is free to reject packages on any basis, of
course, including not liking the name.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Wrong default-directory in shell buffer

[Visuwesh]

[திங்கள் மே 16, 2022] Matthias Meulien wrote:

> Matthias Meulien <orontee@gmail.com> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> Could it be related to "directory tracking", then?
>>
>> I guess so.
>>
>>> There are several different "solutions" to have shell buffers's
>>> `default-directory` track the PWD of the shell, so I'm not sure which
>>> one might be at fault here (if any).
>>
>> I see that shell-dirtrack-verbose is t, and dirtrack-mode is nil. Thus I
>> guess emacs is using the default cd, pushd and popd tracking.
>>
>> I'll study this implementation.
>
> It's simply that when the input is:
>
>   mkdir builddir && cd builddir
>
> the function shell-directory-tracker fails to see the cd command.
>
> I recently develop the habit to call successively:
>
>   mkdir builddir && cd builddir
>   # do some work
>   cd ..
>   rm -rf builddir
>
> repeatedly. If initial value of the default-directory variable is
> /home/matthias/Projets/argos then after 4 iterations it will have been
> updated to /, and with the fifth it will be /..
>
> I observed the same behavior with Emacs 27.1.  No regression!
>
> Comments in shell.el says of directory tracking that: "This is basically
> a fragile hack".  Confirmed.

I have come to the conclusion that the most reliable way to track
directories is to stick the directory in the prompt and parse the prompt
in Emacs side, or if you're on Emacs 28, you can use the OSC7 escape
sequence to track the directory.  I do the latter now, and so far no
problems.

Re: plz -> curl?

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> People will choose the names they want for their packages, and that's
> fine -- it's a free world, and aggressively trying to make people change
> the names of their packages isn't only rude, it's counter productive.

Politely discouraging a counter-productive practice such as naming
packages in a confusing way is neither rude nor counter-productive.

Authors are obviously free to name their packages whatever they want,
but that doesn't mean it's a good idea.  Which in the case of eglot it
definitely isn't, because I can't find anything related to "language
servers" or "lsp" with `apropos'.

Re: plz -> curl?

[Dmitry Gutov]

On 17.05.2022 05:50, Po Lu wrote:
>> As I said, I don't want to use that name, because it implies more
>> comprehensive support for curl than I intend to provide in the
>> library.  As well, there are other packages that provide a front end
>> to curl.
> Then how about "external-http-client"?  That says it is a client for
> HTTP using an external program, but doesn't mention curl by name.
> 

Since the bikeshed is in full swing: IMHO both 'curl' and 
'external-http-client' are not great options because using curl (or any 
external lib or program) to accomplish the goal is a means to an end, or 
perhaps even a downside of this package, rather than its end goal (which 
is, I'm guessing, to provide a nicer and reliable API for making HTTP 
requests).

Re: plz -> curl?

[Adam Porter]

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

Is there an apropos-package command?  If not, maybe now is the time to
write one.

On Tue, May 17, 2022, 05:12 Po Lu <luangruo@yahoo.com> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > People will choose the names they want for their packages, and that's
> > fine -- it's a free world, and aggressively trying to make people change
> > the names of their packages isn't only rude, it's counter productive.
>
> Politely discouraging a counter-productive practice such as naming
> packages in a confusing way is neither rude nor counter-productive.
>
> Authors are obviously free to name their packages whatever they want,
> but that doesn't mean it's a good idea.  Which in the case of eglot it
> definitely isn't, because I can't find anything related to "language
> servers" or "lsp" with `apropos'.
>

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

Re: plz -> curl?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  adam@alphapapa.net,  philipk@posteo.net,
>  mardani29@yahoo.es,  emacs-devel@gnu.org
> Date: Tue, 17 May 2022 11:05:28 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Eglot is not arbitrary, AFAIK it comes from Emacs + polyglot.
> 
> It could still be more obvious, and right now nothing comes up in the
> apropos of "lsp" and "language server" with it installed.

Does it only work with LSP?  And if it does now, can't it be taught to
use other services?

Re: plz -> curl?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Does it only work with LSP?  And if it does now, can't it be taught to
> use other services?

Eglot is supposed to only be an LSP client, and it would probably be
hard to teach it to speak another protocol.

Re: plz -> curl?

[Po Lu]

Adam Porter <adam@alphapapa.net> writes:

> Is there an apropos-package command?  If not, maybe now is the time to
> write one.

What would it do, and how would it help alieviate this problem?

Re: plz -> curl?

[Stefan Monnier]

>> People will choose the names they want for their packages, and that's
>> fine -- it's a free world, and aggressively trying to make people change
>> the names of their packages isn't only rude, it's counter productive.
> Politely discouraging a counter-productive practice such as naming
> packages in a confusing way is neither rude nor counter-productive.

There's a long tradition in ELisp to use "made up" names, like `eglot`
and `plz`.  AFAICT this is not gratuitous but is the result of having to
avoid naming conflicts.  E.g. `lsp-mode` uses the `lsp-` prefix, so any
package which chooses a name that starts with `lsp-` risks causing
a conflict.

It's always easy to retrospectively decide which package should have
which name (after the dust has settled and one of the contenders for
a given name has accrued a decisive advantage), but backward
compatibility as well as the need to choose a name before the dust has
settled (which can take a very long time) mean that non-obvious names
are here to stay.

I don't see any need to fight them or even discourage them.
Instead we need to work on improving discoverability based on other
things than merely the package name.


        Stefan

Re: plz -> curl?

[Eli Zaretskii]

> From: Adam Porter <adam@alphapapa.net>
> Date: Tue, 17 May 2022 05:15:06 -0500
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Richard Stallman <rms@gnu.org>,
>  Philip Kaludercic <philipk@posteo.net>, 
>  mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org>
> 
> Is there an apropos-package command?  If not, maybe now is the time to write one. 

We have package-menu-filter-by-description.

Re: plz -> curl?

[Roland Winkler]

On Tue, May 17 2022, Stefan Monnier wrote:
> It's always easy to retrospectively decide which package should have
> which name (after the dust has settled and one of the contenders for a
> given name has accrued a decisive advantage), but backward
> compatibility as well as the need to choose a name before the dust has
> settled (which can take a very long time) mean that non-obvious names
> are here to stay.

By now for some years I have been the maintainer of the Insidious Big
Brother Database (aka BBDB).  But before that I was rather clueless
what it was doing and how it could possibly be useful at all.  The term
"Insidious Big Brother Database (aka BBDB)" did not help me much.
Sad enough, overhauling the documentation of BBDB that could help
newcomers is one of the biggest pieces that are still missing.

Re: plz -> curl?

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>> Is there an apropos-package command?  If not, maybe now is the time
>> to write one.
>
> What would it do, and how would it help alieviate this problem?

Given a term, list the packages of the configured archives whose name or
description contains that term.  E.g., asking for LSP it would list
eglot, lsp-mode and the gazillion lsp-* addon packages.

As Eli said, there's already package-menu-filter-by-description which
basically does most of the job but requires that you're already in the
*Packages* buffer.

FWIW, I have eglot installed and the apropos commands (apropos,
apropos-command, apropos-documentation) show many eglot symbols when
searching for lsp, but you need to give a prefix arg in order to search
external packages, too.  But strange enough, it does not list the
`eglot' command which is the main command of it (and I get an error
which I'll investigate and report if it's not on my side)...

Bye,
Tassilo

Re: plz -> curl?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  adam@alphapapa.net,  philipk@posteo.net,
>  mardani29@yahoo.es,  emacs-devel@gnu.org
> Date: Tue, 17 May 2022 19:46:15 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does it only work with LSP?  And if it does now, can't it be taught to
> > use other services?
> 
> Eglot is supposed to only be an LSP client, and it would probably be
> hard to teach it to speak another protocol.

OK, but LSP is not the feature it exposes, it's a service it uses to
expose other features.  So it should be okay to name it something that
doesn't necessarily include "LSP" as its substring, but instead
conveys the feature(s) it provides.

Re: Wrong default-directory in shell buffer

[Matthias Meulien]

Visuwesh <visuweshm@gmail.com> writes:

> (...)  I have come to the conclusion that the most reliable way to
> track directories is to stick the directory in the prompt and parse
> the prompt in Emacs side, or if you're on Emacs 28, you can use the
> OSC7 escape sequence to track the directory.  I do the latter now, and
> so far no problems.

Do you have any implementation of the OSC7 trick to share?

On the other hand I must confess I don't understand why we don't rely on
the current directory of the buffer process (from the Unix point of
view):

  matthias@carbon:~/Projets/argos$ mkdir builddir && cd builddir
  matthias@carbon:~/Projets/argos/builddir$ readlink -e /proc/593787/cwd/
  /home/matthias/Projets/argos/builddir

I've read in efaq.info, node: Shell mode loses the current directory,
that there's an intrinsic limitation of Unix but I don't know where this
limitation comes from and if it applies to many Unices...
-- 
Matthias

Re: plz -> curl?

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Adam Porter <adam@alphapapa.net>,  philipk@posteo.net,
>>  mardani29@yahoo.es,  emacs-devel@gnu.org
>> Date: Tue, 17 May 2022 08:50:23 +0800
>> 
>> I agree completely.  There are many unhelpful package names, such as
>> "corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
>> be renamed "lsp-client", which tells the user exactly what it does.
>
> Eglot is not arbitrary, AFAIK it comes from Emacs + polyglot.

It should be noted that the name is nevertheless still confusing,
because people often misread it as elgot (seeing as el... is a popular
prefix).

Re: Wrong default-directory in shell buffer

[Lars Ingebrigtsen]

Matthias Meulien <orontee@gmail.com> writes:

> Do you have any implementation of the OSC7 trick to share?

From comint.el:

(defun comint-osc-directory-tracker (_ text)
  "Update `default-directory' from OSC 7 escape sequences.

This function is intended to be included as an entry of
`comint-osc-handlers'.  You should moreover arrange for your
shell to print the appropriate escape sequence at each prompt,
say with the following command:

    printf \"\\e]7;file://%s%s\\e\\\\\" \"$HOSTNAME\" \"$PWD\"

This functionality serves as an alternative to `dirtrack-mode'
and `shell-dirtrack-mode'."


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Wrong default-directory in shell buffer

[Matthias Meulien]

Thank you!  Using `comint-osc-directory-tracker' with a custom Bash
prompt works like a charm.

One possible minor comment update:

diff --git a/lisp/comint.el b/lisp/comint.el
index 3dc80c20ac..3da61fb992 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -3978,10 +3978,12 @@ comint-redirect-results-list-from-process
 \f
 ;;; OSC escape sequences (Operating System Commands)
 ;;============================================================================
-;; Adding `comint-osc-process-output' to `comint-output-filter-functions'
-;; enables the interpretation of OSC escape sequences.  By default, only
-;; OSC 8, for hyperlinks, is acted upon.  Adding more entries to
-;; `comint-osc-handlers' allows a customized treatment of further sequences.
+;; Adding `comint-osc-process-output' to
+;; `comint-output-filter-functions' enables the interpretation of OSC
+;; escape sequences.  By default, OSC 7 and 8 (for current directory
+;; and hyperlinks respectively) are acted upon.  Adding more entries
+;; to `comint-osc-handlers' allows a customized treatment of further
+;; sequences.
 
 (defvar-local comint-osc-handlers '(("7" . comint-osc-directory-tracker)
                                     ("8" . comint-osc-hyperlink-handler))

Thanks a lot.
-- 
Matthias

Re: Wrong default-directory in shell buffer

[Lars Ingebrigtsen]

Matthias Meulien <orontee@gmail.com> writes:

> One possible minor comment update:

Thanks; pushed to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: plz -> curl?

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

  > Is there an apropos-package command?  If not, maybe now is the time to
  > write one.

If there isn't one, that would be good to add.  Better search tools
can complement memorable names -- but they don't substitute for
memorable names.

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

Re: plz -> curl?

[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 agree completely.  There are many unhelpful package names, such as
  > > "corfu", "cape", "eglot", "marginalia" and "mcd".  At least eglot could
  > > be renamed "lsp-client", which tells the user exactly what it does.

  > Eglot is not arbitrary, AFAIK it comes from Emacs + polyglot.

I agree, it is not arbitrary -- but it is rather enigmatic unless you
know what it's supposed to mean.

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

Re: plz -> curl?

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

  > When considering a library, this calculus might change a bit.  Yet it is
  > still nice for a user to have some idea of what dependencies a package
  > is pulling in.

We might want to add a three-word description field for ELPA packages.
That could appear in the package list, and apropos could search that.


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

Re: plz -> curl?

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

  > For that matter, the name Emacs is just as unhelpful to somebody who
  > doesn't know the program.

It was a meaningful name in 1976: E for Editing, Macs for Macros.
That was 46 years ago -- since then, the context has changed, but it's
unfair to blame me for not foreseeing 46 years of changes back then.

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

Re: plz -> curl?

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

  > It's always easy to retrospectively decide which package should have
  > which name (after the dust has settled and one of the contenders for
  > a given name has accrued a decisive advantage), but backward
  > compatibility as well as the need to choose a name before the dust has
  > settled (which can take a very long time) mean that non-obvious names
  > are here to stay.

We can define a new, clear name and use it to refer to the package by,
and keep the old name as an alias.  That gets the best of these two
worlds.

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

Re: plz -> curl?

[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 have package-menu-filter-by-description.

How about giving this an alias, `package-apropos'?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: plz -> curl?

[Eric Abrahamsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> Is there an apropos-package command?  If not, maybe now is the time
>>> to write one.
>>
>> What would it do, and how would it help alieviate this problem?
>
> Given a term, list the packages of the configured archives whose name or
> description contains that term.  E.g., asking for LSP it would list
> eglot, lsp-mode and the gazillion lsp-* addon packages.

There's also filter-by-keyword in the *Packages* list, I'll bet people
don't make as much use of that as they could.

Re: plz -> curl?

[Jonas Bernoulli]

For a long time I have been hoping that someone™ (who has experience
with that sort of thing) would implement support for libcurl, either
in Emacs directly or as a module.

> plz -> curl?

"curl" is a good name.  I would recommend reserving it for that
module/build-in support.

Re: plz -> curl?

[Jonas Bernoulli]

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

> It's always easy to retrospectively decide which package should have
> which name (after the dust has settled and one of the contenders for
> a given name has accrued a decisive advantage), but backward
> compatibility as well as the need to choose a name before the dust has
> settled (which can take a very long time) mean that non-obvious names
> are here to stay.

Using cute names for unproven third-party packages also has the
advantage that the boring authorities name is still available when the
Emacs developers decide to implement "official" support for the same
thing.

And if that is done by adopting an existing solution, then that is the
best time to rename that package and all its symbols.  Downstreams would
still be inconvenienced by such a change but they are likely to be much
more forgiving when it happens at that time.  After all they get
something out of it too; the package they rely on is now the official
solution and less likely to break in backward incompatible ways *going
forward*.

> Instead we need to work on improving discoverability based on other
> things than merely the package name.

Like finder.el? ;D

> ;; These are supposed to correspond to top-level customization groups,
> ;; says rms.
> (defvar finder-known-keywords '( 36 elements))

Maybe we should allow classifying packages into more than three dozen
groups?

Re: [ELPA] New package: plz

[Jonas Bernoulli]

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

>> It's an HTTP library that uses Curl as a backend.
>
> I hope we can consolidate this with `request.el` and `url.el` sooner
> rather than later.  As others mentioned, adding a backend to plz which
> uses url.el (or at least doesn't require `curl` to be installed) would
> be great.

Some people don't like the interface but that was never the main problem
I had with url.el.  What caused me pain is its bugs, and I suspect for
many other package maintainers it is the same.

Right now though --and that is a first-- I am not aware of any bugs for
which I don't have backported a fix in ghub.el.  (If you must see code,
it is at the very end of ghub.el.  It ain't pretty.)

Of course I am not happy that I have to backport the fixes, especially
because that also affects other packages.  The hope is that those other
packages get bug fixes for free, but of course it is also possible that
my monkey patches contain bugs of their own.

It worries me that I might be breaking other peoples packages, but there
really is no alternative; these url.el bugs caused an endless stream of
bug reports in my packages, and once we figured out the causes, waiting
a few more years until the fixes are in Emacs just wasn't an option
anymore.

I am not saying that url.el is bad, but that maintaining such
functionality is a lot of work.  Doing so requires an expert whose main
or only focus it is to do just that.  So:

> The way HTTP is evolving, I suspect we're going to need to rely on
> C libraries (as opposed to url.el's "it's all ELisp" approach) in the
> not too distant future, tho.

Maybe that's not a bad thing and it is best if we do that sooner rather
than later?

Of course libcurl may have bugs too, but *many* people are using it,
making it highly unlikely that we are the ones who will have to figure
them out.

With url.el that is not the case.  If you use that, then you are going
to have to deal with bugs that have nothing to do with your own package,
if only your package is popular enough.

I think that hinders Emacs evolution as a network client.  Occasionally
I have had an idea that involved networking, but, given my experience
with forge/ghub, I never worked on any of them.  The risk of ending up
having to deal with mystery bugs as a result, currently is just to high.
I might not be the only one who feels that way.

     Jonas


TL;DR Maybe this was overly negative.  That wasn't my intention.  What I
really want to say is this: could someone™ with experience in this area
pretty please start working on bringing libcurl to Emacs?

Re: [ELPA] New package: plz

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2022 13:13:03 +0200
> 
> TL;DR Maybe this was overly negative.  That wasn't my intention.  What I
> really want to say is this: could someone™ with experience in this area
> pretty please start working on bringing libcurl to Emacs?

Are we confident enough that libcurl can satisfy Emacs's needs?
Shouldn't someone™ first study our requirements and make sure they can
be fulfilled by using libcurl?  It is not immediately clear to me that
the answer is YES because Emacs in many cases has some unique
requirements that other applications not necessarily have.

Re: [ELPA] New package: plz

[Stefan Monnier]

> really is no alternative; these url.el bugs caused an endless stream of
> bug reports in my packages, and once we figured out the causes, waiting
> a few more years until the fixes are in Emacs just wasn't an option
> anymore.

This is a false dichotomy.  You can install your advice and hacks in
your package so it works Right Now™ *AND* submit patches upstream so it
gets fixed for all in the longer term.

Where did you get the idea that you had to choose?


        Stefan

Re: [ELPA] New package: plz

[Jonas Bernoulli]

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

>> really is no alternative; these url.el bugs caused an endless stream of
>> bug reports in my packages, and once we figured out the causes, waiting
>> a few more years until the fixes are in Emacs just wasn't an option
>> anymore.
>
> This is a false dichotomy.  You can install your advice and hacks in
> your package so it works Right Now™ *AND* submit patches upstream so it
> gets fixed for all in the longer term.
>
> Where did you get the idea that you had to choose?

That wasn't what I was trying to say.  These bugs have been fixed in
Emacs (either a recent release or the master branch) but since not
everyone immediately updates to the latest release (much less the master
branch) I do have to provide backports.

Of course switching to something other than url.el won't immediately
address that either and maybe hoping that basing Emacs networking on an
established third-party library would reduce the number and/or severity
of the bugs in the long run is illusory too.

I guess all I can say with any certainty is that in the past if found
url.el painful to use and have seen others share similar experiences.
And that, as layman, I have a hunch that using libcurl might help.

Re: [ELPA] New package: plz

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> 
>> TL;DR Maybe this was overly negative.  That wasn't my intention.  What I
>> really want to say is this: could someone™ with experience in this area
>> pretty please start working on bringing libcurl to Emacs?
>
> Are we confident enough that libcurl can satisfy Emacs's needs?
> Shouldn't someone™ first study our requirements and make sure they can
> be fulfilled by using libcurl?  It is not immediately clear to me that
> the answer is YES because Emacs in many cases has some unique
> requirements that other applications not necessarily have.

No, not really.  This is a layman's opinion based on the perceived
success of this library.  Maybe there are better solutions.  Maybe
another third-party library would be a better fit or maybe url.el
just needs more loving.

Then again, if curl is good enough to be used on Mars, then it
should be good enough for Emacs. ;D

Re: [ELPA] New package: plz

[Stefan Monnier]

Jonas Bernoulli [2022-05-21 20:10:13] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> really is no alternative; these url.el bugs caused an endless stream of
>>> bug reports in my packages, and once we figured out the causes, waiting
>>> a few more years until the fixes are in Emacs just wasn't an option
>>> anymore.
>>
>> This is a false dichotomy.  You can install your advice and hacks in
>> your package so it works Right Now™ *AND* submit patches upstream so it
>> gets fixed for all in the longer term.
>>
>> Where did you get the idea that you had to choose?
> That wasn't what I was trying to say.  These bugs have been fixed in
> Emacs (either a recent release or the master branch) but since not
> everyone immediately updates to the latest release (much less the master
> branch) I do have to provide backports.

Oh, sorry, I misunderstood.  Then yes, providing backports/advice/hacks
to make your code work with older releases is par for the course.


        Stefan

Re: plz -> curl?

[Juri Linkov]

>> ;; These are supposed to correspond to top-level customization groups,
>> ;; says rms.
>> (defvar finder-known-keywords '( 36 elements))
>
> Maybe we should allow classifying packages into more than three dozen
> groups?

There are 346 groups in (info "(*Finder*) Keyword unknown")

Re: plz -> curl?

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

  > Using cute names for unproven third-party packages also has the
  > advantage that the boring authorities name is still available when the
  > Emacs developers decide to implement "official" support for the same
  > thing.

It is always possible that the unproven third-party package
will develop into a success.

If we adopt a policy of encouraging unclear names at that stage,
we need to make it clear at that time that we could rename it later
if we wish to.

However, that should not imply _we_ will rewrite the code at that
time.  Basically, that's more work than we can do.  We need to guide
the developer to make the code clear.

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

Re: [ELPA] New package: plz

[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 hope we can consolidate this with `request.el` and `url.el` sooner
  > > rather than later.  As others mentioned, adding a backend to plz which
  > > uses url.el (or at least doesn't require `curl` to be installed) would
  > > be great.

  > Some people don't like the interface but that was never the main problem
  > I had with url.el.  What caused me pain is its bugs, and I suspect for
  > many other package maintainers it is the same.

Please be it noted that I have no opinion about url.el's code.  And no
opinion about plz.el's code.  I criticized its name for lack of clear
relation to the job it does, but nothing else about it.

The concern I raised is the avoidable extra complexity of having three
different libraries to do similar jobs by different methods, with
overlapping but different interfaces.

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