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: user-directory: New library to find user {conf, data, state, ...} files Date: Mon, 8 Nov 2021 16:26:15 +0100 Message-ID: References: <83sfwp1c27.fsf@gnu.org> <83sfwnyi65.fsf@gnu.org> <83k0hzydcg.fsf@gnu.org> <83wnlj7ng4.fsf@gnu.org> <83fss67nvw.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="26844"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 08 16:30:01 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 1mk6av-0006mI-J2 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Nov 2021 16:30:01 +0100 Original-Received: from localhost ([::1]:34610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mk6au-0007M9-J8 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Nov 2021 10:30:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mk6XX-0001Qc-1v for emacs-devel@gnu.org; Mon, 08 Nov 2021 10:26:31 -0500 Original-Received: from mail-pj1-f47.google.com ([209.85.216.47]:39576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mk6XU-0007og-OU; Mon, 08 Nov 2021 10:26:30 -0500 Original-Received: by mail-pj1-f47.google.com with SMTP id y14-20020a17090a2b4e00b001a5824f4918so9057727pjc.4; Mon, 08 Nov 2021 07:26:28 -0800 (PST) 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=8NfT3BNq6xv14ALMCl7SLLsRU6TY6/mv+8InFpW8pqY=; b=bp55uslCUtNO+0p8y7rkyal4nJG2jbHU2YEPCegeik80XBFkUuNSEkxQZmEKa9NZQ1 vWMx/VCBI+2z5PU4uSc5HRn4SvqSWUpUftannWrv9F6Meq9XUpidEqP/W1Vak7UIYaWk h6M1DXaZ7Ga7BumECR7AZyzioEWjGachnoUElnYi7iCgnCKiMzoM9xUp7yrak394yUqZ ErOC0P21TAf/Ic4JlZZ3ZGbBppEAg6oBAXsLwoRDViorA5+Tra7a6H1XG/WsS38Bo648 r01b8kTFQtFeRKuXIogFOa7rT+Qru2B++wl0zYqPIgDn/l4vc/zGZIFcy/uO4YXpUi3b LrRA== X-Gm-Message-State: AOAM532snv8be96MHHWv/7wskkWt7QBYVeK/EnVTrREQmCsyha2isr3V 4rJ0eGvvUoA5rQyTprdACXTwkKsRYsJyBZaN7GBLBcRZ8IA= X-Google-Smtp-Source: ABdhPJwcDYFZE+u771oUSK3jnjcOWWkbb3voTChUgYP+roqhffC0Jpc15BjBv2A3/hiyA6SmND7E+/WJPA5UFWb5Ld4= X-Received: by 2002:a17:90a:be10:: with SMTP id a16mr252254pjs.133.1636385187065; Mon, 08 Nov 2021 07:26:27 -0800 (PST) In-Reply-To: <83fss67nvw.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.29 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:279043 Archived-At: Eli Zaretskii writes: > The problem is that changes which break users' configurations will not > be appreciated. Correct, and fully agreed. I believe we can avoid this. > > With all that being said, we must take great care not to cause > > unnecessary churn. In particular, we should absolutely not break > > anything that's currently working. This means that we should respect > > locations of already existing files, and ensure they continue working > > seamlessly. > > That is fine, but I'm not sure how you can achieve that goal and still > prefer the XDG directories. This is the key point, indeed. The new name will be preferred only when there is no old file. If it exists, the old name will be used. (This is based on how 'locate-user-emacs-file' works.) See below. > > PS. Note that (user-directory 'config) in particular already just falls > > back to use whatever `user-emacs-directory' was set to. There is no > > need to duplicate what is happening in startup.el, or to try to > > outsmart it. > > What do you mean by "falls back"? To respect the current behavior, > the value of user-emacs-directory should be used in preference to > everything else. Sorry, I should have said "use", not "falls back": it returns the value of 'user-emacs-directory' and does nothing else. > But if we do that, then in which cases will the XDG > directories be used, since user-emacs-directory always exists and is > defined. The 'config case is different from the 'cache, 'state and 'data cases, where the XDG directories will be preferred instead. To be more precise, they will be preferred _only_ if we don't specify an old name, or if we did specify an old name but no such file exists. To give an example, let's assume that 'user-emacs-directory' is "~/.emacs.d/". 1. If "~/.emacs.d/old" exists, then we get: (user-file 'config "new" "old") => "~/.emacs.d/old" (user-file 'cache "new" "old") => "~/.emacs.d/old" 2. However, if "~/.emacs.d/old" does not exist: (user-file 'config "new" old") => "~/.emacs.d/new" (user-file 'cache "new" old") => "~/.cache/new" 3. Finally, let's consider the bookmark case, where a user might be using the very old name "~/.emacs.bmk": (user-file 'data "bookmarks" (locate-user-emacs-file "bookmarks" ".emacs.bmk")) => "~/.emacs.bmk" It's true that this requires discipline on behalf of application developers when calling 'user-directory': they need to provide an "old name" in addition to a "new name". I don't see any way around that. (See my separate email about the state of the API so far, and some possible simplifications, especially for the third example above.) I'd consider any failure to use a previously existing file as a bug. Bugs will inevitably exist, but I don't believe fixing them will be fundamentally impossible, or necessarily even hard. Another consideration is that the interface of course has to be helpful: it has to be easy to use correctly, and hard to use incorrectly. I think what it looks like now is not too bad in that sense, but I'm very open to suggestions about how to do better.