bug#47775: First line length and GNU coding standards....

[Marco Antoniotti <marco.antoniotti@unimib.it>]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

Hi

thanks for your responses.

Mine is "code in the wild"... and it uses conventions that predate the
"suggestions" made in more recent versions of the Emacs documentation.

Bottom line, the GNU coding standards requiring - rightly so - 80 columns,
conflict with the requirements on the first line.
Put simply, you cannot have the

;;; foo.el -- This file is a baz with a long description, even if this
example is not

With the requirement of having buffer local variables (forget about
lexical-binding!) in the first line.

One of the two has to yield.  Given "older" conventions and "code in the
wild", the first line (or lines!!!) should be reserved for buffer local
variables (and even the Mode: Emacs-Lisp declaration).  The "file content"
documentation can come afterward.

This is just a convention (*,**) in the Emacs documentation, and possibly
only one package (AFAIK, checkdoc) will be affected.

All the best

Marco

(*) Well, the buffer local variables and the Mode: declaration could appear
in the first lines, as I recall, if my memory does not fail me.
(**) Since we are at it, old Lisp geezers like me use ;;;;, ;;; at the top
level, and ;; and ; for "in code" comments; where the ;;; and ;;
conventions for Emacs-Lisp came from, who knows.





On Mon, Apr 19, 2021 at 2:18 PM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> On 18/04/2021 11:59 -0500, Stefan Kangas wrote:
>
> > Marco Antoniotti <marco.antoniotti@unimib.it> writes:
> >
> >> Bottom line, this is just a bit of a rant, but I really like my (and,
> >> I believe, many other old geezers') style of having something like
> >>
> >> ;;; -*- Mode: Emacs-Lisp; lexical-binding: t;
> some-var-with-a-long-name: t -*-
> >> ;;; foo.el --- The foo pkg, which also happens to have description 79
> col long.
> >
> > Within N years, we will hopefully flip the switch and enable
> > lexical-binding by default, thereby (mostly) eliminating the problem.
> > So I would propose living with this wart.  Just my two cents.
>
> Will that be really possible?  What about code in the wild?
>


-- 
Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
http://cdac2021.lakecomoschool.org
I-20126 Milan (MI) ITALY

[-- Attachment #2: Type: text/html, Size: 7742 bytes --]