From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Extending emacs convention for first line Date: Thu, 20 Oct 2022 14:06:45 -0400 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="37093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: help-gnu-emacs@gnu.org To: Christopher Dimech Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 20 20:07:28 2022 Return-path: Envelope-to: geh-help-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 1olZwy-0009FA-Tu for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 20:07:25 +0200 Original-Received: from localhost ([::1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olZwo-0001uJ-7H for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 14:07:20 -0400 Original-Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olZwf-0001lA-IT for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 14:07:05 -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 1olZwZ-0001ku-BT for help-gnu-emacs@gnu.org; Thu, 20 Oct 2022 14:06:59 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olZwQ-0001pF-00 for help-gnu-emacs@gnu.org; Thu, 20 Oct 2022 14:06:52 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5D0C8100845; Thu, 20 Oct 2022 14:06:48 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 51D31100117; Thu, 20 Oct 2022 14:06:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1666289206; bh=7ZKjr8n7qS1TA4G/Q8ggKQY07X/7E+4XgHDqqxBvmHs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hEFrIwAZDhpUckdhUmrsJIfb4TEC6XWP1t5pEYY6eSW3IIKWEcsP/kTW48y52NaGR RKROnO38rDaSFbH3MVk5vEV0CR7qMyowwyvCY57e2g85u+Z5hDWgGEIT1ieWLO3qGu n/TyGVQcroMv0uBacM8o2XdomtiMkez7RBR6dHIZ8XpRd+KBfqGExxCX0s3qu8ceNl YzEDie2UxSJmcKmNU69boAhV/3vGDecO06B1xofdXdTd8WgK2wXH3ukvtRL4cIESmg UZ9VCnvq7a8XJS85BI2wjCxsYgQdSWVPHzXWUS3qr2TmXlZUI18q1FrtpXU/YrjNcO ULh+L3h9Dg2fA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 420C4120FB3; Thu, 20 Oct 2022 14:06:46 -0400 (EDT) In-Reply-To: (Christopher Dimech's message of "Thu, 20 Oct 2022 19:11:32 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:140204 Archived-At: >> I don't have a strong opinion on this, but I'll note that I hope we can >> get rid of the `-*- lexical-binding: t -*-` cookie in the not too >> distant future. >> >> I think we're slowly working our way up to the point where we can change >> the default to t such that the cookie will be needed only (in the form >> `-*- lexical-binding: nil -*-`) for those files still using the old >> dynbound dialect of ELisp. >> > The suggestion is more focused on allowing descriptions longer > than a single line. And which would avoid us long lines. My note above was only tangentially related to your suggestion, indeed. W.r.t the length of the description, the limited length is (up to a point) a *feature*, since that description can appear in various other places (e.g. the https://elpa.gnu.org/packages/ web page) where an overly long description would be inconvenient. So, I definitely don't want to allow multi-line descriptions here. There's already the `Commentary:` section for a longer description. So I only see two cases where the current convention is problematic: - when the -*- lexical-binding: t -*- cookie pushes the line length beyond 80 columns. - when the filename is itself so long that even with a short description the line length beyond 80 columns. As I mention in my remark, I hope the first problem is transitory (tho it'll still be with us for a few more years). Stefan PS: for some packages, the `Commentary:` can be too long for some uses, e.g. release announcements for GNU ELPA packages don't include the commentary. So maybe we could introduce a new convention for a "short multi-line description" (something like 4-5 lines, we could call it "Summary" or "Abstract", maybe), in addition to the short single-line description. It could be used in release announcements, or appear in https://elpa.gnu.org/packages/ when you hover over a package description (or appear when you click something to "unfold" the description, maybe?).