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 19:12:31 +0300 Message-ID: <83k0hzydcg.fsf@gnu.org> References: <83sfwp1c27.fsf@gnu.org> <83sfwnyi65.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21894"; 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 18:21:32 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 1mfPCd-0005Sr-O7 for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 18:21:31 +0200 Original-Received: from localhost ([::1]:57026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfPCb-0002Ru-Ow for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 12:21:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfP40-0007bq-SK for emacs-devel@gnu.org; Tue, 26 Oct 2021 12:12:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfP40-0001RG-Ef; Tue, 26 Oct 2021 12:12:36 -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=lidpRwha3ipBxa7zrwmHiUvD5lI4qzhLMRgLydHCsJE=; b=hb0Wrm8GMsEg bgOAxdxAsGu3jOWCnxTb7e7YrCdQ3kwbanc78BMlXas1bcNtHlgK0cPAtF3tqI6YbRVlgyQEaUt9t aJ7DjtsVBrX0qYBpnkiBXX9pHq6uQ+P4bzI/h/X8Pc4IQmF9aIUUe3KW/He83Uz1vCbH8xbyIY5cM is5NVT5awee2/YxYbIkmR5mVgRy8q+0lJF/D0g/JT0N/mJxqJp9X1G+K4K0AxIdY4f0TVUuCP4leE fAwDzsQ7/XoiTZwK9UoB9uvBTXynGi7cwvJF1p6UAr8btqbpjj2C2/06fHNcYHCGCewnMJbAyyuiN vBmuz4CY1n5hQf3jcnr8RA==; Original-Received: from [87.69.77.57] (port=1163 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 1mfP3z-0003K1-Gl; Tue, 26 Oct 2021 12:12:36 -0400 In-Reply-To: (message from Stefan Kangas on Tue, 26 Oct 2021 16:45:04 +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:277886 Archived-At: > From: Stefan Kangas > Date: Tue, 26 Oct 2021 16:45:04 +0200 > Cc: Emacs developers > > Eli Zaretskii writes: > > > 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. > > OK, I think we agree that this would be a good thing. > > The contentious point seems to be what we should do until we have such > a library. I think that it is better to update hardcoded strings to > use xdg.el, since it will make the above idea easier to implement. > > However, if we have a plan for a higher-level API in a reasonable > time-frame (for example, before Emacs 29 is released), then I am more > than happy to accept that we might as well wait with any such changes > until that work is done. It is so easy to provide this API (or set of APIs) piecemeal that I don't see why we would need to wait for anything. Let's simply start a file called, say, std-dirs.el or somesuch, and add support there for each directory we bump into. For example, in the specific case that triggered this, just add a function there that calls (or (xdg-user-dir "PICTURES") "~/pics/") and call that function in image-dired.el. Before long, we will have everything we need, and more. If you don't want to provide support for anything except XDG, you can initially leave the fixed strings there as the alternatives, and someone else will pick up where you left off and fill in the blanks. The only decision we need to make is whether we want a single function that accepts an argument telling it the purpose of the standard directory (in this case, I'd use 'PICTURES, a symbol), or maybe a separate function for each kind of directory, like user-pictures-dir.