From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 25 14:51:31 2020 Received: (at submit) by debbugs.gnu.org; 25 Dec 2020 19:51:31 +0000 Received: from localhost ([127.0.0.1]:58168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kst7b-0006hd-Ey for submit@debbugs.gnu.org; Fri, 25 Dec 2020 14:51:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:41398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kst7Y-0006hV-S5 for submit@debbugs.gnu.org; Fri, 25 Dec 2020 14:51:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kst7X-0006WC-RA for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 14:51:28 -0500 Received: from mail.hostpark.net ([212.243.197.30]:42346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kst7U-0003q2-MN for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 14:51:27 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 975DA165D1 for ; Fri, 25 Dec 2020 20:51:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :subject:subject:from:from:received:received; s=sel2011a; t= 1608925880; bh=QKg9yXHWSqcTt34lRoGqwyyOgsFoqFxy8xrx+FDJOoY=; b=U nHsaR51E+24F48vTCKimCL5EzF0tUFsEWYf6MYi22m2W9KfMq4Y8C1nDUoHifkNx wfhm0ZNAPu6IFgvnxgvT4TLYCn0wjNtdSE8CImrxzxaytcJ6K2AfKH37xkBi0FJQ +iEGpwwwqGFDlniGdXyUSPU6TaR8JJ7UIcIRr/IY0Y= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id vt5cnBUT-ED9 for ; Fri, 25 Dec 2020 20:51:20 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 62AB2165BD for ; Fri, 25 Dec 2020 20:51:20 +0100 (CET) From: Jonas Bernoulli To: bug-gnu-emacs@gnu.org Subject: Additional libraries required by transient and magit manuals X-Debbugs-Cc: Stefan Monnier Date: Fri, 25 Dec 2020 20:51:20 +0100 Message-ID: <87r1nd8y13.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I wrote magit's info manual using an org file before org-mode itself switched the input format of its own manual from texinfo to org. At the time it was necessary to improve upon "ox-texinfo.el" to make it suitable for a large manual. While that may not be the cases anymore, I have kept using my extended exporter implemented in "ox-texinfo+.el" and would like to keep doing so. I am guessing that [non]gnu elpa currently use the version of org that comes with Emacs. It would be nice if we could also use the libraries in org's "contrib/lisp/" directory. Transient's manual needs "ox-extra.el" library from that directory. Magit's additionally needs "org-man.el". "ox-texinfo+.el" is not part of org's "contrib/lisp/" directory and would have to be added separately to the machines that build the gnu and nongnu and elpas. I would need it for the following three features: ;; 1. Create `@deffn' and similar definition items by writing list ;; items in Org that look similar to what they will look like in ;; Info. To enable this, add: ;; ;; #+TEXINFO_DEFFN: t ;; ;; to your Org file. After doing that, you can create definition ;; items like so: ;; ;; - Command: magit-section-show ;; ;; Show the body of the current section. ;; ;; - Function: magit-git-exit-code &rest args ;; - Macro: magit-insert-section &rest args ;; - Variable: magit-display-buffer-noselect ;; - User Option: magit-display-buffer-function ;; - Key: q, magit-mode-bury-buffer ;; 2. Optionally share a section's node with some or all of its child ;; sections. By default every section on every level gets its own ;; node, and `ox-texinfo' provides no mechanism for changing that. ;; To place a section in the same node as its parent section, do ;; this: ;; ;; **** Log Performance ;; :PROPERTIES: ;; :NONODE: t ;; :END: ;; 3. Optionally modify the Org file before exporting it. This is ;; implemented using a hook that can be set using the `BIND' ;; property: ;; ;; #+BIND: ox-texinfo+-before-export-hook some-function ;; #+BIND: ox-texinfo+-before-export-hook another-function ;; ;; The function `ox-texinfo+-update-version-strings' is provided ;; as an example. It makes some assumptions that might not be ;; appropriate for your manuals, so you might have to define your ;; own variant. (The third feature can also be invoked using a make target and this needs some love to work properly with "elpa-admin.el", but that's a detail.) You can use git or a browser to get "ox-texinfo+.el" from https://github.com/tarsius/ox-texinfo-plus. Please consider making "org/contrib/lisp/" and "ox-texinfo+.el" available to the elpas. Jonas From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 26 16:02:55 2020 Received: (at 45435) by debbugs.gnu.org; 26 Dec 2020 21:02:55 +0000 Received: from localhost ([127.0.0.1]:59998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktGiF-0003fo-8u for submit@debbugs.gnu.org; Sat, 26 Dec 2020 16:02:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktGiD-0003fF-Md for 45435@debbugs.gnu.org; Sat, 26 Dec 2020 16:02:54 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 11518809A7; Sat, 26 Dec 2020 16:02:48 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 51B648066B; Sat, 26 Dec 2020 16:02:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1609016566; bh=6MIeMsE14FGJJprS6Y0FfkflDK1HzC8SGyrHS4eTiUY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=abRGnJJMTa9nb3jlBEgPuS486fDCOUN/UmuWITrEcdESicKgloG+0uojlsqlSQ7Qd 3edAJOQ+VA5UO9V3g75siMa58bpPSEIulUQQbiM0kfgtUqwCreAUFm606gO4t95hvq 9Lqf9INxeXBn6c1ovPI6FgqB6eNUiA2FsC06lbaH4EyQ0bwVk26ZzBr/x+KW8tjCFo IAtD3vzmxkQhuFzITu2p8nXIMkfmn1plQc55XbKabRVfssUz8eYrMTn/Ze10k+/pN/ ak0dw8iRmniG0IvJJQ6DC0fjdrICdx+lg5QoIKGvu861JrR1ZhxgOY41PkeCT6l4Sm FIo9N0bV48VRA== Received: from alfajor (unknown [104.247.243.191]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C9B8F12014D; Sat, 26 Dec 2020 16:02:45 -0500 (EST) From: Stefan Monnier To: Jonas Bernoulli Subject: Re: bug#45435: Additional libraries required by transient and magit manuals Message-ID: References: <87r1nd8y13.fsf@bernoul.li> Date: Sat, 26 Dec 2020 16:02:44 -0500 In-Reply-To: <87r1nd8y13.fsf@bernoul.li> (Jonas Bernoulli's message of "Fri, 25 Dec 2020 20:51:20 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.135 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45435 Cc: 45435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I am guessing that [non]gnu elpa currently use the version of org that > comes with Emacs. Indeed, more specifically with the Emacs distributed in Debian stable, i.e. Emacs-26 currently. > Please consider making "org/contrib/lisp/" and "ox-texinfo+.el" > available to the elpas. IIUC Bastien is working on (or planning to soon work on) adding org-contrib to NonGNU ELPA. As for `ox-texinfo+.el` (or any other package you fancy), feel free to add them to `elpa.git` or `nongnu.git` (depending on their copyright paperwork status, mostly). But the main point you raise is the use of extra packages when building (Non)GNU ELPA packages, such as for the needs of building the Info manual. There are mostly two issues: 1- The philosophical issue of relying on packages which we don't distribute. I think we should try and only use ELisp packages which we distribute, either as part of Emacs or GNU ELPA or NonGNU ELPA. But this should be easy to fix: just add the package to (Non)GNU ELPA. 2- Making use of those extra packages while building your own (Non)GNU ELPA package. This is a technical issue and I'm not completely sure how best to solve it. I think point 2 is the only relevant problem here, so I suggest we focus on this in the bug#45435. Currently, when building a GNU ELPA package, the `:make` rule has read access to the whole of `elpa.git`, and similarly while building a NonGNU ELPA package, the `:make` rule has read access to the whole of `nongnu.git`. There are several problem, tho: 1- GNU ELPA Packages aren't readable while building NonGNU ELPA packages, and vice-versa. 2- While there is read access to the source code of other packages, these aren't "prepared" to be activated (as by `package-activate-all`), e.g. their [PKG]-pkg.el and more importantly [PKG]-autoloads.el files haven't been built (and they haven't been byte-compiled either). 3- Of course, the code available is (usually) that of the head of their respective branch, which may be in a temporarily broken state. So maybe rather than look for the solution by re-using the code we already have lying around, we should "manually" add the handful of extra packages to the builder's `~/.emacs.d/elpa` ? The downside would be that it requires a manual step from someone with access to `elpa.gnu.org`. Or maybe we could keep the contents of that `~/.emacs.d/elpa` in a separate branch/directory and just make it available to `:make` targets, so anyone with write access to the Git repository can add (installed) packages in there. Hmm... Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 27 07:50:01 2020 Received: (at 45435) by debbugs.gnu.org; 27 Dec 2020 12:50:01 +0000 Received: from localhost ([127.0.0.1]:60410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktVUn-0005vZ-34 for submit@debbugs.gnu.org; Sun, 27 Dec 2020 07:50:01 -0500 Received: from mail.hostpark.net ([212.243.197.30]:35874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktVUj-0005vP-Um for 45435@debbugs.gnu.org; Sun, 27 Dec 2020 07:49:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 3202BB7A6F; Sun, 27 Dec 2020 13:49:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1609073396; bh=5vjfzzsg0JByueG6md7pfHqR WqdkUZA9wbwrDuPlF7U=; b=gXtMEYflXAymHR7h8ceXqc/dpNFh8XU4hUJo17Be BFz/xqD/IPT2lG1ZhdXPyiSKw9qRek92nTNkJcuj3OxbXwBqSJnmkxhJE9fP38Zf VcSLZ4v3ZOxZFwlmdY2ztv+2g2XzpcKrPOAczbktKPmfOAOYZ0ToK3zW0YW8QTMG 0gI= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id HfM_nvGpVhzT; Sun, 27 Dec 2020 13:49:56 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id F3159B7A6E; Sun, 27 Dec 2020 13:49:55 +0100 (CET) From: Jonas Bernoulli To: Stefan Monnier Subject: Re: bug#45435: Additional libraries required by transient and magit manuals In-Reply-To: References: <87r1nd8y13.fsf@bernoul.li> Date: Sun, 27 Dec 2020 13:49:55 +0100 Message-ID: <87o8if8lcc.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45435 Cc: 45435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier writes: > So maybe rather than look for the solution by re-using the code we > already have lying around, we should "manually" add the handful of extra > packages to the builder's `~/.emacs.d/elpa` ? > The downside would be that it requires a manual step from someone with > access to `elpa.gnu.org`. That's what I had in mind and if it were you who kept that up-to-date, as opposed to some fsf admin, then that could work. > Or maybe we could keep the contents of that > `~/.emacs.d/elpa` in a separate branch/directory and just make it > available to `:make` targets, so anyone with write access to the Git > repository can add (installed) packages in there. That is probably the better approach. Would you want check a copy of these libraries into the "main" branch? We do that for "package-build.el" in the Melpa repository like so: pull-package-build: git subtree pull --squash -P package-build package-build master I am not really a fan of that approach but it has the benefit that it is robust. Alternatively you could generalize the code that makes "elpa-admin.el" available. "./admin" could then serve a similar purpose as "./package", i.e. "./admin/elpa-admin" would become the worktree that checks out the "elpa-admin" branch. Maybe that branch should be renamed to "admin/elpa-admin" and other admin tools could use "admin/" as well. Gnu elpa would end up with two identical branches for "ox-texinfo+": "externals/ox-texinfo+" and "admin/ox-texinfo+", nongnu elpa however would only feature the latter. Jonas From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 27 10:58:31 2020 Received: (at 45435) by debbugs.gnu.org; 27 Dec 2020 15:58:31 +0000 Received: from localhost ([127.0.0.1]:33274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktYRC-0004aN-W4 for submit@debbugs.gnu.org; Sun, 27 Dec 2020 10:58:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktYRA-0004a9-R6 for 45435@debbugs.gnu.org; Sun, 27 Dec 2020 10:58:29 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C935410023D; Sun, 27 Dec 2020 10:58:22 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9B3AA100222; Sun, 27 Dec 2020 10:58:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1609084696; bh=iGeZx9wr5+jfCV38QUknOKLH4CycVJe4txZvwtT6Qq0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=G3BY4ps/Z9cMiWFkdiFFcUR19hbJ6IdK8pvjHzV2HfGCF/BFgOdCKqFE+RC7rN5su HHx/RdUkcA3tOGUlOHyMIjBDEVQNqTY/lp9hrkYsb5L9x5K6J1WpEaSnNPVWQSxImG dY6nj8VZ33BQJqzzwIUf8Se6QrsxShzubjsNQnWB/hnjFYGQwOlY6SDcI56oL/EYy2 cU7Udh2V5QpBISVkEakzzC2dTJTAS5R2rqKZmiTqIA2nOKFcmuD6mvy8inInbXXrxZ KKs4eYusyqu+HmeP6xnnEKTe7MPk0VBT+5OmseceTpCoFdJwBim7GVl+XhZeGFequr gIBp1Rq6+mYjg== Received: from alfajor (unknown [104.247.243.191]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 662071201CC; Sun, 27 Dec 2020 10:58:16 -0500 (EST) From: Stefan Monnier To: Jonas Bernoulli Subject: Re: bug#45435: Additional libraries required by transient and magit manuals Message-ID: References: <87r1nd8y13.fsf@bernoul.li> <87o8if8lcc.fsf@bernoul.li> Date: Sun, 27 Dec 2020 10:58:15 -0500 In-Reply-To: <87o8if8lcc.fsf@bernoul.li> (Jonas Bernoulli's message of "Sun, 27 Dec 2020 13:49:55 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.109 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45435 Cc: 45435@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> So maybe rather than look for the solution by re-using the code we >> already have lying around, we should "manually" add the handful of extra >> packages to the builder's `~/.emacs.d/elpa` ? >> The downside would be that it requires a manual step from someone with >> access to `elpa.gnu.org`. > That's what I had in mind and if it were you who kept that up-to-date, > as opposed to some fsf admin, then that could work. I'd most likely be the one keeping it up-to-date (the fsf admins have better things to do than try and understand what we've setup inside the VM ;-). And yes, that would work but I'd rather not be so "indispensable". Also it'd make it yet harder to approximate on your own machine what happens on `elpa.gnu.org`. >> Or maybe we could keep the contents of that >> `~/.emacs.d/elpa` in a separate branch/directory and just make it >> available to `:make` targets, so anyone with write access to the Git >> repository can add (installed) packages in there. > That is probably the better approach. Yes, the more I think about it, the more I'm convinced that it's obviously superior. > Would you want check a copy of these libraries into the "main" branch? I'm thinking of keeping it in a separate branch that can be shared between `elpa.git` and `nongnu.git`. > Maybe that branch should be renamed to "admin/elpa-admin" and other > admin tools could use "admin/" as well. Gnu elpa would end up > with two identical branches for "ox-texinfo+": "externals/ox-texinfo+" > and "admin/ox-texinfo+", nongnu elpa however would only feature the > latter. I'm rather thinking that the new branch would keep the equivalent of `~/.emacs.d/elpa`, i.e. code that's in an "installed" state, e.g. byte compiled, so not "two identical branches". Stefan