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: user-directory: New library to find user {conf, data, state, ...} files Date: Thu, 11 Nov 2021 12:34:48 +0200 Message-ID: <83o86r0ylz.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20540"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 11 11:35:40 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 1ml7Qh-00054P-NJ for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 11:35:39 +0100 Original-Received: from localhost ([::1]:51722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ml7Qf-0005g3-W7 for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 05:35:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml7Px-00049X-DX for emacs-devel@gnu.org; Thu, 11 Nov 2021 05:34:53 -0500 Original-Received: from [2001:470:142:3::e] (port=48362 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml7Pw-0005WQ-E9; Thu, 11 Nov 2021 05:34:52 -0500 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=NBEaw4P/WnyF9G6SjLUKLwy5Qe/yqUnh4NXeehgIJao=; b=VVnTx2Mg/Fv9 Jhh9aeoLqXXiz8noFRNCoDGBvSTtCj6tEDVtJ0rPdwpKhUAVYULVJcdHus59PcW+8nUAzKq5lxSYK UuAwNt50/kgfV27LptCvkIAxXBrScC0mlrXiJf3QIeT8t5TouIn7PwsaQCjC55Rifb2MiByzq5O57 ZOgzysxZOECrh1uCLzxIyjszE6ft7O8uznrb/h9VNTPV/zuN1sh40m6ZjvuICffilEavQVlGxlTlH 9P24ODsmA56iyr+DDcVlrM8UiPN0RlFqmfwXkRLeuVVqbob7DLwEdQxulfMNNT31GEcZeoahK/aw0 A4nGCDLTgf03cQu2T1gt6Q==; Original-Received: from [87.69.77.57] (port=1274 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 1ml7Pu-0003CI-FF; Thu, 11 Nov 2021 05:34:51 -0500 In-Reply-To: (message from Stefan Kangas on Tue, 9 Nov 2021 12:38:52 -0800) 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:279241 Archived-At: > From: Stefan Kangas > Date: Tue, 9 Nov 2021 12:38:52 -0800 > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 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" I'm saying that user-directory should also honor user-emacs-directory, because we have no way of knowing the intent of the caller of user-directory: it could be that the caller wants then to get to some file under it. > 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. Could be, indeed. (But please make user-file accept nil instead of an empty string.) > >> ./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. That's a bummer, because we didn't intend to preload xdg.el. And since it prefers the "traditional" setups anyway, I wonder whether preloading it would be justified, as in most cases its code will be trivially bypassed. > > $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. That's not true for the *.eln files: they cannot be "simply lost". Note that the XDG spec says "data files", which *.eln aren't: they are code. I think it would be wrong to put *.eln files there for the same reasons it would be wrong to put *.elc files there. > > 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'. Why not start with (2)? It will save us one step. > 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") If the 2nd argument is optional for alternative names, that's OK, I think. Thanks.