bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Hello,

I see this problem for a couple of weeks now, never saw it before:

When I made edits to my config file, any running session of Emacs that
has loaded this init file (including the same session) will have an
issue: any action that causes `documentation' being called with one of
the things defined in my init file as argument will reload the complete
init file.

This is a problem: it takes a lot of time and this can happen
repeatedly, often I have to restart Emacs to be able to continue my work
normally.  There are a lot of things that trigger the call of
`documentation' - not only requesting documentation explicitly, but also
things like `eldoc-mode' or cl-printing expressions.

I have not been able to find out why the behavior has changed.  The
reloading happens from C AFAIU.  Please help!

TIA,

Michael.




In GNU Emacs 30.0.50 (build 25, x86_64-pc-linux-gnu, cairo version
 1.16.0) of 2024-01-02 built on drachen
Repository revision: c6125a87633131308dff74fb9a1006659c8611cd
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

> When I made edits to my config file [...]

Let me add the that file in question is "~/gnu-emacs/.gnu-emacs.elc" -
this file is loaded by ~/.emacs (which is the value of
`user-init-file').

"~/gnu-emacs/" contains a separate git repo and I always compile all the
Elisp stuff in that directory.  Dunno if anything of that matters here.

Michael.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Eli Zaretskii]

> Date: Tue, 02 Jan 2024 02:53:50 +0100
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> Hello,
> 
> I see this problem for a couple of weeks now, never saw it before:
> 
> When I made edits to my config file, any running session of Emacs that
> has loaded this init file (including the same session) will have an
> issue: any action that causes `documentation' being called with one of
> the things defined in my init file as argument will reload the complete
> init file.
> 
> This is a problem: it takes a lot of time and this can happen
> repeatedly, often I have to restart Emacs to be able to continue my work
> normally.  There are a lot of things that trigger the call of
> `documentation' - not only requesting documentation explicitly, but also
> things like `eldoc-mode' or cl-printing expressions.
> 
> I have not been able to find out why the behavior has changed.  The
> reloading happens from C AFAIU.  Please help!

I don't think I understand your description, but maybe running Emacs
under GDB with a breakpoint in Fload, with a condition that it will
only break when the offending file is loaded, will allow you to
produce a backtrace, and we could then take from there, armed with the
list of possible offenders -- the functions in the backtrace.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand your description,

Please ask about unclear parts, but maybe the backtraces are good
enough.

> but maybe running Emacs under GDB with a breakpoint in Fload [...]

I got one.  [ I was lazy and was just creating a new frame at the
beginning of my init file when repeated loading was detected and used a
breakpoint on x_create_frame - because I did not want to learn about
conditional breakpoints for now. So please don't get confused because of
the innermost backtrace frames. ]

What I did: I have started the debugged session, then edited and
recompiled my main config file "~/gnu-emacs/.gnu-emacs.el" (which is
loaded from "~/.emacs") from a separate session, and then did C-h f
some-function-defined-in-my-init-file RET in the debugged session.

(function-documentation 'some-function-defined-in-my-init-file)
 --> ("/home/micha/gnu-emacs/.gnu-emacs.elc" . 291847)

if that matters.

| Lisp Backtrace:
| "x-create-frame" (0xf19ff750)
| "x-create-frame-with-faces" (0xf19ff6e8)
| 0xf2605e70 PVEC_COMPILED
| "apply" (0xf19ff660)
| "frame-creation-function" (0xf19ff600)
| "make-frame" (0xf19ff570)
| "byte-code" (0xffffb350)
| "documentation" (0xf19ff518)
| "describe-function-1" (0xf19ff490)
| 0x598c9918 PVEC_COMPILED
| "help--window-setup" (0xf19ff3f8)
| "describe-function" (0xffffbf70)
| 0x583df770 Lisp type 3
| 0x598c9870 PVEC_COMPILED
| "helm-execute-selection-action-1" (0xf19ff300)
| "helm-execute-selection-action" (0xf19ff2a0)
| "helm-internal" (0xffffc848)
| "apply" (0xf19ff1d8)
| "helm" (0xffffcfd8)
| "apply" (0xf19ff178)
| "helm" (0xf19ff100)
| "my-helm-describe-function" (0xffffda40)
| "funcall-interactively" (0xffffda38)
| "call-interactively" (0xf19ff070)
| "command-execute" (0xffffe508)

bt:

| #0  Fx_create_frame (parms=XIL(0x55555ab08d53)) at xfns.c:4902
| #1  0x00005555557e3f89 in funcall_subr (subr=0x555555dda200 <Sx_create_frame>, numargs=1, args=0x7ffff19ff750) at eval.c:3090
| #2  0x0000555555835c25 in exec_byte_code (fun=XIL(0x7ffff25494b5), args_template=770, nargs=3, args=0x7ffff19ff7b8) at bytecode.c:815
| #3  0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x7ffff2605e75), args_template=257, nargs=1, args=0x7ffff19ff668) at eval.c:3135
| #4  0x00005555557e460a in funcall_lambda (fun=XIL(0x7ffff2605e75), nargs=1, arg_vector=0x7ffff19ff668) at eval.c:3207
| #5  0x00005555557e3a4e in funcall_general (fun=XIL(0x7ffff2605e75), numargs=1, args=0x7ffff19ff668) at eval.c:2972
| #6  0x00005555557e3ccf in Ffuncall (nargs=2, args=0x7ffff19ff660) at eval.c:3022
| #7  0x00005555557e2e3d in Fapply (nargs=2, args=0x7ffff19ff660) at eval.c:2650
| #8  0x00005555557e41c2 in funcall_subr (subr=0x555555de3680 <Sapply>, numargs=2, args=0x7ffff19ff660) at eval.c:3113
| #9  0x0000555555835c25 in exec_byte_code (fun=XIL(0x7ffff230db8d), args_template=128, nargs=1, args=0x7ffff19ff600) at bytecode.c:815
| #10 0x0000555555834d38 in Fbyte_code (bytestr=XIL(0x55555b272d14), vector=XIL(0x55555a153e6d), maxdepth=make_fixnum(8)) at bytecode.c:329
| #11 0x00005555557e280f in eval_sub (form=XIL(0x55555ab08ab3)) at eval.c:2531
| #12 0x000055555581d591 in readevalloop (readcharfun=XIL(0x8610), infile0=0x7fffffffb730, sourcename=XIL(0x55555b272c54), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2597
| #13 0x000055555581b5d4 in Fload (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1792
| #14 0x000055555581b89a in save_match_data_load (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1841
| #15 0x00005555557c9db7 in reread_doc_file (file=XIL(0x555556242004)) at doc.c:355
| #16 0x00005555557c9fc5 in Fdocumentation (function=XIL(0x2ae8b20), raw=XIL(0x30)) at doc.c:399
| #17 0x00005555557e3fb0 in funcall_subr (subr=0x555555de1800 <Sdocumentation>, numargs=2, args=0x7ffff19ff518) at eval.c:3092
| #18 0x0000555555835c25 in exec_byte_code (fun=XIL(0x7ffff2264a3d), args_template=257, nargs=1, args=0x7ffff19ff5f0) at bytecode.c:815
| #19 0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x5555579853d5), args_template=257, nargs=1, args=0x7fffffffbf70) at eval.c:3135
| #20 0x00005555557e460a in funcall_lambda (fun=XIL(0x5555579853d5), nargs=1, arg_vector=0x7fffffffbf70) at eval.c:3207
| #21 0x00005555557e4428 in apply_lambda (fun=XIL(0x5555579853d5), args=XIL(0x5555583df6b3), count=...) at eval.c:3157
| #22 0x00005555557e29f2 in eval_sub (form=XIL(0x5555583df723)) at eval.c:2572
| #23 0x00005555557ddbec in Fprogn (body=XIL(0)) at eval.c:432
| #24 0x00005555557e4967 in funcall_lambda (fun=XIL(0x5555583df773), nargs=1, arg_vector=0x7ffff19ff3b0) at eval.c:3287
| #25 0x00005555557e3b44 in funcall_general (fun=XIL(0x5555583df773), numargs=1, args=0x7ffff19ff3b0) at eval.c:2984
| #26 0x0000555555835c4b in exec_byte_code (fun=XIL(0x5555598c9875), args_template=257, nargs=1, args=0x7ffff19ff368) at bytecode.c:817
| #27 0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x55555840ea15), args_template=2304, nargs=9, args=0x7fffffffc848) at eval.c:3135
| #28 0x00005555557e460a in funcall_lambda (fun=XIL(0x55555840ea15), nargs=9, arg_vector=0x7fffffffc848) at eval.c:3207
| #29 0x00005555557e3a4e in funcall_general (fun=XIL(0x55555840ea15), numargs=9, args=0x7fffffffc848) at eval.c:2972
| #30 0x00005555557e3ccf in Ffuncall (nargs=10, args=0x7fffffffc840) at eval.c:3022
| #31 0x00005555557e31ab in Fapply (nargs=2, args=0x7ffff19ff1d8) at eval.c:2693
| #32 0x00005555557e41c2 in funcall_subr (subr=0x555555de3680 <Sapply>, numargs=2, args=0x7ffff19ff1d8) at eval.c:3113
| #33 0x0000555555835c25 in exec_byte_code (fun=XIL(0x555558408e7d), args_template=128, nargs=9, args=0x7fffffffcfd8) at bytecode.c:815
| #34 0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x555558408e7d), args_template=128, nargs=9, args=0x7fffffffcfd8) at eval.c:3135
| #35 0x00005555557e460a in funcall_lambda (fun=XIL(0x555558408e7d), nargs=9, arg_vector=0x7fffffffcfd8) at eval.c:3207
| #36 0x00005555557e3a4e in funcall_general (fun=XIL(0x555558408e7d), numargs=9, args=0x7fffffffcfd8) at eval.c:2972
| #37 0x00005555557e3ccf in Ffuncall (nargs=10, args=0x7fffffffcfd0) at eval.c:3022
| #38 0x00005555557e31ab in Fapply (nargs=2, args=0x7ffff19ff178) at eval.c:2693
| #39 0x00005555557e41c2 in funcall_subr (subr=0x555555de3680 <Sapply>, numargs=2, args=0x7ffff19ff178) at eval.c:3113
| #40 0x0000555555835c25 in exec_byte_code (fun=XIL(0x5555584558fd), args_template=257, nargs=1, args=0x7ffff19ff190) at bytecode.c:815
| #41 0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x55555816c375), args_template=0, nargs=0, args=0x7fffffffda40) at eval.c:3135
| #42 0x00005555557e460a in funcall_lambda (fun=XIL(0x55555816c375), nargs=0, arg_vector=0x7fffffffda40) at eval.c:3207
| #43 0x00005555557e3a4e in funcall_general (fun=XIL(0x55555816c375), numargs=0, args=0x7fffffffda40) at eval.c:2972
| #44 0x00005555557e3ccf in Ffuncall (nargs=1, args=0x7fffffffda38) at eval.c:3022
| #45 0x00005555557d9a2f in Ffuncall_interactively (nargs=1, args=0x7fffffffda38) at callint.c:250
| #46 0x00005555557e41c2 in funcall_subr (subr=0x555555de2d80 <Sfuncall_interactively>, numargs=1, args=0x7fffffffda38) at eval.c:3113
| #47 0x00005555557e3a02 in funcall_general (fun=XIL(0x555555de2d85), numargs=1, args=0x7fffffffda38) at eval.c:2968
| #48 0x00005555557e3ccf in Ffuncall (nargs=2, args=0x7fffffffda30) at eval.c:3022
| #49 0x00005555557e2dfa in Fapply (nargs=3, args=0x7fffffffda30) at eval.c:2646
| #50 0x00005555557d9e43 in Fcall_interactively (function=XIL(0x267ee00), record_flag=XIL(0), keys=XIL(0x555559134945)) at callint.c:342
| #51 0x00005555557e3fe3 in funcall_subr (subr=0x555555de2dc0 <Scall_interactively>, numargs=3, args=0x7ffff19ff070) at eval.c:3094
| #52 0x0000555555835c25 in exec_byte_code (fun=XIL(0x7ffff22d939d), args_template=1025, nargs=1, args=0x7fffffffe510) at bytecode.c:815
| #53 0x00005555557e4296 in fetch_and_exec_byte_code (fun=XIL(0x7ffff22d939d), args_template=1025, nargs=1, args=0x7fffffffe508) at eval.c:3135
| #54 0x00005555557e460a in funcall_lambda (fun=XIL(0x7ffff22d939d), nargs=1, arg_vector=0x7fffffffe508) at eval.c:3207
| #55 0x00005555557e3a4e in funcall_general (fun=XIL(0x7ffff22d939d), numargs=1, args=0x7fffffffe508) at eval.c:2972
| #56 0x00005555557e3ccf in Ffuncall (nargs=2, args=0x7fffffffe500) at eval.c:3022
| #57 0x000055555571f4e7 in command_loop_1 () at keyboard.c:1539
| #58 0x00005555557e02e6 in internal_condition_case (bfun=0x55555571ece5 <command_loop_1>, handlers=XIL(0x90), hfun=0x55555571e283 <cmd_error>) at eval.c:1537
| #59 0x000055555571e93a in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1157
| #60 0x00005555557df842 in internal_catch (tag=XIL(0x10860), func=0x55555571e910 <command_loop_2>, arg=XIL(0x90)) at eval.c:1217
| #61 0x000055555571e8cc in command_loop () at keyboard.c:1135
| #62 0x000055555571de25 in recursive_edit_1 () at keyboard.c:744
| #63 0x000055555571dfd1 in Frecursive_edit () at keyboard.c:827
| #64 0x000055555571a398 in main (argc=1, argv=0x7fffffffe978) at emacs.c:2624

Does this allow us to make any progress?

TIA,

Michael.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Gerd Möllmann]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> | #13 0x000055555581b5d4 in Fload (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1792
> | #14 0x000055555581b89a in save_match_data_load (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1841
> | #15 0x00005555557c9db7 in reread_doc_file (file=XIL(0x555556242004)) at doc.c:355
> | #16 0x00005555557c9fc5 in Fdocumentation (function=XIL(0x2ae8b20),
> | raw=XIL(0x30)) at doc.c:399

Looks to me like Fdocumentation detects that the file containing the doc
has changed, and that it needs to reload it. I think you mentioned that
this happens when you change the file and existing Emacs sessions do the
reload? In that case, this looks like normal behaviour to me, unless I'm
overlooking something?

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  68200@debbugs.gnu.org
> Date: Sun, 07 Jan 2024 06:43:37 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > | #13 0x000055555581b5d4 in Fload (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1792
> > | #14 0x000055555581b89a in save_match_data_load (file=XIL(0x555556242004), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1841
> > | #15 0x00005555557c9db7 in reread_doc_file (file=XIL(0x555556242004)) at doc.c:355
> > | #16 0x00005555557c9fc5 in Fdocumentation (function=XIL(0x2ae8b20),
> > | raw=XIL(0x30)) at doc.c:399
> 
> Looks to me like Fdocumentation detects that the file containing the doc
> has changed, and that it needs to reload it. I think you mentioned that
> this happens when you change the file and existing Emacs sessions do the
> reload? In that case, this looks like normal behaviour to me, unless I'm
> overlooking something?

Right.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Eli Zaretskii <eliz@gnu.org> writes:

> > Looks to me like Fdocumentation detects that the file containing the doc
> > has changed, and that it needs to reload it. I think you mentioned that
> > this happens when you change the file and existing Emacs sessions do the
> > reload? In that case, this looks like normal behaviour to me, unless I'm
> > overlooking something?
>
> Right.

Ok, thanks.

I now remember that for that reason I am using a file local variable
binding byte-compile-dynamic-docstrings: nil.  I the past this setting
prevented this reloading.  But the behavior changed some weeks ago -
like if that binding would be ignored now.


Michael.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Eli Zaretskii <eliz@gnu.org> writes:

> > Looks to me like Fdocumentation detects that the file containing the doc
> > has changed, and that it needs to reload it. I think you mentioned that
> > this happens when you change the file and existing Emacs sessions do the
> > reload? In that case, this looks like normal behaviour to me, unless I'm
> > overlooking something?
>
> Right.

Looks like

  6a01a1a856f ".elc format: Record lambdas' doc strings lazily, not
  inline" (Alan Mackenzie <acm@muc.de> 2023-11-26)

would be related.

Alan, could this be the case?

TIA,

Michael.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Alan Mackenzie]

Hello, Michael.

On Sun, Jan 07, 2024 at 18:33:39 +0100, Michael Heerdegen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > > Looks to me like Fdocumentation detects that the file containing the doc
> > > has changed, and that it needs to reload it. I think you mentioned that
> > > this happens when you change the file and existing Emacs sessions do the
> > > reload? In that case, this looks like normal behaviour to me, unless I'm
> > > overlooking something?

> > Right.

> Looks like

>   6a01a1a856f ".elc format: Record lambdas' doc strings lazily, not
>   inline" (Alan Mackenzie <acm@muc.de> 2023-11-26)

> would be related.

> Alan, could this be the case?

Yes, I think it could.  I've not yet got my brain into that commit from
November (which was quite a long time ago), but ....

In an age when a computer with 1 GB RAM is regarded as small indeed, why
are we so concerned about the, at most, few hundred bytes occupied by
each doc string?  Even if certain libraries were given adequate doc
strings, that still wouldn't swell the occupied storage to more than...
Well, I think there are around 40,000 defuns (etc.) in Emacs (I did scan
the source files for this at one time).  If each doc string were on
average 1024 bytes, that would come to around 40 MB.  That's negligible
these days, surely.

Eli, what would you say to changing the default of the custom variable
byte-compile-dynamic-docstrings to nil?

And I'll have a look at why that variable no longer appears to be
working (though I have rather a lot on in the next few days).

> TIA,

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

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

Alan Mackenzie <acm@muc.de> writes:

> And I'll have a look at why that variable no longer appears to be
> working (though I have rather a lot on in the next few days).

The let-binding of `byte-compile-output-docform' your commit adds in
`byte-compile-output-docform' - you are aware that in my case this
rebinds the buffer local variable before switching to a
different buffer where this binding is not visible?

Michael.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Alan Mackenzie]

Hello, Michael.

On Tue, Jan 09, 2024 at 00:09:29 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > And I'll have a look at why that variable no longer appears to be
> > working (though I have rather a lot on in the next few days).

> The let-binding of `byte-compile-output-docform' your commit adds in
> `byte-compile-output-docform' - you are aware that in my case this
> rebinds the buffer local variable before switching to a
> different buffer where this binding is not visible?

Ah.  I've always been a bit vague about mixing buffer local bindings
with let bindings.  Thanks for spotting the cause of the bug.

You've almost certainly written your own patch for it by now, but
nevertheless, could I ask you to try out this patch.  I don't have a
convenient test case here.


diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 2bc8d54ba77..ad8d53d01e9 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -2605,9 +2605,10 @@ byte-compile-output-docform
 `defvaralias', `autoload' and `custom-declare-variable' need that."
   ;; We need to examine byte-compile-dynamic-docstrings
   ;; in the input buffer (now current), not in the output buffer.
-  (let ((byte-compile-dynamic-docstrings byte-compile-dynamic-docstrings))
+  (let ((dynamic-docstrings byte-compile-dynamic-docstrings))
     (with-current-buffer byte-compile--outbuffer
-      (let ((position (point))
+      (let ((byte-compile-dynamic-docstrings dynamic-docstrings)
+            (position (point))
             (print-continuous-numbering t)
             print-number-table
             ;; FIXME: The bindings below are only needed for when we're

Thanks!

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#68200: File local byte-compile-dynamic-docstrings:nil ignored (was: bug#68200: 30.0.50; Emacs reloads init file when calling `documentation')

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

