From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master f8fed41 2/3: image-dired: Improve XDG compliance Date: Tue, 26 Oct 2021 17:28:18 +0300 Message-ID: <83sfwnyi65.fsf@gnu.org> References: <83sfwp1c27.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14707"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 16:34:35 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 1mfNX8-0003U9-Ku for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 16:34:34 +0200 Original-Received: from localhost ([::1]:40042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfNX7-0000hU-3T for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 10:34:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNRA-0003HD-Lv for emacs-devel@gnu.org; Tue, 26 Oct 2021 10:28:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNRA-00024s-72; Tue, 26 Oct 2021 10:28:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=guauYLZBKyhCiut8gXDGa7xbA88EyGLA4QeZ9CJr67Y=; b=ar4SCY4xTTPr JMitcoLy/E1f09ZGnTyjSD3Mubb8NhaKDdJFn1yOyvWHC9vPxagwuttMLd6gPg7UurkFO3uw23Bqw RCBnaFAsfn0IuwHHIYMkZjC7FpmLiNlFr4Z4+Q2170IKOqEj6bgEG4up6YM2fBDPkBM1XLFm5PovW 9lnRwdrOe8bfxYj8cyUmMcr91n9P3KjkqxX6oZQ+ON0hq+iaWQXp9tRLlyLTVA5pHmXFmT6Tib8jx UzvDvvpBq25VjBPmk2Gu805r5Pxj0jmaa7a4X9mrs6EpfODrSKGv9JFgBJgH8ldX6Axs9CEulpMf5 rpWAcWT6e7wAxcUkRdKaww==; Original-Received: from [87.69.77.57] (port=1739 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNR8-00026r-QP; Tue, 26 Oct 2021 10:28:23 -0400 In-Reply-To: (message from Stefan Kangas on Tue, 26 Oct 2021 16:01:50 +0200) 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:277870 Archived-At: > From: Stefan Kangas > Date: Tue, 26 Oct 2021 16:01:50 +0200 > Cc: Emacs developers > > Eli Zaretskii writes: > > > XDG is also prone to fashion changes. What will we do when it goes > > out of fashion, and we have dozens of xdg-user-dir calls in our > > application code? change all of them to some latest desktop fashion? > > Yes, that's what we should do in that case. I'm quite astonished to read this, coming from an active Emacs developer. It's basically an antithesis of good maintainability. > Such work will be much > easier if we have already adapted our code to use the xdg > specification: if you move xdg.el to "lisp/obsolete" the byte-compiler > will warn about any places where we use it. But we have no easy way > to find strings like "~/pics", and therefore can't easily update them. I didn't propose to have hard-coded strings like "~/pics", not at all. I proposed to have a couple of higher-level APIs that will hide system-dependent stuff, including hard-coded strings if some systems need that. xdg.el will then be one layer lower, and application code will not call it directly. > In other words, if we expect the standard to change very soon, it is > already a step forward to update hardcoded strings like "~/pics" like > I did in image-dired.el. These "semi-standards" change quite frequently, and we should be prepared for the next change in advance, even if we don't know when will that happen. > However, I don't really see any reason to expect a replacement to the > XDG Base Directory Specification (XDG BDS) any time soon. As Philip > points out, it has only become more ubiquitous over the almost 20 > years since its inception, and no replacement is on the horizon. > Therefore, this all seems very academic to me, and I think the points > below about other platforms are more immediately relevant. Good maintainability is not an academic subject, it is pretty much in our face here.