Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 76868) by debbugs.gnu.org; 10 Mar 2025 00:35:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 20:35:10 2025 Received: from localhost ([127.0.0.1]:35091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1trR6r-0001hy-LP for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 20:35:09 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55177) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <haj@HIDDEN>) id 1trR6p-0001fJ-NC for 76868 <at> debbugs.gnu.org; Sun, 09 Mar 2025 20:35:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 499BE240028 for <76868 <at> debbugs.gnu.org>; Mon, 10 Mar 2025 01:35:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1741566900; bh=BY/3xMfxUzk9y7K6oUxm+jtkdkIvvY0/48LcRG0WrQ4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=mkWe/10LotNJfkv1v1kNaft8it3KnVKQNS0VpP0FJjdcq/VZG1/BUV5Jw3c9/4q8T 7mfetm+6f0PqFJX0yIQAV6GdcKXcxGyj3yjkS0LhZ6JT0P+PbScXHCPrwtGN/QYGKQ fBBOoWNG9Gotq5EXFiuSJckP3oeg6uJhwpJvKPzwcjlvrtoYgIvBtcQF+hh02O5rnn nPtp4I+hi1rex+BeSVtL6uA2FQovMpC3U34+mwfkBImcvwBtapXo00k+8bZwuz26IG zAkks2+G9Wd5wgVVIv8NSuII6WSycc+X7rKYpANuAi5eYSR9F+Kz/z+4jqYawSwZNy jBC0YmvTRUbOA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z9yb74lYLz6trs; Mon, 10 Mar 2025 01:34:59 +0100 (CET) From: =?utf-8?Q?Harald_J=C3=B6rg?= <haj@HIDDEN> To: John Ciolfi <ciolfi@HIDDEN> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled In-Reply-To: <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN> (John Ciolfi's message of "Sun, 9 Mar 2025 16:41:00 +0000") References: <r9ldtfh6yr.fsf@HIDDEN> <6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN> <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN> <87o6yafdyy.fsf@HIDDEN> <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN> Date: Mon, 10 Mar 2025 00:34:59 +0000 Message-ID: <87r035en9o.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76868 Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>, "John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, Mauro Aranda <maurooaranda@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) John Ciolfi <ciolfi@HIDDEN> writes: > Thanks for the detailed response. I learned something new. To me it > seems that perl isn't supplying enough information for cperl-mode to > get the trailers correct. Ideally, we could definitively tell the type > of content below the __END__ or __DATA__ keywords. I suppose one > could set file local variables to configure > cperl-fontify-trailer. However, one needs to know about this option. I > wonder if there's a way to make the option more obvious? File local variables work but need caution. Several tools might compete with content for the first line, and a local variables list "near the end of the file" might come unexpected to a program reading from the DATA file handle. Often it is "less intrusive" to use a .dir-locals.el file. > A small suggestion is to update the help text or cperl-fontify-trailer > to indicate it also changes the indent behavior. I think the name > cperl-trailer-type is a good name too, though updating the help text > may be sufficient. Improving the docstring by including the behavior of indentation is indeed a good idea! I'll do that for the master branch. -- Cheers, haj
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 10 Mar 2025 00:35:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 20:35:24 2025 Received: from localhost ([127.0.0.1]:35097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1trR76-0001m9-1h for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 20:35:24 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36314) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <haj@HIDDEN>) id 1trR73-0001g8-P5 for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 20:35:22 -0400 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 <haj@HIDDEN>) id 1trR6n-0005fj-GT for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 20:35:05 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <haj@HIDDEN>) id 1trR6l-0004bR-Gr for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 20:35:05 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 58F16240101 for <bug-gnu-emacs@HIDDEN>; Mon, 10 Mar 2025 01:35:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1741566900; bh=BY/3xMfxUzk9y7K6oUxm+jtkdkIvvY0/48LcRG0WrQ4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=mkWe/10LotNJfkv1v1kNaft8it3KnVKQNS0VpP0FJjdcq/VZG1/BUV5Jw3c9/4q8T 7mfetm+6f0PqFJX0yIQAV6GdcKXcxGyj3yjkS0LhZ6JT0P+PbScXHCPrwtGN/QYGKQ fBBOoWNG9Gotq5EXFiuSJckP3oeg6uJhwpJvKPzwcjlvrtoYgIvBtcQF+hh02O5rnn nPtp4I+hi1rex+BeSVtL6uA2FQovMpC3U34+mwfkBImcvwBtapXo00k+8bZwuz26IG zAkks2+G9Wd5wgVVIv8NSuII6WSycc+X7rKYpANuAi5eYSR9F+Kz/z+4jqYawSwZNy jBC0YmvTRUbOA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z9yb74lYLz6trs; Mon, 10 Mar 2025 01:34:59 +0100 (CET) From: =?utf-8?Q?Harald_J=C3=B6rg?= <haj@HIDDEN> To: John Ciolfi <ciolfi@HIDDEN> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled In-Reply-To: <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN> (John Ciolfi's message of "Sun, 9 Mar 2025 16:41:00 +0000") References: <r9ldtfh6yr.fsf@HIDDEN> <6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN> <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN> <87o6yafdyy.fsf@HIDDEN> <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN> Date: Mon, 10 Mar 2025 00:34:59 +0000 Message-ID: <87r035en9o.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=haj@HIDDEN; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>, "John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, Mauro Aranda <maurooaranda@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) John Ciolfi <ciolfi@HIDDEN> writes: > Thanks for the detailed response. I learned something new. To me it > seems that perl isn't supplying enough information for cperl-mode to > get the trailers correct. Ideally, we could definitively tell the type > of content below the __END__ or __DATA__ keywords. I suppose one > could set file local variables to configure > cperl-fontify-trailer. However, one needs to know about this option. I > wonder if there's a way to make the option more obvious? File local variables work but need caution. Several tools might compete with content for the first line, and a local variables list "near the end of the file" might come unexpected to a program reading from the DATA file handle. Often it is "less intrusive" to use a .dir-locals.el file. > A small suggestion is to update the help text or cperl-fontify-trailer > to indicate it also changes the indent behavior. I think the name > cperl-trailer-type is a good name too, though updating the help text > may be sufficient. Improving the docstring by including the behavior of indentation is indeed a good idea! I'll do that for the master branch. -- Cheers, haj
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at 76868) by debbugs.gnu.org; 9 Mar 2025 16:41:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 12:41:11 2025
Received: from localhost ([127.0.0.1]:34072 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trJiA-0007Ck-CN
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 12:41:11 -0400
Received: from us-smtp-delivery-120.mimecast.com ([170.10.129.120]:31003)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ciolfi@HIDDEN>) id 1trJi6-0007CY-KH
for 76868 <at> debbugs.gnu.org; Sun, 09 Mar 2025 12:41:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com;
s=mimecast20180117; t=1741538466;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=FAZBSiKUR1sUEVaeivHKuak4IE9CnezhprOWrsENgxI=;
b=IFioER3wx/aKNpHOjRdiMbefQMQFlSs+VwS3dDWM8o1th1pGFi4QL1ifPVrp+gNDSCOu81
JhQz3PaS/+558k4LJxKjK91Ta2ANJ8d56GZQCj7EcI8nPY/vr0b8tMbSE1FPq6Xfcju4Yi
7pfvu3dBGKj0fYS4KVOzhm0Ipgktmaw=
Received: from CY7PR03CU001.outbound.protection.outlook.com
(mail-westcentralusazlp17012034.outbound.protection.outlook.com
[40.93.6.34]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-533-Vssi0-DhOtSu_1FsEqMmNA-1; Sun, 09 Mar 2025 12:41:03 -0400
X-MC-Unique: Vssi0-DhOtSu_1FsEqMmNA-1
X-Mimecast-MFC-AGG-ID: Vssi0-DhOtSu_1FsEqMmNA_1741538462
Received: from MN2PR05MB6766.namprd05.prod.outlook.com (2603:10b6:208:185::15)
by BL3PR05MB9041.namprd05.prod.outlook.com (2603:10b6:208:3b0::14)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.26; Sun, 9 Mar
2025 16:41:01 +0000
Received: from MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f]) by MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f%4]) with mapi id 15.20.8511.025; Sun, 9 Mar 2025
16:41:00 +0000
From: John Ciolfi <ciolfi@HIDDEN>
To: =?iso-8859-1?Q?Harald_J=F6rg?= <haj@HIDDEN>, "John Ciolfi via Bug
reports for GNU Emacs, the Swiss army knife of text editors"
<bug-gnu-emacs@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Topic: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Index: AQHbkD+UBow31zELIkS3UJNlkmYXFbNpY1oAgAC0S1CAAM9O/oAAFqaK
Date: Sun, 9 Mar 2025 16:41:00 +0000
Message-ID: <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN>
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
<MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
<87o6yafdyy.fsf@HIDDEN>
In-Reply-To: <87o6yafdyy.fsf@HIDDEN>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR05MB6766:EE_|BL3PR05MB9041:EE_
x-ms-office365-filtering-correlation-id: dd8e9b9f-ef2d-4373-08ce-08dd5f292ce6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
ARA:13230040|366016|1800799024|376014|38070700018|7053199007|8096899003
x-microsoft-antispam-message-info: =?iso-8859-1?Q?fqPzjccip9/Qinh6oZnYVfn0cozfNW9rfe1IQq1fpA5ksrDpr3ohDGK/si?=
=?iso-8859-1?Q?iAtadgRyhG83itpMGpINK491NahZ+vFo01OMgqMT8eaaoYcv8tXzUJS0nc?=
=?iso-8859-1?Q?JLB+4VhkhDntiFBI4vmrOTlo5xkKGl+KWHAUi9wXdMTEjz4WlPhVV7Mnl2?=
=?iso-8859-1?Q?KEYGRyrv0epCAjT0RCpoDkiEOWHlMXmVnrNUApU56/4cqvMVoRioNC67fu?=
=?iso-8859-1?Q?y3VgzsU1eWNDGC0Bt9qJQU3FXFgsMKH4uwd/OryezbFZbdmMKksyhDHT/H?=
=?iso-8859-1?Q?hzL3YMQlGaDzieO4VQZ+AtvIwBou6QU5Eo/37i6hC6klS19lCQQoC6DsHj?=
=?iso-8859-1?Q?VCT2aUaPGDnM1LR/Ku75gh5/kJQxZtz9dQzHIBiJinRTj6z1Vi2Lh8qwvF?=
=?iso-8859-1?Q?BsyZsErHYrMt0Rpemm0dg/SVuYicp87S1206ron/h1KLlZqhfeFUgWvyJL?=
=?iso-8859-1?Q?nspsh2IGayqR1iW7ruOxv/x0AZsvkAPQKxSXxWHmYXEJGCNbPuQVS4EWdg?=
=?iso-8859-1?Q?lxTiMFY0vkPHTtDZnSeTDBCVkrKgqL2WZTi6CJkNJDmAv6i22i5j4Zov2a?=
=?iso-8859-1?Q?+ktXfFtaTWtG/P/4taebVbXlvVyiPxxcYrGCDdwClDvcYtfoo/FmWfSzK9?=
=?iso-8859-1?Q?EBGE2L5malony543u80A9sZ3U0Xx2VCaL8l+nYv6Yx/Mr5yobbRzFtLMTZ?=
=?iso-8859-1?Q?CGLMRh4HFgGEEf8xwVLrJF6sD7q6aMiZFweuJU+2fXtIFSmhlqx5v2kl9O?=
=?iso-8859-1?Q?cVlMNX1GLK1NLXefNLamcySnKQXhuJ1wse03ikSDTicCHDUF51cokh49WV?=
=?iso-8859-1?Q?6hHZD3K1rRkur0EhUT0IBHGwPTZ0EHCCT1I2arr+/yA8ckmRsreFbIcb0W?=
=?iso-8859-1?Q?+xihspu4EWaIIZ3Dw9/Xrt8kUcfnzIw9E1LG+4jv11Ll06UCS+jG8w7pD1?=
=?iso-8859-1?Q?FqHBSUukB0pNuyN/aP8U0O071VlNhH2ZM45GWYPRGkr5NCceSUYej9InQv?=
=?iso-8859-1?Q?IPU3lnCEwEifmBHhuYuWrtRErigx70Ly/biowAEb+0Y5C7zKcgOYUKQHk5?=
=?iso-8859-1?Q?ZEyFfgLndrttVIuVUmTroInPVf0koStyOAr33xh0FlWcvunQJS4hRa171P?=
=?iso-8859-1?Q?+PyBL5nOUDpEGjiJ3d7iGlyKMxR9lLxeKpMe1Ayzi8/FIGbZf+Aux5QpZR?=
=?iso-8859-1?Q?qkFZarMa3gGz3msbJfIBYWaWmJsfsipqG0pcVac4cc5AB3KBiHtrx3KJkW?=
=?iso-8859-1?Q?pD2FavDPKJar+T4w2dnLGicaVyyerg9opJdjAjsfwECqXag6AOVTuKSB3s?=
=?iso-8859-1?Q?fJwVep1GrLdMvAG6S1cacJW3vHwMlErf31q2KMkOlGsADdM/FOcww/Ddlh?=
=?iso-8859-1?Q?DtcJ+cXakCX/2+xthw2w7sYOihXGEJSeHxHsmNaR5dHlxUZaG4lYo2MYWJ?=
=?iso-8859-1?Q?Uwnk29PlHvQ/911Iq1GluDvHufIhSh6P1fnsCA=3D=3D?=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MN2PR05MB6766.namprd05.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230040)(366016)(1800799024)(376014)(38070700018)(7053199007)(8096899003);
DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?40O7N6qeOXtYDR0EyqgDF7MDH0HIXVVWNh0A+ZFJodrtcvnPFM6EYedVBB?=
=?iso-8859-1?Q?rJiUoSGS2Rb8i4F2if1/DxlTX4r1Pjq9YrXz3TIucOYoLh3apgJWa6xXlm?=
=?iso-8859-1?Q?JslNAzmFP3EGBxkStr2Wcd1h4nVTyHhLhgRvZUjE7tdtb8iLuMkqD3F6t6?=
=?iso-8859-1?Q?mMzJzzzXKS3X2v2eryc4LRcTasTpYuZJQkcVtkt//1/cIwxfS4rBCKp8WE?=
=?iso-8859-1?Q?02/yGzAoj0icfNqOafBoHSEa3sm0EvKEW2NTzenpBc903cC8pv/EQJBfOx?=
=?iso-8859-1?Q?LO9irKYePCbIUM8Pvs0udWvOIjBg5eJo2Lqb/HioqmelRGZ4qRLVrT2KVn?=
=?iso-8859-1?Q?VB58UHdjxtCI0re5EOsNTwJ2zWTrhm5GMaeyFf2pz+6GpdGB8QSDkdWTmf?=
=?iso-8859-1?Q?bDxNW8LA6iUJULxbWA0To42tBYlFUVX7CIFyBsxnuAxSWY9IBdYVj+rB5K?=
=?iso-8859-1?Q?3SQXNGAWXhdGwMayajrp2bGGPBW3nPZZ9PLd39D8z1zl/IS2OVdKPiGMgn?=
=?iso-8859-1?Q?/ua8MoLYuScKO8IRloDoS9vB7uyQkhi5IfHtRPUh5S4aawRlq72sBKLCHw?=
=?iso-8859-1?Q?JQYosZBWW8bcb+fOOgdWEeq5dVsCVuCEVcb7cOYtHUwFDtsq0Oc6ConI2S?=
=?iso-8859-1?Q?Xsq2LtlRHOAseqU0cUaGDa2LHpBZ2oSP/m/Mv6UZRRmRtIB2vGcqAi6TbW?=
=?iso-8859-1?Q?InxXTjRItD9q9k+AfVuWvVkUuPQkxQZF1PPn0uGt8gjsFF9tImDgX1lpFz?=
=?iso-8859-1?Q?GrBQoCttIbOn9j99cSbqSzM5cLeQzSTOwXKr213MZCeD85ImUQVjEpKEGH?=
=?iso-8859-1?Q?I9JZsMhjkx64xJ7t4XVuetWmJMKXOG+2FA4xKJ9+XUp+04DkJx6nztyKYK?=
=?iso-8859-1?Q?h4TI+yYQmr0YBns8NMdZoMlglyJHnNgrb20Hv1eHqoALSiq97tfbRGQAMw?=
=?iso-8859-1?Q?bbZtO/HoSJbV78/p1a5MNYZLyaTWCrWHFrSsmIn4SI6V4d3xSr5aysSHW0?=
=?iso-8859-1?Q?UYp3Fbs2iS36YcMY2v4LYPhhIdGtaE4R7lrE1xQvyJ3mz9/PzeTTNlkWxm?=
=?iso-8859-1?Q?qGkQUsdAGz7ch7kmWJlSRmFNaG7mUG0zBNWuAnCuDth8kHRXc/sSOluQ3W?=
=?iso-8859-1?Q?Git95pfU1s3vBCg78HK3maCtRPXFUWfh6Q2RYbb6s7/vI4V4G2Smrh0Dts?=
=?iso-8859-1?Q?PejC7lCwQJ72/PDq9q4XFyxZbdc1hPIespfxb2eO8osVpirppOlM/ipXVV?=
=?iso-8859-1?Q?8oUgitniA4mkHeRaOpv6P6IO98tgqQ7l6H/tWtXefcp+dYsCNn+QUOZ+pj?=
=?iso-8859-1?Q?u/PXmj/xRZtNcRleM2WDjMNMTW+Z9m0E3Em0b4oRLktzvnOZgeRo1C+u5d?=
=?iso-8859-1?Q?wzXmrFeD0zoJuBsEqdeqfO7Cps7cQ5zay+z+nrriebb+jw0T+QznBLpHoE?=
=?iso-8859-1?Q?pGiMZZHqSbPl5m9B/k1J7KM4JKc2nsESfL1JeVhqGlpXFHi99yBkJjalM3?=
=?iso-8859-1?Q?wmLRzprTPr965eT9GxD6MgFZGGriAexsSYUVzD0+9mjvT+dwNUvkj6RNgn?=
=?iso-8859-1?Q?CjUYoItqHlPHmKL6JNsvjU2RqXwT2dUKFQul3A2qQKZlGta9oBDRQ9D46u?=
=?iso-8859-1?Q?+TPaMVhfEWZ8l/+8yWEOLzjG16QvbMcyPa?=
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 1kifgoIhAWTx9eJLFvHrlfhbaL7CiE0pQrbvtnpg/3vUtEOquoA5TusMmua27BIbCuzyE5/KG8zKdAsicgyFHr7WvO2okP/lq1OISJiguwPvbmczRhg5HYHEFtwXmfzLCiIfO7vI0cGqzYxaMJCWCCoC0ZJ5sV0KDP7a4+jRTxAOuxriIruFuiyvf1xTCLMVtRQ044RRhJNVWZUzqip2G5fCBrPz/sO/iFgbO8tRJoU+QsxruLcnYFVTcYczzQgdHW/1oAxTrNkq7GD8FYHkv0xz9L9e5PCAcFAQvs2LPzPgwpqw20AWCvh5x9FqcQqSwzGMkTPqtq7FZPB+MKvuLz0NQKmf2XEsln0pzie79tU6WuUj/owQztXbKZQ9HJnZy6UgYUuJdVLmjtwjiN0AA8B4DL2YuBSpKE3BHFIuKDqZjA5axWgGuErfDT4O80qsAftGLzHf14oQH2OMAKbh0AyBIQaIS5kvhG8WO+txswdPP1QkNiGCltYW2Ih2IHqoM2dSgkhw2s4+iNJ75fXFprUGRfsTT+DILdDpeH6oCruCKs5HpE8NHrLHdsV18X20qtF1JQVIQwdNiqjiGNKO0/wXc55EaGBuDbGA2ish45o=
X-OriginatorOrg: mathworks.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6766.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd8e9b9f-ef2d-4373-08ce-08dd5f292ce6
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2025 16:41:00.7984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99dd3a11-4348-4468-9bdd-e5072b1dc1e6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FheYCH1bTgBQCx2O9xBsXXS9IktUm3UYAC8SDB3ABjy/IKc1Joa7TXXZZy1Emu47UZgCb83Wcgrq6au+Dp5ZiQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR05MB9041
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 6sC3pGfaND8D2QcTjeox4PSG2yVrCxJB0l3CHMSdy2E_1741538462
X-Mimecast-Originator: mathworks.com
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76868
Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>,
Mauro Aranda <maurooaranda@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Thanks for the detailed response. I learned something new. To me it seems t=
hat perl isn't supplying enough information for cperl-mode to get the trail=
ers correct. Ideally, we could definitively tell the type of content below =
the __END__ or __DATA__ keywords. I suppose one could set file local varia=
bles to configure cperl-fontify-trailer. However, one needs to know about t=
his option. I wonder if there's a way to make the option more obvious?
A small suggestion is to update the help text or cperl-fontify-trailer to i=
ndicate it also changes the indent behavior. I think the name cperl-traile=
r-type is a good name too, though updating the help text may be sufficient.
Thanks
John
________________________________
From: Harald J=F6rg <haj@HIDDEN>
Sent: Sunday, March 9, 2025 8:28 PM
To: John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text=
editors <bug-gnu-emacs@HIDDEN>
Cc: Mauro Aranda <maurooaranda@HIDDEN>; 76868 <at> debbugs.gnu.org <76868@deb=
bugs.gnu.org>; John Ciolfi <ciolfi@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line =3D <DATA>) { print $line; }
> close DATA;
> __DATA__
> This is not
> perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.
Indeed, setting the option cperl-fontify-trailer to 'comment' is
supposed to prevent this sort of thing from happening.
> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. ...
I agree that the name of the option is misleading. Maybe we should add
an alias like cperl-trailer-type? The possible values of "perl-code"
and "comment" still work with that name. However, changing the default
is, in my opinion, not the correct way, because there are valid use
cases for the current default behavior.
> ... The Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. ...
That's not the whole truth. Programs which use AutoSplit or SelfLoader
work by intentionally having Perl code after the __END__ or __DATA__
tokens. Both AutoSplit and SelfLoader are part of the Perl core.
https://perldoc.perl.org/AutoSplit<https://perldoc.perl.org/AutoSplit>
https://perldoc.perl.org/SelfLoader<https://perldoc.perl.org/SelfLoader>
> The only case I'm aware of where the lines following these keywords is
> perl is to use the trick to put __END__ to comment out the bottom part
> of a perl program, but even in that case, it should be colored as
> comments.
By far more common is the practice to have POD (Perl's documentation
format) after the __END__ token. This is not read by the Perl
interpreter, but by perldoc and other POD viewers. POD is part of the
Perl language. CPerl mode handles POD for fontification, and supports
POD authoring by imenu indexing of POD headings and by ispell checking
for POD sections.
So, different ways to use the space after the tokens are valid. If you
do not use POD or Perl code after __END__ or __DATA__, setting the
option cperl-fontify-trailer to "comment" does the trick. But the
default value is there for a valid purpose, too. User options are not
supposed to change the behavior of Emacs which would be the case if the
default value is flipped.
If you regularly indent a whole buffer which may contain trailers not
understood by CPerl mode, you can set the variable temporarily:
(defun indent-buffer-without-trailer ()
(interactive)
(let ((cperl-fontify-trailer "comment"))
(cperl-indent-region (point-min) (point-max))))
> Thanks
>
> -------------------------------------------------------------------------=
-----------
> From: Mauro Aranda <maurooaranda@HIDDEN>
> Sent: Saturday, March 8, 2025 10:51 AM
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org
> <76868 <at> debbugs.gnu.org>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>
>> Hi
>>
>> Given the following cperl-mode program, test.pl
>>
>> # -*- mode: cperl; -*-
>> print "hello\n";
>> __END__
>> This is not
>> perl code!
>>
>> The lines after the __END__ are treated as perl code. They are
> syntactically colored and indented
>> which is incorrect. In perl, __END__ defines the end of the Perl code
> in the file. Any text that
>> appears after __END__ is ignored by the Perl compiler.
>>
>> All lines after __END__ should be treated as comments.
>>
>
> Any chance that the option cperl-fontify-trailer helps here?
>
> I remember reporting something similar in:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161<https://debbugs.gnu=
.org/cgi/bugreport.cgi?bug=3D66161>
In the comments of that bug report I've also listed CPAN examples for
each of the use cases.
--
Cheers,
haj
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Thanks for the detailed response. I learned something new. To me it seems t=
hat perl isn't supplying enough information for cperl-mode to get the trail=
ers correct. Ideally, we could definitively tell the type of content below =
the __END__ or __DATA__ keywords.
I suppose one could set file local variables to configure cperl-fontify-tr=
ailer. However, one needs to know about this option. I wonder if there's a =
way to make the option more obvious? </div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
A small suggestion is to update the help text or cperl-fontify-trailer to i=
ndicate it also changes the indent behavior. I think the name cperl-t=
railer-type is a good name too, though updating the help text may be suffic=
ient.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Thanks</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
John</div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style=3D"display: inline-block; width: 98%;">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calibri, =
sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Harald=
J=F6rg <haj@HIDDEN><br>
<b>Sent:</b> Sunday, March 9, 2025 8:28 PM<br>
<b>To:</b> John Ciolfi via Bug reports for GNU Emacs, the Swiss army k=
nife of text editors <bug-gnu-emacs@HIDDEN><br>
<b>Cc:</b> Mauro Aranda <maurooaranda@HIDDEN>; 76868@debbugs.=
gnu.org <76868 <at> debbugs.gnu.org>; John Ciolfi <ciolfi@HIDDEN=
><br>
<b>Subject:</b> Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly=
handled</span>
<div> </div>
</div>
<div class=3D"elementToProof">John Ciolfi via "Bug reports for GNU Ema=
cs, the Swiss army knife of text<br>
editors" <bug-gnu-emacs@HIDDEN> writes:<br>
<br>
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my<br>
> case, the lines after the __END__ are more than just comments and get<=
br>
> corrupted when they are indented. There is also the __DATA__ keyword<b=
r>
> and the default setting of cperl-fontify-trailier causes the data to<b=
r>
> be indented which alters the behavior of the program (corrupts the<br>
> result). Consider:<br>
><br>
> while (my $line =3D <DATA>) { print $line; }<br>
> close DATA;<br>
> __DATA__<br>
> This is not<br>
> perl code<br>
><br>
> If you indent, C-x h followed by C-M-\, the results change. Indenting<=
br>
> shouldn't change results.<br>
<br>
Indeed, setting the option cperl-fontify-trailer to 'comment' is<br>
supposed to prevent this sort of thing from happening.<br>
<br>
> Could you consider changing the default value of cperl-fontify-trailer=
<br>
> to comment so that cperl-mode doesn't indent them? Also, the name is a=
<br>
> little misleading because the more important piece is whether to<br>
> semantically treat the lines after these keywords as perl code. ...<br=
>
<br>
I agree that the name of the option is misleading. Maybe we should add<br>
an alias like cperl-trailer-type? The possible values of "perl-code&qu=
ot;<br>
and "comment" still work with that name. However, changing the de=
fault<br>
is, in my opinion, not the correct way, because there are valid use<br>
cases for the current default behavior.<br>
<br>
> ... The Perl interpreter never treats these as perl code, so it's odd<=
br>
> cperl-mode treats them as perl code. ...<br>
<br>
That's not the whole truth. Programs which use AutoSplit or SelfLoader<br>
work by intentionally having Perl code after the __END__ or __DATA__<br>
tokens. Both AutoSplit and SelfLoader are part of the Perl core.<br>
<br>
<a href=3D"https://perldoc.perl.org/AutoSplit" id=3D"OWA8169ff41-2c6c-4e31-=
a0af-79323be78c69" class=3D"OWAAutoLink" data-auth=3D"NotApplicable">https:=
//perldoc.perl.org/AutoSplit</a><br>
<a href=3D"https://perldoc.perl.org/SelfLoader" id=3D"OWAf445c9aa-8adc-041c=
-31c7-537916e22c20" class=3D"OWAAutoLink" data-auth=3D"NotApplicable">https=
://perldoc.perl.org/SelfLoader</a><br>
<br>
> The only case I'm aware of where the lines following these keywords is=
<br>
> perl is to use the trick to put __END__ to comment out the bottom part=
<br>
> of a perl program, but even in that case, it should be colored as<br>
> comments.<br>
<br>
By far more common is the practice to have POD (Perl's documentation<br>
format) after the __END__ token. This is not read by the Perl<br>
interpreter, but by perldoc and other POD viewers. POD is part of the<br>
Perl language. CPerl mode handles POD for fontification, and supports<br>
POD authoring by imenu indexing of POD headings and by ispell checking<br>
for POD sections.<br>
<br>
So, different ways to use the space after the tokens are valid. If you<br>
do not use POD or Perl code after __END__ or __DATA__, setting the<br>
option cperl-fontify-trailer to "comment" does the trick. But the=
<br>
default value is there for a valid purpose, too. User options are not<br>
supposed to change the behavior of Emacs which would be the case if the<br>
default value is flipped.<br>
<br>
If you regularly indent a whole buffer which may contain trailers not<br>
understood by CPerl mode, you can set the variable temporarily:<br>
<br>
(defun indent-buffer-without-trailer ()<br>
(interactive)<br>
(let ((cperl-fontify-trailer "comment"))<br>
(cperl-indent-region (point-min) (point-max))))<br>
<br>
> Thanks<br>
><br>
> ----------------------------------------------------------------------=
--------------<br>
> From: Mauro Aranda <maurooaranda@HIDDEN><br>
> Sent: Saturday, March 8, 2025 10:51 AM<br>
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org<br=
>
> <76868 <at> debbugs.gnu.org><br>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handle=
d<br>
><br>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss<=
br>
> army knife of text editors wrote:<br>
>><br>
>> Hi<br>
>><br>
>> Given the following cperl-mode program, test.pl<br>
>><br>
>> # -*- mode: cperl; -*-<br>
>> print "hello\n";<br>
>> __END__<br>
>> This is not<br>
>> perl code!<br>
>><br>
>> The lines after the __END__ are treated as perl code. They are<br>
> syntactically colored and indented<br>
>> which is incorrect. In perl, __END__ defines the end of the Perl c=
ode<br>
> in the file. Any text that<br>
>> appears after __END__ is ignored by the Perl compiler.<br>
>><br>
>> All lines after __END__ should be treated as comments.<br>
>><br>
><br>
> Any chance that the option cperl-fontify-trailer helps here?<br>
><br>
> I remember reporting something similar in:<br>
> <a href=3D"https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161" id=
=3D"OWA932fbcdf-9233-b05d-f2bf-61cc4c11889d" class=3D"OWAAutoLink" data-aut=
h=3D"NotApplicable">
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161</a><br>
<br>
In the comments of that bug report I've also listed CPAN examples for<br>
each of the use cases.<br>
--<br>
Cheers,<br>
haj</div>
</body>
</html>
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_--
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 9 Mar 2025 16:41:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 12:41:22 2025
Received: from localhost ([127.0.0.1]:34075 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trJiL-0007D9-Ec
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 12:41:22 -0400
Received: from lists.gnu.org ([2001:470:142::17]:57354)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ciolfi@HIDDEN>)
id 1trJiI-0007Ct-99
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 12:41:19 -0400
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 <ciolfi@HIDDEN>)
id 1trJiC-0001Z4-Vm
for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 12:41:12 -0400
Received: from us-smtp-delivery-120.mimecast.com ([170.10.129.120])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ciolfi@HIDDEN>)
id 1trJi9-0005jj-FX
for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 12:41:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com;
s=mimecast20180117; t=1741538465;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=FAZBSiKUR1sUEVaeivHKuak4IE9CnezhprOWrsENgxI=;
b=LKSaGRAlwwYhgoKJzizCkeom2x/ujsuiUSacb6vM1Ke3KYDqpxVi94FO8Z162XRa0zUJUn
tCkl5zudByUPA8Qu2Q69tRnIqzvnGtXZ6tRq2wSkdpqMkomq714Se1YljKtor8c2S5KlLW
uWD2C9jyJFV4v415Rm9GvFzhemx5+kc=
Received: from CY7PR03CU001.outbound.protection.outlook.com
(mail-westcentralusazlp17012034.outbound.protection.outlook.com
[40.93.6.34]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-533-Vssi0-DhOtSu_1FsEqMmNA-1; Sun, 09 Mar 2025 12:41:03 -0400
X-MC-Unique: Vssi0-DhOtSu_1FsEqMmNA-1
X-Mimecast-MFC-AGG-ID: Vssi0-DhOtSu_1FsEqMmNA_1741538462
Received: from MN2PR05MB6766.namprd05.prod.outlook.com (2603:10b6:208:185::15)
by BL3PR05MB9041.namprd05.prod.outlook.com (2603:10b6:208:3b0::14)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.26; Sun, 9 Mar
2025 16:41:01 +0000
Received: from MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f]) by MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f%4]) with mapi id 15.20.8511.025; Sun, 9 Mar 2025
16:41:00 +0000
From: John Ciolfi <ciolfi@HIDDEN>
To: =?iso-8859-1?Q?Harald_J=F6rg?= <haj@HIDDEN>, "John Ciolfi via Bug
reports for GNU Emacs, the Swiss army knife of text editors"
<bug-gnu-emacs@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Topic: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Index: AQHbkD+UBow31zELIkS3UJNlkmYXFbNpY1oAgAC0S1CAAM9O/oAAFqaK
Date: Sun, 9 Mar 2025 16:41:00 +0000
Message-ID: <MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72@HIDDEN>
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
<MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
<87o6yafdyy.fsf@HIDDEN>
In-Reply-To: <87o6yafdyy.fsf@HIDDEN>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR05MB6766:EE_|BL3PR05MB9041:EE_
x-ms-office365-filtering-correlation-id: dd8e9b9f-ef2d-4373-08ce-08dd5f292ce6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
ARA:13230040|366016|1800799024|376014|38070700018|7053199007|8096899003
x-microsoft-antispam-message-info: =?iso-8859-1?Q?fqPzjccip9/Qinh6oZnYVfn0cozfNW9rfe1IQq1fpA5ksrDpr3ohDGK/si?=
=?iso-8859-1?Q?iAtadgRyhG83itpMGpINK491NahZ+vFo01OMgqMT8eaaoYcv8tXzUJS0nc?=
=?iso-8859-1?Q?JLB+4VhkhDntiFBI4vmrOTlo5xkKGl+KWHAUi9wXdMTEjz4WlPhVV7Mnl2?=
=?iso-8859-1?Q?KEYGRyrv0epCAjT0RCpoDkiEOWHlMXmVnrNUApU56/4cqvMVoRioNC67fu?=
=?iso-8859-1?Q?y3VgzsU1eWNDGC0Bt9qJQU3FXFgsMKH4uwd/OryezbFZbdmMKksyhDHT/H?=
=?iso-8859-1?Q?hzL3YMQlGaDzieO4VQZ+AtvIwBou6QU5Eo/37i6hC6klS19lCQQoC6DsHj?=
=?iso-8859-1?Q?VCT2aUaPGDnM1LR/Ku75gh5/kJQxZtz9dQzHIBiJinRTj6z1Vi2Lh8qwvF?=
=?iso-8859-1?Q?BsyZsErHYrMt0Rpemm0dg/SVuYicp87S1206ron/h1KLlZqhfeFUgWvyJL?=
=?iso-8859-1?Q?nspsh2IGayqR1iW7ruOxv/x0AZsvkAPQKxSXxWHmYXEJGCNbPuQVS4EWdg?=
=?iso-8859-1?Q?lxTiMFY0vkPHTtDZnSeTDBCVkrKgqL2WZTi6CJkNJDmAv6i22i5j4Zov2a?=
=?iso-8859-1?Q?+ktXfFtaTWtG/P/4taebVbXlvVyiPxxcYrGCDdwClDvcYtfoo/FmWfSzK9?=
=?iso-8859-1?Q?EBGE2L5malony543u80A9sZ3U0Xx2VCaL8l+nYv6Yx/Mr5yobbRzFtLMTZ?=
=?iso-8859-1?Q?CGLMRh4HFgGEEf8xwVLrJF6sD7q6aMiZFweuJU+2fXtIFSmhlqx5v2kl9O?=
=?iso-8859-1?Q?cVlMNX1GLK1NLXefNLamcySnKQXhuJ1wse03ikSDTicCHDUF51cokh49WV?=
=?iso-8859-1?Q?6hHZD3K1rRkur0EhUT0IBHGwPTZ0EHCCT1I2arr+/yA8ckmRsreFbIcb0W?=
=?iso-8859-1?Q?+xihspu4EWaIIZ3Dw9/Xrt8kUcfnzIw9E1LG+4jv11Ll06UCS+jG8w7pD1?=
=?iso-8859-1?Q?FqHBSUukB0pNuyN/aP8U0O071VlNhH2ZM45GWYPRGkr5NCceSUYej9InQv?=
=?iso-8859-1?Q?IPU3lnCEwEifmBHhuYuWrtRErigx70Ly/biowAEb+0Y5C7zKcgOYUKQHk5?=
=?iso-8859-1?Q?ZEyFfgLndrttVIuVUmTroInPVf0koStyOAr33xh0FlWcvunQJS4hRa171P?=
=?iso-8859-1?Q?+PyBL5nOUDpEGjiJ3d7iGlyKMxR9lLxeKpMe1Ayzi8/FIGbZf+Aux5QpZR?=
=?iso-8859-1?Q?qkFZarMa3gGz3msbJfIBYWaWmJsfsipqG0pcVac4cc5AB3KBiHtrx3KJkW?=
=?iso-8859-1?Q?pD2FavDPKJar+T4w2dnLGicaVyyerg9opJdjAjsfwECqXag6AOVTuKSB3s?=
=?iso-8859-1?Q?fJwVep1GrLdMvAG6S1cacJW3vHwMlErf31q2KMkOlGsADdM/FOcww/Ddlh?=
=?iso-8859-1?Q?DtcJ+cXakCX/2+xthw2w7sYOihXGEJSeHxHsmNaR5dHlxUZaG4lYo2MYWJ?=
=?iso-8859-1?Q?Uwnk29PlHvQ/911Iq1GluDvHufIhSh6P1fnsCA=3D=3D?=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MN2PR05MB6766.namprd05.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230040)(366016)(1800799024)(376014)(38070700018)(7053199007)(8096899003);
DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?40O7N6qeOXtYDR0EyqgDF7MDH0HIXVVWNh0A+ZFJodrtcvnPFM6EYedVBB?=
=?iso-8859-1?Q?rJiUoSGS2Rb8i4F2if1/DxlTX4r1Pjq9YrXz3TIucOYoLh3apgJWa6xXlm?=
=?iso-8859-1?Q?JslNAzmFP3EGBxkStr2Wcd1h4nVTyHhLhgRvZUjE7tdtb8iLuMkqD3F6t6?=
=?iso-8859-1?Q?mMzJzzzXKS3X2v2eryc4LRcTasTpYuZJQkcVtkt//1/cIwxfS4rBCKp8WE?=
=?iso-8859-1?Q?02/yGzAoj0icfNqOafBoHSEa3sm0EvKEW2NTzenpBc903cC8pv/EQJBfOx?=
=?iso-8859-1?Q?LO9irKYePCbIUM8Pvs0udWvOIjBg5eJo2Lqb/HioqmelRGZ4qRLVrT2KVn?=
=?iso-8859-1?Q?VB58UHdjxtCI0re5EOsNTwJ2zWTrhm5GMaeyFf2pz+6GpdGB8QSDkdWTmf?=
=?iso-8859-1?Q?bDxNW8LA6iUJULxbWA0To42tBYlFUVX7CIFyBsxnuAxSWY9IBdYVj+rB5K?=
=?iso-8859-1?Q?3SQXNGAWXhdGwMayajrp2bGGPBW3nPZZ9PLd39D8z1zl/IS2OVdKPiGMgn?=
=?iso-8859-1?Q?/ua8MoLYuScKO8IRloDoS9vB7uyQkhi5IfHtRPUh5S4aawRlq72sBKLCHw?=
=?iso-8859-1?Q?JQYosZBWW8bcb+fOOgdWEeq5dVsCVuCEVcb7cOYtHUwFDtsq0Oc6ConI2S?=
=?iso-8859-1?Q?Xsq2LtlRHOAseqU0cUaGDa2LHpBZ2oSP/m/Mv6UZRRmRtIB2vGcqAi6TbW?=
=?iso-8859-1?Q?InxXTjRItD9q9k+AfVuWvVkUuPQkxQZF1PPn0uGt8gjsFF9tImDgX1lpFz?=
=?iso-8859-1?Q?GrBQoCttIbOn9j99cSbqSzM5cLeQzSTOwXKr213MZCeD85ImUQVjEpKEGH?=
=?iso-8859-1?Q?I9JZsMhjkx64xJ7t4XVuetWmJMKXOG+2FA4xKJ9+XUp+04DkJx6nztyKYK?=
=?iso-8859-1?Q?h4TI+yYQmr0YBns8NMdZoMlglyJHnNgrb20Hv1eHqoALSiq97tfbRGQAMw?=
=?iso-8859-1?Q?bbZtO/HoSJbV78/p1a5MNYZLyaTWCrWHFrSsmIn4SI6V4d3xSr5aysSHW0?=
=?iso-8859-1?Q?UYp3Fbs2iS36YcMY2v4LYPhhIdGtaE4R7lrE1xQvyJ3mz9/PzeTTNlkWxm?=
=?iso-8859-1?Q?qGkQUsdAGz7ch7kmWJlSRmFNaG7mUG0zBNWuAnCuDth8kHRXc/sSOluQ3W?=
=?iso-8859-1?Q?Git95pfU1s3vBCg78HK3maCtRPXFUWfh6Q2RYbb6s7/vI4V4G2Smrh0Dts?=
=?iso-8859-1?Q?PejC7lCwQJ72/PDq9q4XFyxZbdc1hPIespfxb2eO8osVpirppOlM/ipXVV?=
=?iso-8859-1?Q?8oUgitniA4mkHeRaOpv6P6IO98tgqQ7l6H/tWtXefcp+dYsCNn+QUOZ+pj?=
=?iso-8859-1?Q?u/PXmj/xRZtNcRleM2WDjMNMTW+Z9m0E3Em0b4oRLktzvnOZgeRo1C+u5d?=
=?iso-8859-1?Q?wzXmrFeD0zoJuBsEqdeqfO7Cps7cQ5zay+z+nrriebb+jw0T+QznBLpHoE?=
=?iso-8859-1?Q?pGiMZZHqSbPl5m9B/k1J7KM4JKc2nsESfL1JeVhqGlpXFHi99yBkJjalM3?=
=?iso-8859-1?Q?wmLRzprTPr965eT9GxD6MgFZGGriAexsSYUVzD0+9mjvT+dwNUvkj6RNgn?=
=?iso-8859-1?Q?CjUYoItqHlPHmKL6JNsvjU2RqXwT2dUKFQul3A2qQKZlGta9oBDRQ9D46u?=
=?iso-8859-1?Q?+TPaMVhfEWZ8l/+8yWEOLzjG16QvbMcyPa?=
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 1kifgoIhAWTx9eJLFvHrlfhbaL7CiE0pQrbvtnpg/3vUtEOquoA5TusMmua27BIbCuzyE5/KG8zKdAsicgyFHr7WvO2okP/lq1OISJiguwPvbmczRhg5HYHEFtwXmfzLCiIfO7vI0cGqzYxaMJCWCCoC0ZJ5sV0KDP7a4+jRTxAOuxriIruFuiyvf1xTCLMVtRQ044RRhJNVWZUzqip2G5fCBrPz/sO/iFgbO8tRJoU+QsxruLcnYFVTcYczzQgdHW/1oAxTrNkq7GD8FYHkv0xz9L9e5PCAcFAQvs2LPzPgwpqw20AWCvh5x9FqcQqSwzGMkTPqtq7FZPB+MKvuLz0NQKmf2XEsln0pzie79tU6WuUj/owQztXbKZQ9HJnZy6UgYUuJdVLmjtwjiN0AA8B4DL2YuBSpKE3BHFIuKDqZjA5axWgGuErfDT4O80qsAftGLzHf14oQH2OMAKbh0AyBIQaIS5kvhG8WO+txswdPP1QkNiGCltYW2Ih2IHqoM2dSgkhw2s4+iNJ75fXFprUGRfsTT+DILdDpeH6oCruCKs5HpE8NHrLHdsV18X20qtF1JQVIQwdNiqjiGNKO0/wXc55EaGBuDbGA2ish45o=
X-OriginatorOrg: mathworks.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6766.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd8e9b9f-ef2d-4373-08ce-08dd5f292ce6
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2025 16:41:00.7984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99dd3a11-4348-4468-9bdd-e5072b1dc1e6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FheYCH1bTgBQCx2O9xBsXXS9IktUm3UYAC8SDB3ABjy/IKc1Joa7TXXZZy1Emu47UZgCb83Wcgrq6au+Dp5ZiQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR05MB9041
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: SnS9vKOKysiBobsFkfaBoOySWko2aUIx71hsWNSF2Dw_1741538462
X-Mimecast-Originator: mathworks.com
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_"
Received-SPF: pass client-ip=170.10.129.120; envelope-from=ciolfi@HIDDEN;
helo=us-smtp-delivery-120.mimecast.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>,
Mauro Aranda <maurooaranda@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Thanks for the detailed response. I learned something new. To me it seems t=
hat perl isn't supplying enough information for cperl-mode to get the trail=
ers correct. Ideally, we could definitively tell the type of content below =
the __END__ or __DATA__ keywords. I suppose one could set file local varia=
bles to configure cperl-fontify-trailer. However, one needs to know about t=
his option. I wonder if there's a way to make the option more obvious?
A small suggestion is to update the help text or cperl-fontify-trailer to i=
ndicate it also changes the indent behavior. I think the name cperl-traile=
r-type is a good name too, though updating the help text may be sufficient.
Thanks
John
________________________________
From: Harald J=F6rg <haj@HIDDEN>
Sent: Sunday, March 9, 2025 8:28 PM
To: John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text=
editors <bug-gnu-emacs@HIDDEN>
Cc: Mauro Aranda <maurooaranda@HIDDEN>; 76868 <at> debbugs.gnu.org <76868@deb=
bugs.gnu.org>; John Ciolfi <ciolfi@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line =3D <DATA>) { print $line; }
> close DATA;
> __DATA__
> This is not
> perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.
Indeed, setting the option cperl-fontify-trailer to 'comment' is
supposed to prevent this sort of thing from happening.
> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. ...
I agree that the name of the option is misleading. Maybe we should add
an alias like cperl-trailer-type? The possible values of "perl-code"
and "comment" still work with that name. However, changing the default
is, in my opinion, not the correct way, because there are valid use
cases for the current default behavior.
> ... The Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. ...
That's not the whole truth. Programs which use AutoSplit or SelfLoader
work by intentionally having Perl code after the __END__ or __DATA__
tokens. Both AutoSplit and SelfLoader are part of the Perl core.
https://perldoc.perl.org/AutoSplit<https://perldoc.perl.org/AutoSplit>
https://perldoc.perl.org/SelfLoader<https://perldoc.perl.org/SelfLoader>
> The only case I'm aware of where the lines following these keywords is
> perl is to use the trick to put __END__ to comment out the bottom part
> of a perl program, but even in that case, it should be colored as
> comments.
By far more common is the practice to have POD (Perl's documentation
format) after the __END__ token. This is not read by the Perl
interpreter, but by perldoc and other POD viewers. POD is part of the
Perl language. CPerl mode handles POD for fontification, and supports
POD authoring by imenu indexing of POD headings and by ispell checking
for POD sections.
So, different ways to use the space after the tokens are valid. If you
do not use POD or Perl code after __END__ or __DATA__, setting the
option cperl-fontify-trailer to "comment" does the trick. But the
default value is there for a valid purpose, too. User options are not
supposed to change the behavior of Emacs which would be the case if the
default value is flipped.
If you regularly indent a whole buffer which may contain trailers not
understood by CPerl mode, you can set the variable temporarily:
(defun indent-buffer-without-trailer ()
(interactive)
(let ((cperl-fontify-trailer "comment"))
(cperl-indent-region (point-min) (point-max))))
> Thanks
>
> -------------------------------------------------------------------------=
-----------
> From: Mauro Aranda <maurooaranda@HIDDEN>
> Sent: Saturday, March 8, 2025 10:51 AM
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org
> <76868 <at> debbugs.gnu.org>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>
>> Hi
>>
>> Given the following cperl-mode program, test.pl
>>
>> # -*- mode: cperl; -*-
>> print "hello\n";
>> __END__
>> This is not
>> perl code!
>>
>> The lines after the __END__ are treated as perl code. They are
> syntactically colored and indented
>> which is incorrect. In perl, __END__ defines the end of the Perl code
> in the file. Any text that
>> appears after __END__ is ignored by the Perl compiler.
>>
>> All lines after __END__ should be treated as comments.
>>
>
> Any chance that the option cperl-fontify-trailer helps here?
>
> I remember reporting something similar in:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161<https://debbugs.gnu=
.org/cgi/bugreport.cgi?bug=3D66161>
In the comments of that bug report I've also listed CPAN examples for
each of the use cases.
--
Cheers,
haj
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Thanks for the detailed response. I learned something new. To me it seems t=
hat perl isn't supplying enough information for cperl-mode to get the trail=
ers correct. Ideally, we could definitively tell the type of content below =
the __END__ or __DATA__ keywords.
I suppose one could set file local variables to configure cperl-fontify-tr=
ailer. However, one needs to know about this option. I wonder if there's a =
way to make the option more obvious? </div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
A small suggestion is to update the help text or cperl-fontify-trailer to i=
ndicate it also changes the indent behavior. I think the name cperl-t=
railer-type is a good name too, though updating the help text may be suffic=
ient.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Thanks</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
John</div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style=3D"display: inline-block; width: 98%;">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calibri, =
sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Harald=
J=F6rg <haj@HIDDEN><br>
<b>Sent:</b> Sunday, March 9, 2025 8:28 PM<br>
<b>To:</b> John Ciolfi via Bug reports for GNU Emacs, the Swiss army k=
nife of text editors <bug-gnu-emacs@HIDDEN><br>
<b>Cc:</b> Mauro Aranda <maurooaranda@HIDDEN>; 76868@debbugs.=
gnu.org <76868 <at> debbugs.gnu.org>; John Ciolfi <ciolfi@HIDDEN=
><br>
<b>Subject:</b> Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly=
handled</span>
<div> </div>
</div>
<div class=3D"elementToProof">John Ciolfi via "Bug reports for GNU Ema=
cs, the Swiss army knife of text<br>
editors" <bug-gnu-emacs@HIDDEN> writes:<br>
<br>
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my<br>
> case, the lines after the __END__ are more than just comments and get<=
br>
> corrupted when they are indented. There is also the __DATA__ keyword<b=
r>
> and the default setting of cperl-fontify-trailier causes the data to<b=
r>
> be indented which alters the behavior of the program (corrupts the<br>
> result). Consider:<br>
><br>
> while (my $line =3D <DATA>) { print $line; }<br>
> close DATA;<br>
> __DATA__<br>
> This is not<br>
> perl code<br>
><br>
> If you indent, C-x h followed by C-M-\, the results change. Indenting<=
br>
> shouldn't change results.<br>
<br>
Indeed, setting the option cperl-fontify-trailer to 'comment' is<br>
supposed to prevent this sort of thing from happening.<br>
<br>
> Could you consider changing the default value of cperl-fontify-trailer=
<br>
> to comment so that cperl-mode doesn't indent them? Also, the name is a=
<br>
> little misleading because the more important piece is whether to<br>
> semantically treat the lines after these keywords as perl code. ...<br=
>
<br>
I agree that the name of the option is misleading. Maybe we should add<br>
an alias like cperl-trailer-type? The possible values of "perl-code&qu=
ot;<br>
and "comment" still work with that name. However, changing the de=
fault<br>
is, in my opinion, not the correct way, because there are valid use<br>
cases for the current default behavior.<br>
<br>
> ... The Perl interpreter never treats these as perl code, so it's odd<=
br>
> cperl-mode treats them as perl code. ...<br>
<br>
That's not the whole truth. Programs which use AutoSplit or SelfLoader<br>
work by intentionally having Perl code after the __END__ or __DATA__<br>
tokens. Both AutoSplit and SelfLoader are part of the Perl core.<br>
<br>
<a href=3D"https://perldoc.perl.org/AutoSplit" id=3D"OWA8169ff41-2c6c-4e31-=
a0af-79323be78c69" class=3D"OWAAutoLink" data-auth=3D"NotApplicable">https:=
//perldoc.perl.org/AutoSplit</a><br>
<a href=3D"https://perldoc.perl.org/SelfLoader" id=3D"OWAf445c9aa-8adc-041c=
-31c7-537916e22c20" class=3D"OWAAutoLink" data-auth=3D"NotApplicable">https=
://perldoc.perl.org/SelfLoader</a><br>
<br>
> The only case I'm aware of where the lines following these keywords is=
<br>
> perl is to use the trick to put __END__ to comment out the bottom part=
<br>
> of a perl program, but even in that case, it should be colored as<br>
> comments.<br>
<br>
By far more common is the practice to have POD (Perl's documentation<br>
format) after the __END__ token. This is not read by the Perl<br>
interpreter, but by perldoc and other POD viewers. POD is part of the<br>
Perl language. CPerl mode handles POD for fontification, and supports<br>
POD authoring by imenu indexing of POD headings and by ispell checking<br>
for POD sections.<br>
<br>
So, different ways to use the space after the tokens are valid. If you<br>
do not use POD or Perl code after __END__ or __DATA__, setting the<br>
option cperl-fontify-trailer to "comment" does the trick. But the=
<br>
default value is there for a valid purpose, too. User options are not<br>
supposed to change the behavior of Emacs which would be the case if the<br>
default value is flipped.<br>
<br>
If you regularly indent a whole buffer which may contain trailers not<br>
understood by CPerl mode, you can set the variable temporarily:<br>
<br>
(defun indent-buffer-without-trailer ()<br>
(interactive)<br>
(let ((cperl-fontify-trailer "comment"))<br>
(cperl-indent-region (point-min) (point-max))))<br>
<br>
> Thanks<br>
><br>
> ----------------------------------------------------------------------=
--------------<br>
> From: Mauro Aranda <maurooaranda@HIDDEN><br>
> Sent: Saturday, March 8, 2025 10:51 AM<br>
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org<br=
>
> <76868 <at> debbugs.gnu.org><br>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handle=
d<br>
><br>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss<=
br>
> army knife of text editors wrote:<br>
>><br>
>> Hi<br>
>><br>
>> Given the following cperl-mode program, test.pl<br>
>><br>
>> # -*- mode: cperl; -*-<br>
>> print "hello\n";<br>
>> __END__<br>
>> This is not<br>
>> perl code!<br>
>><br>
>> The lines after the __END__ are treated as perl code. They are<br>
> syntactically colored and indented<br>
>> which is incorrect. In perl, __END__ defines the end of the Perl c=
ode<br>
> in the file. Any text that<br>
>> appears after __END__ is ignored by the Perl compiler.<br>
>><br>
>> All lines after __END__ should be treated as comments.<br>
>><br>
><br>
> Any chance that the option cperl-fontify-trailer helps here?<br>
><br>
> I remember reporting something similar in:<br>
> <a href=3D"https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161" id=
=3D"OWA932fbcdf-9233-b05d-f2bf-61cc4c11889d" class=3D"OWAAutoLink" data-aut=
h=3D"NotApplicable">
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161</a><br>
<br>
In the comments of that bug report I've also listed CPAN examples for<br>
each of the use cases.<br>
--<br>
Cheers,<br>
haj</div>
</body>
</html>
--_000_MN2PR05MB6766F6C3DE30E21D92AEDDBFD1D72MN2PR05MB6766namp_--
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at 76868) by debbugs.gnu.org; 9 Mar 2025 14:58:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 10:58:25 2025
Received: from localhost ([127.0.0.1]:33800 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trI6j-0007aJ-1E
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 10:58:25 -0400
Received: from mout02.posteo.de ([185.67.36.66]:34163)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <haj@HIDDEN>) id 1trI6g-0007a1-CB
for 76868 <at> debbugs.gnu.org; Sun, 09 Mar 2025 10:58:23 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 41F0E240101
for <76868 <at> debbugs.gnu.org>; Sun, 9 Mar 2025 15:58:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017;
t=1741532295; bh=4SVJyx4JI+75+pmEDkgfi8zb1wOFM/ZKBuT5GbuCeSQ=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
From;
b=o6I2IfE99W7kmxZbQJ9+1TO0cNnfT5lphVsf0myAEWQYESLqKAHJl9Pg7Ptfz2Ekv
os/JyhzSKkVAeiOMhhvD8+pW42cHBE5Mz+e/9/IUKNcegDZr5BvGr+1q2eWcnPWqX0
kNrzRdVL4b2RgMMx0ubdidH0EnMjzzlY4o2a3emDmIQeDueMMgEdfNRIJ4lEH8rrtw
nAdvEOuZ456oyqSPcECFXEfsGs/+G+wupbmFAbDcR57lgIHMfiXGTJWwzZu37d7VAn
rP/GTvAzBe5b7L3VsEpjCn7iyBGjj+t3qXr3lSfJ4NLBmN89oBfaEy/Q1bRTyI+umL
VZngqg/5M/oIw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4Z9jnd2gQWz6twf;
Sun, 9 Mar 2025 15:58:13 +0100 (CET)
From: =?utf-8?Q?Harald_J=C3=B6rg?= <haj@HIDDEN>
To: John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
In-Reply-To: <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
(John Ciolfi via's message of "Sun, 9 Mar 2025 02:59:11 +0000")
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
<MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
Date: Sun, 09 Mar 2025 14:58:13 +0000
Message-ID: <87o6yafdyy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76868
Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>,
John Ciolfi <ciolfi@HIDDEN>, Mauro Aranda <maurooaranda@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line = <DATA>) { print $line; }
> close DATA;
> __DATA__
> This is not
> perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.
Indeed, setting the option cperl-fontify-trailer to 'comment' is
supposed to prevent this sort of thing from happening.
> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. ...
I agree that the name of the option is misleading. Maybe we should add
an alias like cperl-trailer-type? The possible values of "perl-code"
and "comment" still work with that name. However, changing the default
is, in my opinion, not the correct way, because there are valid use
cases for the current default behavior.
> ... The Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. ...
That's not the whole truth. Programs which use AutoSplit or SelfLoader
work by intentionally having Perl code after the __END__ or __DATA__
tokens. Both AutoSplit and SelfLoader are part of the Perl core.
https://perldoc.perl.org/AutoSplit
https://perldoc.perl.org/SelfLoader
> The only case I'm aware of where the lines following these keywords is
> perl is to use the trick to put __END__ to comment out the bottom part
> of a perl program, but even in that case, it should be colored as
> comments.
By far more common is the practice to have POD (Perl's documentation
format) after the __END__ token. This is not read by the Perl
interpreter, but by perldoc and other POD viewers. POD is part of the
Perl language. CPerl mode handles POD for fontification, and supports
POD authoring by imenu indexing of POD headings and by ispell checking
for POD sections.
So, different ways to use the space after the tokens are valid. If you
do not use POD or Perl code after __END__ or __DATA__, setting the
option cperl-fontify-trailer to "comment" does the trick. But the
default value is there for a valid purpose, too. User options are not
supposed to change the behavior of Emacs which would be the case if the
default value is flipped.
If you regularly indent a whole buffer which may contain trailers not
understood by CPerl mode, you can set the variable temporarily:
(defun indent-buffer-without-trailer ()
(interactive)
(let ((cperl-fontify-trailer "comment"))
(cperl-indent-region (point-min) (point-max))))
> Thanks
>
> ------------------------------------------------------------------------------------
> From: Mauro Aranda <maurooaranda@HIDDEN>
> Sent: Saturday, March 8, 2025 10:51 AM
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org
> <76868 <at> debbugs.gnu.org>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>
>> Hi
>>
>> Given the following cperl-mode program, test.pl
>>
>> # -*- mode: cperl; -*-
>> print "hello\n";
>> __END__
>> This is not
>> perl code!
>>
>> The lines after the __END__ are treated as perl code. They are
> syntactically colored and indented
>> which is incorrect. In perl, __END__ defines the end of the Perl code
> in the file. Any text that
>> appears after __END__ is ignored by the Perl compiler.
>>
>> All lines after __END__ should be treated as comments.
>>
>
> Any chance that the option cperl-fontify-trailer helps here?
>
> I remember reporting something similar in:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161
In the comments of that bug report I've also listed CPAN examples for
each of the use cases.
--
Cheers,
haj
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 9 Mar 2025 14:58:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 10:58:31 2025
Received: from localhost ([127.0.0.1]:33803 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trI6p-0007ac-0I
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 10:58:31 -0400
Received: from lists.gnu.org ([2001:470:142::17]:56054)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <haj@HIDDEN>) id 1trI6m-0007aB-2M
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 10:58:28 -0400
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 <haj@HIDDEN>) id 1trI6g-0000gA-OG
for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 10:58:22 -0400
Received: from mout02.posteo.de ([185.67.36.66])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <haj@HIDDEN>) id 1trI6e-00036P-Ag
for bug-gnu-emacs@HIDDEN; Sun, 09 Mar 2025 10:58:22 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 24FB6240101
for <bug-gnu-emacs@HIDDEN>; Sun, 9 Mar 2025 15:58:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017;
t=1741532295; bh=4SVJyx4JI+75+pmEDkgfi8zb1wOFM/ZKBuT5GbuCeSQ=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
From;
b=o6I2IfE99W7kmxZbQJ9+1TO0cNnfT5lphVsf0myAEWQYESLqKAHJl9Pg7Ptfz2Ekv
os/JyhzSKkVAeiOMhhvD8+pW42cHBE5Mz+e/9/IUKNcegDZr5BvGr+1q2eWcnPWqX0
kNrzRdVL4b2RgMMx0ubdidH0EnMjzzlY4o2a3emDmIQeDueMMgEdfNRIJ4lEH8rrtw
nAdvEOuZ456oyqSPcECFXEfsGs/+G+wupbmFAbDcR57lgIHMfiXGTJWwzZu37d7VAn
rP/GTvAzBe5b7L3VsEpjCn7iyBGjj+t3qXr3lSfJ4NLBmN89oBfaEy/Q1bRTyI+umL
VZngqg/5M/oIw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4Z9jnd2gQWz6twf;
Sun, 9 Mar 2025 15:58:13 +0100 (CET)
From: =?utf-8?Q?Harald_J=C3=B6rg?= <haj@HIDDEN>
To: John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
In-Reply-To: <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
(John Ciolfi via's message of "Sun, 9 Mar 2025 02:59:11 +0000")
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
<MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
Date: Sun, 09 Mar 2025 14:58:13 +0000
Message-ID: <87o6yafdyy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.66; envelope-from=haj@HIDDEN;
helo=mout02.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: "76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>,
John Ciolfi <ciolfi@HIDDEN>, Mauro Aranda <maurooaranda@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line = <DATA>) { print $line; }
> close DATA;
> __DATA__
> This is not
> perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.
Indeed, setting the option cperl-fontify-trailer to 'comment' is
supposed to prevent this sort of thing from happening.
> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. ...
I agree that the name of the option is misleading. Maybe we should add
an alias like cperl-trailer-type? The possible values of "perl-code"
and "comment" still work with that name. However, changing the default
is, in my opinion, not the correct way, because there are valid use
cases for the current default behavior.
> ... The Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. ...
That's not the whole truth. Programs which use AutoSplit or SelfLoader
work by intentionally having Perl code after the __END__ or __DATA__
tokens. Both AutoSplit and SelfLoader are part of the Perl core.
https://perldoc.perl.org/AutoSplit
https://perldoc.perl.org/SelfLoader
> The only case I'm aware of where the lines following these keywords is
> perl is to use the trick to put __END__ to comment out the bottom part
> of a perl program, but even in that case, it should be colored as
> comments.
By far more common is the practice to have POD (Perl's documentation
format) after the __END__ token. This is not read by the Perl
interpreter, but by perldoc and other POD viewers. POD is part of the
Perl language. CPerl mode handles POD for fontification, and supports
POD authoring by imenu indexing of POD headings and by ispell checking
for POD sections.
So, different ways to use the space after the tokens are valid. If you
do not use POD or Perl code after __END__ or __DATA__, setting the
option cperl-fontify-trailer to "comment" does the trick. But the
default value is there for a valid purpose, too. User options are not
supposed to change the behavior of Emacs which would be the case if the
default value is flipped.
If you regularly indent a whole buffer which may contain trailers not
understood by CPerl mode, you can set the variable temporarily:
(defun indent-buffer-without-trailer ()
(interactive)
(let ((cperl-fontify-trailer "comment"))
(cperl-indent-region (point-min) (point-max))))
> Thanks
>
> ------------------------------------------------------------------------------------
> From: Mauro Aranda <maurooaranda@HIDDEN>
> Sent: Saturday, March 8, 2025 10:51 AM
> To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org
> <76868 <at> debbugs.gnu.org>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>
>> Hi
>>
>> Given the following cperl-mode program, test.pl
>>
>> # -*- mode: cperl; -*-
>> print "hello\n";
>> __END__
>> This is not
>> perl code!
>>
>> The lines after the __END__ are treated as perl code. They are
> syntactically colored and indented
>> which is incorrect. In perl, __END__ defines the end of the Perl code
> in the file. Any text that
>> appears after __END__ is ignored by the Perl compiler.
>>
>> All lines after __END__ should be treated as comments.
>>
>
> Any chance that the option cperl-fontify-trailer helps here?
>
> I remember reporting something similar in:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161
In the comments of that bug report I've also listed CPAN examples for
each of the use cases.
--
Cheers,
haj
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at 76868) by debbugs.gnu.org; 9 Mar 2025 11:00:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 07:00:56 2025
Received: from localhost ([127.0.0.1]:58573 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trEOu-0003Ur-2K
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 07:00:56 -0400
Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:59727)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <maurooaranda@HIDDEN>)
id 1trEOq-0003UT-L9
for 76868 <at> debbugs.gnu.org; Sun, 09 Mar 2025 07:00:53 -0400
Received: by mail-pl1-x634.google.com with SMTP id
d9443c01a7336-22548a28d0cso24021975ad.3
for <76868 <at> debbugs.gnu.org>; Sun, 09 Mar 2025 04:00:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1741518046; x=1742122846; darn=debbugs.gnu.org;
h=content-transfer-encoding:in-reply-to:from:cc:content-language
:references:to:subject:user-agent:mime-version:date:message-id:from
:to:cc:subject:date:message-id:reply-to;
bh=3Q/cZPL++aJ1b1gQOHaGIIrm45XzdjDOoqemrxEEXxc=;
b=Cz9kBdUGS+goQ2eFvUhKeCBfrB7k6qfKtNI5AiMY51tPYyDnq+AXxWU5YEAEaQ/GEF
kmwEnmsQX0Hmtr1YLPq2DcaBFdmqO8NncaxOXactq8ucrirnPOIWWBgiXVuKPYwK5zLC
CG2C7Os34uUpqAOzPWsIfmwy7s46yOSKYn8Y9TM+03KGO5a6fuG77Glq1afblYYJaSdQ
iB9DqB4uXlkvanzvZrvUh15VSasXfr81o/F5W6X259/f04w5EcZgWSxmEpyeARg1QKDa
b8g34UkaQtM/1A9i6UlcvY/12rHKfc6GfFMaB1tJVNsjxAkjeAqWkJgf+JbWQDR/JNnN
6NOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1741518046; x=1742122846;
h=content-transfer-encoding:in-reply-to:from:cc:content-language
:references:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=3Q/cZPL++aJ1b1gQOHaGIIrm45XzdjDOoqemrxEEXxc=;
b=RxXAXcfY7HqPwRhDz/B8e/w2SH0/yWs8XkLjj2s8KGBJVE8cTKeEkMkL7FcmVFBbpR
NiFrn6nMcr2r10vOc/N+L58n541NvrM+2hxbbiFpxQ9z+f3PH1ZNrQ9KmbbtkZ2g8RAy
tl7O9RFRsV9i7/VaK6gSRjG9b5L7GSAP+M5n9H6CJ4x08WcGwsV6mWMPG+XEHGZo9sx3
ByunX5D8Ib4Vbjkd2LoFH4pbA9yeY3q1Vea3aGrkKlIvOXf4y99YciYcCC7bzGc/BAOc
qZi1io6fEjkvaY0B5fsJKmtqgI0hhS2ltapJrRG3NIfdk7ema6w/i9DlN3jpuxeyWaYv
pz+g==
X-Forwarded-Encrypted: i=1;
AJvYcCWju33iN+uLS3JvVB4YWWL+TzUd8v4M9g9FP0UyYWfKl5p+KPpmcqq8lnTerlNRT+LQTEe+Gw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw58uz7baOC/ZdVZf6sUPKetJmxHlZVww1J6y1X4HpMa98T3Zgc
R+JyGtgOEV7OC/orimHRJy+Rb59ltW+03zcj8B+HfzvPIuKvcMJzJR7QvogC
X-Gm-Gg: ASbGnctZp+vyXmuSHZ4cVyuXXY8LTJYnktLbNcVapMpLiBdgYP7DpOaZDMwA0PB5wIS
jZQ11j1Kwv6XBzIsTUINjH1S3GsUrS1AX4+EfT8gosbQ1XaGYnFePPuhfUyZ/QMf/TwLvEBNoTy
0BzBEvwkAIiBViqVu+rFKAyVWbjyd4ai8kxgR7MX650+ATc4kTrd4kx5MyxQSl+EijhRs/suLZw
Cpn6QMNzBS7qke3LGY4vpqMqe1MrOB8ShM8Pwt+FtA6yvbIRKWyQmYb6UWbg9NL257O41iOxyvd
kVOK1GRlwye+ubNK+NOqjGVsc0NSiULK45XaGucsuvgZCIyFqbk=
X-Google-Smtp-Source: AGHT+IERERFv/nDvxr9jcRgYy+hGf73PhngknXWjWJajmeNZI1j0gjVi8ILNzs0EE5EXsTOOi5JU/g==
X-Received: by 2002:a17:902:ce0a:b0:223:6436:72bf with SMTP id
d9443c01a7336-22428bf7a47mr198322235ad.44.1741518046471;
Sun, 09 Mar 2025 04:00:46 -0700 (PDT)
Received: from [192.168.0.234] ([181.228.33.6])
by smtp.gmail.com with ESMTPSA id
d9443c01a7336-224109ddff3sm58799335ad.44.2025.03.09.04.00.43
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 09 Mar 2025 04:00:45 -0700 (PDT)
Message-ID: <1be12f4e-ef1a-4adf-93de-0d2c7e6c0796@HIDDEN>
Date: Sun, 9 Mar 2025 08:00:42 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
To: John Ciolfi <ciolfi@HIDDEN>,
"76868 <at> debbugs.gnu.org" <76868 <at> debbugs.gnu.org>
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
<MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
Content-Language: en-US
From: Mauro Aranda <maurooaranda@HIDDEN>
In-Reply-To: <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76868
Cc: =?UTF-8?Q?Harald_J=C3=B6rg?= <haj@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 8/3/25 23:59, John Ciolfi wrote:
> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line = <DATA>) { print $line; } close DATA; __DATA__ This
> is not perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.
>
> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. The
> Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. The only case I'm aware of where
> the lines following these keywords is perl is to use the trick to put
> __END__ to comment out the bottom part of a perl program, but even in
> that case, it should be colored as comments.
>
> Thanks
>
CCing Harald.
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at 76868) by debbugs.gnu.org; 9 Mar 2025 02:59:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 08 21:59:29 2025
Received: from localhost ([127.0.0.1]:57510 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tr6sy-0005Ky-Hh
for submit <at> debbugs.gnu.org; Sat, 08 Mar 2025 21:59:29 -0500
Received: from us-smtp-delivery-120.mimecast.com ([170.10.133.120]:24385)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ciolfi@HIDDEN>) id 1tr6sp-0005Kj-B4
for 76868 <at> debbugs.gnu.org; Sat, 08 Mar 2025 21:59:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com;
s=mimecast20180117; t=1741489158;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=j2ZUmDTAUgkZYLB1LwWO03xKVSgU8fzr/K/x8QkG9Dk=;
b=HGZXmazvlpNFK4HO5SF50zO5PlLGEz4cvePwbo4ZoiLru8csQZhBaeH69zFqwxfv+GaacK
oj+P964mpwuOtUllbxSh9f2ySYq/3uOUdo7Jz3I4Ci7Xe2yXLhQzziO9Wj/xj9KPJEMAup
VYZhbLV5XW/H7UtmfHjb9gFVYNTQLa4=
Received: from BYAPR05CU005.outbound.protection.outlook.com
(mail-westusazlp17010003.outbound.protection.outlook.com [40.93.1.3]) by
relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
cipher=TLS_AES_256_GCM_SHA384) id us-mta-104-QKl1lr6zPaaKzmd_18zRMw-1; Sat,
08 Mar 2025 21:59:16 -0500
X-MC-Unique: QKl1lr6zPaaKzmd_18zRMw-1
X-Mimecast-MFC-AGG-ID: QKl1lr6zPaaKzmd_18zRMw_1741489155
Received: from MN2PR05MB6766.namprd05.prod.outlook.com (2603:10b6:208:185::15)
by SA6PR05MB10697.namprd05.prod.outlook.com (2603:10b6:806:404::10)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.26; Sun, 9 Mar
2025 02:59:12 +0000
Received: from MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f]) by MN2PR05MB6766.namprd05.prod.outlook.com
([fe80::5ea6:b1eb:653c:426f%4]) with mapi id 15.20.8511.023; Sun, 9 Mar 2025
02:59:11 +0000
From: John Ciolfi <ciolfi@HIDDEN>
To: Mauro Aranda <maurooaranda@HIDDEN>, "76868 <at> debbugs.gnu.org"
<76868 <at> debbugs.gnu.org>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Topic: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Thread-Index: AQHbkD+UBow31zELIkS3UJNlkmYXFbNpY1oAgAC0S1A=
Date: Sun, 9 Mar 2025 02:59:11 +0000
Message-ID: <MN2PR05MB6766E7BB87CB5068B53F398ED1D72@HIDDEN>
References: <r9ldtfh6yr.fsf@HIDDEN>
<6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
In-Reply-To: <6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN2PR05MB6766:EE_|SA6PR05MB10697:EE_
x-ms-office365-filtering-correlation-id: 85ea8f93-2295-450e-da01-08dd5eb65e44
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
ARA:13230040|1800799024|366016|376014|38070700018|7053199007|8096899003
x-microsoft-antispam-message-info: =?iso-8859-1?Q?4X6H+0/NjkPwsZSBkd6/IGQ/BkOeQVp2Bgjja2qKv3CMv1sNzC94HS3o87?=
=?iso-8859-1?Q?EHFgt8lTQxRK7uOXxp+UoC0ZHhSahLiTb5wLBIK4py3ExiAhnCHC7jRkSw?=
=?iso-8859-1?Q?6ajwnUQa4WNa7p/WDrpyzuFT3TdfhZNuJnLAh+FlfpFuZblOelDew9F+4B?=
=?iso-8859-1?Q?dGOiEyoeVvIfcvU32Pk9u/d14AjSEFMEqjYXrqgX/ZL9S/P6W+N3efnxD8?=
=?iso-8859-1?Q?SJpqMdbKT+Im64XFlR4mOxY1y2NhTR/Bcd8THuZby/W/CeFcSgvN6MBEpQ?=
=?iso-8859-1?Q?uVKifDDAG3kOq0BfXedizi2fN+UDTjRkUj8UuTwCfL1ihf2ZaXtYfK+tMs?=
=?iso-8859-1?Q?g70dhB535Xwv0ZARsLRUc59GamzNwfWDSUXFx8N1hO6aAfakonGWpo6Qvl?=
=?iso-8859-1?Q?n5sPv+E0uxl8Wjg7SverXCeQuQb8/1yGwJl1TgtLghy5pxf4SxqH2SrLkj?=
=?iso-8859-1?Q?Spon45rtgzstpm8nBZwkrTPnMwGtSCzxhCl+GlvaxCsDACiuvrMwyOqi1K?=
=?iso-8859-1?Q?0LG/uOPQU1vwz8b6+EzSldtxKYnTFrsPpnwa6/30ktQkLNeHnR4khfDC8g?=
=?iso-8859-1?Q?lqm8gNBHMaikWSo+TxViXpg+lWI93g6RzN4XMya4p/leZ7MDv4HNEqH+pf?=
=?iso-8859-1?Q?ukNFdwjP/2R/sDGgZS05w+ac/GIaRCtB8Q2bCyt774USEc6lDjN1gcDpKk?=
=?iso-8859-1?Q?ehBTlQXj6Ffn3wQsztwtVY8lW5pSIgs+G7gltGV4KqWQvzyv4lxHlwkpm1?=
=?iso-8859-1?Q?nuZ4jf1ALBLMgCmVG3u3p8BzZoZCXG4rp49X5Z503I/P8ggXuhOM2kb5kR?=
=?iso-8859-1?Q?kQRvF+1EKkZuvDOtapnAcVTiVBc1SN1DmkFKqRSHM0zUfBhuzLKO6w0/7n?=
=?iso-8859-1?Q?2YNL+fsutXYTCzS/Uu7QkMH+gxddg5PCASPHm027CbIvolIM8sc63ywimz?=
=?iso-8859-1?Q?Ob+QFWAOyzhZIdh2N7Rv7lT6DI3XXoamsd0DWDEgXDSwn8+Yg41e6dByYm?=
=?iso-8859-1?Q?pDdMy895OD6Sb/UXwlupnveicQSXXFpm3VMPMRs3YkCpjt44FYjHihicbn?=
=?iso-8859-1?Q?zabMCFjFcPI/IT1CObuSO72L1xeJ7+Ydq/L3hQIW5fCF4rZoXX0avujK8X?=
=?iso-8859-1?Q?mnDIF1SPe3cFOVBlb4wvX/adrqmmDuU4HSIRxXlq3LOD/kOpgYB+8HSfhK?=
=?iso-8859-1?Q?7/kctq1/fvwmZ/vy1VTYKVgiGcb73mgvYK4pW4bl+P5+32aMtHxJiia8zf?=
=?iso-8859-1?Q?HAgGz9YegoF+kWPoOf46PhbXGLPoskKtxFxUo5aNNE6gtBbCYSocLGcTXe?=
=?iso-8859-1?Q?43gQH1H6444U1YkzWpAiuxo3UtfbxZwEVRzdkCaAkwWuGFrQcZ5dLIbiSD?=
=?iso-8859-1?Q?g5VDc5DFsdjb6o6h9isq9YbzFvvP8VfUNv7n8FzeHX4lm8WdXI1vyJknlY?=
=?iso-8859-1?Q?atbPkEwfgMhgANQL?=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MN2PR05MB6766.namprd05.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230040)(1800799024)(366016)(376014)(38070700018)(7053199007)(8096899003);
DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?zSZUDMaUQQfRLC6to4qoWDpOi51LqZkUAjaKmK/S8Ke87EHPHInRgZoRhN?=
=?iso-8859-1?Q?V+5kLK+G7Ry9GHuPWgKea/OV9giUHeAnSCUcNCnBu1apOZ7NQ8H3p2nnrn?=
=?iso-8859-1?Q?go27CT9o27GzZUJMlfB7pviFEY/8tWc+rqAfmIxfopgKhHkV67n/3PXYK/?=
=?iso-8859-1?Q?XtoYWqLJo/TJbh8+nQrwshXbY+Ki3kxvm9vMzgRi78oQbqvmK2x1jFluJc?=
=?iso-8859-1?Q?7BdwmvU2CDi/Fu14y6R8n6TPW+ZFrKpzz11X3rV+kC+vv7nI9t1CHIMsoL?=
=?iso-8859-1?Q?1G6SbdEyLXnV4ateQoungfcq+xSEY0HxIUF+SK2pU3NpeE3xB6ugzdkQM9?=
=?iso-8859-1?Q?irO6avswuNfJ4DgkjwkbrnEY/88zOFRnB3I7uENr+EzM9T0aa0BYup167+?=
=?iso-8859-1?Q?iPjRlUA8XXDCTX9X2WGJxelaYlrG4xK9A7rEv8el4WsyuRyCcD0GvbFVCr?=
=?iso-8859-1?Q?55Hef0f7LfqtWzdGMC9v1O+5XBhM05IIYAR2GYagSLLhG5VxfUT8pLdRVm?=
=?iso-8859-1?Q?e7X07CBhFP0bWyxyB0qlXjyWbmUusnGnoUAyrtxhelsJYaj2/cJa2/7JIR?=
=?iso-8859-1?Q?GpFVxeDuC0OzxB128T98ybuW1RSeBmsq3V1TSfGfH3d9Hvg/3WMdqZOBDJ?=
=?iso-8859-1?Q?uXVm9YdvkqweAuD4vjtOrcZQ2ix0vd6c6ttjgy7xxHeaAtBQlfpYx1SOdM?=
=?iso-8859-1?Q?l7AgKO3oJFuLH4GFGPL6Bb8L5EzOw2JSKnLDI9X03gCCNIH5PErhzJBohp?=
=?iso-8859-1?Q?5gBDCtgK67dIYlPuWlHWVW66ESz0qmsLED9P6hnjOAqi04bKGaJyF2EV9o?=
=?iso-8859-1?Q?fdEOd3bJAUAWy+DDdEto7lA6rZW/Afw6e8tn+pyazscUfSafvwBI3t2mBA?=
=?iso-8859-1?Q?EaMYj63pOvPq5bmMu0kMpnji/j+a2ne2+wlSGczQpWZCej3+HpfPFoGacz?=
=?iso-8859-1?Q?T2qr6Srth0Go7uFWdrMknFp0l1wYYTdKdEK5yFC7CFyPSsheWeRtASEgv4?=
=?iso-8859-1?Q?h2iqn+CT4LGWvBb7TbnRNUH4xtQn5v9cUg8dRzRg1pGzcNPJQ8q1nQIR5I?=
=?iso-8859-1?Q?iFXy169GHDfsWa6L9nuR9Pj20iScSqFC58xUYu0Skd59dAjuim2j4d7fsZ?=
=?iso-8859-1?Q?9qlJI+av/3QW6w4Bi8eR/UriqvfDhFoLCLRMSwX2j/2M3ZR2PtzEmSfUWT?=
=?iso-8859-1?Q?yjHXb/iyRIRW37W5clWpmLvF/2fUv8TljSWU7t3zZ/j31sMgqzMOfgAxvS?=
=?iso-8859-1?Q?Owklwe2hQUPJrkB8mdXr1cBMpv1fuI1GDDAz7zfX6v8vR3CsPtwrHx93Bq?=
=?iso-8859-1?Q?NsWyuG6wFOtQ+8uKjivl0dGPk4c93V6vdoNClc7XH+/53ORmqT8Y4cA+sA?=
=?iso-8859-1?Q?F4vzaqRMhF0CVc7Q8Lx7P56oKTAcf1LjLP2KmgzDgjOZIe8acGlN2tIAOU?=
=?iso-8859-1?Q?cr+G67NrEmuaOGtGAY3+wJvjPpdYAfNCAhWKzn+NvLboxfKba6r4RGgeCi?=
=?iso-8859-1?Q?ehmBkVvQ6PkbveuMvph8QYC/pR4h/Jq8wZ89s8PN+6JwyfojYmKlCY6vLt?=
=?iso-8859-1?Q?Hb+MTG0KuzUc+ltBc/8z0dZX8T+wiM9OlDIWXcJF6dYXZXO90aYlofN/sw?=
=?iso-8859-1?Q?BP4GOawodcBm7NApxGywUXF7Zyloo5UKKB?=
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: dUEXTzB5wKD7d2hKtd9ddlqm5MlWSF86v3QLQ1oCYs0+VT3Xm58IgfKnYhW3qvHDIsLl/ajcu6EVlmpo3bdfxxK5/nXItG08EJnon9OuY1B0ZB9N7odfVNoPcAxR3nvs78LO9ACxu3I5wS+F7feSLk7uO/mf87C/H2bkD/SRJrqY4iclsEYzhRp8bpeX67AVyLxcr8cT3kJf1B6J31A82trF2+jaN+oNEF8iH67I6zpVFDl7JDyBnhcyHiUIJHuOzgpOqYRTBf2xOoEP/r5X7+D1/qwLljzz7Bn2p4I+yIub9ZXocRt7NHRSxWvNzY4UnqOKVHvvQGf8c1PZgTBrU4erNVhFc+lV0+tyFHpPg0b9aVea3VoBsK1/S93rYA+SnZhPvBACjbdCOcMfi7+AYyD5nQtdj81oFmZryVIlaTAE4BKKHR9P+NRKaFYdaABdBWw1KlmU/VLBgg77UjfLLjsVszdcD3EmKehZY0WuVRxjf5KExz5zd9b+RkYOyP+OmYGN/9zdbVQv7XF+vT0EINMSQUnC4NWifWE1275WYhCu/VT55DOFomXHNudrev0HIfCXS7p1S+xCUoNzV//sznnQVDyBAhC/Le87K0tGU0Y=
X-OriginatorOrg: mathworks.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6766.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85ea8f93-2295-450e-da01-08dd5eb65e44
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2025 02:59:11.4969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99dd3a11-4348-4468-9bdd-e5072b1dc1e6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SOmeRUrD6S3+TGaWVu3hxUEFFhmq+LBkYILFkQYR0CRJIfob9F/W+ote4P74fAXSoqlSeea/MMRktbiZh8Zhyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR05MB10697
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 7EjDH1jYmr54KalIZBT2xobGvE6g-76j96Mu6CCvzL8_1741489155
X-Mimecast-Originator: mathworks.com
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_MN2PR05MB6766E7BB87CB5068B53F398ED1D72MN2PR05MB6766namp_"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76868
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--_000_MN2PR05MB6766E7BB87CB5068B53F398ED1D72MN2PR05MB6766namp_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Yes, setting cperl-fontify-trailer to comment fixes the bug. In my case, th=
e lines after the __END__ are more than just comments and get corrupted whe=
n they are indented. There is also the __DATA__ keyword and the default set=
ting of cperl-fontify-trailier causes the data to be indented which alters =
the behavior of the program (corrupts the result). Consider:
while (my $line =3D <DATA>) { print $line; }
close DATA;
__DATA__
This is not
perl code
If you indent, C-x h followed by C-M-\, the results change. Indenting shoul=
dn't change results.
Could you consider changing the default value of cperl-fontify-trailer to c=
omment so that cperl-mode doesn't indent them? Also, the name is a little m=
isleading because the more important piece is whether to semantically treat=
the lines after these keywords as perl code. The Perl interpreter never tr=
eats these as perl code, so it's odd cperl-mode treats them as perl code. T=
he only case I'm aware of where the lines following these keywords is perl =
is to use the trick to put __END__ to comment out the bottom part of a perl=
program, but even in that case, it should be colored as comments.
Thanks
________________________________
From: Mauro Aranda <maurooaranda@HIDDEN>
Sent: Saturday, March 8, 2025 10:51 AM
To: John Ciolfi <ciolfi@HIDDEN>; 76868 <at> debbugs.gnu.org <76868@debbug=
s.gnu.org>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
army knife of text editors wrote:
>
> Hi
>
> Given the following cperl-mode program, test.pl
>
> # -*- mode: cperl; -*-
> print "hello\n";
> __END__
> This is not
> perl code!
>
> The lines after the __END__ are treated as perl code. They are
syntactically colored and indented
> which is incorrect. In perl, __END__ defines the end of the Perl code
in the file. Any text that
> appears after __END__ is ignored by the Perl compiler.
>
> All lines after __END__ should be treated as comments.
>
Any chance that the option cperl-fontify-trailer helps here?
I remember reporting something similar in:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66161<https://debbugs.gnu.o=
rg/cgi/bugreport.cgi?bug=3D66161>
--_000_MN2PR05MB6766E7BB87CB5068B53F398ED1D72MN2PR05MB6766namp_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Yes, setting cperl-fontify-trailer to comment fixes the bug. In my case, th=
e lines after the __END__ are more than just comments and get corrupted whe=
n they are indented. There is also the __DATA__ keyword and the default set=
ting of cperl-fontify-trailier causes
the data to be indented which alters the behavior of the program (corrupts=
the result). Consider:</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"margin-left: 40px; font-family: Cons=
olas, Courier, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
while (my $line =3D <DATA>) { print $line; }</div>
<div class=3D"elementToProof" style=3D"margin-left: 40px; font-family: Cons=
olas, Courier, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
close DATA;</div>
<div class=3D"elementToProof" style=3D"margin-left: 40px; font-family: Cons=
olas, Courier, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
__DATA__</div>
<div class=3D"elementToProof" style=3D"margin-left: 40px; font-family: Cons=
olas, Courier, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
This is not</div>
<div class=3D"elementToProof" style=3D"margin-left: 40px; font-family: Cons=
olas, Courier, monospace; font-size: 12pt; color: rgb(0, 0, 0);">
perl code</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
If you indent, C-x h followed by C-M-\, the results change. Indenting shoul=
dn't change results.</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
Could you consider changing the default value of cperl-fontify-trailer to c=
omment so that cperl-mode doesn't indent them? Also, the name is a little m=
isleading because the more important piece is whether to semantically treat=
the lines after these keywords
as perl code. The Perl interpreter never treats these as perl code, so it'=
s odd cperl-mode treats them as perl code. The only case I'm aware of where=
the lines following these keywords is perl is to use the trick to put __EN=
D__ to comment out the bottom part
of a perl program, but even in that case, it should be colored as comments=
.</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"margin-left: 0px; font-family: Aptos=
, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; =
font-size: 12pt; color: rgb(0, 0, 0);">
Thanks</div>
<div id=3D"appendonsend"></div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<hr style=3D"display: inline-block; width: 98%;">
<div class=3D"elementToProof" dir=3D"ltr" id=3D"divRplyFwdMsg"><span style=
=3D"font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);=
"><b>From:</b> Mauro Aranda <maurooaranda@HIDDEN><br>
</span></div>
<div style=3D"direction: ltr; font-family: Calibri, sans-serif; font-size: =
11pt; color: rgb(0, 0, 0);">
<b>Sent:</b> Saturday, March 8, 2025 10:51 AM<br>
<b>To:</b> John Ciolfi <ciolfi@HIDDEN>; 76868@HIDDEN=
.org <76868 <at> debbugs.gnu.org><br>
<b>Subject:</b> Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly=
handled</div>
<div class=3D"elementToProof" style=3D"direction: ltr;"> </div>
<div class=3D"elementToProof">On 8/3/25 12:34, John Ciolfi via Bug reports =
for GNU Emacs, the Swiss<br>
army knife of text editors wrote:<br>
><br>
> Hi<br>
><br>
> Given the following cperl-mode program, test.pl<br>
><br>
> # -*- mode: cperl; -*-<br>
> print "hello\n";<br>
> __END__<br>
> This is not<br>
> perl code!<br>
><br>
> The lines after the __END__ are treated as perl code. They are<br>
syntactically colored and indented<br>
> which is incorrect. In perl, __END__ defines the end of the Perl code<=
br>
in the file. Any text that<br>
> appears after __END__ is ignored by the Perl compiler.<br>
><br>
> All lines after __END__ should be treated as comments.<br>
><br>
<br>
Any chance that the option cperl-fontify-trailer helps here?<br>
<br>
I remember reporting something similar in:</div>
<div class=3D"elementToProof"><a href=3D"https://debbugs.gnu.org/cgi/bugrep=
ort.cgi?bug=3D66161" id=3D"OWA0c28e0c5-5e16-daaa-1742-643d0966d407" class=
=3D"OWAAutoLink" data-auth=3D"NotApplicable">https://debbugs.gnu.org/cgi/bu=
greport.cgi?bug=3D66161</a></div>
</body>
</html>
--_000_MN2PR05MB6766E7BB87CB5068B53F398ED1D72MN2PR05MB6766namp_--
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.Received: (at 76868) by debbugs.gnu.org; 8 Mar 2025 15:51:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 08 10:51:30 2025 Received: from localhost ([127.0.0.1]:56252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tqwSX-0008OM-TH for submit <at> debbugs.gnu.org; Sat, 08 Mar 2025 10:51:30 -0500 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]:45254) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <maurooaranda@HIDDEN>) id 1tqwSU-0008O3-RK for 76868 <at> debbugs.gnu.org; Sat, 08 Mar 2025 10:51:27 -0500 Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2fec13a4067so4497603a91.2 for <76868 <at> debbugs.gnu.org>; Sat, 08 Mar 2025 07:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741449080; x=1742053880; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=Sw6nJvhC8LZs6ybT+yMqlATJKCIiZHmrOTk/75iQc6M=; b=OzpcZ4ut6LT1X6Q6PnEAJFymrkjvdLMvaSgY6E9jRP3n+qo18vE2vLsIzn3UV/Es7U CNeaU/1krQYw3fmbKzPeBZaIRAuO3424YqcQ+5T6vR819hQoZHTxofiogW/7dJahfCG4 7SIx0NcnYFJQPn0sT0qjiZZbjFa4yVw76+S7iu4+LDBZPrySSom9pNwb0g6NkWpnXrtM ko7+mjNGaqsfLppQObif2hwGt95f3WsQgsCofE18fxtSYHKOvNWsxl7V/jMyVL0/9VAE pZrPeWsTw50j4+UoVu4SITU9eUyAXl+pgTVfQXEbKJ2GP2j5YHochRpgpPuK2Z7ZWYF9 0nRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741449080; x=1742053880; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Sw6nJvhC8LZs6ybT+yMqlATJKCIiZHmrOTk/75iQc6M=; b=jCzVFEN7lMmHdS+UsVFKQ5z9KkfNjb7WhMnsTp0bB8BllFAWQxWQMmC+pDzRGzQSJ/ 1kxWVpME8iggzd4I8pt/Qgy1j21GearRn/bawmU5gpptc4znrLc9tAMGLmS5dE9vPViu KiPHz1zMYJF+Qm4Zpq82Q5sMSlzmRB6G+psKdHo3cVbHZ3zS8eCWhz6G3/uQ5e+hsa+2 12C+ARDWa7ovfPzhqc73YufTlL7fbkWIbp2EPPFyvlikTjDEcvI97dUNuWf1G7WZdcEj 4b3yqeenFxvhMVbfV/aPOoc5/uTr2hwdQnFZ1DZF7c5wDC2F6E/DbpEDeJ+TAv2AyKz2 38Fg== X-Forwarded-Encrypted: i=1; AJvYcCWncJxJwR9Qk7oELdquj42nxWALUHehqoL8K9FGuTBtyQlqrRZ1jWbqS5Ps8xMoHeXgV+vY1g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwaMppwBxC8sb4goELZzH1AdWrVduOLBKH56/M8/ymbMHVONIcR VGTnwzcJTVr2sb4VNF42JrqfdjDq1CcKT5O6nHEUEyL6Li4JXHNh X-Gm-Gg: ASbGncuDF8DHBRY4oo64IzZejA4crD1X70OztpKIrLkAhtwUTyJr5sQefFVfc31VLpk kKR1T+fXCyQlW5030G++veMddu/lCinJqcJ6RKERBRTWOYLDnHvO82kkry0SOhQfsBS5a8Fmq4S fjz9c5O+ty1Fe1smMa4MCvxln+2FltWSFzP8NhA6wSYdyZCaDxEI1q4f+QnujqQhu3EE38aUGxK 2iSQMsjBvTXpnwqOnnaVUmhnv67fs8UNetRsHTGm5iPoQufz0ay56UHbOnOSiqUGLqJ7WLXcg2F LeiPEzIB7crzU6rZTJT0/Vd3l7GxVGaxpbO1TLB+DdrjJUXY4a34B9dtDwoGMQ== X-Google-Smtp-Source: AGHT+IFQxvohsSIZMx6rPjy8VZRqmJchxcBqha0NwaAZ60p1tNzN3smOmAYfwDbOuAk8Pnvtwf+Zdg== X-Received: by 2002:a17:90b:38ca:b0:2f7:7680:51a6 with SMTP id 98e67ed59e1d1-2ff7ce65528mr11339885a91.6.1741449080489; Sat, 08 Mar 2025 07:51:20 -0800 (PST) Received: from [192.168.0.234] ([181.228.33.6]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2ff4e7ff96esm6766318a91.35.2025.03.08.07.51.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Mar 2025 07:51:19 -0800 (PST) Message-ID: <6a11c30b-0972-4ec0-8709-a7a595be3636@HIDDEN> Date: Sat, 8 Mar 2025 12:51:16 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled To: ciolfi@HIDDEN, 76868 <at> debbugs.gnu.org References: <r9ldtfh6yr.fsf@HIDDEN> Content-Language: en-US From: Mauro Aranda <maurooaranda@HIDDEN> In-Reply-To: <r9ldtfh6yr.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76868 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > > Hi > > Given the following cperl-mode program, test.pl > > # -*- mode: cperl; -*- > print "hello\n"; > __END__ > This is not > perl code! > > The lines after the __END__ are treated as perl code. They are syntactically colored and indented > which is incorrect. In perl, __END__ defines the end of the Perl code in the file. Any text that > appears after __END__ is ignored by the Perl compiler. > > All lines after __END__ should be treated as comments. > Any chance that the option cperl-fontify-trailer helps here? I remember reporting something similar in: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161
bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 8 Mar 2025 15:34:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 08 10:34:51 2025
Received: from localhost ([127.0.0.1]:56174 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tqwCQ-0004P0-20
for submit <at> debbugs.gnu.org; Sat, 08 Mar 2025 10:34:51 -0500
Received: from lists.gnu.org ([2001:470:142::17]:48142)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ciolfi@HIDDEN>)
id 1tqwCM-0004OY-4G
for submit <at> debbugs.gnu.org; Sat, 08 Mar 2025 10:34:47 -0500
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 <ciolfi@HIDDEN>)
id 1tqwCF-0004S4-27
for bug-gnu-emacs@HIDDEN; Sat, 08 Mar 2025 10:34:39 -0500
Received: from us-smtp-delivery-120.mimecast.com ([170.10.129.120])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ciolfi@HIDDEN>)
id 1tqwCB-0003rD-RE
for bug-gnu-emacs@HIDDEN; Sat, 08 Mar 2025 10:34:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com;
s=mimecast20180117; t=1741448073;
h=from:from:reply-to:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
content-type:content-type: content-transfer-encoding:content-transfer-encoding;
bh=1hqIZPwpsxVQ3TZPSJ5BUDFswHv3smhdjSYGMDtklj4=;
b=EXgI0+QWEG0rSwMMASERTzq6dwFFegwcnwQlJ8mI7Djkvz0dj44rrbxv4/rJy4+7HsGXBj
qhEpwmiH0Aj/nvGTqG44TQ61fdX0cKf+wJpH0BgQxZrT0XVSCfr522l0ibBzNqhjTn+fpk
1JZO3jMUqvyHU/uBenaIq9MFbrpQojc=
Received: from CY3PR05CU001.outbound.protection.outlook.com
(mail-westcentralusazlp17013075.outbound.protection.outlook.com
[40.93.6.75]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-693-NQpQ-qkdPZ2XbD4-i6eaEg-1; Sat, 08 Mar 2025 10:34:30 -0500
X-MC-Unique: NQpQ-qkdPZ2XbD4-i6eaEg-1
X-Mimecast-MFC-AGG-ID: NQpQ-qkdPZ2XbD4-i6eaEg_1741448069
Received: from SA9PR13CA0029.namprd13.prod.outlook.com (2603:10b6:806:21::34)
by BL3PR05MB9164.namprd05.prod.outlook.com (2603:10b6:208:3bb::16)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.24; Sat, 8 Mar
2025 15:34:23 +0000
Received: from SN1PEPF0002BA50.namprd03.prod.outlook.com
(2603:10b6:806:21:cafe::b7) by SA9PR13CA0029.outlook.office365.com
(2603:10b6:806:21::34) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8534.15 via Frontend Transport; Sat,
8 Mar 2025 15:34:23 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 144.212.100.35)
smtp.mailfrom=mathworks.com; dkim=none (message not signed)
header.d=none;dmarc=pass action=none header.from=mathworks.com
Received: from exedge.mathworks.com (144.212.100.35) by
SN1PEPF0002BA50.mail.protection.outlook.com (10.167.242.73) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.8511.15 via Frontend Transport; Sat, 8 Mar 2025 15:34:22 +0000
Received: from EX1901AH.mathworks.com (172.31.53.42) by
EX19EDGE00AH.mathworks.com (172.31.187.34) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1544.14; Sat, 8 Mar 2025 10:35:43 -0500
Received: from EX1901AH.mathworks.com (172.31.53.42) by EX1901AH.mathworks.com
(172.31.53.42) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Sat, 8 Mar
2025 10:34:20 -0500
Received: from mail-vif.mathworks.com (144.212.95.101) by
EX1901AH.mathworks.com (172.31.53.42) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1544.14 via Frontend Transport; Sat, 8 Mar 2025 10:34:20 -0500
Received: from ah-ciolfi-l.dhcp.mathworks.com (ah-ciolfi-l.dhcp.mathworks.com
[172.21.82.138])
by mail-vif.mathworks.com (8.14.7/8.14.7) with ESMTP id 528FYKmL024499;
Sat, 8 Mar 2025 10:34:20 -0500
Received: from ah-ciolfi-l.dhcp.mathworks.com (localhost [127.0.0.1])
by ah-ciolfi-l.dhcp.mathworks.com (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with
ESMTP id 528FYKOn299160; Sat, 8 Mar 2025 10:34:20 -0500
Received: (from ciolfi@localhost)
by ah-ciolfi-l.dhcp.mathworks.com (8.17.1.9/8.17.1.9/Submit) id 528FYKOp299159;
Sat, 8 Mar 2025 10:34:20 -0500
X-Authentication-Warning: ah-ciolfi-l.dhcp.mathworks.com: ciolfi set sender to
ciolfi@HIDDEN using -f
From: John Ciolfi <ciolfi@HIDDEN>
To: <bug-gnu-emacs@HIDDEN>
Subject: 29.4; cperl-mode __END__ is incorrectly handled
Date: Sat, 8 Mar 2025 10:34:20 -0500
Message-ID: <r9ldtfh6yr.fsf@HIDDEN>
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA50:EE_|BL3PR05MB9164:EE_
X-MS-Office365-Filtering-Correlation-Id: 78abda01-1767-40a8-22a7-08dd5e56b39c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
ARA:13230040|82310400026|376014|36860700013|1800799024
X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?BncLDFJ/6/mV03OCmgf0IZoxoNQEs3z35sv+FtEVx9VqYlY07g1yD721erSl?=
=?us-ascii?Q?9AR9WSXIO9i0XIzGT1WUvw7wsExNEGhyNai8nbIRNDz3HM0xJz7eO8iWV0Q8?=
=?us-ascii?Q?GBqMPtsCX/Zm6KhRWCG6Z1glwvEjlrmEjnrZvU4XfzOR6b9YammXX4gj5i7/?=
=?us-ascii?Q?33tczv1UCcF7IALxY2coBJlc3gEKuWZjZMj4QwcSlvv0J6QI22aNF61X2XUc?=
=?us-ascii?Q?rOlZ3P1FbQ4ZaVKrBeUfrnujC5zOiblD1E1+6Rt0V4KSliDVHVF4umxrhn7W?=
=?us-ascii?Q?YUtcZUFgkgqtcTMTeORBT36y5ufh18LcqDJI4DdLYr1g5jhA/JEoHwvB78Xh?=
=?us-ascii?Q?VQv6+KvHZR+uYbBCjRUriW9z1uUc0eyPVB/+Un2ySI8l34497Lw8ug6Bal9D?=
=?us-ascii?Q?nmyTTpKnVOtn54CTMyGT5u9vDK9jh91T9I9AyLkhh7U5W7MRQ0CaUi5OmNRF?=
=?us-ascii?Q?Y9v+hDno3zM5yz2Vzh4+NdBsuStGWWv4HSUpHtzA5MCNDsNmSQWU5Inw6wEK?=
=?us-ascii?Q?nhPTmNW/tNczB2frimmji0mnbRYflMxfOlmc9Fvnt1M0cR5N0x7TRvPwCLCz?=
=?us-ascii?Q?n+TKnPPluUxpt8QWA+5qH+wC3vJpJZNI7dMhROpucbjXbAuoGS03F3YNTP4q?=
=?us-ascii?Q?CLwBb42w8OuKH1bHIGMUEVLplvZtxPXHYzXVtW0qdoqnMUHjrs5nhcPSDEeJ?=
=?us-ascii?Q?lHGVZvpgV5w1A58IFx/VeB0JU3axgtiUBEaV5EUA3a3gHPrsj9sBQFPtWpPW?=
=?us-ascii?Q?wgip7NignV0GhooZykWxbg2CB0V6YoK5B0+aVNxfs+QGrTz2k5UuQ4c30uZv?=
=?us-ascii?Q?d7s1h+u8rdy8LP7t3Ona9FowWzhyeQEZY3SevbGycH/JYmCeeresuxGBp/zm?=
=?us-ascii?Q?E7UqiI8Sve9HSuNwETG9M7cMK8K4R4uJKWIF9AZZ19sZvzBV/xP7PUGPwn+G?=
=?us-ascii?Q?C+3DSR2q2VOlKKh16HqzlvxbWTG4GQXPtzTsvNQ+KiBFwxBSJ+AB5S+qn3Dt?=
=?us-ascii?Q?3uUcUARoabUIcIoYS8jiN+2EcicW3aZpzn5qzNP+NKw3aIs15DMuP/r6OHzP?=
=?us-ascii?Q?AdPB6IiaBSUr8AUuoM4SYZZyOlsHntnWKaxKPnEm8kAnModKO1HmCfeqU9Ss?=
=?us-ascii?Q?ZRvtaCBHOA7G2xcu5z3ljXB67PSCYlZ37iWo3GVQb6xqk9GfeXTLgrJ0cGT9?=
=?us-ascii?Q?2FS0wAQeRciwmwqZqC1BkrlrLkNfJPm/wULFYLGN5shksZi21o1ti+NbTkAI?=
=?us-ascii?Q?KXzpZBZrf72vtDZjQBpGkuDEVmrexXNW2R/nIuRMKlrIXUGr2IOY23sGGcqd?=
=?us-ascii?Q?vMGt1oYkzv9DSAT3LdCwDcVC/9yKS8LzdFbDHlMZL8X5g+zYkQM9WSQt/Sow?=
=?us-ascii?Q?Dl7SF1hc+BQ/laQjQSkBGFzOvmrlZmVfIAtD81uTdryuuvVXE+3FMO471xqH?=
=?us-ascii?Q?aLyVxfn27lgScjgiqE5zYUES+d2+zxcnFmjMZRdqvYWKtbGuINxM1g=3D=3D?=
X-Forefront-Antispam-Report: CIP:144.212.100.35; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:exedge.mathworks.com; PTR:mxgw-ah.mathworks.com; CAT:NONE;
SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024); DIR:OUT;
SFP:1101
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: l+htVkHO29AqvENOefo/sWBMfocdZvFaCCcSHE5HLaQEx5VKt9hJFNt23HCwe/V1tz40kHPe79ZAaZw5Z3ocvMvtTKfdkmnJ/JL0cE0V/Fb46ABRMjuPz+riYHFt7QSkHnzqUMCYk/7Yy8anpbANCWsWw1SisTiZuvybb+f+kDxIer2v416zgA97vI/rwtlI8uYqu1Cb4wh9xV7hVI+RVjxT8j6b95k3TeTzDOwFI/6CJJqFVuO4HiNxTqGLvsm+U+s9eH8iTL2GQlbSJGyuxtrQGz0lDqfjUxB5Q6LbscPezMXmZ+y3hDP42mnSiX7KHTEimtBtsxqG664iYxl0SVQM3UNRqcpDvjM5m1yeq8qQQejbCm2XUQc26eTAR6addtjhqmvLOPLzHNMYbJGY88nipgh3jyosUpT7tbKrysLkZBNZbWWdD3bUD5ysQYNs2fgREvKNK4nzf94AOMEFxTfshEkHLJnB2vU/bz5SEE9S/Lh2gOXDq8whEprgiLTMK2Ui3yOZDvjqZ+Tf9LH28pgvEUdo3g8jqiSj3t4w8XnYEJ+43I5hvo47ROnDHZAcXzplnUnNn3P5o8qhHCp+e8SdaDzSnOJ3+ilyb8+C7G8=
X-OriginatorOrg: mathworks.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2025 15:34:22.8156 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 78abda01-1767-40a8-22a7-08dd5e56b39c
X-MS-Exchange-CrossTenant-Id: 99dd3a11-4348-4468-9bdd-e5072b1dc1e6
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=99dd3a11-4348-4468-9bdd-e5072b1dc1e6; Ip=[144.212.100.35];
Helo=[exedge.mathworks.com]
X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002BA50.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR05MB9164
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: qJ7LpDkU1eYzZbJIIrHssqn9XQn67AsV5xliS5fIbMY_1741448069
X-Mimecast-Originator: mathworks.com
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=170.10.129.120; envelope-from=ciolfi@HIDDEN;
helo=us-smtp-delivery-120.mimecast.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: ciolfi@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
Hi
Given the following cperl-mode program, test.pl
# -*- mode: cperl; -*-
print "hello\n";
__END__
This is not
perl code!
The lines after the __END__ are treated as perl code. They are syntacticall=
y colored and indented
which is incorrect. In perl, __END__ defines the end of the Perl code in th=
e file. Any text that
appears after __END__ is ignored by the Perl compiler.
All lines after __END__ should be treated as comments.
Thanks
John
In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0) of 2024-07-22, modified by Debian built on
x86-ubc-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --build x86_64-linux-gnu --prefix=3D/usr
--sharedstatedir=3D/var/lib --libexecdir=3D/usr/libexec
--localstatedir=3D/var/lib --infodir=3D/usr/share/info
--mandir=3D/usr/share/man --with-libsystemd --with-pop=3Dyes
--enable-locallisppath=3D/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:=
/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share=
/emacs/site-lisp
--with-sound=3Dalsa --without-gconf --with-mailutils
--with-native-compilation --build x86_64-linux-gnu --prefix=3D/usr
--sharedstatedir=3D/var/lib --libexecdir=3D/usr/libexec
--localstatedir=3D/var/lib --infodir=3D/usr/share/info
--mandir=3D/usr/share/man --with-libsystemd --with-pop=3Dyes
--enable-locallisppath=3D/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:=
/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share=
/emacs/site-lisp
--with-sound=3Dalsa --without-gconf --with-mailutils
--with-native-compilation --with-cairo --with-x=3Dyes
--with-x-toolkit=3Dgtk3 --with-toolkit-scroll-bars 'CFLAGS=3D-g -O2
-ffile-prefix-map=3D/build/reproducible-path/emacs-29.4+1=3D. -fstack-prot=
ector-strong
-Wformat -Werror=3Dformat-security -Wall' 'CPPFLAGS=3D-Wdate-time
-D_FORTIFY_SOURCE=3D2' LDFLAGS=3D-Wl,-z,relro'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr
warnings subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp
byte-compile cus-edit pp cus-start cus-load icons wid-edit cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 105675 8530)
(symbols 48 8853 7)
(strings 32 23487 2243)
(string-bytes 1 691014)
(vectors 16 17555)
(vector-slots 8 353713 18074)
(floats 8 39 42)
(intervals 56 579 2)
(buffers 984 14))
ciolfi@HIDDEN:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#76868; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.