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: Mon, 25 Oct 2021 16:14:24 +0300 Message-ID: <83sfwp1c27.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12807"; 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 Mon Oct 25 15:17:44 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 1mezrD-00036h-Fd for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 15:17:43 +0200 Original-Received: from localhost ([::1]:45702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mezrB-000610-E1 for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 09:17:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mezo8-0002S3-L2 for emacs-devel@gnu.org; Mon, 25 Oct 2021 09:14:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41522) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mezo8-0000Rz-4b; Mon, 25 Oct 2021 09:14:32 -0400 Original-Received: from [87.69.77.57] (port=4055 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 1mezo7-0004cw-My; Mon, 25 Oct 2021 13:14:32 +0000 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:277747 Archived-At: I can't say I'm happy with creeping of XDG specifics into our application code. It's too platform-specific, so it gets in the way of either adhering to platform-specific directories on each platform, or having completely platform-independent identical directories on all platforms. Both of these alternatives could be useful, but XDG provides neither: it only caters to a single platform, and leaves the rest to manual coding. Here's the result: (defcustom image-dired-main-image-directory (or (xdg-user-dir "PICTURES") "~/pics/") Why "~/pics/"? What platform behaves like that? Probably none. 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? To me, xdg.el was supposed to be a platform-specific layer on which to base platform-independent abstractions. Those abstractions should have other platform-specific layers for other platforms, and the abstractions should then be used in application code. So when fashions change on this or that platform, we need to change only the code that implements the abstractions. Our handling of XDG in startup.el to find the user's Emacs home directory fits this description; code like the above does not. Can we agree not to use xdg.el in application code, and instead develop those abstractions and start using them? For example, how about having a function user-pics-directory, which will return the appropriate file name for the underlying platform? Doing that will not diminish our support for XDG (as long as it lasts), but will allow us to have application code XDG-clean, so to speak. OK?