From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.bugs Subject: bug#65027: 30.0.50; [PATCH] Document .elpaignore behavior in the Emacs Lisp manual Date: Fri, 4 Aug 2023 21:36:45 -0500 Message-ID: References: <761581a0-fa77-e89c-01e8-d0baeae838f5@gmail.com> <83cz04xzvk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13480"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , philipk@posteo.net, 65027@debbugs.gnu.org, eliz@gnu.org, monnier@iro.umontreal.ca To: rms@gnu.org, info@protesilaos.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 05 04:38:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qS7BM-0003K6-IF for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Aug 2023 04:38:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qS7B9-0002ap-Lp; Fri, 04 Aug 2023 22:38:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qS7B6-0002aW-53 for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 22:38:05 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qS7B4-0000It-O1 for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 22:38:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qS7B4-0000el-JN for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 22:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Corwin Brust Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Aug 2023 02:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65027 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65027-submit@debbugs.gnu.org id=B65027.16912030242436 (code B ref 65027); Sat, 05 Aug 2023 02:38:02 +0000 Original-Received: (at 65027) by debbugs.gnu.org; 5 Aug 2023 02:37:04 +0000 Original-Received: from localhost ([127.0.0.1]:55124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qS7A7-0000dD-K5 for submit@debbugs.gnu.org; Fri, 04 Aug 2023 22:37:03 -0400 Original-Received: from mail-oi1-f172.google.com ([209.85.167.172]:45484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qS7A6-0000cg-8F for 65027@debbugs.gnu.org; Fri, 04 Aug 2023 22:37:02 -0400 Original-Received: by mail-oi1-f172.google.com with SMTP id 5614622812f47-3a6f87b2993so2092159b6e.3 for <65027@debbugs.gnu.org>; Fri, 04 Aug 2023 19:37:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691203016; x=1691807816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oPFF7Ksw83+X3m7a5+jwTmtcofe2xTKBvMAXpzAvPBI=; b=PsZ8VN+U0OjLg4U0b/eoIrtGZdOPMK8RiaD7FM+aMLRfvvlmAr9IkJwGrUmGEc7+e+ 6WLOg3N5K5LDwm0gLSUVX69vu4gjXntIjhFrkW30hu3A48+RTNSjtOxocP6Lc/Ksed7J iGazBPaFPoaM5hB80qOPklfHlPHg3HYVRGyf0jlms5Yep00y9nBcjhGTP2EtkMqzfddu 8iIxKLptwOpDZfq0YtzKCQ1f7Tkwm0ABQjSQJTIE2D9tt0ASWiLgfanvBXOXb0eR3rV/ ts4QVKbqkxGNhv7xRhJOm9VIika520NX4l2+EdxUeX+FqXrgWF9SAJIrbYEiONsIyB2C Z+UA== X-Gm-Message-State: AOJu0Yy41dn4tHAT0SDOfDcqf7b6lv4HviX3gt0eUqpNfn/TRJk+cNfW IeUn7+nn9acmXzDMn6wMoCDXign8qRZEW8cn8Lg= X-Google-Smtp-Source: AGHT+IGKq7ZCJ6+3IsZmomWA4v3wiDXSeOfqAaWVdCejChY1qkjocRTeLQ6A3gHjG/Ff50FVW79aohJ8s4p6a4GZh4c= X-Received: by 2002:a54:4886:0:b0:3a7:238a:143e with SMTP id r6-20020a544886000000b003a7238a143emr3868074oic.2.1691203016390; Fri, 04 Aug 2023 19:36:56 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266721 Archived-At: On Fri, Aug 4, 2023 at 8:58=E2=80=AFPM Richard Stallman wrote= : > > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > Yeah, something more general that I've noticed is that as a package > > author, the documentation for how to make a package for GNU ELPA is > > split between the GNU ELPA README and the Emacs Lisp manual. > > It could be an improvement to merge all that documentation into one > text and rewrite it for coherence and clarity. I have been discussing a similar ideal with some others off list, of whom I'm tagging in (potentially sharing blame with ;) only prot. > That has a drawback: it would make the Emacs Lisp Reference Manual > substantially bigger. Copies would be less convenient and more > expensive. > > I think there is no need for this material to be in the Emacs Lisp > Reference Manual. So I suggest making a separate short manual about > adding a package to GNU ELPA. The Emacs Lisp Reference Manual can > direct people to it. My/our suggestion is to create a new manual ("ELPA: the missing manual") that should be provided with Emacs releases, with the current version available online via gnu.org. This new manual can start with some new (and/or moved, consolidated, expanded, ...) sections aimed at Emacs users wanting a deeper understanding of Emacs packaging. Following that, it can include some specifics ("best practices"?) especially for package authors, with the remainder being collected manuals for ELPA packages. A slight twist on this idea could be to frame more generally, for example "Emacs Features and Packaging" (instead of anything about ELPA). This might allow In any event, if this seems worth discussing further, I think work could begin with agreeing on the specific (and probably rather narrow) scope. I think we need, for example, to describe the criteria used to decide what goes into the proposed addition manual. We might also want to create a "rubric" (simple rule, or very simple flow chart) that helps us understand when a feature's documentation will be in the Emacs manual, the elisp manual, or this new manual, and so on, until the task beings to look ominously do-able or all volunteers are scared off >:) Prot, am I right that you (still, also) have energy for something like this? Other thoughts as you consider in the context of this thread?