Unhelpful text in C-h v search-default-mode

Unhelpful text in C-h v search-default-mode

[Alan Mackenzie]

Hello, Emacs.

In a recent master branch Emacs, (not with -Q), from an info buffer, I
did C-h v search-default-mode.  The text printed in *Help* included this:

    Its value is
    #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
    Original value was nil
    Local in buffer *info*<3>; global value is nil

..  This is quite frankly entirely unhelpful; it gives no way to find out
what the lambda is, in particular, no way to get to its source code.  It
isn't even possible to disassemble the function.

After a good deal of searching, I think I found the pertinent source
code, but am not sure, namely in isearch.el L4685, right near the end:

      (setq-local isearch-fold-quotes-mode--state
                  (buffer-local-set-state
                   search-default-mode
                   (lambda (string &optional _lax)
                     (thread-last
                       (regexp-quote string)
                       (replace-regexp-in-string "`" "[`‘]")
                       (replace-regexp-in-string "'" "['’]")
                       (replace-regexp-in-string "\"" "[\"""]")))))

..  Here, this customisable variable search-default-mode gets set to a
lambda function.  The problem could have been avoided if the extra effort
to come up with a symbol for this function had been expended, and the
function written separately as a defun with a name.

I am asking people to be careful not to use lambda forms like this,
instead always prefering defun and a name.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Unhelpful text in C-h v search-default-mode

[Juri Linkov]

> In a recent master branch Emacs, (not with -Q), from an info buffer, I
> did C-h v search-default-mode.  The text printed in *Help* included this:
>
>     Its value is
>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>     Original value was nil
>     Local in buffer *info*<3>; global value is nil
>
> ..  This is quite frankly entirely unhelpful; it gives no way to find out
> what the lambda is, in particular, no way to get to its source code.  It
> isn't even possible to disassemble the function.
>
> After a good deal of searching, I think I found the pertinent source
> code, but am not sure, namely in isearch.el L4685, right near the end:
>
>       (setq-local isearch-fold-quotes-mode--state
>                   (buffer-local-set-state
>                    search-default-mode
>                    (lambda (string &optional _lax)
>                      (thread-last
>                        (regexp-quote string)
>                        (replace-regexp-in-string "`" "[`‘]")
>                        (replace-regexp-in-string "'" "['’]")
>                        (replace-regexp-in-string "\"" "[\"""]")))))
>
> ..  Here, this customisable variable search-default-mode gets set to a
> lambda function.  The problem could have been avoided if the extra effort
> to come up with a symbol for this function had been expended, and the
> function written separately as a defun with a name.
>
> I am asking people to be careful not to use lambda forms like this,
> instead always prefering defun and a name.

A good name for the new function would be 'isearch-fold-quotes-regexp'
modeled after the existing 'isearch-symbol-regexp', 'char-fold-to-regexp'.

Re: Unhelpful text in C-h v search-default-mode

[Juri Linkov]

> In a recent master branch Emacs, (not with -Q), from an info buffer, I
> did C-h v search-default-mode.  The text printed in *Help* included this:
>
>     Its value is
>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>     Original value was nil
>     Local in buffer *info*<3>; global value is nil
>
> ..  This is quite frankly entirely unhelpful; it gives no way to find out
> what the lambda is, in particular, no way to get to its source code.  It
> isn't even possible to disassemble the function.

Another example:

0. emacs -Q
1. M-x list-timers

   *     0.1s     t show-paren-function
   *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>

I wonder how users are supposed to know what function it is?
Searching by the delay number 0.5 reveals this lambda comes from

        (setq jit-lock-context-timer
              (run-with-idle-timer jit-lock-context-time t
                                   (lambda ()
                                     (unless jit-lock--antiblink-grace-timer
                                       (jit-lock-context-fontify)))))

Re: Unhelpful text in C-h v search-default-mode

[Emanuel Berg]

Juri Linkov wrote:

>> In a recent master branch Emacs, (not with -Q), from an info buffer, I
>> did C-h v search-default-mode.  The text printed in *Help* included this:
>>
>>     Its value is
>>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>>     Original value was nil
>>     Local in buffer *info*<3>; global value is nil
>>
>> ..  This is quite frankly entirely unhelpful; it gives no way to find out
>> what the lambda is, in particular, no way to get to its source code.  It
>> isn't even possible to disassemble the function.
>
> Another example:
>
> 0. emacs -Q
> 1. M-x list-timers
>
>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
>
> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes
> from
>
>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))