Alan Mackenzie <acm@muc.de> writes:

> You've almost certainly written your own patch for it by now, but
> nevertheless, could I ask you to try out this patch.  I don't have a
> convenient test case here.
>
> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 2bc8d54ba77..ad8d53d01e9 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -2605,9 +2605,10 @@ byte-compile-output-docform
>  `defvaralias', `autoload' and `custom-declare-variable' need that."
>    ;; We need to examine byte-compile-dynamic-docstrings
>    ;; in the input buffer (now current), not in the output buffer.
> -  (let ((byte-compile-dynamic-docstrings byte-compile-dynamic-docstrings))
> +  (let ((dynamic-docstrings byte-compile-dynamic-docstrings))
>      (with-current-buffer byte-compile--outbuffer
> -      (let ((position (point))
> +      (let ((byte-compile-dynamic-docstrings dynamic-docstrings)
> +            (position (point))

Yes, that's what I tried as well.  This approach seems to fix this
problem here, so: fine by me.


Thanks,

Michael.

bug#68200: File local byte-compile-dynamic-docstrings:nil ignored (was: bug#68200: 30.0.50; Emacs reloads init file when calling `documentation')

[Alan Mackenzie]

Hello, Michael.

On Wed, Jan 10, 2024 at 04:28:32 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > You've almost certainly written your own patch for it by now, but
> > nevertheless, could I ask you to try out this patch.  I don't have a
> > convenient test case here.

> > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> > index 2bc8d54ba77..ad8d53d01e9 100644
> > --- a/lisp/emacs-lisp/bytecomp.el
> > +++ b/lisp/emacs-lisp/bytecomp.el
> > @@ -2605,9 +2605,10 @@ byte-compile-output-docform
> >  `defvaralias', `autoload' and `custom-declare-variable' need that."
> >    ;; We need to examine byte-compile-dynamic-docstrings
> >    ;; in the input buffer (now current), not in the output buffer.
> > -  (let ((byte-compile-dynamic-docstrings byte-compile-dynamic-docstrings))
> > +  (let ((dynamic-docstrings byte-compile-dynamic-docstrings))
> >      (with-current-buffer byte-compile--outbuffer
> > -      (let ((position (point))
> > +      (let ((byte-compile-dynamic-docstrings dynamic-docstrings)
> > +            (position (point))

> Yes, that's what I tried as well.  This approach seems to fix this
> problem here, so: fine by me.

OK, I've committed the fix and I'm closing the bug with this post.

> Thanks,

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Eli Zaretskii]

> Date: Mon, 8 Jan 2024 21:22:16 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>,
>   Gerd Möllmann <gerd.moellmann@gmail.com>,
>   68200@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> In an age when a computer with 1 GB RAM is regarded as small indeed, why
> are we so concerned about the, at most, few hundred bytes occupied by
> each doc string?

Because RAM is always at premium, and because these things add up.

> Even if certain libraries were given adequate doc
> strings, that still wouldn't swell the occupied storage to more than...
> Well, I think there are around 40,000 defuns (etc.) in Emacs (I did scan
> the source files for this at one time).  If each doc string were on
> average 1024 bytes, that would come to around 40 MB.  That's negligible
> these days, surely.

No, 40MB is far from being negligible.

> Eli, what would you say to changing the default of the custom variable
> byte-compile-dynamic-docstrings to nil?

Why would that be useful? to hide bugs in code that doesn't work when
the variable is non-nil?

> And I'll have a look at why that variable no longer appears to be
> working (though I have rather a lot on in the next few days).

Thanks.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Alan Mackenzie]

Hello, Eli.

On Tue, Jan 09, 2024 at 14:36:02 +0200, Eli Zaretskii wrote:
> > Date: Mon, 8 Jan 2024 21:22:16 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>,
> >   Gerd Möllmann <gerd.moellmann@gmail.com>,
> >   68200@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > In an age when a computer with 1 GB RAM is regarded as small indeed, why
> > are we so concerned about the, at most, few hundred bytes occupied by
> > each doc string?

> Because RAM is always at premium, and because these things add up.

> > Even if certain libraries were given adequate doc
> > strings, that still wouldn't swell the occupied storage to more than...
> > Well, I think there are around 40,000 defuns (etc.) in Emacs (I did scan
> > the source files for this at one time).  If each doc string were on
> > average 1024 bytes, that would come to around 40 MB.  That's negligible
> > these days, surely.

> No, 40MB is far from being negligible.

It's not negligible compared with the rest of Emacs, but is less than ¼%
of the RAM in a machine with 16GB.

> > Eli, what would you say to changing the default of the custom variable
> > byte-compile-dynamic-docstrings to nil?

> Why would that be useful? to hide bugs in code that doesn't work when
> the variable is non-nil?

No, the bug has been fixed.  But, as Michael pointed out, lots of things
are being done with doc strings now which weren't being done when the
dynamic doc strings were introduced.  Indeed, they were surely a
workaround for limited RAM in machines a very long time ago.

Now that we're doing more with doc strings, the inconvenience of not
getting a doc string after editing a source file might well outweigh the
relatively small amount of RAM that these doc strings need.

Hence the suggestion to change the default.

[ .... ]

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Eli Zaretskii]

> Date: Thu, 11 Jan 2024 18:10:58 +0000
> Cc: michael_heerdegen@web.de, gerd.moellmann@gmail.com, 68200@debbugs.gnu.org,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > No, 40MB is far from being negligible.
> 
> It's not negligible compared with the rest of Emacs, but is less than ¼%
> of the RAM in a machine with 16GB.

No, it isn't, because most of those 16GB are in use at any given
moment.

> No, the bug has been fixed.  But, as Michael pointed out, lots of things
> are being done with doc strings now which weren't being done when the
> dynamic doc strings were introduced.  Indeed, they were surely a
> workaround for limited RAM in machines a very long time ago.
> 
> Now that we're doing more with doc strings, the inconvenience of not
> getting a doc string after editing a source file might well outweigh the
> relatively small amount of RAM that these doc strings need.
> 
> Hence the suggestion to change the default.

Since I disagree with your argument about memory being available for
free, I also disagree with the suggestion that is based on that
argument.

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Alan Mackenzie]

Hello, Eli.

On Thu, Jan 11, 2024 at 21:22:08 +0200, Eli Zaretskii wrote:
> > Date: Thu, 11 Jan 2024 18:10:58 +0000
> > Cc: michael_heerdegen@web.de, gerd.moellmann@gmail.com, 68200@debbugs.gnu.org,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > No, 40MB is far from being negligible.

> > It's not negligible compared with the rest of Emacs, but is less than ¼%
> > of the RAM in a machine with 16GB.

> No, it isn't, because most of those 16GB are in use at any given
> moment.

I'm sure they're not on my machine.  But I'm glad RAM is now measured in
GB, not MB.

> > No, the bug has been fixed.  But, as Michael pointed out, lots of things
> > are being done with doc strings now which weren't being done when the
> > dynamic doc strings were introduced.  Indeed, they were surely a
> > workaround for limited RAM in machines a very long time ago.

> > Now that we're doing more with doc strings, the inconvenience of not
> > getting a doc string after editing a source file might well outweigh the
> > relatively small amount of RAM that these doc strings need.

> > Hence the suggestion to change the default.

> Since I disagree with your argument about memory being available for
> free, I also disagree with the suggestion that is based on that
> argument.

No problem.  If I find annoyance with files continually reloading, like
Michael did, I can always set my own value of that variable.

Have a good evening!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#68200: 30.0.50; Emacs reloads init file when calling `documentation'

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> In an age when a computer with 1 GB RAM is regarded as small indeed, why
> are we so concerned about the, at most, few hundred bytes occupied by
> each doc string?  Even if certain libraries were given adequate doc
> strings, that still wouldn't swell the occupied storage to more than...
> Well, I think there are around 40,000 defuns (etc.) in Emacs (I did scan
> the source files for this at one time).  If each doc string were on
> average 1024 bytes, that would come to around 40 MB.  That's negligible
> these days, surely.
>
> Eli, what would you say to changing the default of the custom variable
> byte-compile-dynamic-docstrings to nil?

Could you come up with a more accurate number?  Maybe I'm missing
something, but 40 MB sounds like a lot to me.  Most docstrings should be
much smaller than 1024 bytes (15 full rows with our 65 character width).