[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27748: 26.0.50; doc strings should be in DOC file
From: |
Stefan Kangas |
Subject: |
bug#27748: 26.0.50; doc strings should be in DOC file |
Date: |
Sat, 25 Sep 2021 08:41:17 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Noam Postavsky <npostavs@gmail.com> writes:
>
>>> These strings still aren't in the DOC file, but I'm not sure whether
>>> that's a problem or not -- what are the practical effects of the doc
>>> string of `delete-auto-save-files' not being in that file?
>>
>> It's mostly just an optimization thing, so not hugely important (at the
>> time, Ken was working on a pure Lisp dumping strategy, so shrinking the
>> preloaded code was important for that, but we've gone with the pdumper
>> instead). However, I seem to recall that applying something like this
>> will make it possible to solve Bug#4845, because the docstring loading
>> mechanism will no longer be reliant on finding "(defun foo" in the .elc
>> file. So that might be nifty.
>
> Stefan M recently suggested getting rid of the DOC file entirely, so I
> wonder whether he has any comments here. (Added to the CCs.)
FWIW, I think we should get rid of it. Stefan M did an analysis of this
and the amount of saved memory was very small, from bytecomp.el:
;; For the compilation itself, we could largely get rid of this hunk-handler,
;; if it weren't for the fact that we need to figure out when a defalias
;; defines a macro, so as to add it to byte-compile-macro-environment.
;;
;; FIXME: we also use this hunk-handler to implement the function's dynamic
;; docstring feature. We could actually implement it more elegantly in
;; byte-compile-lambda so it applies to all lambdas, but the problem is that
;; the resulting .elc format will not be recognized by make-docfile, so
;; either we stop using DOC for the docstrings of preloaded elc files (at the
;; cost of around 24KB on 32bit hosts, double on 64bit hosts) or we need to
;; build DOC in a more clever way (e.g. handle anonymous elements).
- bug#27748: 26.0.50; doc strings should be in DOC file,
Stefan Kangas <=