From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Patch: perform autoloading when docs is missing from autoload object Date: Wed, 22 Sep 2021 18:18:36 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27310"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 22 18:39:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mT5Hi-0006vG-6D for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Sep 2021 18:39:50 +0200 Original-Received: from localhost ([::1]:37208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mT5Hf-0000yj-Ma for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Sep 2021 12:39:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mT4xJ-0006CD-Au for emacs-devel@gnu.org; Wed, 22 Sep 2021 12:18:45 -0400 Original-Received: from mail-oln040092072041.outbound.protection.outlook.com ([40.92.72.41]:32128 helo=EUR03-VE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mT4xG-0007gX-6R for emacs-devel@gnu.org; Wed, 22 Sep 2021 12:18:44 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ieqq5kZPCGei9E33eSST5Qw/Mjscmuel4rnWhYNHUIKudzNiw4NzR/TJvDnVQ48YlxsNIK2BZ+2mpRXtm3k3FfXUGjILa397tFbQKnIkEl02viAqk/3IMbOzZiW3JrNwZVSOKWyOcl42Mj0FJdQMKCCfY9cPyD1Sx2B30+XvKBQSPkp2agDIvPR0FYghvbbqf5bV6jOfiHcAcNimRgPE13HfH9sCbRx5st3bEy7ofp1uE9TaL7KwOjaIpdvV+Oupbx8cw+eenheaaGlxTeG4osyzSIANwuAWClxtwxpDV3jN2LH7aZoKfsHyl+PfR94fvrwna6mdqQqnRZd5sKuD5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WsGwk/ImYf0K1P5PMRa8/RRNLYyaLGNkOBRJgChm/Fs=; b=n3viRnyCm5Nps7Yu6dRH1mtdaxw7XgjLK58QW80OQR6rxC7rI9MozJGGulG0K6oLA0ERSAy/Sli4FDoAk1MuylKFtpOdcCm50kP52yhcsnS9lKT9lYhExUmvUN7ZVZAn8DP46Hq4Ymov8UA9oo3iAWjSjljpZsrZqKXBTuPMlYsaB9jw481YWXBgT22jgeMnxXcRC0amWAYm5+OkkIRvHyOdOHfrXn310agd1VNTS0bcIwXUDabLP5+CNs2C82HSdpFzj8YgQ6eI1iQwgNBX4CBVU5GhFc5EQSzoNWKy9BKGCqxFmnDND6WRZSZ1IpY8kSIBxawAntcjYGcFQqp8+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WsGwk/ImYf0K1P5PMRa8/RRNLYyaLGNkOBRJgChm/Fs=; b=r0NWPfd68zSyfQsGaXgKk4YiTmT7DSC7+JOkMXY7C+IEf2ouIbwDrD0wV4aXFN0Cl+vZ7rlO48oo/uIdI/X/IsDFpbr24mzJ4GugSZeTHPPEfVY32cgodb5+/4TWqFgIR2eVP40EjJKwYADIyVdf1eZ7pQ46Sqic4L0XQdXHWQH/C7ukN4hp2p65dVQKJ3W2eTV3X9IQFCwRP9s1DwQZ9vFCA+de+ApjVylsx/0dKGCwL5Jwrm8zEql+IV8acJzvJpDz1OnWokf59vLts7U9c0J4xwNgTiBA94Mdv/7Bvuzkns092PSTFbagb0hYeo4jksM6OtF96XIM5cVwXSRbCw== Original-Received: from DB9PR09MB4986.eurprd09.prod.outlook.com (2603:10a6:10:2a9::19) by DBBPR09MB3510.eurprd09.prod.outlook.com (2603:10a6:10:dd::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Wed, 22 Sep 2021 16:18:38 +0000 Original-Received: from DB9PR09MB4986.eurprd09.prod.outlook.com ([fe80::80be:d528:d357:5d3a]) by DB9PR09MB4986.eurprd09.prod.outlook.com ([fe80::80be:d528:d357:5d3a%9]) with mapi id 15.20.4523.018; Wed, 22 Sep 2021 16:18:38 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 20 Sep 2021 13:02:47 -0400") X-TMN: [/Xdf6yv0K2cXfgogZvNF/R12uU3W+Pqb] X-ClientProxiedBy: HE1PR08CA0045.eurprd08.prod.outlook.com (2603:10a6:7:2a::16) To DB9PR09MB4986.eurprd09.prod.outlook.com (2603:10a6:10:2a9::19) X-Microsoft-Original-Message-ID: <87y27ovb1f.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by HE1PR08CA0045.eurprd08.prod.outlook.com (2603:10a6:7:2a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.14 via Frontend Transport; Wed, 22 Sep 2021 16:18:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 829de149-1523-4631-5822-08d97de4a263 X-MS-TrafficTypeDiagnostic: DBBPR09MB3510: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 62GvsTF5uD+2c7uqmFZbis6wBFXIr0YdTW8GoDMEfLJKq0ifU1NM4d8qadL8VZwLmJSuvELIwvmxFnCE+BulCWDFmC3jj4AY1Q6GTKax2GDzxUaL6UgVHRBPeL9NDQJaumqcv+VKlxRZRqBEVkcBdHzPc+rVf5gsz39hbDAVSnyZyf+oywJCTXuMRYOG6cA9rzKWPoyG4q4c6N0htmFI32jmCGW7e27kpNgPjz9/WW31xJXZlsP+CDwyvmIxNRQ57LBxvg9L/o5CM7y0QDmmeM9NQdxVlvLvsuKMJnnjxAZYkld9ybPEKuRNGLAJ9V+9C8ttWwDhsSzhkric6J4LK87L3ha/l10x6daVq+FPuyb+8+XmSnd6B3FSDtCtHG8zHkGX0+qpzrGKf5PdQjwaoTcz7TGP/ztOAg69OfrthDRwSEzFEUHljZ3+sWxSEvL3 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Q/nm/k9nU9EfJBMefdXVw8uLz2NmcLb9SodUfIZ4O2bMXHmZkM+wRaDHCkDiBL4/8IG0OQDUVu7PeAd3lQXg5/k1z0KL1PP4I+i9GbI90sDlR/EtDk/QO7NkFe5Kl3Q1gVioCbwzL1pygn9SVC7cRg== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 829de149-1523-4631-5822-08d97de4a263 X-MS-Exchange-CrossTenant-AuthSource: DB9PR09MB4986.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2021 16:18:38.7806 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR09MB3510 Received-SPF: pass client-ip=40.92.72.41; envelope-from=arthur.miller@live.com; helo=EUR03-VE1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275322 Archived-At: Stefan Monnier writes: >> I tested with package-quickstart. As said, manually opened .elc and >> evaled the buffer. > > Hmm... Can't see an obvious reason why it didn't do "the right thing" > for you (tho `M-x eval-buffer` will result in an unusable (FILE . OFFSET) > pair because the `load-file-name` var is not setup; a better test is to > load the file, but that doesn't explain why you ended up with an actual > doc *string*). Sorry for bit late answer, I was little busy with playing with help-buffer, so wasn't have so much time for anything else. I wanted to try this with Emac -Q to be sure it's not my init file. I did as you describe, and just loaded the file in Emacs -Q, but it still puts in embedded docs. I am not sure, I have just been looking now around, without actually exectuing anything, but I think that the actual data is emitted in (defun autoload-print-form (form)) in autoload.el, and I don't see there anything about offsets. But I am not sure about it, to be honest; was just quick look at the pipleine. I have tried to trace package-quicstart-refresh calls, but I didn't come out more informed than I was before, so I will leave it for the moment. >> By the way, when I was reading the manual, and testing all this, I could see >> that autoloads from Emacs sources were with offsets in autoload object. > > Yes, this a special case: they're offsets into the `etc/DOC` file, > generated by the `lib-src/make-docfile.c` auxiliary tool. > This so as to bring the cost down further: instead of (FILE . OFFSET) we > can use just OFFSET where FILE is known implicitly to be `etc/DOC`. Cool, thank you for the info. Can't generated autoloads use the same trick for every file? I reason that every .elc file installe din elpa is known at compile time and load time as well. Since file itself is recorded in autoload object, can't the same be applied? Or are there more details in the play? >> But I couldn't see those from installed packages. That is why I have >> finally ditched the entire package-quickstart and Emacs >> autoload generation. > > Looking at the code, everything seems to be in place such that > byte-compiling the `package-quickstart.el` file *should* end up with > (FILE . OFFSET)s, but I haven't tested it to confirm yet. > You say it doesn't work, so apparently there's something somewhere that > still gets in the way :-( As mentioned above, I just tried with Emacs -Q and doing as you described, but I just see embedded docs. I am not trolling or anything, I'll be glad to help to find why is it so if I can. >>>> So the entire business of docs in autoloads is due to autoload file generation, >>>> seems to me, if I don't misunderstanding something? >>> I'm afraid I don't know what you mean by "business of docs in autoloads". >> Eh; sorry, that was a goofy expression. I meant that documentation ends up >> in autoload objects, because Emacs code that scrapes for autoloads explicitly put >> it there. I am no 100% sure, that is just my assumption, I hoped you would say >> yes or no :). > > Ah, well then "yes" ;-) > >> Rationale was that it is faster to just parsing with 'read' without loading >> structures in the memory; > > Most Elisp files can be loaded fairly quickly (some exceptions are > things like `org.el` that pull in a lot of dependencies) and we'd only do > it once per session an only in some particular cases (not in loops, > etc...), so it's not that terribly important. > Indeed require/provide mechanism is a good thing and I also think it is not that important. When you touch on loading files; may I ask, if you have time to anser; why require/provide isn't automated in a sense, that it always provide a feature equaly named as the file loaded? When I was learning about it, as I understand, a file can provide several features, which not many elisp file actually do. It can also be used to name feature differently from the file itself, which few actually do. It is all good, flexibility is always good, but for if I would like to check if a file is loaded, and I don't know which features it provides, if any, do I have any easy way of knowing it? I can look at load-hist and serach in lists, but it is very convenient to say, as an example, (require 'subr) and be confident that the file won't be loaded if it is already loaded. 'load' loads files unconditionally, right? It probably should since it is a low-level function I guess. Sorry if I am asking too much, there is so much to learn about Emacs :).