One will know it by not using an anonymous function (a lambda)
but making a proper function and giving it a descriptive name,
as you see with `show-paren-function' in your own example :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Unhelpful text in C-h v search-default-mode

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Dec 2023 09:12:49 +0200
> 
> > In a recent master branch Emacs, (not with -Q), from an info buffer, I
> > did C-h v search-default-mode.  The text printed in *Help* included this:
> >
> >     Its value is
> >     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> >     Original value was nil
> >     Local in buffer *info*<3>; global value is nil
> >
> > ..  This is quite frankly entirely unhelpful; it gives no way to find out
> > what the lambda is, in particular, no way to get to its source code.  It
> > isn't even possible to disassemble the function.
> 
> Another example:
> 
> 0. emacs -Q
> 1. M-x list-timers
> 
>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
> 
> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes from
> 
>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))
> 

What happens with that in a build without native-compilation? does
what list-timers shows in that case look more friendly?

Re: Unhelpful text in C-h v search-default-mode

[Eli Zaretskii]

> Date: Fri, 29 Dec 2023 09:50:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
> > From: Juri Linkov <juri@linkov.net>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 29 Dec 2023 09:12:49 +0200
> > 
> > 0. emacs -Q
> > 1. M-x list-timers
> > 
> >    *     0.1s     t show-paren-function
> >    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
> > 
> > I wonder how users are supposed to know what function it is?
> > Searching by the delay number 0.5 reveals this lambda comes from
> > 
> >         (setq jit-lock-context-timer
> >               (run-with-idle-timer jit-lock-context-time t
> >                                    (lambda ()
> >                                      (unless jit-lock--antiblink-grace-timer
> >                                        (jit-lock-context-fontify)))))
> > 
> 
> What happens with that in a build without native-compilation? does
> what list-timers shows in that case look more friendly?

Answering my own question:

               0.2s         0.5s blink-cursor-timer-function
   *           0.1s            t show-paren-function
   *           0.5s      :repeat blink-cursor-start
   *           0.5s            t #f(compiled-function () #<bytecode 0x12cdf98f4135684a> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])

So are you saying that #<bytecode 0x12cdf98f4135684a> is friendlier
than #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>?
If so, please explain how is it friendlier.

Re: Unhelpful text in C-h v search-default-mode

[Juri Linkov]

>> > 1. M-x list-timers
>> >
>> >    *     0.1s     t show-paren-function
>> >    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
>> >
>> > I wonder how users are supposed to know what function it is?
>> > Searching by the delay number 0.5 reveals this lambda comes from
>> >
>> >         (setq jit-lock-context-timer
>> >               (run-with-idle-timer jit-lock-context-time t
>> >                                    (lambda ()
>> >                                      (unless jit-lock--antiblink-grace-timer
>> >                                        (jit-lock-context-fontify)))))
>> >
>>
>> What happens with that in a build without native-compilation? does
>> what list-timers shows in that case look more friendly?
>
> Answering my own question:
>
>   0.2s    0.5s blink-cursor-timer-function
> * 0.1s       t show-paren-function
> * 0.5s :repeat blink-cursor-start
> * 0.5s       t #f(compiled-function () #<bytecode 0x12cdf98f4135684a>
>                [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
>
> So are you saying that #<bytecode 0x12cdf98f4135684a> is friendlier
> than #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>?
> If so, please explain how is it friendlier.

At least it contains symbols like 'jit-lock-context-fontify'
that provide a hint what is this function about, and
it's possible to grep these symbols.  Hopefully Alan could
improve the readability of these cryptic names.

Re: Unhelpful text in C-h v search-default-mode

[Alan Mackenzie]

Hello, Juri.

On Fri, Dec 29, 2023 at 09:12:49 +0200, Juri Linkov wrote:
> > In a recent master branch Emacs, (not with -Q), from an info buffer, I
> > did C-h v search-default-mode.  The text printed in *Help* included this:

> >     Its value is
> >     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> >     Original value was nil
> >     Local in buffer *info*<3>; global value is nil

> > ..  This is quite frankly entirely unhelpful; it gives no way to find out
> > what the lambda is, in particular, no way to get to its source code.  It
> > isn't even possible to disassemble the function.

> Another example:

> 0. emacs -Q
> 1. M-x list-timers

>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>

> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes from

>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))

The new feature I've been working on for a couple of months should fix
this problem, too.  I'm making steady progress, currently being stuck on
cl-generic.el, due to its appalling lack of documentation.

Incidentally, why do we need the long string of hex digits in the subr
names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
codes for "anonymous_lambda", and would appear to be utterly
superfluous.  They serve only to make it more difficult to use the
function name, or to talk about it, and they make the list-timers output
much wider than it need be.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Unhelpful text in C-h v search-default-mode

[Emanuel Berg]

Alan Mackenzie wrote:

> Incidentally, why do we need the long string of hex digits
> in the subr names F616e....6461_anonymous_lambda_109?
> These are simply the ASCII codes for "anonymous_lambda"

Impressive that you just saw that!

I had to spend a lot of time before I even realized the
initial "F" is for function, i.e. not part of the hex string.

You just made one mistake, hex 2d is actually the hyphen, "-".
Yeah, this is what happens to people who rely on skills.

I found the code one the web and spent some time adopting it
to my style. But the credit for solving the problem belongs to
the SX user Inaimathi (see URL below).

As a side note, I know not everyone likes cl-lib and `cl-loop'
in particular but here at least I am very appreciative of the
below solution, style aspects not the least.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/hex.el
;;
;; original code:
;;   https://stackoverflow.com/a/12007656

