From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 17:50:52 -0400 Message-ID: References: <877dfavmzw.fsf@posteo.net> <87czp2c6qd.fsf@gnus.org> <87o88lr63i.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="23917"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , 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 23:52:24 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 1mSngc-0005vg-Pq for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 23:52:22 +0200 Original-Received: from localhost ([::1]:44502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSnga-0000Gy-Kd for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 17:52:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSnfl-00081e-HW for emacs-devel@gnu.org; Tue, 21 Sep 2021 17:51:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSnfi-0005YA-LG for emacs-devel@gnu.org; Tue, 21 Sep 2021 17:51:28 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CD0DF10018E; Tue, 21 Sep 2021 17:51:23 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 597F7100174; Tue, 21 Sep 2021 17:51:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1632261082; bh=NQyUWQHRtzUKm3qaSWwZrNgt+51XM3BbTtb0rfkh4lw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=XSwOHbckPvTcqS2zJ/C8zNVx37RA6ZP9EhLEWYXNtf6zylsEilR0spifFVYGlAanJ yEql59UxQ2YKb7sfTYI3fEUDd1F2stZWP4XRICLTd66tr9XqBkVV4IXf2qOSe4Dtv/ vdJjhfBuR7UHFqPxfsQwcRMz7xtKpTgvzAl3kt1BqFBm6niD6zeB0OODxzUZ5xMuEf wFvP8WfqVIrs91f0EWF1PmE2YCHyX5WHwD2rVHBbVMKhI3HzEhrmnHaLcsnrkFZqHV Ospxae44SRd/xOWNn8qujPe6TVGVTTe8UjATK96f0hQ2Qmorva2F1qoRU2fkWatARR Z8IHaItEu3Irw== Original-Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 41EBE12023A; Tue, 21 Sep 2021 17:51:22 -0400 (EDT) In-Reply-To: <87o88lr63i.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 21 Sep 2021 21:06:41 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:275272 Archived-At: > I am not sure how this would help provide forwards compatibility for > older versions? Are you proposing that instead of using > file-name-concat, libraries use compat28-file-name-concat that is > defined in a library for older versions? Yes. > My intuition would be that this wouldn't be worth the effort, seeing as > most people would probably hesitate to use such long names. If the function is important enough that the author would otherwise make its own local function, then I think they'd be happy to use that slightly longer name rather than having their own local definition. If not, then it's probably just as well if they simply don't use it (and that should avoid having the compatibility library accrue too many definitions of too little value). Stefan