Adding use-package to ELPA

Adding use-package to ELPA

[Philip Kaludercic]

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


Hi,

from [0] it seems like use-package has collected the copyright
assignments from all the significant contributors, but nobody has had
the time to act on this.

As it seems to be a popular package, I tried adding it to GNU ELPA:


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

From 7492166c278e17b40ddc524d244b588e46be63cf Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 3 Mar 2022 11:08:40 +0100
Subject: [PATCH] * elpa-packages (use-package, bind-key): New packages

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

diff --git a/elpa-packages b/elpa-packages
index cfbf18b8a6..588c2fe161 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -60,6 +60,8 @@
   :lisp-dir "lisp"
   :doc "doc/bbdb.texi")
  ("beacon"		:url "https://github.com/Malabarba/beacon")
+ ("bind-key"         :url "https://github.com/jwiegley/use-package"
+  :ignored-files ("doc" "Makefile*" "bind-chords.el" "use-package*"))
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
@@ -571,6 +573,8 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
+ ("use-package"         :url "https://github.com/jwiegley/use-package"
+  :ignored-files ("doc" "Makefile*" "bind-*" "use-package-chords.el"))
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-got"		:url "https://git.omarpolo.com/vc-got"
-- 
2.30.2


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


and setting aside the copyright lines, it seems to work.  I guess the
more interesting question is if this should be added to ELPA or the
core?

[0] https://github.com/jwiegley/use-package/issues/282

-- 
	Philip Kaludercic

Adding use-package to ELPA

[Philip Kaludercic]

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


Hi,

from [0] it seems like use-package has collected the copyright
assignments from all the significant contributors, but nobody has had
the time to act on this.

As it seems to be a popular package, I tried adding it to GNU ELPA:


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

From 7492166c278e17b40ddc524d244b588e46be63cf Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Thu, 3 Mar 2022 11:08:40 +0100
Subject: [PATCH] * elpa-packages (use-package, bind-key): New packages

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

diff --git a/elpa-packages b/elpa-packages
index cfbf18b8a6..588c2fe161 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -60,6 +60,8 @@
   :lisp-dir "lisp"
   :doc "doc/bbdb.texi")
  ("beacon"		:url "https://github.com/Malabarba/beacon")
+ ("bind-key"         :url "https://github.com/jwiegley/use-package"
+  :ignored-files ("doc" "Makefile*" "bind-chords.el" "use-package*"))
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
@@ -571,6 +573,8 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
+ ("use-package"         :url "https://github.com/jwiegley/use-package"
+  :ignored-files ("doc" "Makefile*" "bind-*" "use-package-chords.el"))
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-got"		:url "https://git.omarpolo.com/vc-got"
-- 
2.30.2


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


and setting aside the copyright lines, it seems to work.  I guess the
more interesting question is if this should be added to ELPA or the
core?

[0] https://github.com/jwiegley/use-package/issues/282

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[Stefan Monnier]

Philip Kaludercic [2022-03-03 12:41:30] wrote:
> and setting aside the copyright lines, it seems to work.  I guess the
> more interesting question is if this should be added to ELPA or the
> core?

AFAIK, John's intention was to add it to the core, but seeing how it
still hasn't happened, I think it would make sense to add it to GNU ELPA
for now (alongside its two siblings `leaf` and `setup` ;-).


        Stefan

Re: Adding use-package to ELPA

[John Wiegley]

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

> AFAIK, John's intention was to add it to the core, but seeing how it still
> hasn't happened, I think it would make sense to add it to GNU ELPA for now
> (alongside its two siblings `leaf` and `setup` ;-).

I would definitely like to see it move to core, and would be happy to work
with others to make this happen. I feel it still needs enough effort -- mostly
in terms of documentation -- that this is why it hasn't happened yet.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding use-package to 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. ]]]

  > from [0] it seems like use-package has collected the copyright
  > assignments from all the significant contributors, but nobody has had
  > the time to act on this.

  > As it seems to be a popular package, I tried adding it to GNU ELPA:

