From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: master f8fed41 2/3: image-dired: Improve XDG compliance Date: Tue, 26 Oct 2021 16:01:50 +0200 Message-ID: References: <83sfwp1c27.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3871"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 16:02:47 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 1mfN2M-0000pH-9c for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 16:02:46 +0200 Original-Received: from localhost ([::1]:41650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfN2K-0004My-Oi for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 10:02:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfN1i-0003eU-IR for emacs-devel@gnu.org; Tue, 26 Oct 2021 10:02:06 -0400 Original-Received: from mail-pj1-f47.google.com ([209.85.216.47]:40663) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfN1g-00042Z-84; Tue, 26 Oct 2021 10:02:06 -0400 Original-Received: by mail-pj1-f47.google.com with SMTP id n36-20020a17090a5aa700b0019fa884ab85so2325420pji.5; Tue, 26 Oct 2021 07:02:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xsj5YtDoil8NGHWRGw1l1kAk3Yvl7GbZ/UqflYTU6T0=; b=g2Zi5FYcZ4+wR47nPx8DASE6sRRKA/z8wd4MZV1sZJkWpgNF4T5MOVT1HIn/vnhIOQ pDKp8D6kWZ8MOFUgtHCJI5inWVt+ghD1HIvZhUypJO05HyMsa1VB0J0Ep3ne9649C/BQ dqAENYNsoG829wnGwMHdmEeOOtNNuwsr8+EJD35odyG5dFSL0Gd27A3C4MdsVFZEyBNQ OfKjMnQl4Wdtqgp2Syg2huYlbI4I8GnHaYn3Lgh2Jk0uCfndPNOv76Wy3VL4NCJsTSv2 wsUi9Gdmtp7qfaf07mcsqDCujViAC6kqoPEIrx1EQolIHCnJHeLEkrSVK5/V/YicWR1W lK/Q== X-Gm-Message-State: AOAM5338guu6koutxcqElFZ7SWd23WZN3mjHolONEsPqe+kzL48/okwW EXFcCrLZnsMPws8fHpEHyofdPCiUkyDxBdQi/XXgYBtJ63s= X-Google-Smtp-Source: ABdhPJxIpxRkaRsec6VbPpNwMr/IfmLIDPxc0WnKcT2pWYOaIvrYKyb7CTNVh9ppRkEAufUFIB+XSa+yWRstblAbFlU= X-Received: by 2002:a17:902:b691:b029:12d:2b6:d116 with SMTP id c17-20020a170902b691b029012d02b6d116mr21749227pls.71.1635256922179; Tue, 26 Oct 2021 07:02:02 -0700 (PDT) In-Reply-To: <83sfwp1c27.fsf@gnu.org> Received-SPF: pass client-ip=209.85.216.47; envelope-from=stefankangas@gmail.com; helo=mail-pj1-f47.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:277859 Archived-At: 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. 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. 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. 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. > 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. I have no objections to the general plan you propose, and I encourage anyone with a particular interest in such support to work on it. (It will be mainly of interest to macOS or MS-Windows users, I think? But they should probably already be using a lot of software that uses the XDG BDS. I note that I have several BDS mandated directories on my macOS laptop.) However, I do not see any logic in stopping work on XDG BDS support until such a library or functions has been implemented. Just like above, any work we do in conforming better to the XDG BDS can only serve to make the "platform independent" or "XDG BDS independent" plan you propose easier to implement.