From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marco Antoniotti Newsgroups: gmane.emacs.bugs Subject: bug#47775: First line length and GNU coding standards.... Date: Mon, 19 Apr 2021 14:32:57 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000543ddb05c05288ea" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31857"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , 47775@debbugs.gnu.org To: Filipp Gunbin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 19 14:35:28 2021 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 1lYT7g-00087z-5b for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 14:35:28 +0200 Original-Received: from localhost ([::1]:35990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYT7f-0008Gi-5b for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 08:35:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYT6I-00072Q-VP for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37116) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYT6I-0004Ai-Nb for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYT6I-0003to-Ko for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Marco Antoniotti Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Apr 2021 12:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47775 X-GNU-PR-Package: emacs Original-Received: via spool by 47775-submit@debbugs.gnu.org id=B47775.161883560514896 (code B ref 47775); Mon, 19 Apr 2021 12:34:02 +0000 Original-Received: (at 47775) by debbugs.gnu.org; 19 Apr 2021 12:33:25 +0000 Original-Received: from localhost ([127.0.0.1]:48655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYT5d-0003s8-JT for submit@debbugs.gnu.org; Mon, 19 Apr 2021 08:33:25 -0400 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:51102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYT5Y-0003rt-P6 for 47775@debbugs.gnu.org; Mon, 19 Apr 2021 08:33:20 -0400 Original-Received: by mail-pj1-f45.google.com with SMTP id u11so14191224pjr.0 for <47775@debbugs.gnu.org>; Mon, 19 Apr 2021 05:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unimib.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f5S1sGzh5IBVixWj1GPJyUBa0zRELj24m8oD2np70SY=; b=RA72DucoK3WXbzwSz+s/wqHmhrlYfxTcD7LuKYN8fSR3YLoybLjDov7B9JkLTBBrn0 iFTMkINlF18QtraxMHyzZM1UdAdjIfjJ3rKWEoCk5YXby/dUlN8oxBJhifDR07UXD3AT i3CNcSHsjgli898/PVMAn/prJZGRW4WCDWKsMkubPS0PrzArZdFSJdMctpd4pqMcVbCa r9J13Z6YH69teFClDbAta/wFFgOLCBkyPP5O4rrZ81gKPs6PJOWfTSmr89+U61qO5u4D TXYzECdfGL4jS6qLS+0CVMbxIL/kHSlirJVy0e5TRvwlP0wdUDuBm62sIQ3FBDpvXbtt /Zrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f5S1sGzh5IBVixWj1GPJyUBa0zRELj24m8oD2np70SY=; b=ZmvpRLjA3x8mz6iKk71aWnErpIT3NgSYRRuYPQ+ZepqlazMcSbsZyeS6al1nUE74p2 ATQhLZSWK4NDih8oblS5FkDAuZc2Zq98aIhgxviOiXyj2Tc98nUKS90qij8M/6m/Y3iq WMQuwzrj0KVwCi6yqe41+HX947ckiOXFnvqkH+kVSEXtM7CkGme510Kfpm7o6nBFGUwH JQ8XHPZOc3TBOtiwAgQdYvU3qMOeViEL2o3eCG/YgjpLajYEZn3Z4iCJxSCJjFbtlYzU JZ76GVWvTpsX0SJyp0IfA0T803Ta4bd1lPItZk7xptyxEw2rqof5d75DwiokZl7bLiDz Gxxg== X-Gm-Message-State: AOAM532VrEzejVrfCP1nR9fCAFt/AIMbTZjAK/CN68+G+r/jGY3KzxID mh+uMLwPtqv8MzKsMe6g2UrDAQBHay5pAPDONs0Oig== X-Google-Smtp-Source: ABdhPJxEJzKum+ofi8kumOon8Ozq8ZQYd4GLrfobghVRwQlLVurT7yodNXSdOX1k2BCzuo3fctjD7encB15l/h7+jQw= X-Received: by 2002:a17:902:be10:b029:e9:78a0:dd33 with SMTP id r16-20020a170902be10b02900e978a0dd33mr22573773pls.1.1618835590621; Mon, 19 Apr 2021 05:33:10 -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" Xref: news.gmane.io gmane.emacs.bugs:204431 Archived-At: --000000000000543ddb05c05288ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On 18/04/2021 11:59 -0500, Stefan Kangas wrote: > > > Marco Antoniotti 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? > --=20 Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Universit=C3=A0 Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 http://cdac2021.lakecomoschool.org I-20126 Milan (MI) ITALY --000000000000543ddb05c05288ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

thanks for your responses= .

Mine is "code in the wild"... and it uses con= ventions that predate the "suggestions" made in more recent versi= ons of the Emacs documentation.

Bottom line, the GNU codi= ng standards requiring - rightly so - 80 columns, conflict with the require= ments on the first line.
Put simply, you cannot have the

<= /div>
;;; 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 (forg= et about lexical-binding!) in = the first line.

One of the two has to yield.=C2=A0 Given = "older" conventions and "code in the wild", the first l= ine (or lines!!!) should be reserved for buffer local variables (and even t= he Mode: Emacs-Lisp declaratio= n).=C2=A0 The "file content" documentation can come afterward.

This is just a convention (*,**) in the Emacs docume= ntation, and possibly only one package (AFAIK, checkdoc) will be affected.<= /div>

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 Em= acs-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, Stefa= n Kangas wrote:

> Marco Antoniotti <marco.antoniotti@unimib.it> writes:
>
>> Bottom line, this is just a bit of a rant, but I really like my (a= nd,
>> 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.<= br> > So I would propose living with this wart.=C2=A0 Just my two cents.

Will that be really possible?=C2=A0 What about code in the wild?


--
Ma= rco Antoniotti, Associate Professor=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 tel.=C2=A0+39 - 02 64 48 79 01DISCo, Universit=C3=A0 Mil= ano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 http://cdac2021.lakecomoschool.orgI-20126 Milan (MI) ITALY<= /span>
--000000000000543ddb05c05288ea--