unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* cl-lib warnings (was: bug#60102: Move gv-expander of substring to cl-lib)
       [not found] ` <86o7s3lsnx.fsf@mail.linkov.net>
@ 2022-12-20 18:42   ` Stefan Monnier
  2022-12-21  8:37     ` cl-lib warnings Juri Linkov
  0 siblings, 1 reply; 61+ messages in thread
From: Stefan Monnier @ 2022-12-20 18:42 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

>> The `gv-expander` of `substring` uses the `cl--set-substring` function
>> that's defined only in `cl-lib`, so currently, you can compile
>>
>>     (setf (substring ...) ...)
>>
>> without requiring `cl-lib` but at run time it will tend to signal
>> a `void-function` error.
>> We could autoload `cl--set-substring`, but I think a better choice is to
>> move this `gv-expander` to `cl-lib.el`.
>
> I tried your patch by evaluating `(tab-bar-make-keymap-1)`,
> but it still fails with:

My match was indeed motivated by the `tar-bar.el` code, but it doesn't
fix the `tab-bar.el` code, indeed.

The problem of the `tab-bar.el` code is (well, was, since I changed it
in the mean time) that `(setf (substring ...) ...)` needs `cl-lib` but
`tab-bar.el` doesn't `(require 'cl-lib)`.

It is compounded by the fact that `cl-lib` is preloaded in
`src/bootstrap-emacs`, so we don't get a compiler warning about
the possibility that `cl--set-substring` won't be available at runtime,
since `tab-bar.el` is preloaded and hence compiled by `src/bootstrap-emacs`.

And even if you try to recompile it with `src/emacs`, you still
won't get a compilation warning if you're using the native compiler,
because the native compiler itself requires `cl-lib`.

IOW, it's becoming difficult to be warned by the compiler about missing
`(require 'cl-lib)` :-(

Looking at historical evolution, I think the sanest way to fix this is
to preload `cl-lib`.


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-20 18:42   ` cl-lib warnings (was: bug#60102: Move gv-expander of substring to cl-lib) Stefan Monnier
@ 2022-12-21  8:37     ` Juri Linkov
  2022-12-21 12:45       ` Eli Zaretskii
  0 siblings, 1 reply; 61+ messages in thread
From: Juri Linkov @ 2022-12-21  8:37 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> IOW, it's becoming difficult to be warned by the compiler about missing
> `(require 'cl-lib)` :-(
>
> Looking at historical evolution, I think the sanest way to fix this is
> to preload `cl-lib`.

These cl-related files are already preloaded:

- emacs-lisp/cl-preloaded with byte-compiled size 29482;
- emacs-lisp/cl-generic with byte-compiled size 66127;

So maybe it's not a problem to preload cl-lib
with byte-compiled size 19861.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21  8:37     ` cl-lib warnings Juri Linkov
@ 2022-12-21 12:45       ` Eli Zaretskii
  2022-12-21 12:57         ` João Távora
  2022-12-21 17:53         ` Stefan Monnier
  0 siblings, 2 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-21 12:45 UTC (permalink / raw)
  To: Juri Linkov; +Cc: monnier, emacs-devel

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Wed, 21 Dec 2022 10:37:16 +0200
> 
> > IOW, it's becoming difficult to be warned by the compiler about missing
> > `(require 'cl-lib)` :-(
> >
> > Looking at historical evolution, I think the sanest way to fix this is
> > to preload `cl-lib`.
> 
> These cl-related files are already preloaded:
> 
> - emacs-lisp/cl-preloaded with byte-compiled size 29482;
> - emacs-lisp/cl-generic with byte-compiled size 66127;
> 
> So maybe it's not a problem to preload cl-lib
> with byte-compiled size 19861.

Yeah, let's also preload Org while at that.  And Gnus.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 12:45       ` Eli Zaretskii
@ 2022-12-21 12:57         ` João Távora
  2022-12-21 13:47           ` Eli Zaretskii
  2022-12-21 17:53         ` Stefan Monnier
  1 sibling, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-21 12:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juri Linkov, Stefan Monnier, emacs-devel

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

On Wed, Dec 21, 2022, 12:45 Eli Zaretskii <

> > These cl-related files are already preloaded:
> >
> > - emacs-lisp/cl-preloaded with byte-compiled size 29482;
> > - emacs-lisp/cl-generic with byte-compiled size 66127;
> >
> > So maybe it's not a problem to preload cl-lib
> > with byte-compiled size 19861.
>
> Yeah, let's also preload Org while at that.  And Gnus.
>

Hmm, we could trade it in for eldoc.el which is preloaded for some reason
related to Elisp-mode but really doesn't need to be (last time I checked).

>

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 12:57         ` João Távora
@ 2022-12-21 13:47           ` Eli Zaretskii
  2022-12-21 14:04             ` João Távora
  2022-12-21 14:15             ` Eli Zaretskii
  0 siblings, 2 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-21 13:47 UTC (permalink / raw)
  To: João Távora; +Cc: juri, monnier, emacs-devel

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 21 Dec 2022 12:57:21 +0000
> Cc: Juri Linkov <juri@linkov.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
>  > So maybe it's not a problem to preload cl-lib
>  > with byte-compiled size 19861.
> 
>  Yeah, let's also preload Org while at that.  And Gnus.
> 
> Hmm, we could trade it in for eldoc.el which is preloaded for some reason related to Elisp-mode but really
> doesn't need to be (last time I checked).

If we don't preload eldoc, it will be automatically loaded once you do
"emacs -Q".  So it makes no sense not to preload it, unless we also
display it by default.




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 13:47           ` Eli Zaretskii
@ 2022-12-21 14:04             ` João Távora
  2022-12-21 14:20               ` Eli Zaretskii
  2022-12-21 14:15             ` Eli Zaretskii
  1 sibling, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-21 14:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 1:47 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 21 Dec 2022 12:57:21 +0000
> > Cc: Juri Linkov <juri@linkov.net>, Stefan Monnier <
> monnier@iro.umontreal.ca>,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> >  > So maybe it's not a problem to preload cl-lib
> >  > with byte-compiled size 19861.
> >
> >  Yeah, let's also preload Org while at that.  And Gnus.
> >
> > Hmm, we could trade it in for eldoc.el which is preloaded for some
> reason related to Elisp-mode but really
> > doesn't need to be (last time I checked).
>
> If we don't preload eldoc, it will be automatically loaded once you do
> "emacs -Q".  So it makes no sense not to preload it,
>

But I can't see how ElDoc can be useful when doing lots of
things from emacs -Q like adding '--batch -f batch-byte-compile'
or '--batch -f elisp-flymake--batch-compile-for-flymake', to name
 just two.

Even when just emacs -Q is used, which starts up
lisp-interaction-mode, which derives from emacs-lisp-mode, it's
not unthinkable that ElDoc won't be actually needed at all.

So IMO ElDoc should be auto-loaded, but not preloaded.
There's also another reason to do so: upgrading ElDoc via
M-x package-install (note that it is a :core GNU ELPA package)
is, last time I checked, made more difficult, and requires the
user to restart Emacs.

> unless we also display it by default.

You meant "disable" instead of "display" right?

João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 13:47           ` Eli Zaretskii
  2022-12-21 14:04             ` João Távora
@ 2022-12-21 14:15             ` Eli Zaretskii
  1 sibling, 0 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-21 14:15 UTC (permalink / raw)
  To: joaotavora; +Cc: juri, monnier, emacs-devel

> Date: Wed, 21 Dec 2022 15:47:48 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> If we don't preload eldoc, it will be automatically loaded once you do
> "emacs -Q".  So it makes no sense not to preload it, unless we also
> display it by default.
  ^^^^^^^
Ugh, that was supposed to be "disable", sorry.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:04             ` João Távora
@ 2022-12-21 14:20               ` Eli Zaretskii
  2022-12-21 14:35                 ` João Távora
  2022-12-21 14:50                 ` Juanma Barranquero
  0 siblings, 2 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-21 14:20 UTC (permalink / raw)
  To: João Távora; +Cc: juri, monnier, emacs-devel

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 21 Dec 2022 14:04:34 +0000
> Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
>  If we don't preload eldoc, it will be automatically loaded once you do
>  "emacs -Q".  So it makes no sense not to preload it, 
> 
> But I can't see how ElDoc can be useful when doing lots of 
> things from emacs -Q like adding '--batch -f batch-byte-compile'
> or '--batch -f elisp-flymake--batch-compile-for-flymake', to name
>  just two.
> 
> Even when just emacs -Q is used, which starts up
> lisp-interaction-mode, which derives from emacs-lisp-mode, it's
> not unthinkable that ElDoc won't be actually needed at all.
> 
> So IMO ElDoc should be auto-loaded, but not preloaded.
> There's also another reason to do so: upgrading ElDoc via
> M-x package-install (note that it is a :core GNU ELPA package) 
> is, last time I checked, made more difficult, and requires the
> user to restart Emacs.

If you want to lobby for disabling ElDoc by default, feel free (and
good luck!).  But that is a different discussion.

Our policy and practice was since long ago that any package which is
always or almost always loaded at startup without any user say-so,
should be preloaded, since not doing that makes very little sense.  So
until and unless we decide to disable ElDoc, it should stay preloaded.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:20               ` Eli Zaretskii
@ 2022-12-21 14:35                 ` João Távora
  2022-12-21 14:50                 ` Juanma Barranquero
  1 sibling, 0 replies; 61+ messages in thread
From: João Távora @ 2022-12-21 14:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 2:20 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 21 Dec 2022 14:04:34 +0000
> > Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >
> >  If we don't preload eldoc, it will be automatically loaded once you do
> >  "emacs -Q".  So it makes no sense not to preload it,
> >
> > But I can't see how ElDoc can be useful when doing lots of
> > things from emacs -Q like adding '--batch -f batch-byte-compile'
> > or '--batch -f elisp-flymake--batch-compile-for-flymake', to name
> >  just two.
> >
> > Even when just emacs -Q is used, which starts up
> > lisp-interaction-mode, which derives from emacs-lisp-mode, it's
> > not unthinkable that ElDoc won't be actually needed at all.
> >
> > So IMO ElDoc should be auto-loaded, but not preloaded.
> > There's also another reason to do so: upgrading ElDoc via
> > M-x package-install (note that it is a :core GNU ELPA package)
> > is, last time I checked, made more difficult, and requires the
> > user to restart Emacs.
>
> If you want to lobby for disabling ElDoc by default, feel free (and
> good luck!).  But that is a different discussion.
>

Yes, that is a prerequisite, of course.  AFAICT there is no reason to
global-eldoc-mode enabled globally (or really, to have that variable
at all). Major modes and minor modes (like elisp-mode or eglot), which
are its clients, and which want to keep the can use add-hook and
have it load just-in-time when (eldoc-mode 1) happens or somesuch.


> Our policy and practice was since long ago that any package which is
> always or almost always loaded at startup without any user say-so,
> should be preloaded, since not doing that makes very little sense.  So
> until and unless we decide to disable ElDoc, it should stay preloaded.
>

Makes sense, of course.  And I think Juri's point is that cl-lib.el is among
those relatively small packages which is "almost always loaded".

João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:20               ` Eli Zaretskii
  2022-12-21 14:35                 ` João Távora
@ 2022-12-21 14:50                 ` Juanma Barranquero
  2022-12-21 14:55                   ` João Távora
                                     ` (2 more replies)
  1 sibling, 3 replies; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-21 14:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: João Távora, juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 3:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Our policy and practice was since long ago that any package which is
> always or almost always loaded at startup without any user say-so,
> should be preloaded, since not doing that makes very little sense.

We don't have precise metrics for "always or almost always loaded at
startup", I think.

But cl-lib is unconditionally required by 191 files under lisp/, right now.
Including things like
desktop, help-fns, help-mode, kmacro, imenu, tab-line and package, among
many others.
And of course vc, Calc and Org. And use-package, which will perhaps become
the de facto
way to customize their .emacs for many people.

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:50                 ` Juanma Barranquero
@ 2022-12-21 14:55                   ` João Távora
  2022-12-21 14:57                     ` Juanma Barranquero
  2022-12-21 17:14                   ` Eli Zaretskii
  2023-01-06  5:40                   ` Sean Whitton
  2 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-21 14:55 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Eli Zaretskii, juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 2:51 PM Juanma Barranquero <lekktu@gmail.com> wrote:

>
> But cl-lib is unconditionally required by 191 files under lisp/, right
> now. Including things like
> desktop, help-fns, help-mode, kmacro, imenu, tab-line and package, among
> many others.
> And of course vc, Calc and Org. And use-package, which will perhaps become
> the de facto
> way to customize their .emacs for many people.
>

Agree with the rest of the argument, but let's hope the latter doesn't
materialize.  I'd rather not have to to learn to learn another DSL to
process bug reports. But yes yes, that's a different discussion.

João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:55                   ` João Távora
@ 2022-12-21 14:57                     ` Juanma Barranquero
  2022-12-21 15:08                       ` João Távora
  0 siblings, 1 reply; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-21 14:57 UTC (permalink / raw)
  To: João Távora; +Cc: Eli Zaretskii, juri, monnier, emacs-devel

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

I don't think we've added use-package to the Emacs core with the hope that
people will use it less than they do ;-)

But yes, another discussion altogether.

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:57                     ` Juanma Barranquero
@ 2022-12-21 15:08                       ` João Távora
  2022-12-26  3:13                         ` Milan Glacier
  0 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-21 15:08 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Eli Zaretskii, juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 2:57 PM Juanma Barranquero <lekktu@gmail.com> wrote:

> I don't think we've added use-package to the Emacs core with the hope that
> people will use it less than they do ;-)
>

Yeah, I know.  But maybe we didn't quite consider the ~30
commands or so that it provides to do things already possible
with well-understood primitives that have existed forever.

I don't have a problem with people using it, just as I don't have
a problem with people using Magit, which I also don't.  It's just
I plan to kindly ask the potential bug-reporter to show his minimal
configuration in terms of stuff I can unequivocally understand
the semantics of.

João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:50                 ` Juanma Barranquero
  2022-12-21 14:55                   ` João Távora
@ 2022-12-21 17:14                   ` Eli Zaretskii
  2022-12-21 22:33                     ` Juanma Barranquero
  2023-01-06  5:40                   ` Sean Whitton
  2 siblings, 1 reply; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-21 17:14 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: joaotavora, juri, monnier, emacs-devel

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 21 Dec 2022 15:50:52 +0100
> Cc: João Távora <joaotavora@gmail.com>, juri@linkov.net, 
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On Wed, Dec 21, 2022 at 3:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
>  
> > Our policy and practice was since long ago that any package which is
> > always or almost always loaded at startup without any user say-so,
> > should be preloaded, since not doing that makes very little sense.
>   
> We don't have precise metrics for "always or almost always loaded at startup", I think.

"Always" doesn't require any metrics.

> But cl-lib is unconditionally required by 191 files under lisp/,
> right now.

Out of 1600+, yes.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 12:45       ` Eli Zaretskii
  2022-12-21 12:57         ` João Távora
@ 2022-12-21 17:53         ` Stefan Monnier
  2022-12-24 22:55           ` Sean Whitton
  2022-12-25  8:29           ` Juri Linkov
  1 sibling, 2 replies; 61+ messages in thread
From: Stefan Monnier @ 2022-12-21 17:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juri Linkov, emacs-devel

>> - emacs-lisp/cl-preloaded with byte-compiled size 29482;
>> - emacs-lisp/cl-generic with byte-compiled size 66127;
>>
>> So maybe it's not a problem to preload cl-lib
>> with byte-compiled size 19861.
>
> Yeah, let's also preload Org while at that.  And Gnus.

FWIW, I suspect that `cl-lib.el` is used in many more Emacs sessions
than `tab-bar.el` (byte-compiled size 92652), so I'd be in favor of
*not* preloading `tab-bar.el` and preload `cl-lib.el` instead (which
should result in an overall smaller preloaded heap).


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 17:14                   ` Eli Zaretskii
@ 2022-12-21 22:33                     ` Juanma Barranquero
  2022-12-22  7:13                       ` Eli Zaretskii
  0 siblings, 1 reply; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-21 22:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: joaotavora, juri, monnier, emacs-devel

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

On Wed, Dec 21, 2022 at 6:14 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Out of 1600+, yes.

Well, my point was not that it was a majority, though 11.78% is more than I
expected.
My point is that there are among them some packages that are (quite likely)
widely used
(like desktop.el, or the help ones, or Org) so even if only 12% of .el
files load cl-lib,
that surely represents a much bigger percentage of Emacs instances.

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 22:33                     ` Juanma Barranquero
@ 2022-12-22  7:13                       ` Eli Zaretskii
  2022-12-22  7:23                         ` Juanma Barranquero
  2022-12-22 22:24                         ` Yuan Fu
  0 siblings, 2 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-22  7:13 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: joaotavora, juri, monnier, emacs-devel

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 21 Dec 2022 23:33:29 +0100
> Cc: joaotavora@gmail.com, juri@linkov.net, monnier@iro.umontreal.ca, 
> 	emacs-devel@gnu.org
> 
> On Wed, Dec 21, 2022 at 6:14 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Out of 1600+, yes.
> 
> Well, my point was not that it was a majority, though 11.78% is more than I expected.
> My point is that there are among them some packages that are (quite likely) widely used
> (like desktop.el, or the help ones, or Org) so even if only 12% of .el files load cl-lib,
> that surely represents a much bigger percentage of Emacs instances.

I'm afraid if we preload cl-lib, that would open the gates of hell
whereby all of our code will be rewritten in cl-lib dialect that is
(at least for me) much harder to read and maintain.  So maybe wait
until I'm safely dead (at least as far as Emacs is concerned) before
doing that.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-22  7:13                       ` Eli Zaretskii
@ 2022-12-22  7:23                         ` Juanma Barranquero
  2022-12-22  8:53                           ` Eli Zaretskii
  2022-12-22 22:24                         ` Yuan Fu
  1 sibling, 1 reply; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-22  7:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: joaotavora, juri, monnier, emacs-devel

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

Perhaps now it's not a good time to say that I'm using cl-lib in my rework
of bs.el to derive bs-mode from tabulated-list-mode... ;-)

(But no,I'm not "rewriting bs.el in cl-lib dialect", I think I've used four
or five functions.)

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-22  7:23                         ` Juanma Barranquero
@ 2022-12-22  8:53                           ` Eli Zaretskii
  0 siblings, 0 replies; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-22  8:53 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: joaotavora, juri, monnier, emacs-devel

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 22 Dec 2022 08:23:18 +0100
> Cc: joaotavora@gmail.com, juri@linkov.net, monnier@iro.umontreal.ca, 
>  emacs-devel@gnu.org
> 
> Perhaps now it's not a good time to say that I'm using cl-lib in my rework of bs.el to derive bs-mode from
> tabulated-list-mode... ;-)

You are not alone.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-22  7:13                       ` Eli Zaretskii
  2022-12-22  7:23                         ` Juanma Barranquero
@ 2022-12-22 22:24                         ` Yuan Fu
  2022-12-22 23:56                           ` Stefan Monnier
  2022-12-23  7:30                           ` Eli Zaretskii
  1 sibling, 2 replies; 61+ messages in thread
From: Yuan Fu @ 2022-12-22 22:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juanma Barranquero, joaotavora, juri, monnier, emacs-devel



> On Dec 21, 2022, at 11:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Wed, 21 Dec 2022 23:33:29 +0100
>> Cc: joaotavora@gmail.com, juri@linkov.net, monnier@iro.umontreal.ca, 
>> 	emacs-devel@gnu.org
>> 
>> On Wed, Dec 21, 2022 at 6:14 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> Out of 1600+, yes.
>> 
>> Well, my point was not that it was a majority, though 11.78% is more than I expected.
>> My point is that there are among them some packages that are (quite likely) widely used
>> (like desktop.el, or the help ones, or Org) so even if only 12% of .el files load cl-lib,
>> that surely represents a much bigger percentage of Emacs instances.
> 
> I'm afraid if we preload cl-lib, that would open the gates of hell
> whereby all of our code will be rewritten in cl-lib dialect that is
> (at least for me) much harder to read and maintain.  So maybe wait
> until I'm safely dead (at least as far as Emacs is concerned) before
> doing that.
> 

Wait, what constitutes of cl-lib dialect? Do you mean things like cl-defun? I hope using cl-loop and cl-reduce, cl-remove-if and the like doesn’t make code harder to read.

Yuan


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-22 22:24                         ` Yuan Fu
@ 2022-12-22 23:56                           ` Stefan Monnier
  2022-12-23  7:30                           ` Eli Zaretskii
  1 sibling, 0 replies; 61+ messages in thread
From: Stefan Monnier @ 2022-12-22 23:56 UTC (permalink / raw)
  To: Yuan Fu; +Cc: Eli Zaretskii, Juanma Barranquero, joaotavora, juri, emacs-devel

> Wait, what constitutes of cl-lib dialect? Do you mean things like cl-defun?
> I hope using cl-loop and cl-reduce, cl-remove-if and the like doesn’t make
> code harder to read.

I think `cl-loop` does :-(
`cl-reduce` and `cl-remove-if` are less problematic since they are
functions,

`cl-defun` is probably fine as long as you just use `&key`, but things like
`&aux` or destructuring are likely to make the code just harder to read.


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-22 22:24                         ` Yuan Fu
  2022-12-22 23:56                           ` Stefan Monnier
@ 2022-12-23  7:30                           ` Eli Zaretskii
  2022-12-23 23:42                             ` Yuan Fu
  1 sibling, 1 reply; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-23  7:30 UTC (permalink / raw)
  To: Yuan Fu; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 22 Dec 2022 14:24:02 -0800
> Cc: Juanma Barranquero <lekktu@gmail.com>,
>  joaotavora@gmail.com,
>  juri@linkov.net,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> > I'm afraid if we preload cl-lib, that would open the gates of hell
> > whereby all of our code will be rewritten in cl-lib dialect that is
> > (at least for me) much harder to read and maintain.  So maybe wait
> > until I'm safely dead (at least as far as Emacs is concerned) before
> > doing that.
> > 
> 
> Wait, what constitutes of cl-lib dialect? Do you mean things like cl-defun? I hope using cl-loop and cl-reduce, cl-remove-if and the like doesn’t make code harder to read.

Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
use Fortran or C, I will use Fortran or C; I don't want to see Fortran
for-loops in Emacs Lisp.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-23  7:30                           ` Eli Zaretskii
@ 2022-12-23 23:42                             ` Yuan Fu
  2022-12-24  0:24                               ` Juanma Barranquero
                                                 ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Yuan Fu @ 2022-12-23 23:42 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Juanma Barranquero, João Távora, juri, monnier,
	emacs-devel

>> Wait, what constitutes of cl-lib dialect? Do you mean things like cl-defun?
>> I hope using cl-loop and cl-reduce, cl-remove-if and the like doesn’t make
>> code harder to read.
> 
> I think `cl-loop` does :-(
> `cl-reduce` and `cl-remove-if` are less problematic since they are
> functions,
> 
> `cl-defun` is probably fine as long as you just use `&key`, but things like
> `&aux` or destructuring are likely to make the code just harder to read.


>> 
>> Wait, what constitutes of cl-lib dialect? Do you mean things like cl-defun? I hope using cl-loop and cl-reduce, cl-remove-if and the like doesn’t make code harder to read.
> 
> Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
> use Fortran or C, I will use Fortran or C; I don't want to see Fortran
> for-loops in Emacs Lisp.

Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs codebase.

Yuan


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-23 23:42                             ` Yuan Fu
@ 2022-12-24  0:24                               ` Juanma Barranquero
  2022-12-24 14:08                                 ` Stefan Monnier
  2022-12-24  0:26                               ` João Távora
  2022-12-24  6:40                               ` Eli Zaretskii
  2 siblings, 1 reply; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-24  0:24 UTC (permalink / raw)
  To: Yuan Fu; +Cc: Eli Zaretskii, João Távora, juri, monnier, emacs-devel

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

On Sat, Dec 24, 2022 at 12:42 AM Yuan Fu <casouri@gmail.com> wrote:

> Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs
codebase.

I doubt you're responsible for 730+ uses of cl-loop across 150+ files ;-)

It is expressive, and sometimes the easiest way to do something, but it
certainly looks unLispy. Perhaps elisp should've adopted the iter macro.
Ah, well...

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-23 23:42                             ` Yuan Fu
  2022-12-24  0:24                               ` Juanma Barranquero
@ 2022-12-24  0:26                               ` João Távora
  2022-12-24 10:33                                 ` Philip Kaludercic
  2022-12-24 22:59                                 ` cl-lib warnings Sean Whitton
  2022-12-24  6:40                               ` Eli Zaretskii
  2 siblings, 2 replies; 61+ messages in thread
From: João Távora @ 2022-12-24  0:26 UTC (permalink / raw)
  To: Yuan Fu
  Cc: Eli Zaretskii, Juanma Barranquero, Juri Linkov, Stefan Monnier,
	emacs-devel

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

On Fri, Dec 23, 2022, 23:42 Yuan Fu <casouri@gmail.com> wrote:

> Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
> > use Fortran or C, I will use Fortran or C; I don't want to see Fortran
> > for-loops in Emacs Lisp.
>
> Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs codebase.
>

As a data point, some of us are, like you, highly appreciative of cl-loop,
and cannot see anything remotely approaching its versatility in other
programming languages. I don't know what its detractors recommend for
iterating over a plist, to give just one example.

João

>

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-23 23:42                             ` Yuan Fu
  2022-12-24  0:24                               ` Juanma Barranquero
  2022-12-24  0:26                               ` João Távora
@ 2022-12-24  6:40                               ` Eli Zaretskii
  2022-12-24 13:01                                 ` Dmitry Gutov
  2 siblings, 1 reply; 61+ messages in thread
From: Eli Zaretskii @ 2022-12-24  6:40 UTC (permalink / raw)
  To: Yuan Fu; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 23 Dec 2022 15:42:52 -0800
> Cc: Juanma Barranquero <lekktu@gmail.com>,
>  João Távora <joaotavora@gmail.com>,
>  juri@linkov.net,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> > Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
> > use Fortran or C, I will use Fortran or C; I don't want to see Fortran
> > for-loops in Emacs Lisp.
> 
> Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs codebase.

Thank you.  IMHO, it should be used only when using the normal ELisp
constructs makes the code too complex to understand.

But that's just MO and my stylistic preference; I'm not going to
reject changes because they use cl-loop.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24  0:26                               ` João Távora
@ 2022-12-24 10:33                                 ` Philip Kaludercic
  2022-12-24 11:01                                   ` João Távora
  2022-12-24 22:59                                 ` cl-lib warnings Sean Whitton
  1 sibling, 1 reply; 61+ messages in thread
From: Philip Kaludercic @ 2022-12-24 10:33 UTC (permalink / raw)
  To: João Távora
  Cc: Yuan Fu, Eli Zaretskii, Juanma Barranquero, Juri Linkov,
	Stefan Monnier, emacs-devel

João Távora <joaotavora@gmail.com> writes:

> On Fri, Dec 23, 2022, 23:42 Yuan Fu <casouri@gmail.com> wrote:
>
>> Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
>> > use Fortran or C, I will use Fortran or C; I don't want to see Fortran
>> > for-loops in Emacs Lisp.
>>
>> Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs codebase.
>>
>
> As a data point, some of us are, like you, highly appreciative of cl-loop,
> and cannot see anything remotely approaching its versatility in other
> programming languages. I don't know what its detractors recommend for
> iterating over a plist, to give just one example.

I would guess a custom function, say `plist-map' along the lines of
`maphash'.  I am kind of surprised to see that this doesn't exist, but
according to my intuition of property lists, they are not meant to be
iterated.

While writing this, I also just realise this exists in the "map"
package.

  (map-do (lambda (key val)
            (message "Key %s, Value %s" key val))
          '(:one 1 :two 2 :three 3))



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24 10:33                                 ` Philip Kaludercic
@ 2022-12-24 11:01                                   ` João Távora
  2022-12-26  0:11                                     ` cl-loop and plists vs alists Philip Kaludercic
  0 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-24 11:01 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Yuan Fu, Eli Zaretskii, Juanma Barranquero, Juri Linkov,
	Stefan Monnier, emacs-devel

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

On Sat, Dec 24, 2022, 10:33 Philip Kaludercic <philipk@posteo.net> wrote:

> .
>
> I would guess a custom function, say `plist-map' along the lines of
> `maphash'.  I am kind of surprised to see that this doesn't exist, but
> according to my intuition of property lists, they are not meant to be
> iterated.
>

Until you step into the real world and you have to.

>
> While writing this, I also just realise this exists in the "map"
> package.
>
>   (map-do (lambda (key val)
>             (message "Key %s, Value %s" key val))
>           '(:one 1 :two 2 :three 3))
>

Right, a custom function, a loser in versatility (even if this one is
polymorphic, that strength is wasted here) Take your example: print only
three pairs max and a "and more" if there are more than there.

João

>

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24  6:40                               ` Eli Zaretskii
@ 2022-12-24 13:01                                 ` Dmitry Gutov
  0 siblings, 0 replies; 61+ messages in thread
From: Dmitry Gutov @ 2022-12-24 13:01 UTC (permalink / raw)
  To: Eli Zaretskii, Yuan Fu; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

On 24/12/2022 08:40, Eli Zaretskii wrote:
>> From: Yuan Fu<casouri@gmail.com>
>> Date: Fri, 23 Dec 2022 15:42:52 -0800
>> Cc: Juanma Barranquero<lekktu@gmail.com>,
>>   João Távora<joaotavora@gmail.com>,
>>   juri@linkov.net,
>>   monnier@iro.umontreal.ca,
>>   emacs-devel@gnu.org
>>
>>> Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
>>> use Fortran or C, I will use Fortran or C; I don't want to see Fortran
>>> for-loops in Emacs Lisp.
>> Darn it! I loved cl-loop 😄 I’ll curb my use of cl-loop in Emacs codebase.
> Thank you.  IMHO, it should be used only when using the normal ELisp
> constructs makes the code too complex to understand.

In at least some cases, it's the most readable among the fastest ways to 
implement some feature (i.e. when you need to map+filter, it avoids 
intermediate allocations).



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24  0:24                               ` Juanma Barranquero
@ 2022-12-24 14:08                                 ` Stefan Monnier
  2022-12-24 14:39                                   ` Juanma Barranquero
  0 siblings, 1 reply; 61+ messages in thread
From: Stefan Monnier @ 2022-12-24 14:08 UTC (permalink / raw)
  To: Juanma Barranquero
  Cc: Yuan Fu, Eli Zaretskii, João Távora, juri, emacs-devel

> It is expressive, and sometimes the easiest way to do something, but it
> certainly looks unLispy. Perhaps elisp should've adopted the iter macro.

Which "iter" macro are you referring to?
BTW, nowadays for non-trivial loops, I like to use `named-let`.


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24 14:08                                 ` Stefan Monnier
@ 2022-12-24 14:39                                   ` Juanma Barranquero
  2022-12-24 19:13                                     ` Tomas Hlavaty
  0 siblings, 1 reply; 61+ messages in thread
From: Juanma Barranquero @ 2022-12-24 14:39 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Yuan Fu, Eli Zaretskii, João Távora, juri, emacs-devel

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

On Sat, Dec 24, 2022 at 3:08 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:


> Which "iter" macro are you referring to?
>

There's  a package for Common Lisp that implements an iter construct that
is, basically, the whole CL `loop' but with a more lispy syntax.

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24 14:39                                   ` Juanma Barranquero
@ 2022-12-24 19:13                                     ` Tomas Hlavaty
  0 siblings, 0 replies; 61+ messages in thread
From: Tomas Hlavaty @ 2022-12-24 19:13 UTC (permalink / raw)
  To: Juanma Barranquero, Stefan Monnier
  Cc: Yuan Fu, Eli Zaretskii, João Távora, juri, emacs-devel

On Sat 24 Dec 2022 at 15:39, Juanma Barranquero <lekktu@gmail.com> wrote:
> There's  a package for Common Lisp that implements an iter construct that
> is, basically, the whole CL `loop' but with a more lispy syntax.

iterate is a bad idea
use the simplest lisp construct for the problem at hand instead



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 17:53         ` Stefan Monnier
@ 2022-12-24 22:55           ` Sean Whitton
  2022-12-25  7:05             ` tomas
  2022-12-25  8:29           ` Juri Linkov
  1 sibling, 1 reply; 61+ messages in thread
From: Sean Whitton @ 2022-12-24 22:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Juri Linkov, emacs-devel

Hello,

On Wed 21 Dec 2022 at 12:53PM -05, Stefan Monnier wrote:

> FWIW, I suspect that `cl-lib.el` is used in many more Emacs sessions
> than `tab-bar.el` (byte-compiled size 92652), so I'd be in favor of
> *not* preloading `tab-bar.el` and preload `cl-lib.el` instead (which
> should result in an overall smaller preloaded heap).

Bugs which would not occur were cl-lib preloaded come up relatively
often, and tend to spawn long mailing list/debbugs threads where people
figure out what to do.  Therefore, we'd save a lot of developer time if
we preloaded cl-lib.  This is the most significant advantage.

Preloading cl-lib would not amount to much of a tacit endorsement of
using CL facilities or style any more often than at present, for the
following reasons.

Firstly, we already preload some of cl-*, and we already preload cl-lib
in the bootstrap image, so relative to that it's a small change.

Secondly, this is Lisp, so culturally speaking, people are going to use
cl-lib if they want to use it, regardless of any perception of tacit
upstream endorsement.  And in fact, I bet some people are motivated to
use it just because of how there are prominent Emacs developers who
don't like CL-style code, so maybe not preloading it means there is more
such code written :)

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24  0:26                               ` João Távora
  2022-12-24 10:33                                 ` Philip Kaludercic
@ 2022-12-24 22:59                                 ` Sean Whitton
  2022-12-25  1:21                                   ` Stefan Monnier
  1 sibling, 1 reply; 61+ messages in thread
From: Sean Whitton @ 2022-12-24 22:59 UTC (permalink / raw)
  To: João Távora
  Cc: Yuan Fu, Eli Zaretskii, Juanma Barranquero, Juri Linkov,
	Stefan Monnier, emacs-devel

Hello,

On Sat 24 Dec 2022 at 12:26AM GMT, João Távora wrote:

> On Fri, Dec 23, 2022, 23:42 Yuan Fu <casouri@gmail.com> wrote:
>
>  > Yes, cl-loop is one of the worst offenders in my eyes.  If I want to
>  > use Fortran or C, I will use Fortran or C; I don't want to see Fortran
>  > for-loops in Emacs Lisp.
>
>  Darn it! I loved cl-loop :-) I’ll curb my use of cl-loop in Emacs codebase.
>
> As a data point, some of us are, like you, highly appreciative of cl-loop, and
> cannot see anything remotely approaching its versatility in other programming
> languages.

I love both LOOP and FORMAT, but I don't use them indiscriminately.

I find it very interesting how many Emacs Lisp programmers want to use a
highly functional, Scheme-inspired style -- e.g. the recommendation in
this thread to use named-let -- despite how the roots of Emacs Lisp are
highly imperative.

> I don't know what its detractors recommend for iterating over a plist,
> to give just one example.

Alexandria has a nice DOPLIST.  That's usually what I use in CL over
LOOP, for plists, actually.

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24 22:59                                 ` cl-lib warnings Sean Whitton
@ 2022-12-25  1:21                                   ` Stefan Monnier
  2022-12-25  2:39                                     ` package-initialize was " T.V Raman
                                                       ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Stefan Monnier @ 2022-12-25  1:21 UTC (permalink / raw)
  To: Sean Whitton
  Cc: João Távora, Yuan Fu, Eli Zaretskii, Juanma Barranquero,
	Juri Linkov, emacs-devel

> I find it very interesting how many Emacs Lisp programmers want to use a
> highly functional, Scheme-inspired style -- e.g. the recommendation in
> this thread to use named-let -- despite how the roots of Emacs Lisp are
> highly imperative.

What can I say, I'm a pure functional programmer at heart (my own
experimental language is pure, statically (and dependently) typed, and
strongly normalizing).

FWIW, if you use `named-let` consciously/carefully enough (i.e. so all
the "recursive" calls are in tail position) the resulting code is
a plain old imperative `while` loop using `setq` to update
iteration variables.

That's actually the main problem with `named-let`: it's a bit too easy to
use non-tail-recursive calls, which are not only more costly but eat up
the stack.  Maybe we should have a version of it that signals an error
if there are non-tail-recursive calls.


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* package-initialize was  Re: cl-lib warnings
  2022-12-25  1:21                                   ` Stefan Monnier
@ 2022-12-25  2:39                                     ` T.V Raman
  2022-12-25  4:11                                       ` T.V Raman
  2022-12-26  0:01                                       ` Stefan Monnier
  2022-12-25  7:02                                     ` tomas
  2022-12-26  4:47                                     ` Sean Whitton
  2 siblings, 2 replies; 61+ messages in thread
From: T.V Raman @ 2022-12-25  2:39 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Sean Whitton, João Távora, Yuan Fu, Eli Zaretskii,
	Juanma Barranquero, Juri Linkov, emacs-devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 659 bytes --]

So I started noticing my emacspeak build spew out cl is deprecated
warning for all files in emacspeak and found something curious:

A. Emacspeak does (require 'cl-lib) but that wasn't the source of the
   warning.
B. The Make rule uses -f package-initialize so emacspeak extensions for
   various packages compile cleanly --- and that produces a warning
   now -- did not until like a week ago.

C. and curiously: if your files do a (package-initialize) in the file
   --- then the warning disappears.

Why the difference between (B) and (C)?
-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: package-initialize was  Re: cl-lib warnings
  2022-12-25  2:39                                     ` package-initialize was " T.V Raman
@ 2022-12-25  4:11                                       ` T.V Raman
  2022-12-26  0:01                                       ` Stefan Monnier
  1 sibling, 0 replies; 61+ messages in thread
From: T.V Raman @ 2022-12-25  4:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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

Forgot to include an example: See attached foo.el and try the following
compilations:
emacs -batch -q -f batch-byte-compile foo.el
20:07:00 tmp $
No warnings.
20:08:00 tmp $ emacs -batch -q -no-site-file -f package-initialize -f batch-byte-compile foo.el
Package cl is deprecated
20:08:23 tmp $ 

[-- Attachment #2: foo.el --]
[-- Type: application/emacs-lisp, Size: 99 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/plain; charset=gb18030, Size: 101 bytes --]


-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-25  1:21                                   ` Stefan Monnier
  2022-12-25  2:39                                     ` package-initialize was " T.V Raman
@ 2022-12-25  7:02                                     ` tomas
  2022-12-25  9:55                                       ` João Távora
  2022-12-26  4:47                                     ` Sean Whitton
  2 siblings, 1 reply; 61+ messages in thread
From: tomas @ 2022-12-25  7:02 UTC (permalink / raw)
  To: emacs-devel

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

On Sat, Dec 24, 2022 at 08:21:24PM -0500, Stefan Monnier wrote:
> > I find it very interesting how many Emacs Lisp programmers want to use a
> > highly functional, Scheme-inspired style -- e.g. the recommendation in
> > this thread to use named-let -- despite how the roots of Emacs Lisp are
> > highly imperative.
> 
> What can I say, I'm a pure functional programmer at heart (my own
> experimental language is pure, statically (and dependently) typed, and
> strongly normalizing).

To add confusion to this, I'm a somewhat "in between" type and find
the Lisps ambiguity quite charming. If I had to describe where I
see myself, I'd say "functional in the large, indulging imperatives
in the small" or something.

That said, I love functional let, so thanks, Stefan :-)

Go figure.

Cheers
-- 
t

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-24 22:55           ` Sean Whitton
@ 2022-12-25  7:05             ` tomas
  0 siblings, 0 replies; 61+ messages in thread
From: tomas @ 2022-12-25  7:05 UTC (permalink / raw)
  To: emacs-devel

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

On Sat, Dec 24, 2022 at 03:55:28PM -0700, Sean Whitton wrote:

> [...]  And in fact, I bet some people are motivated to
> use it just because of how there are prominent Emacs developers who
> don't like CL-style code, so maybe not preloading it means there is more
> such code written :)

So you mean "CL" stands for "Contrarian Lisp"? ;-P

(Yes, tongue-in-cheek, honestly)

Cheers
-- 
t

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 17:53         ` Stefan Monnier
  2022-12-24 22:55           ` Sean Whitton
@ 2022-12-25  8:29           ` Juri Linkov
  1 sibling, 0 replies; 61+ messages in thread
From: Juri Linkov @ 2022-12-25  8:29 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

> FWIW, I suspect that `cl-lib.el` is used in many more Emacs sessions
> than `tab-bar.el` (byte-compiled size 92652), so I'd be in favor of
> *not* preloading `tab-bar.el` and preload `cl-lib.el` instead (which
> should result in an overall smaller preloaded heap).

I have no objections against not preloading tab-bar.el.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-25  7:02                                     ` tomas
@ 2022-12-25  9:55                                       ` João Távora
  2022-12-25 11:33                                         ` tomas
  0 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-25  9:55 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

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

On Sun, Dec 25, 2022, 07:03 <tomas@tuxteam.de> wrote:

To add confusion to this, I'm a somewhat "in between" type and find
> the Lisps ambiguity quite charming. If I had to describe where I
> see myself, I'd say "functional in the large, indulging imperatives
> in the small" or something.


Yes, quite. Is it a good time to ask, since we're all huggy wuggy about
Lisp's inclusive style, why the new Scheme stuff gets a namespacing hall
pass while the CL stuff was all banished to akward prefix-land?

João

>

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-25  9:55                                       ` João Távora
@ 2022-12-25 11:33                                         ` tomas
  0 siblings, 0 replies; 61+ messages in thread
From: tomas @ 2022-12-25 11:33 UTC (permalink / raw)
  To: João Távora; +Cc: emacs-devel

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

On Sun, Dec 25, 2022 at 09:55:27AM +0000, João Távora wrote:
> On Sun, Dec 25, 2022, 07:03 <tomas@tuxteam.de> wrote:
> 
> To add confusion to this, I'm a somewhat "in between" type and find
> > the Lisps ambiguity quite charming. If I had to describe where I
> > see myself, I'd say "functional in the large, indulging imperatives
> > in the small" or something.
> 
> 
> Yes, quite. Is it a good time to ask, since we're all huggy wuggy about
> Lisp's inclusive style, why the new Scheme stuff gets a namespacing hall
> pass while the CL stuff was all banished to akward prefix-land?

  *<:-)

Actually quite an interesting topic, but I fear that this mailing
list's margins will be too narrow to scribble it down (IOW: we are
moving dangerously off-topic).

Where do we navigate the sea between "strict, but everyone understands
at a glance" and "permissive, but the land splinters into different
subcultures incapable of working together"?

With Lisp (in the broad sense), all is possible.

Something for computer language sociologists to ponder.

Again, personally, I'd tend towards diversity, but I'm aware of the
downsides.

Cheers
-- 
t

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: package-initialize was  Re: cl-lib warnings
  2022-12-25  2:39                                     ` package-initialize was " T.V Raman
  2022-12-25  4:11                                       ` T.V Raman
@ 2022-12-26  0:01                                       ` Stefan Monnier
  2022-12-26  2:18                                         ` T.V Raman
  1 sibling, 1 reply; 61+ messages in thread
From: Stefan Monnier @ 2022-12-26  0:01 UTC (permalink / raw)
  To: T.V Raman
  Cc: Sean Whitton, João Távora, Yuan Fu, Eli Zaretskii,
	Juanma Barranquero, Juri Linkov, emacs-devel

> So I started noticing my emacspeak build spew out cl is deprecated
> warning for all files in emacspeak and found something curious:
>
> A. Emacspeak does (require 'cl-lib) but that wasn't the source of the
>    warning.

"cl deprecated warnings" have nothing to do with `cl-lib`.
They have to do with `cl`.

> Why the difference between (B) and (C)?

It's probably only tangentially related to the real cause.


        Stefan




^ permalink raw reply	[flat|nested] 61+ messages in thread

* cl-loop and plists vs alists
  2022-12-24 11:01                                   ` João Távora
@ 2022-12-26  0:11                                     ` Philip Kaludercic
  2022-12-26  0:35                                       ` João Távora
  0 siblings, 1 reply; 61+ messages in thread
From: Philip Kaludercic @ 2022-12-26  0:11 UTC (permalink / raw)
  To: João Távora; +Cc: emacs-devel


(I have removed the remaining CC's because this has nothing to do with
the previous discussion, but I'd like to hear if anyone knows more on
the topic.)

João Távora <joaotavora@gmail.com> writes:

> On Sat, Dec 24, 2022, 10:33 Philip Kaludercic <philipk@posteo.net> wrote:
>
>> .
>>
>> I would guess a custom function, say `plist-map' along the lines of
>> `maphash'.  I am kind of surprised to see that this doesn't exist, but
>> according to my intuition of property lists, they are not meant to be
>> iterated.
>>
>
> Until you step into the real world and you have to.

Can you elaborate this point?  Is this by intrinsic necessity or due to
the "mistakes" of others.  Plists are "harder" to iterate, because your
steps are cddrs which is an unusual way to run over a data structure.
Same applies to adding and removing associations from a plist.  The
advantage is that they are easier to write.

Maybe somebody knows the history here, why and where which of the two
were used.  Again, my hunch is that going by the respective strengths
and weaknesses of the two (in relation to the conventional tools), we
can give some heuristic of when it is /better/ to use which of the two.

>> While writing this, I also just realise this exists in the "map"
>> package.
>>
>>   (map-do (lambda (key val)
>>             (message "Key %s, Value %s" key val))
>>           '(:one 1 :two 2 :three 3))
>>
>
> Right, a custom function, a loser in versatility (even if this one is
> polymorphic, that strength is wasted here) Take your example: print only
> three pairs max and a "and more" if there are more than there.

I get your point, but this example is geared towards cl-loop.  It is
powerful as long as you are doing the "right" things.  But when you
decide to change the problem and say "print only the three pairs with
maximal values and a "and more" if there are more than there." then I
believe that the language that cl-loop provides isn't elegant anymore.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-loop and plists vs alists
  2022-12-26  0:11                                     ` cl-loop and plists vs alists Philip Kaludercic
@ 2022-12-26  0:35                                       ` João Távora
  2022-12-26 21:06                                         ` Bob Rogers
  0 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-26  0:35 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

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

On Mon, Dec 26, 2022 at 12:11 AM Philip Kaludercic <philipk@posteo.net>
wrote:


> > Until you step into the real world and you have to.
>
> Can you elaborate this point?  Is this by intrinsic necessity or due to
> the "mistakes" of others.


Nothing special to elaborate.  If a data structure is a plist and you can't
change that, and you need to manipulate it, you're in the real world.


> Plists are "harder" to iterate, because your
> steps are cddrs which is an unusual way to run over a data structure.
> Same applies to adding and removing associations from a plist.  The
> advantage is that they are easier to write.


IMO the major advantage is that you can use them for lambda lists.


> Maybe somebody knows the history here, why and where which of the two
> were used.  Again, my hunch is that going by the respective strengths
> and weaknesses of the two (in relation to the conventional tools), we
> can give some heuristic of when it is /better/ to use which of the two.
>

Both alists and plists are used intensely in at least two large commercial
CL systems I have worked with.  I also see them in OSS pretty often.

I get your point, but this example is geared towards cl-loop.  It is


It was your example. I just weaked it trivially to make it slightly more
realistic.

Of course LOOP isn't for _everything_, else we wouldn't need anything else.
It's a very versatile (and very often the most performant) util and that's
why
it's in the CL standard. The only thing approaching it is the ITERATE
macro,
modelled directly after LOOP, but that's not nearly as widespread and IMO
not improvement enough to be worth investing the effort.

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: package-initialize was  Re: cl-lib warnings
  2022-12-26  0:01                                       ` Stefan Monnier
@ 2022-12-26  2:18                                         ` T.V Raman
  0 siblings, 0 replies; 61+ messages in thread
From: T.V Raman @ 2022-12-26  2:18 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Sean Whitton, João Távora, Yuan Fu, Eli Zaretskii,
	Juanma Barranquero, Juri Linkov, emacs-devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 278 bytes --]

So how exactly do I find out where that warning is coming from?

Started about a week ago but every file in the emacspeak build produces
the warning and it's distracting 
-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 15:08                       ` João Távora
@ 2022-12-26  3:13                         ` Milan Glacier
  2022-12-26 15:10                           ` João Távora
  0 siblings, 1 reply; 61+ messages in thread
From: Milan Glacier @ 2022-12-26  3:13 UTC (permalink / raw)
  To: João Távora
  Cc: Juanma Barranquero, Eli Zaretskii, juri, monnier, emacs-devel

On 12/21/22 15:08, João Távora wrote:
>On Wed, Dec 21, 2022 at 2:57 PM Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> I don't think we've added use-package to the Emacs core with the hope that
>> people will use it less than they do ;-)
>>
>
>Yeah, I know.  But maybe we didn't quite consider the ~30
>commands or so that it provides to do things already possible
>with well-understood primitives that have existed forever.
>
>I don't have a problem with people using it, just as I don't have
>a problem with people using Magit, which I also don't.  It's just
>I plan to kindly ask the potential bug-reporter to show his minimal
>configuration in terms of stuff I can unequivocally understand
>the semantics of.
>
>João

use-package is a macro, so if someone uses use-package to configure the
package, when he needs to debug (for example minimal configuration), he
can always present the expanded form. (which basically just expands to
stuffs like setq, autoload, add-hook stuffs).



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-25  1:21                                   ` Stefan Monnier
  2022-12-25  2:39                                     ` package-initialize was " T.V Raman
  2022-12-25  7:02                                     ` tomas
@ 2022-12-26  4:47                                     ` Sean Whitton
  2 siblings, 0 replies; 61+ messages in thread
From: Sean Whitton @ 2022-12-26  4:47 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: João Távora, Yuan Fu, Eli Zaretskii, Juanma Barranquero,
	Juri Linkov, emacs-devel

Hello,

On Sat 24 Dec 2022 at 08:21PM -05, Stefan Monnier wrote:

> What can I say, I'm a pure functional programmer at heart (my own
> experimental language is pure, statically (and dependently) typed, and
> strongly normalizing).

named-let is nice.  I use when a recursive definition seems most
expressive of programmer intent and anaphoric macros aren't available :)

It doesn't seem advisable, to me, to force things that aren't naturally
expressed with functional programming idioms into those idioms.  But I
guess you're trading that off for the advantages of purity, right?

> That's actually the main problem with `named-let`: it's a bit too easy
> to use non-tail-recursive calls, which are not only more costly but
> eat up the stack.  Maybe we should have a version of it that signals
> an error if there are non-tail-recursive calls.

That would be cool.

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-26  3:13                         ` Milan Glacier
@ 2022-12-26 15:10                           ` João Távora
  2022-12-26 23:48                             ` Milan Glacier
  0 siblings, 1 reply; 61+ messages in thread
From: João Távora @ 2022-12-26 15:10 UTC (permalink / raw)
  To: Milan Glacier; +Cc: emacs-devel

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

On Mon, Dec 26, 2022 at 3:13 AM Milan Glacier <news@milanglacier.com> wrote:

> use-package is a macro, so if someone uses use-package to configure the
> package, when he needs to debug (for example minimal configuration), he
> can always present the expanded form. (which basically just expands to
> stuffs like setq, autoload, add-hook stuffs).
>

Yes, this was my initial hope too, that something like
`pp-macroexpand-last-sexp` could help me.  But it's got
enough fluff to make it tiring to read.  Here's what a simple
'(use-package foo)' with no options expands to:

(progn
  (defvar use-package--warning1
    #'(lambda
        (keyword err)
        (let
            ((msg
              (format "%s/%s: %s" 'foo keyword
                      (error-message-string err))))
          (display-warning 'use-package msg :error))))
  (condition-case-unless-debug err
      (if
          (not
           (require 'foo nil t))
          (display-warning 'use-package
                           (format "Cannot load %s" 'foo)
                           :error))
    (error
     (funcall use-package--warning1 :catch err))))

I'm afraid mode options will make this even more
complicated.  And what's with that defvar?

-- 
João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-loop and plists vs alists
  2022-12-26  0:35                                       ` João Távora
@ 2022-12-26 21:06                                         ` Bob Rogers
  0 siblings, 0 replies; 61+ messages in thread
From: Bob Rogers @ 2022-12-26 21:06 UTC (permalink / raw)
  To: João Távora; +Cc: Philip Kaludercic, emacs-devel

   From: João Távora <joaotavora@gmail.com>
   Date: Mon, 26 Dec 2022 00:35:58 +0000

   On Mon, Dec 26, 2022 at 12:11 AM Philip Kaludercic <philipk@posteo.net>
   wrote:

   . . .

   > Plists are "harder" to iterate, because your
   > steps are cddrs which is an unusual way to run over a data structure.
   > Same applies to adding and removing associations from a plist.  The
   > advantage is that they are easier to write.

   IMO the major advantage is that you can use them for lambda lists.

Indeed, when I was hacking Lisp in the 80's and early 90's, by far the
most common application of iterating through plists that I saw was
processing &key parameters in &rest lists.  (This was the only time I
would use loop, albeit grudgingly.)  Otherwise, given a free hand, an
alist was the better data structure choice.

					-- Bob Rogers
					   http://www.rgrjr.com/



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-26 15:10                           ` João Távora
@ 2022-12-26 23:48                             ` Milan Glacier
  2022-12-27  0:05                               ` João Távora
  0 siblings, 1 reply; 61+ messages in thread
From: Milan Glacier @ 2022-12-26 23:48 UTC (permalink / raw)
  To: João Távora; +Cc: emacs-devel

On 12/26/22 15:10, João Távora wrote:
>On Mon, Dec 26, 2022 at 3:13 AM Milan Glacier <news@milanglacier.com> wrote:
>
>> use-package is a macro, so if someone uses use-package to configure the
>> package, when he needs to debug (for example minimal configuration), he
>> can always present the expanded form. (which basically just expands to
>> stuffs like setq, autoload, add-hook stuffs).
>>
>
>Yes, this was my initial hope too, that something like
>`pp-macroexpand-last-sexp` could help me.  But it's got
>enough fluff to make it tiring to read.  Here's what a simple
>'(use-package foo)' with no options expands to:
>
>(progn
>  (defvar use-package--warning1
>    #'(lambda
>        (keyword err)
>        (let
>            ((msg
>              (format "%s/%s: %s" 'foo keyword
>                      (error-message-string err))))
>          (display-warning 'use-package msg :error))))
>  (condition-case-unless-debug err
>      (if
>          (not
>           (require 'foo nil t))
>          (display-warning 'use-package
>                           (format "Cannot load %s" 'foo)
>                           :error))
>    (error
>     (funcall use-package--warning1 :catch err))))
>
>I'm afraid mode options will make this even more
>complicated.  And what's with that defvar?

use-package is really a magic. But nobody uses a blank `(use-package
foo)`, usually a simple and pracctical use-package call would be
something like this:
     
     (use-package foo
     :config (setq foo-1 nil)
     :init (setq foo-2 nil)
     :hook ((python-mode emacs-lisp-mode) . foo-mode))

which specifies the code to be evaluated before foo is loaded (:init
part), the code to be evaluated after foo is loaded (:config part), and
the hook related to this package, which expands to:

     (progn
       (unless
           (fboundp 'foo-mode)
         (autoload
           (function foo-mode)
           "foo" nil t))
       (setq foo-2 nil)
       (eval-after-load 'foo
         '(progn
            (setq foo-1 nil)
            t))
       (add-hook 'python-mode-hook
                 (function foo-mode))
       (add-hook 'emacs-lisp-mode-hook
                 (function foo-mode)))

I think the expanded form are not that hard to read.

(I personally am not a fan of use-package, I don't think it brings any
thing new. Often I need to expand it to see if its behavior is expected,
then why shouldn't I just write plain setq, add-hook stuffs directly?)



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-26 23:48                             ` Milan Glacier
@ 2022-12-27  0:05                               ` João Távora
  2022-12-27  3:43                                 ` Tim Cross
  2022-12-27 13:00                                 ` Stefan Kangas
  0 siblings, 2 replies; 61+ messages in thread
From: João Távora @ 2022-12-27  0:05 UTC (permalink / raw)
  To: Milan Glacier; +Cc: emacs-devel

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

On Mon, Dec 26, 2022 at 11:49 PM Milan Glacier <news@milanglacier.com>
wrote:

>
> >I'm afraid mode options will make this even more
> >complicated.  And what's with that defvar?
>
> use-package is really a magic. But nobody uses a blank `(use-package
> foo)`, usually a simple and pracctical use-package call would be
> something like this:
>
>      (use-package foo
>      :config (setq foo-1 nil)
>      :init (setq foo-2 nil)
>      :hook ((python-mode emacs-lisp-mode) . foo-mode))
>
> which specifies the code to be evaluated before foo is loaded (:init
> part), the code to be evaluated after foo is loaded (:config part), and
> the hook related to this package, which expands to:
>

My expansion of that same form is larger and harder to read,
with condition-case and variables and stuff.  But it would seem
that the fluff overhead is constant, which is good.

So I get your point: with enough practice, it's easy to see the
primitives in use.


> (I personally am not a fan of use-package, I don't think it brings any
> thing new. Often I need to expand it to see if its behavior is expected,
> then why shouldn't I just write plain setq, add-hook stuffs directly?)
>

Exactly.

João

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-27  0:05                               ` João Távora
@ 2022-12-27  3:43                                 ` Tim Cross
  2022-12-27 10:16                                   ` Lynn Winebarger
  2022-12-27 13:00                                 ` Stefan Kangas
  1 sibling, 1 reply; 61+ messages in thread
From: Tim Cross @ 2022-12-27  3:43 UTC (permalink / raw)
  To: emacs-devel


João Távora <joaotavora@gmail.com> writes:

> On Mon, Dec 26, 2022 at 11:49 PM Milan Glacier <news@milanglacier.com> wrote:
>
>  >I'm afraid mode options will make this even more
>  >complicated.  And what's with that defvar?
>
>  use-package is really a magic. But nobody uses a blank `(use-package
>  foo)`, usually a simple and pracctical use-package call would be
>  something like this:
>
>       (use-package foo
>       :config (setq foo-1 nil)
>       :init (setq foo-2 nil)
>       :hook ((python-mode emacs-lisp-mode) . foo-mode))
>
>  which specifies the code to be evaluated before foo is loaded (:init
>  part), the code to be evaluated after foo is loaded (:config part), and
>  the hook related to this package, which expands to:
>
> My expansion of that same form is larger and harder to read, 
> with condition-case and variables and stuff.  But it would seem 
> that the fluff overhead is constant, which is good.
>
> So I get your point: with enough practice, it's easy to see the
> primitives in use.
>  
>  (I personally am not a fan of use-package, I don't think it brings any
>  thing new. Often I need to expand it to see if its behavior is expected,
>  then why shouldn't I just write plain setq, add-hook stuffs directly?)
>
> Exactly. 
>

I am a fan of use-package. I've been using it for years. I really don't
follow the reasoning of the argument against it on the basis that it
brings nothing new in the sense you can achieve the same result using
existing facilities. This could be argued about many things, especially
when it comes to code and programming. Many 'new' things are really just
further abstractions or alternative abstractions for
features/functionality which already exists. By definition, anything
achieved via a macro could also be done just by using 'existing
primitives'.

I also find the suggestion use package is not good because when you
expand the macro, it will be harder to read than if you had simply
implemented the code directly using existing primitives. This is true of
many macros and I think completely misses the point. In the many years
I've been using use-package, there has been exactly one instance where I
needed to expand the macro to understand what it was doing. Actually, I
didn't need to do it, I did it more out of interest.

What I like about use-package is it has made my init file more concise
and easier to manage and while I could achieve exactly the same outcome
writing a lot of additional elisp myself, I appreciate the fact I don't
have to and I can spend more time focusing on my real work. This is
especially true because much of that additional elisp I would be forced
to write if I didn't have use-package is very much 'boiler plate' code -
boring utility code to add hooks, update mode, interpreter, filename
magic, package installation, key bindings, setq etc. Essentially, I find
use-package does exactly what a useful macros does - it adds some sugar
which helps me avoid having to write boring repetitive code of low interest. 

I am completely neutral regarding the inclusion of use-package into
Emacs core. It is a relatively small package and having it there is
convenient.  However, having to install it from ELPA was trivial and
convenient as well. Having it as part of Emacs core has made no
significant difference for me - perhaps my init file is now 2 lines
smaller. I do admit not really understanding the need many seem to have
regarding getting stuff into 'core'. 



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-27  3:43                                 ` Tim Cross
@ 2022-12-27 10:16                                   ` Lynn Winebarger
  0 siblings, 0 replies; 61+ messages in thread
From: Lynn Winebarger @ 2022-12-27 10:16 UTC (permalink / raw)
  To: Tim Cross; +Cc: emacs-devel

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

On Mon, Dec 26, 2022, 11:14 PM Tim Cross <theophilusx@gmail.com> wrote:

>  I do admit not really understanding the need many seem to have
> regarding getting stuff into 'core'.


If it's in core, emacs maintainers have the responsibility of either not
breaking it or keeping it updated, and integrating its functionality so
other parts of core may rely on it.

Lynn


>
>
>
>

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

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-27  0:05                               ` João Távora
  2022-12-27  3:43                                 ` Tim Cross
@ 2022-12-27 13:00                                 ` Stefan Kangas
  1 sibling, 0 replies; 61+ messages in thread
From: Stefan Kangas @ 2022-12-27 13:00 UTC (permalink / raw)
  To: João Távora, Milan Glacier; +Cc: emacs-devel

João Távora <joaotavora@gmail.com> writes:

> My expansion of that same form is larger and harder to read,
> with condition-case and variables and stuff.  But it would seem
> that the fluff overhead is constant, which is good.

I find that this helps:

    (setq use-package-expand-minimally t)

> So I get your point: with enough practice, it's easy to see the
> primitives in use.

Yup.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2022-12-21 14:50                 ` Juanma Barranquero
  2022-12-21 14:55                   ` João Távora
  2022-12-21 17:14                   ` Eli Zaretskii
@ 2023-01-06  5:40                   ` Sean Whitton
  2023-01-06  7:34                     ` Eli Zaretskii
  2 siblings, 1 reply; 61+ messages in thread
From: Sean Whitton @ 2023-01-06  5:40 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Juanma Barranquero, João Távora, juri, monnier,
	emacs-devel

Hello,

On Wed 21 Dec 2022 at 03:50PM +01, Juanma Barranquero wrote:

> On Wed, Dec 21, 2022 at 3:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
>  
>> Our policy and practice was since long ago that any package which is
>> always or almost always loaded at startup without any user say-so,
>> should be preloaded, since not doing that makes very little sense.
>   
> We don't have precise metrics for "always or almost always loaded at startup",
> I think.
>
> But cl-lib is unconditionally required by 191 files under lisp/, right
> now.  Including things like desktop, help-fns, help-mode, kmacro,
> imenu, tab-line and package, among many others.  And of course vc,
> Calc and Org. And use-package, which will perhaps become the de facto
> way to customize their .emacs for many people.

Eli's the only person who's expressed concern about preloading cl-lib,
but I don't believe he's responded to Juanma's statistics here.

Eli, what do you think about this argument that cl-lib meets the
criteria you stated?

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2023-01-06  5:40                   ` Sean Whitton
@ 2023-01-06  7:34                     ` Eli Zaretskii
  2023-01-06 17:58                       ` Sean Whitton
  0 siblings, 1 reply; 61+ messages in thread
From: Eli Zaretskii @ 2023-01-06  7:34 UTC (permalink / raw)
  To: Sean Whitton; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Juanma Barranquero <lekktu@gmail.com>, João Távora
>  <joaotavora@gmail.com>,  juri@linkov.net,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Thu, 05 Jan 2023 22:40:24 -0700
> 
> >> Our policy and practice was since long ago that any package which is
> >> always or almost always loaded at startup without any user say-so,
> >> should be preloaded, since not doing that makes very little sense.
> >   
> > We don't have precise metrics for "always or almost always loaded at startup",
> > I think.
> >
> > But cl-lib is unconditionally required by 191 files under lisp/, right
> > now.  Including things like desktop, help-fns, help-mode, kmacro,
> > imenu, tab-line and package, among many others.  And of course vc,
> > Calc and Org. And use-package, which will perhaps become the de facto
> > way to customize their .emacs for many people.
> 
> Eli's the only person who's expressed concern about preloading cl-lib,
> but I don't believe he's responded to Juanma's statistics here.
> 
> Eli, what do you think about this argument that cl-lib meets the
> criteria you stated?

It doesn't.  If you think it does, I must have failed to explain the
criteria.

The "almost always" is not a numerical criterion, its "almost" part is
intended to cover the cases where the package is _always_ loaded at
startup, but only in some configurations of Emacs.  Like something
that happens only in GTK builds.  So counting the number of Lisp
packages that require cl-lib is not going to change my mind.

In general, I'm worried by IMO too nonchalant attitude towards
preloading more and more into Emacs.  We should actively try to keep
the memory footprint of the Emacs process in check.  It is true that
each package we add increases the footprint by a small amount, but
those small amounts eventually add up to a sum that is significant.
On my system starting "emacs -q" with various versions of Emacs
produces the following memory footprint values:

  emacs 22.1  10.6 MiB
  emacs 23.1  11.5 MiB
  emacs 24.1  13.4 MiB
  emacs 25.1  32.5 MiB
  emacs 26.1  35.5 MiB
  emacs 27.1  25.1 MiB
  emacs 28.2  26.7 MiB

Granted, not all of the increase is due to preloading more Lisp, but
some of it is, and so IMO we should resist the temptation to add more
just because it saves us some 'require's.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2023-01-06  7:34                     ` Eli Zaretskii
@ 2023-01-06 17:58                       ` Sean Whitton
  2023-01-06 18:14                         ` Eli Zaretskii
  0 siblings, 1 reply; 61+ messages in thread
From: Sean Whitton @ 2023-01-06 17:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

Hello,

On Fri 06 Jan 2023 at 09:34AM +02, Eli Zaretskii wrote:

> The "almost always" is not a numerical criterion, its "almost" part is
> intended to cover the cases where the package is _always_ loaded at
> startup, but only in some configurations of Emacs.  Like something
> that happens only in GTK builds.  So counting the number of Lisp
> packages that require cl-lib is not going to change my mind.

Okay, thanks.

> In general, I'm worried by IMO too nonchalant attitude towards
> preloading more and more into Emacs.  We should actively try to keep
> the memory footprint of the Emacs process in check.  It is true that
> each package we add increases the footprint by a small amount, but
> those small amounts eventually add up to a sum that is significant.
> On my system starting "emacs -q" with various versions of Emacs
> produces the following memory footprint values:
>
>   emacs 22.1  10.6 MiB
>   emacs 23.1  11.5 MiB
>   emacs 24.1  13.4 MiB
>   emacs 25.1  32.5 MiB
>   emacs 26.1  35.5 MiB
>   emacs 27.1  25.1 MiB
>   emacs 28.2  26.7 MiB
>
> Granted, not all of the increase is due to preloading more Lisp, but
> some of it is, and so IMO we should resist the temptation to add more
> just because it saves us some 'require's.

What sort of target do you think we should have?

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2023-01-06 17:58                       ` Sean Whitton
@ 2023-01-06 18:14                         ` Eli Zaretskii
  2023-01-06 19:03                           ` Sean Whitton
  0 siblings, 1 reply; 61+ messages in thread
From: Eli Zaretskii @ 2023-01-06 18:14 UTC (permalink / raw)
  To: Sean Whitton; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: lekktu@gmail.com,  joaotavora@gmail.com,  juri@linkov.net,
>   monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 06 Jan 2023 10:58:06 -0700
> 
> > In general, I'm worried by IMO too nonchalant attitude towards
> > preloading more and more into Emacs.  We should actively try to keep
> > the memory footprint of the Emacs process in check.  It is true that
> > each package we add increases the footprint by a small amount, but
> > those small amounts eventually add up to a sum that is significant.
> > On my system starting "emacs -q" with various versions of Emacs
> > produces the following memory footprint values:
> >
> >   emacs 22.1  10.6 MiB
> >   emacs 23.1  11.5 MiB
> >   emacs 24.1  13.4 MiB
> >   emacs 25.1  32.5 MiB
> >   emacs 26.1  35.5 MiB
> >   emacs 27.1  25.1 MiB
> >   emacs 28.2  26.7 MiB
> >
> > Granted, not all of the increase is due to preloading more Lisp, but
> > some of it is, and so IMO we should resist the temptation to add more
> > just because it saves us some 'require's.
> 
> What sort of target do you think we should have?

I don't think I understand the question.  What do you mean by "target"
here?



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2023-01-06 18:14                         ` Eli Zaretskii
@ 2023-01-06 19:03                           ` Sean Whitton
  2023-01-06 19:45                             ` Eli Zaretskii
  0 siblings, 1 reply; 61+ messages in thread
From: Sean Whitton @ 2023-01-06 19:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

Hello,

On Fri 06 Jan 2023 at 08:14PM +02, Eli Zaretskii wrote:

> I don't think I understand the question.  What do you mean by "target"
> here?

How low should we be trying to keep the memory footprint?  What sort of
systems are we hoping to be able to support?

-- 
Sean Whitton



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: cl-lib warnings
  2023-01-06 19:03                           ` Sean Whitton
@ 2023-01-06 19:45                             ` Eli Zaretskii
  0 siblings, 0 replies; 61+ messages in thread
From: Eli Zaretskii @ 2023-01-06 19:45 UTC (permalink / raw)
  To: Sean Whitton; +Cc: lekktu, joaotavora, juri, monnier, emacs-devel

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: lekktu@gmail.com,  joaotavora@gmail.com,  juri@linkov.net,
>   monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 06 Jan 2023 12:03:58 -0700
> 
> On Fri 06 Jan 2023 at 08:14PM +02, Eli Zaretskii wrote:
> 
> > I don't think I understand the question.  What do you mean by "target"
> > here?
> 
> How low should we be trying to keep the memory footprint?  What sort of
> systems are we hoping to be able to support?

I don't think I have an answer to that, not in absolute numbers.  I'm
just saying that we should have a very good reason for adding files to
the set we preload.



^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2023-01-06 19:45 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <jwvv8mc4eax.fsf@iro.umontreal.ca>
     [not found] ` <86o7s3lsnx.fsf@mail.linkov.net>
2022-12-20 18:42   ` cl-lib warnings (was: bug#60102: Move gv-expander of substring to cl-lib) Stefan Monnier
2022-12-21  8:37     ` cl-lib warnings Juri Linkov
2022-12-21 12:45       ` Eli Zaretskii
2022-12-21 12:57         ` João Távora
2022-12-21 13:47           ` Eli Zaretskii
2022-12-21 14:04             ` João Távora
2022-12-21 14:20               ` Eli Zaretskii
2022-12-21 14:35                 ` João Távora
2022-12-21 14:50                 ` Juanma Barranquero
2022-12-21 14:55                   ` João Távora
2022-12-21 14:57                     ` Juanma Barranquero
2022-12-21 15:08                       ` João Távora
2022-12-26  3:13                         ` Milan Glacier
2022-12-26 15:10                           ` João Távora
2022-12-26 23:48                             ` Milan Glacier
2022-12-27  0:05                               ` João Távora
2022-12-27  3:43                                 ` Tim Cross
2022-12-27 10:16                                   ` Lynn Winebarger
2022-12-27 13:00                                 ` Stefan Kangas
2022-12-21 17:14                   ` Eli Zaretskii
2022-12-21 22:33                     ` Juanma Barranquero
2022-12-22  7:13                       ` Eli Zaretskii
2022-12-22  7:23                         ` Juanma Barranquero
2022-12-22  8:53                           ` Eli Zaretskii
2022-12-22 22:24                         ` Yuan Fu
2022-12-22 23:56                           ` Stefan Monnier
2022-12-23  7:30                           ` Eli Zaretskii
2022-12-23 23:42                             ` Yuan Fu
2022-12-24  0:24                               ` Juanma Barranquero
2022-12-24 14:08                                 ` Stefan Monnier
2022-12-24 14:39                                   ` Juanma Barranquero
2022-12-24 19:13                                     ` Tomas Hlavaty
2022-12-24  0:26                               ` João Távora
2022-12-24 10:33                                 ` Philip Kaludercic
2022-12-24 11:01                                   ` João Távora
2022-12-26  0:11                                     ` cl-loop and plists vs alists Philip Kaludercic
2022-12-26  0:35                                       ` João Távora
2022-12-26 21:06                                         ` Bob Rogers
2022-12-24 22:59                                 ` cl-lib warnings Sean Whitton
2022-12-25  1:21                                   ` Stefan Monnier
2022-12-25  2:39                                     ` package-initialize was " T.V Raman
2022-12-25  4:11                                       ` T.V Raman
2022-12-26  0:01                                       ` Stefan Monnier
2022-12-26  2:18                                         ` T.V Raman
2022-12-25  7:02                                     ` tomas
2022-12-25  9:55                                       ` João Távora
2022-12-25 11:33                                         ` tomas
2022-12-26  4:47                                     ` Sean Whitton
2022-12-24  6:40                               ` Eli Zaretskii
2022-12-24 13:01                                 ` Dmitry Gutov
2023-01-06  5:40                   ` Sean Whitton
2023-01-06  7:34                     ` Eli Zaretskii
2023-01-06 17:58                       ` Sean Whitton
2023-01-06 18:14                         ` Eli Zaretskii
2023-01-06 19:03                           ` Sean Whitton
2023-01-06 19:45                             ` Eli Zaretskii
2022-12-21 14:15             ` Eli Zaretskii
2022-12-21 17:53         ` Stefan Monnier
2022-12-24 22:55           ` Sean Whitton
2022-12-25  7:05             ` tomas
2022-12-25  8:29           ` Juri Linkov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).