Thank you.

-- 
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: Adding use-package to ELPA

[Philip Kaludercic]

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. ]]]
>
>   > from [0] it seems like use-package has collected the copyright
>   > assignments from all the significant contributors, but nobody has had
>   > the time to act on this.
>
>   > As it seems to be a popular package, I tried adding it to GNU ELPA:
>
> Thank you.

To clarify, as the way you quoted my messages is confusing, I haven't
added use-package to GNU ELPA the package repository, but I have just
attempted to build it within my local checkout of the ELPA build system.
As mentioned, the question is open whether or not the package should be
added to ELPA or not (I prefer adding it to ELPA, but I am biased).

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[chad]

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

On Sat, Mar 5, 2022 at 3:17 AM Philip Kaludercic <philipk@posteo.net> wrote:

> [...]
> As mentioned, the question is open whether or not the package should be
> added to ELPA or not (I prefer adding it to ELPA, but I am biased).
>

If you prefer adding it to ELPA as opposed to adding it to the core, could
you expand a bit on why you prefer that? It seems remarkably stable, pretty
amenable to external expansion, and apparently has all of the assignments
lined up (I had thought this was still incomplete, personally), so I would
expect it to be a good fit for core. That said, I haven't looked at the
matter closely.

Thanks,
~Chad

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

Re: Adding use-package to 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. ]]]

  > To clarify, as the way you quoted my messages is confusing, I haven't
  > added use-package to GNU ELPA the package repository, but I have just
  > attempted to build it within my local checkout of the ELPA build system.

I did indeed misunderstand it.  Thanks.

-- 
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: Adding use-package to ELPA

[Philip Kaludercic]

chad <yandros@gmail.com> writes:

> On Sat, Mar 5, 2022 at 3:17 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> [...]
>> As mentioned, the question is open whether or not the package should be
>> added to ELPA or not (I prefer adding it to ELPA, but I am biased).
>
> If you prefer adding it to ELPA as opposed to adding it to the core, could
> you expand a bit on why you prefer that? It seems remarkably stable, pretty
> amenable to external expansion, and apparently has all of the assignments
> lined up (I had thought this was still incomplete, personally), so I would
> expect it to be a good fit for core. That said, I haven't looked at the
> matter closely.

The main reason is that if the documentation is currently not optimal, I
think this is better tolerated when distributed via ELPA then when it is
distributed as part of Emacs itself, where I'd expect higher standards.

The less concrete reason is tied to me being the maintainer of a
alternative package (setup on ELPA), that takes a different approach to
the issue of a configuration macro.  As you can imagine, I prefer it
over `use-package', that I see as having inconsistencies and
idiosyncrasies, that should be addressed if it were added to the core.

Then again, I understand that being a very popular package in it's
current form, so slimming it down or changing the default behaviour
would not be applicable either.  Yet for a lot of people who already do
use or want to use `use-package', having it available OOTB would be
definitive advantage.  But then again, couldn't this be said for a
number of packages?

In the end, I didn't ask the question because I already knew what the
answer is, but because I was honestly interested in hearing different
perspectives.

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[John Wiegley]

>>>>> "PK" == Philip Kaludercic <philipk@posteo.net> writes:

