From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 15:37:07 +0200 Message-ID: References: <877dfavmzw.fsf@posteo.net> <875yuut79f.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34208"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 15:40:26 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mSg0V-0008Y3-FV for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 15:40:24 +0200 Original-Received: from localhost ([::1]:35034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSg0Q-0006eW-Me for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 09:40:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfxT-0003Pm-HH for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:37:15 -0400 Original-Received: from mail-oln040092071038.outbound.protection.outlook.com ([40.92.71.38]:6180 helo=EUR03-DB5-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfxP-0000Kp-J4 for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:37:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nH4cYD3OdU+0i4KVA4bLOZGC0f52zd6klicVxW56prLIRUTOGadLGr9WoR5mIy3ZWaTkpGTYshGw9fYHOPY1zrDIvJFslX9IOTdAeezxx1r2tuMMwod0yCODJ9LRdg6CRAm69m6aVOTvSsbIAzMViuDhi0n7J/nbN3v7CkqxKXNV9iriFesqovE81FsFR2EGcIyuKgZHgFlqGWkJ8VLJXQCvdwd0Er9O5J0ncBM7hctHOTW3BkclAmKb2Bb7X7IeqA7VC8Qm5hew4MGWNuRJfiVEEiUzFzqoQbKUySsDBaWak+pj3+nEpwg8OUVteQIj2SvCN/F4qHjyYRbElkYFUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PTkcXAjoivCWn291G0q3urzl6xn0f3UQevhJxFNa684=; b=T3FexLExsNtWQVFjPgHx9trjUd/wkYsVoBve+/9tpzharblCYZWy09fp7UqJaj6V+WP4qqJtqGSBRNCpcy4ghUZgONtdUGBUOACdQej1PhKKmZJoURHOfWYaBDlwb6b02OgJD53A+yVXwUNR2xPsRclL6vY7c3FwOZDjGt8U6OBbCmbQXBBeqmQ7GunyeCfUZSs0OJl7pS9yTojeCg+znie8SJLn5PpYtK/nr9agi9k/krGgwE4ZbEM7pE5FTFkAOLVw6EBG2cdSR3amPcqC0OTYlzY+MxVsaWyxExLGGFnCCQt1AbB+VNo4qIe9POnrVpwVFM4UHoBFXTgQBbdCcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PTkcXAjoivCWn291G0q3urzl6xn0f3UQevhJxFNa684=; b=RFVcCQdsjrtefzUj6ILUa8xPh9NqK0yhpII+wHIKyqL6DbDHFOYnVc4A7CJvqeJNQErz7REiPK40Sb6tBuPCSTvzwc2Bifa3BdRCuWxVxPOTgIMX0Jz7c9xqWfmHtpUxWyngTjOTMsA+vb2sQh3mePsqbtjVdHdAzD5o5l0wv3rdXVxuhe9Ok8OJXckagAy9xJRchg2faFWmq6ds1QG5iujTtDOUoGF4FyIZ168h/o2sZGZQ65HKavw5367v7/JcEto+IapXBBYcTdAHx8zj6Cy+9v/nY4bzGxmIx/SDZiGF+J7jkIf5q6zpuqEWIO6nRUrpgAND486L2ZJ7PEFh5A== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB5185.eurprd09.prod.outlook.com (2603:10a6:20b:30a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Tue, 21 Sep 2021 13:37:09 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c55c:ece5:bed2:a9dc]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c55c:ece5:bed2:a9dc%9]) with mapi id 15.20.4544.013; Tue, 21 Sep 2021 13:37:09 +0000 In-Reply-To: <875yuut79f.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 21 Sep 2021 12:58:36 +0000") X-TMN: [QPTL8y6atOmfNqFfMwPRNWl5PTkimG7b] X-ClientProxiedBy: HE1PR0502CA0017.eurprd05.prod.outlook.com (2603:10a6:3:e3::27) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87wnnaqccc.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by HE1PR0502CA0017.eurprd05.prod.outlook.com (2603:10a6:3:e3::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13 via Frontend Transport; Tue, 21 Sep 2021 13:37:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 35fdb50b-7efe-4390-7f57-08d97d04e8c8 X-MS-TrafficTypeDiagnostic: AM9PR09MB5185: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hSqpmksXYeOTsjAS58wL8iK19kPbyQsbu9vJdK7pnVlk4DoGYlfBNmM57vdRNVlY0NPhKvE+4N7Bg1eDRujIKqgavJXzR6Z5jNNXSO5OnalnieLSaBxG4b5viRJzoSmBQznL9lNctzxkuvHnnuWyY/NAE++qqN8lvBMg9hxV8iKr/aHptf8K4DqnFl54ErMhfWwJJQT78ehzvlwiIH2nFVQx4fTOV50xB/bExVaq0Kr0/nwcWhT096zd/56RfcOsFj7SYhBZP7GBKDwjOJRIeuqPMbQNjuFERj3wOEkz5vQAfFr+qzUssge+RvVayroHwInD4A7kDQoCMWU7mCzIAsEhhADZvDyPnlYvA/HQv9OtcB8OXE56To71rf3zk6kiIptPIF7BGO7S3DfddYsUToPImkchNphmrE1BFFoFiXU0XZLbrpIEmoWLUIIHlYX6 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kLOgqgD9ZHJCb/sPXiTb15W+oocFAEe/gBu4y/WRYluWmAty3cY5onIxjFQyHoDnlYZtE1tqXfmt8r0RyPc+bGWO546n1hYjFuehR+gqJzBgIALZ+sdIMlMChEQ+ZYJvf7rlAlR6cbuNuBJfjiYbNw== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 35fdb50b-7efe-4390-7f57-08d97d04e8c8 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2021 13:37:09.1885 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB5185 Received-SPF: pass client-ip=40.92.71.38; envelope-from=arthur.miller@live.com; helo=EUR03-DB5-obe.outbound.protection.outlook.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, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275231 Archived-At: Philip Kaludercic writes: > Stefan Monnier writes: > >>> By its very nature it is an intrusive package, as it defines functions, >>> macros and advice outside of the "namespace", but I don't see any way >>> around that if transparent compatibility is to be provided (anything >>> else would just replicate dash, s, f, ...). >> >> I think this uncleanliness is a bit risky. Better put the definitions >> in their own namespace. > > Just to be on the same page, what exactly is the risk? I understand the > issue on a gut-level, it goes against convention and recommendations, > but the idea is that this package would do that, so that others don't > have to. It is not on a "gut-level" :). I was thinking about same, and wrote you a longer answer I just sent. There were no replys when I started, I see now several people replied. There can be two functions defineing slightly different behaviour in different version, there can also be 3rd party packages expecting certain behaviour, and there is no need to advise too much, say windowing code if application need to just check is directory-empty-p. > Other than that, all the functions and macros are defined first using a > "compat--" prefix, then perhaps are aliased to a symbol without a > prefix. > >> I don't think "transparent compatibility" is >> worth the trouble here, and I don't think `s`, `f`, ... solve the >> same problem. > > Of course not, s, f, and the rest of the dash-adjacent ecosystem have > different intentions, it is only as a side effect that they provide more > functionality than older versions of Emacs do. They define different API from Emacs, more used by people comming from different Lisp(s), clojure if I am correct? > Most of the examples I provide in the file I attached above are simple > or slower reimplementations that make programming more convenient, but > where "transparent compatibility" becomes interesting is when providing > noop compatibility that allows package developers to make use of newer > features that are not backwards compatible, such as the additional > interactive argument. The infrastructure doesn't exist to handle this > information, but package developers will hold back from using these new > features because they don't want to abandon all users that aren't on > 28.1. > > I don't see how examples like these could be handled without transparent > compatibility. When it comes to providing newly intoduced functionality, there shouldn't be a problem, it should always be possible to just add a function, like dired-empty-p: (when (version< emacs-version "28") (defun directory-empty-p (file-name) "Check if a directory contains any other files then dot-files" (when (file-directory-p file-name) (null (directory-files file-name nil directory-files-no-dot-files-regexp t))))) You don't even need to advise directory-files for that. But for already existing functions that might lead to problems. I think so at least. In the answer I sent you, I was thinking of buffer-local function variables instead of advices which are global.