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: Tue, 9 Nov 2021 12:38:52 -0800 Message-ID: References: <83sfwp1c27.fsf@gnu.org> <83sfwnyi65.fsf@gnu.org> <83k0hzydcg.fsf@gnu.org> <83wnlj7ng4.fsf@gnu.org> <83fss67nvw.fsf@gnu.org> <835yt27b4a.fsf@gnu.org> <83lf1x428l.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="11899"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 09 21:40:13 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 1mkXuf-0002tv-Jc for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Nov 2021 21:40:13 +0100 Original-Received: from localhost ([::1]:60916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkXue-0004iz-8Y for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Nov 2021 15:40:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkXtQ-0003FA-Ro for emacs-devel@gnu.org; Tue, 09 Nov 2021 15:38:56 -0500 Original-Received: from mail-pl1-f174.google.com ([209.85.214.174]:35778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkXtO-0000ps-WA; Tue, 09 Nov 2021 15:38:56 -0500 Original-Received: by mail-pl1-f174.google.com with SMTP id b13so790093plg.2; Tue, 09 Nov 2021 12:38:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=pih2SMspNa3I6OKvoibY1leupApq7VNHJrrqot+9HbQ=; b=sQL0RTlOb7gncI6BLKVYrfyoaeMjEA2ytbDX6bvEIWasSFZ3/LuH/fliFG5joZtBnV bIwptQb68hsoajTMo7HUdNcEp/u+fK+SCSjiOTkNN3PzFhM/Ag3TxqdIXnBA7lhiJzsJ u03+FtRVknQdjpyaLbKM9AXrJ8HOD7ajlM25WFHiNSMwa/MoCRl7FQ0zLlnrxha1lyzS C0t+Ui++VdwQ/FekqovUWb35Vla5+b7h1II42/N/rY7uDlsmt6OwActo+uxQnMz0agEl nWOT7K1aZXRBnkSIhDFwLFjb3iAgmPcJR/cSJ9u/w9nNKNh3WtwNSm5nFi2VlQeInhR+ K0gw== X-Gm-Message-State: AOAM531LBoRKDTJTG4liHZz1Za1ywl7Ys+hreTD84UhK0GqqVSrS1jnq L0f5qt9hp3fzSA7e8RyHv8zPpus8zcjFDv/DFQQH8mOT X-Google-Smtp-Source: ABdhPJxwoD74+7QjidYUkaNENw7t5yKDYkRcrrh+sEvu/B7p2+ltuqh3wdmNQiFDoctpQhKlrEQ0rq7Y2NCXtRwQt7k= X-Received: by 2002:a17:90b:1e0e:: with SMTP id pg14mr10345992pjb.143.1636490332944; Tue, 09 Nov 2021 12:38:52 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Nov 2021 12:38:52 -0800 In-Reply-To: <83lf1x428l.fsf@gnu.org> Received-SPF: pass client-ip=209.85.214.174; envelope-from=stefankangas@gmail.com; helo=mail-pl1-f174.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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:279126 Archived-At: Eli Zaretskii writes: >> When looking for the directory, the new one will always be preferred. >> The old name in all cases is just `user-emacs-directory', so it doesn't >> make sense to look for it. > > That's not true, unless we are mis-communicating. I have quite a few > directories under ~/.emacs.d/, and most of them are important. Are > you saying we will now look for them all according to the XDG spec? Aha, yes we are talking about two different things. If you need some file in `user-emacs-directory' ("file" in the Unix sense here, i.e. it could also be a directory) you would use `user-file'. So to get "~/.emacs.d/auto-save-list/" you would say: (user-file 'state "auto-save-list") => "~/.local/state/emacs/auto-save-list" `user-directory' only returns the top-level directory. There is no way to give it a name of a file. (user-directory 'state) => "/home/skangas/.local/state/emacs" However, your question makes me think that we should make `user-file' the only public function here, to avoid confusion. I think it's rare to need the directory itself, and if someone does they could just use user-emacs-directory => "~/.emacs.d/" or (user-file 'cache "") => "~/.cache/emacs" So I think we should rename the library to user-file.el, and make `user-file' the only non-internal and user-facing function. That makes it simpler, and more clear. >> ./startup.el547: (push (expand-file-name "eln-cache/" >> user-emacs-directory) > > Isn't that a problem? It would mean we'd need to preload xdg.el and > user-file, and all the stuff they need to work, right? Also, the XDG > spec says about "cache": Yes, if we want to move the eln-cache to the cache directory, we need to do something about preloading. The relevant XDG code could be moved from xdg.el and xdg.el could depend on the preloaded location; this is about 30-40 lines of code. We would also need to rewrite the code I have in user-directory.el to not use cl-lib.el. > $XDG_CACHE_HOME defines the base directory relative to which > user-specific non-essential data files should be stored. > > I don't think files in eln-cache can be classified as "non-essential". > They are important for using Emacs; removing them will make Emacs slow > and sluggish for quite some time after startup. Removing anything from a cache will always make performance worse until you can recache it, but the character of a cache is that it can always be recreated from some original data. So my understanding is that "non-essential" here is provided to contrast with the data file, and simply means that it is not (highly) important not to lose those files. I.e. it is just a way to further specify that this is the directory for cached files. > And you are saying we will redirect all those to the XDG tree? Users > have files in these places, and they need to trust Emacs to find those > files when it is restarted. How can we change where we look for them > without breaking configurations? For each file NAME: (1) look for NAME in the XDG directory, if NAME exists there and is readable return it, otherwise (2) look for it in `user-emacs-directory', if NAME exists there and is readable return it, otherwise (3) return the file name of NAME in the XDG directory. This is the same basic approach that we also use in `locate-user-emacs-file'. Is that what you mean? >> (user-file 'data "bookmarks" "~/.emacs.bmk") > > Once again, why not just one argument? For backwards compatibility. The "bookmarks" file used to be in "~/.emacs.bmk" (before 2010 or so?). We currently locate it using this call: (locate-user-emacs-file "bookmarks" ".emacs.bmk")