PK> The less concrete reason is tied to me being the maintainer of a
PK> alternative package (setup on ELPA), that takes a different approach to
PK> the issue of a configuration macro. As you can imagine, I prefer it over
PK> `use-package', that I see as having inconsistencies and idiosyncrasies,
PK> that should be addressed if it were added to the core.

My only desire is the least inertia for users. Personally, I'd prefer it if
setup, leaf and use-package were all in core, and let the user decide which
one they wish to require at startup time. These types of packages are a bit
special, because -- since they configure everything else -- it's best if they
need the least configuration to become available. But I also understand that
we tend to pick "a way" when something goes into core, and this results in
maintainers having to make a choice of one over the other.

At the moment my only compelling evidence for use-package I find is its
current ubiquity. Most Emacs package I come across on GitHub these days offer
a use-package form for configuration. It would be nice if these could be
copied and pasted into one's .emacs with an absolute minimum of extra fuss.

But I'm not asserting that use-package is the best solution to the underlying
problem. I am interested to know more about the idiosyncrasies you've found.
The core of use-package has become highly user-configurable, so maybe it's a
problem that can be changed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding use-package to ELPA

[Philip Kaludercic]

"John Wiegley" <johnw@gnu.org> writes:

>>>>>> "PK" == Philip Kaludercic <philipk@posteo.net> writes:
>
> PK> The less concrete reason is tied to me being the maintainer of a
> PK> alternative package (setup on ELPA), that takes a different approach to
> PK> the issue of a configuration macro. As you can imagine, I prefer it over
> PK> `use-package', that I see as having inconsistencies and idiosyncrasies,
> PK> that should be addressed if it were added to the core.
>
> My only desire is the least inertia for users. Personally, I'd prefer it if
> setup, leaf and use-package were all in core, and let the user decide which
> one they wish to require at startup time. These types of packages are a bit
> special, because -- since they configure everything else -- it's best if they
> need the least configuration to become available. But I also understand that
> we tend to pick "a way" when something goes into core, and this results in
> maintainers having to make a choice of one over the other.

