From: Christopher Dimech <dimech@gmx.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Extending emacs convention for first line
Date: Thu, 20 Oct 2022 22:11:02 +0200 [thread overview]
Message-ID: <trinity-e210bf1d-e7e7-4581-bbb2-1a6bfaf70896-1666296662107@3c-app-mailcom-bs08> (raw)
In-Reply-To: <jwvv8oe9ya0.fsf-monnier+emacs@gnu.org>
> Sent: Friday, October 21, 2022 at 6:06 AM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Extending emacs convention for first line
>
> >> 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?).
I do not see it would be necessary. What can be done is take first paragraph
in the commentary. And leave the single line brief intact.
next prev parent reply other threads:[~2022-10-20 20:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 19:40 Extending emacs convention for first line Christopher Dimech
2022-10-18 1:33 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-10-18 1:53 ` Emanuel Berg
2022-10-20 17:11 ` Christopher Dimech
2022-10-20 18:06 ` Stefan Monnier
2022-10-20 20:11 ` Christopher Dimech [this message]
2022-10-20 22:57 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-10-21 17:34 ` Christopher Dimech
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=trinity-e210bf1d-e7e7-4581-bbb2-1a6bfaf70896-1666296662107@3c-app-mailcom-bs08 \
--to=dimech@gmx.com \
--cc=help-gnu-emacs@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.
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).