Subject: Re: bug#59900: 30.0.50; map pattern in pcase causes a byte-compile error

From: Eli Zaretskii <[email-masked]>
Date: Fri, 09 Dec 2022 21:06:46 +0200

> From: Michael Heerdegen <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Fri, 09 Dec 2022 19:02:32 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > Thanks, but all this still doesn't answer my questions,
> > unfortunately.  You-all are describing something that I cannot wrap my
> > head around, because that basic question was not answered yet.
> 
> What specific question?

The one I asked at the very beginning of this discussion:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59900#8

> pcase is extensible: It allows to define new pattern types.  "rx.el"
> defines a `rx' pcase pattern, "map.el" a `map' pcase pattern.  The
> normal way to be able to use them is to `require' the library in which
> they are defined.
> 
> Since `pcase' is a macro, the library (rx.el or map.el) must be loaded
> when a `pcase' form using such a pattern is compiled.
> 
> The `rx' pattern definition in rx.el uses autoload cookies so that
> compiling works even when rx.el is not loaded - it gets loaded
> automatically when compiling.
> 
> The map.el `map' pcase pattern doesn't use autoloading.  The OP found a
> case where compiling succeeded until some days ago without requiring
> map.el explictily, and now a require is needed.  But that was only by
> luck: AFAIU, map.el was already loaded in that scenario, and now it is
> any more.  But there is no guarantee that the library is always loaded
> when compiling arbitrary files, so one should _always_ explicitly
> require map.el when the file contains pcase forms with `map' patterns -
> even if this worked without in some cases in the past by luck.
> 
> The wish of the OP to make the `map' pattern in map.el `autoload'able
> like the `rx' pattern in rx.el is reasonable, I can try to create a
> patch.
> 
> But strictly speaking here is no bug, just the OP relying on something
> that in the past worked by luck.

It sounds like the bug is in the package which uses map.el, and that
package is not part of Emacs.