FWIW, as the maintainer of setup, I would strongly advise not to add it
to the core, as the package is far less mature.  I don't know enough
about leaf to say anything about the package, though it seems to be that
adding both would be superfluous, as they are relatively similar.  My
point with adding use-package to ELPA is that it already simplifies the
configuration to

    (unless (package-installed-p 'use-package)
      (package-install 'use-package))

without having to first configure MELPA.  How much of a difference this
makes is of course a different discussion.

> At the moment my only compelling evidence for use-package I find is its
> current ubiquity. Most Emacs package I come across on GitHub these days offer
> a use-package form for configuration. It would be nice if these could be
> copied and pasted into one's .emacs with an absolute minimum of extra fuss.

I agree, if any configuration macro were to be added, it would have to
be use-package, if anything just because of this point.

> But I'm not asserting that use-package is the best solution to the underlying
> problem. I am interested to know more about the idiosyncrasies you've found.
> The core of use-package has become highly user-configurable, so maybe it's a
> problem that can be changed.

I stopped using use-package ~2 years ago, so I don't remember the
details, but it could sketch up a few points that could be discussed,
and perhaps be addressed or at least acknowledged before adding the
package to the core.

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[John Wiegley]

>>>>> "PK" == Philip Kaludercic <philipk@posteo.net> writes:

PK> I stopped using use-package ~2 years ago, so I don't remember the details,
PK> but it could sketch up a few points that could be discussed, and perhaps
PK> be addressed or at least acknowledged before adding the package to the
PK> core.

Yes, I'd be very open to that discussion. The 2.0 rewrite was before 2015, so
it sounds like what you found is relevant to the current state of the code.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding use-package to ELPA

[Stefan Monnier]

>>>>>> "PK" == Philip Kaludercic <philipk@posteo.net> writes:
> PK> I stopped using use-package ~2 years ago, so I don't remember the details,
> PK> but it could sketch up a few points that could be discussed, and perhaps
> PK> be addressed or at least acknowledged before adding the package to the
> PK> core.
> Yes, I'd be very open to that discussion. The 2.0 rewrite was before 2015, so
> it sounds like what you found is relevant to the current state of the code.

I'll just throw in a request of mine: make it so `flymake-mode` gets
usable feedback when used in an init file.

With "old style" configuration by hand, it's pretty much hopeless, but
with something like use-package it seems we should be able to get
something tolerable.


        Stefan

Re: Adding use-package to ELPA

[Philip Kaludercic]

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

>>>>>>> "PK" == Philip Kaludercic <philipk@posteo.net> writes:
>> PK> I stopped using use-package ~2 years ago, so I don't remember the details,
>> PK> but it could sketch up a few points that could be discussed, and perhaps
>> PK> be addressed or at least acknowledged before adding the package to the
>> PK> core.
>> Yes, I'd be very open to that discussion. The 2.0 rewrite was before 2015, so
>> it sounds like what you found is relevant to the current state of the code.
>
> I'll just throw in a request of mine: make it so `flymake-mode` gets
> usable feedback when used in an init file.
>
> With "old style" configuration by hand, it's pretty much hopeless, but
> with something like use-package it seems we should be able to get
> something tolerable.

Do you know what the background is behind the issue?

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[Stefan Monnier]

> I'll just throw in a request of mine: make it so `flymake-mode` gets
> usable feedback when used in an init file.

To make it more concrete.
Currently if your init file contains just:

    ;;; -*- lexical-binding: t -*-
    (setq smtpmail-smtp-service 587)

and you enable `flymake-mode`, it will complain:

    assignment to free variable ‘smtpmail-smtp-service’

There's no much we can do about it in general.
With Setup/Leaf/use-package, OTOH, the user would presumably write
something like:

    ;;; -*- lexical-binding: t -*-
    (setup smtpmail
      (setq smtpmail-smtp-service 587))

which does provide the link between `smtpmail-smtp-service` and the
`smtpmail.el` file necessary for Emacs to be able in theory to discover
that `smtpmail-smtp-service` is not just some unknown free variable.

Currently, the above snippet using Setup still gives the same
warning, tho.

So `setup.el` could maybe do something like:

    (defmacro setup (pkg &rest args)
      (when (we-are-byte-compiling-p)
        (require (byte-run-strip-symbol-positions pkg)))
      ...)

so as to silence the warning.


        Stefan

Re: Adding use-package to ELPA

[John Wiegley]

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

>> I'll just throw in a request of mine: make it so `flymake-mode` gets usable
>> feedback when used in an init file.

SM> To make it more concrete.
SM> Currently if your init file contains just:

SM>     ;;; -*- lexical-binding: t -*-
SM>     (setq smtpmail-smtp-service 587)

SM> and you enable `flymake-mode`, it will complain:

SM>     assignment to free variable ‘smtpmail-smtp-service’

Ah, I understand what you mean now.

In use-package, this is exactly what the `:defines` keyword was created for,
so that you can indicate to the byte-compiler which variables will be defined
when the module is loaded.

This special handling is done in `use-package-normalize-keywords`, so one
could advise that function to intercept the list yielded by :defines and do
what's necessary to satisfy flymake. That is, if :defines itself isn't already
enough.
        
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding use-package to ELPA

[Philip Kaludercic]

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

>> I'll just throw in a request of mine: make it so `flymake-mode` gets
>> usable feedback when used in an init file.
>
> To make it more concrete.
> Currently if your init file contains just:
>
>     ;;; -*- lexical-binding: t -*-
>     (setq smtpmail-smtp-service 587)
>
> and you enable `flymake-mode`, it will complain:
>
>     assignment to free variable ‘smtpmail-smtp-service’
>
> There's no much we can do about it in general.
> With Setup/Leaf/use-package, OTOH, the user would presumably write
> something like:
>
>     ;;; -*- lexical-binding: t -*-
>     (setup smtpmail
>       (setq smtpmail-smtp-service 587))

> which does provide the link between `smtpmail-smtp-service` and the
> `smtpmail.el` file necessary for Emacs to be able in theory to discover
> that `smtpmail-smtp-service` is not just some unknown free variable.
>
> Currently, the above snippet using Setup still gives the same
> warning, tho.

True, because the above examples just expands to

      (setq smtpmail-smtp-service 587)

I'd usually recommend to use a local macro to avoid these issues,
because something like

      (setup smtpmail
        (:option smtpmail-smtp-service 587))

would expand to a `customize-set-variable'-like code, where
`smtpmail-smtp-service' would appear as a quoted symbol.

> So `setup.el` could maybe do something like:
>
>     (defmacro setup (pkg &rest args)
>       (when (we-are-byte-compiling-p)
>         (require (byte-run-strip-symbol-positions pkg)))
>       ...)

What is the point of using byte-run-strip-symbol-positions here?  I just
tried something like this, but it doesn't seem to work.

> so as to silence the warning.
>
>
>         Stefan
>

"John Wiegley" <johnw@gnu.org> writes:

>>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I'll just throw in a request of mine: make it so `flymake-mode` gets usable
>>> feedback when used in an init file.
>
> SM> To make it more concrete.
> SM> Currently if your init file contains just:
>
> SM>     ;;; -*- lexical-binding: t -*-
> SM>     (setq smtpmail-smtp-service 587)
>
> SM> and you enable `flymake-mode`, it will complain:
>
> SM>     assignment to free variable ‘smtpmail-smtp-service’
>
> Ah, I understand what you mean now.
>
> In use-package, this is exactly what the `:defines` keyword was created for,
> so that you can indicate to the byte-compiler which variables will be defined
> when the module is loaded.

I guess the issue here is that you would have to mention every variable
twice, declaring it with :defines before using it, while it could
actually be inferred, as Stefan points out.

> This special handling is done in `use-package-normalize-keywords`, so one
> could advise that function to intercept the list yielded by :defines and do
> what's necessary to satisfy flymake. That is, if :defines itself isn't already
> enough.

AFAIK flymake just reports the issues generated by the byte-compiler, so
if that is fixed, flymake shouldn't complain either.

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[Stefan Monnier]

> True, because the above examples just expands to
>
>       (setq smtpmail-smtp-service 587)
>
> I'd usually recommend to use a local macro to avoid these issues,
> because something like
>
>       (setup smtpmail
>         (:option smtpmail-smtp-service 587))
>
> would expand to a `customize-set-variable'-like code, where
> `smtpmail-smtp-service' would appear as a quoted symbol.

If it expands to `customize-set-variable`, then presumably you wouldn't
get the warning, indeed (that's good) but you also wouldn't get
a warning if you mistype the var (less good).

I want both: absence of warnings when the var name is right, and
presence of a warning when it isn't (and presence of a warning when the
var is obsolete).

>> So `setup.el` could maybe do something like:
>>
>>     (defmacro setup (pkg &rest args)
>>       (when (we-are-byte-compiling-p)
>>         (require (byte-run-strip-symbol-positions pkg)))
>>       ...)
>
> What is the point of using byte-run-strip-symbol-positions here?

Macros receive source code as input, which can/should come with
source-position information.  Before we can safely run that code we need
to strip the position info.

> I just tried something like this, but it doesn't seem to work.

I'm glad to see that I'm still able to write incorrect code.


        Stefan

Re: Adding use-package to ELPA

[Philip Kaludercic]

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

>> True, because the above examples just expands to
>>
>>       (setq smtpmail-smtp-service 587)
>>
>> I'd usually recommend to use a local macro to avoid these issues,
>> because something like
>>
>>       (setup smtpmail
>>         (:option smtpmail-smtp-service 587))
>>
>> would expand to a `customize-set-variable'-like code, where
>> `smtpmail-smtp-service' would appear as a quoted symbol.
>
> If it expands to `customize-set-variable`, then presumably you wouldn't
> get the warning, indeed (that's good) but you also wouldn't get
> a warning if you mistype the var (less good).
>
> I want both: absence of warnings when the var name is right, and
> presence of a warning when it isn't (and presence of a warning when the
> var is obsolete).

True, so this is certainly worth investigating.  Yet this is only part
of the problem, as function have a similar pattern, but they cannot
reliably be detected in this way.  E.g.

  (setup foo (:hook bar))

wouldn't be able to infer that bar is a function that exists, just
because it is being added to foo-bar-mode.

>>> So `setup.el` could maybe do something like:
>>>
>>>     (defmacro setup (pkg &rest args)
>>>       (when (we-are-byte-compiling-p)
>>>         (require (byte-run-strip-symbol-positions pkg)))
>>>       ...)
>>
>> What is the point of using byte-run-strip-symbol-positions here?
>
> Macros receive source code as input, which can/should come with
> source-position information.  Before we can safely run that code we need
> to strip the position info.

I'm glad to see that there are always some details about macros one
doesn't know about.

>> I just tried something like this, but it doesn't seem to work.
>
> I'm glad to see that I'm still able to write incorrect code.

Eh, my bad, I had used (macroexp-compiling-p) that apparently didn't do
the right job.  Without that check, it works in principle, but of course
doesn't do the intended thing.

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[Stefan Monnier]

> True, so this is certainly worth investigating.  Yet this is only part
> of the problem, as function have a similar pattern, but they cannot
> reliably be detected in this way.  E.g.
>
>   (setup foo (:hook bar))
>
> wouldn't be able to infer that bar is a function that exists, just
> because it is being added to foo-bar-mode.

There should be some reason to believe that `bar` will exist.
Without more info about where `bar` will come from, I can't begin this
think about how we can arrange to silence this warning.

> I'm glad to see that there are always some details about macros one
> doesn't know about.

This one is new in Emacs-29, thanks to Alan's "symbol with pos" feature.
See, even once you get to know it all, we introduce new details to keep
you entertained.

>>> I just tried something like this, but it doesn't seem to work.
>> I'm glad to see that I'm still able to write incorrect code.
> Eh, my bad, I had used (macroexp-compiling-p) that apparently didn't do
> the right job.

Hmm... it *should* work.
Feel free to send me further info personally so we can fix the problem.


        Stefan

Re: Adding use-package to ELPA

[Philip Kaludercic]

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

>> True, so this is certainly worth investigating.  Yet this is only part
>> of the problem, as function have a similar pattern, but they cannot
>> reliably be detected in this way.  E.g.
>>
>>   (setup foo (:hook bar))
>>
>> wouldn't be able to infer that bar is a function that exists, just
>> because it is being added to foo-bar-mode.
>
> There should be some reason to believe that `bar` will exist.
> Without more info about where `bar` will come from, I can't begin this
> think about how we can arrange to silence this warning.

I'm not sure if we had discussed this before, but couldn't the
initialisation file receive a different treatment by the byte-compiler,
than other files?

>>>> I just tried something like this, but it doesn't seem to work.
>>> I'm glad to see that I'm still able to write incorrect code.
>> Eh, my bad, I had used (macroexp-compiling-p) that apparently didn't do
>> the right job.
>
> Hmm... it *should* work.
> Feel free to send me further info personally so we can fix the problem.

Never mind this, the issue was that I overwrote
`macroexpand-all-environment', breaking macroexp-compiling-p.  With this
issue fixed, these warnings are fixed.

-- 
	Philip Kaludercic

Re: Adding use-package to ELPA

[Stefan Monnier]

Philip Kaludercic [2022-03-08 08:21:50] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> True, so this is certainly worth investigating.  Yet this is only part
>>> of the problem, as function have a similar pattern, but they cannot
>>> reliably be detected in this way.  E.g.
>>>
>>>   (setup foo (:hook bar))
>>>
>>> wouldn't be able to infer that bar is a function that exists, just
>>> because it is being added to foo-bar-mode.
>>
>> There should be some reason to believe that `bar` will exist.
>> Without more info about where `bar` will come from, I can't begin this
>> think about how we can arrange to silence this warning.
>
> I'm not sure if we had discussed this before, but couldn't the
> initialisation file receive a different treatment by the byte-compiler,
> than other files?

*The* init file, yes, of course it could.
But that won't help for people who split it into several files.
So, it's better if we can avoid such ad-hoc solutions.

> Never mind this, the issue was that I overwrote
> `macroexpand-all-environment', breaking macroexp-compiling-p.
> With this issue fixed, these warnings are fixed.

Great,


        Stefan