bug#60102: Move gv-expander of substring to cl-lib

bug#60102: Move gv-expander of substring to cl-lib

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Tags: patch

Tags: patch

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

There are 2 other place definitions in `gv.el` which similarly rely on
helper functions defined in `cl-lib` (namely `buffer-substring` and
`frame-visible-p`) which we could move as well, but since we marked
those as obsolete anyway I think we can "let them die" where they are,
with their quirks left alone.  If you feel otherwise, I can update the
patch to move them to `cl-lib.el` as well.


        Stefan


 In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnux32, GTK+ Version
 3.24.35, cairo version 1.16.0) of 2022-12-09 built on alfajor
Repository revision: b134e7e6abf18286d38e1b589f0fdae523cf1e73
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gv-substring.patch --]
[-- Type: text/patch, Size: 1619 bytes --]

diff --git a/lisp/emacs-lisp/cl-lib.el b/lisp/emacs-lisp/cl-lib.el
index b83b44974d3..ceb5c21baf1 100644
--- a/lisp/emacs-lisp/cl-lib.el
+++ b/lisp/emacs-lisp/cl-lib.el
@@ -170,6 +170,17 @@ cl--set-substring
 	  val
 	  (and (< end (length str)) (substring str end))))
 
+(gv-define-expander substring
+  (lambda (do place from &optional to)
+    (gv-letplace (getter setter) place
+      (macroexp-let2* nil ((start from) (end to))
+        (funcall do `(substring ,getter ,start ,end)
+                 (lambda (v)
+                   (macroexp-let2 nil v v
+                     `(progn
+                        ,(funcall setter `(cl--set-substring
+                                           ,getter ,start ,end ,v))
+                        ,v))))))))
 
 ;;; Blocks and exits.
 
diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el
index 11251d7a963..29cfca9cb62 100644
--- a/lisp/emacs-lisp/gv.el
+++ b/lisp/emacs-lisp/gv.el
@@ -815,17 +815,5 @@ eq
                      ((eq ,getter ,val) ,(funcall setter `(not ,val))))))))))
 (make-obsolete-generalized-variable 'eq nil "29.1")
 
-(gv-define-expander substring
-  (lambda (do place from &optional to)
-    (gv-letplace (getter setter) place
-      (macroexp-let2* nil ((start from) (end to))
-        (funcall do `(substring ,getter ,start ,end)
-                 (lambda (v)
-                   (macroexp-let2 nil v v
-                     `(progn
-                        ,(funcall setter `(cl--set-substring
-                                           ,getter ,start ,end ,v))
-                        ,v))))))))
-
 (provide 'gv)
 ;;; gv.el ends here

bug#60102: Move gv-expander of substring to cl-lib

[Eli Zaretskii]

> Date: Thu, 15 Dec 2022 15:12:06 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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`.
> 
> There are 2 other place definitions in `gv.el` which similarly rely on
> helper functions defined in `cl-lib` (namely `buffer-substring` and
> `frame-visible-p`) which we could move as well, but since we marked
> those as obsolete anyway I think we can "let them die" where they are,
> with their quirks left alone.  If you feel otherwise, I can update the
> patch to move them to `cl-lib.el` as well.

Is the patch for master or for the release branch?  I think it should
go to master.

Thanks.

bug#60102: Move gv-expander of substring to cl-lib

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Is the patch for master or for the release branch?

Definitely not for the release branch, no.
So I take it you think it's OK for `master`, thanks.


        Stefan

bug#60102: Move gv-expander of substring to cl-lib

[Stefan Kangas]

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

>> Is the patch for master or for the release branch?
>
> Definitely not for the release branch, no.
> So I take it you think it's OK for `master`, thanks.

It seems like this patch was never installed?  Should it be?

bug#60102: Move gv-expander of substring to cl-lib

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> Is the patch for master or for the release branch?
>> Definitely not for the release branch, no.
>> So I take it you think it's OK for `master`, thanks.
> It seems like this patch was never installed?  Should it be?

Indeed, thanks, pushed,


        Stefan

bug#60102: Move gv-expander of substring to cl-lib

[Juri Linkov]

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

Debugger entered--Lisp error: (void-function cl--set-substring)
  cl--set-substring(#("*scratch* x" 0 9 ...
  tab-bar-auto-width(((sep-1 menu-item " " ignore) (current-tab menu-item #("*scratch* x" 0 9 ...
  tab-bar-make-keymap-1()
  (progn (tab-bar-make-keymap-1))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

OTOH, autoloading `cl--set-substring` fixes this error.

cl-lib warnings (was: bug#60102: Move gv-expander of substring to cl-lib)

[Stefan Monnier]

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

Re: cl-lib warnings

[Juri Linkov]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Milan Glacier]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Milan Glacier]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Tim Cross]

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

Re: cl-lib warnings

[Lynn Winebarger]

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

Re: cl-lib warnings

[Stefan Kangas]

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.

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Yuan Fu]

> 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

Re: cl-lib warnings

[Stefan Monnier]

> 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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Yuan Fu]

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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[Stefan Monnier]

> 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

Re: cl-lib warnings

[Juanma Barranquero]

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

Re: cl-lib warnings

[Tomas Hlavaty]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[Philip Kaludercic]

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

Re: cl-lib warnings

[João Távora]

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

cl-loop and plists vs alists

[Philip Kaludercic]

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

Re: cl-loop and plists vs alists

[João Távora]

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

Re: cl-loop and plists vs alists

[Bob Rogers]

   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/

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[Stefan Monnier]

> 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

package-initialize was Re: cl-lib warnings

[T.V Raman]

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

Re: package-initialize was Re: cl-lib warnings

[T.V Raman]

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

Re: package-initialize was Re: cl-lib warnings

[Stefan Monnier]

> 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

Re: package-initialize was Re: cl-lib warnings

[T.V Raman]

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

Re: cl-lib warnings

[tomas]

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

Re: cl-lib warnings

[João Távora]

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

Re: cl-lib warnings

[tomas]

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

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Dmitry Gutov]

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

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Eli Zaretskii]

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

Re: cl-lib warnings

[Stefan Monnier]

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

Re: cl-lib warnings

[Sean Whitton]

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

Re: cl-lib warnings

[tomas]

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

Re: cl-lib warnings

[Juri Linkov]

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