(require 'cl-lib)

(defun decode-hex (str)
  (apply #'concat
    (cl-loop
      for i from 0 to (1- (/ (length str) 2))
      for hex-byte = (substring str (* 2 i) (* 2 (1+ i)))
      collect (format "%c" (string-to-number hex-byte 16)) )))

;; (decode-hex "616e6f6e796d6f75732d6c616d626461") ; anonymous-lambda

(provide 'hex)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Unhelpful text in C-h v search-default-mode

[Juri Linkov]

>> Incidentally, why do we need the long string of hex digits
>> in the subr names F616e....6461_anonymous_lambda_109?
>> These are simply the ASCII codes for "anonymous_lambda"
>
> Impressive that you just saw that!
>
> I had to spend a lot of time before I even realized the
> initial "F" is for function, i.e. not part of the hex string.

Interesting.  I didn't know that
#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
contains an "encrypted" message:

(replace-regexp-in-string ".."
 (lambda (hex) (string (string-to-number hex 16)))
 "616e6f6e796d6f75732d6c616d626461")
=> "anonymous-lambda"

Re: Unhelpful text in C-h v search-default-mode

[Emanuel Berg]

Juri Linkov wrote:

>>> Incidentally, why do we need the long string of hex digits
>>> in the subr names F616e....6461_anonymous_lambda_109?
>>> These are simply the ASCII codes for "anonymous_lambda"
>>
>> Impressive that you just saw that!
>>
>> I had to spend a lot of time before I even realized the
>> initial "F" is for function, i.e. not part of the
>> hex string.
>
> Interesting. I didn't know that
> #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> contains an "encrypted" message

Yeah, it is amazing you can still have this much fun with Emacs
after all these years using it every day!

> (replace-regexp-in-string ".."
>  (lambda (hex) (string (string-to-number hex 16)))
>  "616e6f6e796d6f75732d6c616d626461")
> => "anonymous-lambda"

Right, even tho I really appreciate the way `cl-loop' solved
the translation in my previous post I have to give it to you,
your solution is cleaner.

It is closer in style to this shell script and Unix tool
parsing which does the same thing:

$ str=$(printf '616e6f6e796d6f75732d6c616d626461' | sed 's,..,\\x&,g')
$ printf '%b\n' "$str"
anonymous-lambda

Anyway I added it to my hex.el file with a reference to your
post on the gnu.emacs.devel archives, see URL below.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/hex.el
;;
;; original code:
;;   https://stackoverflow.com/a/12007656
;;   https://lists.gnu.org/archive/html/emacs-devel/2023-12/msg00947.html

(require 'cl-lib)

(defun decode-hex-2 (str)
  (replace-regexp-in-string ".."
    (lambda (hex) (string (string-to-number hex 16)))
    str) )

;; (decode-hex-2 "616e6f6e796d6f75732d6c616d626461")

(defun decode-hex (str)
  (apply #'concat
    (cl-loop
      for i from 0 to (1- (/ (length str) 2))
      for hex-byte = (substring str (* 2 i) (* 2 (1+ i)))
      collect (format "%c" (string-to-number hex-byte 16)) )))

;; (decode-hex "616e6f6e796d6f75732d6c616d626461")

(provide 'hex)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Unhelpful text in C-h v search-default-mode

[Eli Zaretskii]

> Date: Fri, 29 Dec 2023 10:01:35 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Incidentally, why do we need the long string of hex digits in the subr
> names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
> codes for "anonymous_lambda", and would appear to be utterly
> superfluous.  They serve only to make it more difficult to use the
> function name, or to talk about it, and they make the list-timers output
> much wider than it need be.

Let's ask Andrea (CC'ed) to tell why he decided to use this notation.

Re: Unhelpful text in C-h v search-default-mode

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 29 Dec 2023 10:01:35 +0000
>> Cc: emacs-devel@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> Incidentally, why do we need the long string of hex digits in the subr
>> names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
>> codes for "anonymous_lambda", and would appear to be utterly
>> superfluous.  They serve only to make it more difficult to use the
>> function name, or to talk about it, and they make the list-timers output
>> much wider than it need be.
>
> Let's ask Andrea (CC'ed) to tell why he decided to use this notation.

I believe it was just to have a unique name, for that probably at the
time I just used the C name.  I welcome patches to improve this if we
feel is important.

  Andrea