From: npostavs@users.sourceforge.net
To: Ken Raeburn <raeburn@raeburn.org>
Cc: 27748@debbugs.gnu.org
Subject: bug#27748: 26.0.50; doc strings should be in DOC file
Date: Wed, 30 Aug 2017 20:50:32 -0400 [thread overview]
Message-ID: <87val47e7b.fsf@users.sourceforge.net> (raw)
In-Reply-To: <BDAD29A9-7B3E-4DF4-8A1C-026270E71DD6@raeburn.org> (Ken Raeburn's message of "Tue, 29 Aug 2017 06:09:09 -0400")
Ken Raeburn <raeburn@raeburn.org> writes:
> Sorry it’s taken me a while to get to testing these out…
Hah, no problem. I confess it's been on my todo list to test out your
scratch/raeburn-startup branch for an even longer while...
> On Aug 20, 2017, at 18:05, npostavs@users.sourceforge.net wrote:
>>
>>> 1. defcustom doc strings from files compiled with lexical binding.
>
>> With patch 0001 defcustoms which are compiled to bytecode now produce
>> dynamic docstrings which make-doc can digest (note that I had to change
>> make-doc a bit for this, but the .elc format remains the same as far as
>> the Emacs loading it is concerned. See the commit message for details).
>
> I think I like the new format. It’s a little bit bigger, but it may
> load faster, as we can do one big fseek at the beginning of the file
> (thus not even loading a lot of those pages) rather than lots of small
> ones as we go along.
Indeed, that was my thought too. I haven't measured anything though.
> Will this new make-docfile play nicely with files compiled with
> byte-compile-dynamic, where byte code is mixed in with the usual doc
> strings? Or if we decide to make lambdas (which have “(fn…)” doc
> strings by default but have no names to associate with them in DOC)
> load their doc strings dynamically from the .elc file?
Hmm, it will not. We would have to add a "nameless" type I guess,
something like ^_A^_anonymous docstring here...^_.
I pushed patches [2: bc5d96a0b2] and [3: 160295867d] to master, since
they are pretty straightforward bugfixes.
[2: bc5d96a0b2]: 2017-08-30 20:07:39 -0400
Drop docstrings from cl-defsubst produced inline bodies (Bug#27748)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bc5d96a0b2a1dccf7eeeec459e40d21b54c977f4>
[3: 160295867d]: 2017-08-30 20:07:39 -0400
Support lazy loading for autogenerated usage docstrings too (Bug#27748)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=160295867de98241a16f2ede93da7e825ed4406b
prev parent reply other threads:[~2017-08-31 0:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 6:47 bug#27748: 26.0.50; doc strings should be in DOC file Ken Raeburn
2017-08-06 0:09 ` npostavs
2017-08-08 1:03 ` npostavs
2017-08-13 18:04 ` npostavs
2019-06-24 22:38 ` Lars Ingebrigtsen
2019-06-24 23:00 ` Noam Postavsky
2020-08-10 15:00 ` Lars Ingebrigtsen
2021-05-10 12:09 ` Lars Ingebrigtsen
2021-09-25 15:41 ` Stefan Kangas
2021-09-26 5:32 ` Lars Ingebrigtsen
2021-10-23 17:32 ` Stefan Kangas
2021-10-24 12:59 ` Lars Ingebrigtsen
2017-08-20 22:05 ` npostavs
2017-08-29 10:09 ` Ken Raeburn
2017-08-31 0:50 ` npostavs [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87val47e7b.fsf@users.sourceforge.net \
--to=npostavs@users.sourceforge.net \
--cc=27748@debbugs.gnu.org \
--cc=raeburn@raeburn.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).