From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: hw Newsgroups: gmane.emacs.help Subject: Re: how to force auto-save of buffers not visiting files, right now? Date: Sun, 20 Mar 2022 11:19:52 +0100 Message-ID: <4486cbd26d1c5c4587507212bfbb7ca34c5d92ea.camel@adminart.net> References: <87zglq200a.fsf@web.de> <8fffdb6b532a1fc1805229acfcf9510c3afe18ec.camel@adminart.net> <87wngsmdwp.fsf@web.de> <9f32ac59eb1bc186b015c0b6c5b94822e70d4135.camel@adminart.net> <87y2164u5p.fsf@web.de> <9c3935a33573d50e595f37103434db5e29c21063.camel@adminart.net> <87ilsa61tn.fsf@web.de> <37e890d9c251b30d0caf83aa590bca1ad92ec5d4.camel@adminart.net> <87wngqclgk.fsf@gmx.de> <95f0e96687187c20086bf9f85a031a7271401407.camel@adminart.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39075"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 20 11:21:50 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1nVsh3-0009vD-W0 for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 20 Mar 2022 11:21:50 +0100 Original-Received: from localhost ([::1]:40416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nVsh2-0003Om-AX for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 20 Mar 2022 06:21:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVsfF-0003O0-C9 for help-gnu-emacs@gnu.org; Sun, 20 Mar 2022 06:19:57 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]:38767) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVsfD-0000bg-4q for help-gnu-emacs@gnu.org; Sun, 20 Mar 2022 06:19:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1647771592; s=strato-dkim-0002; d=adminart.net; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=MR9BqWv9IL0+CD3UZWoYfjMhGjMkV0dxb9YfSzJ0e7I=; b=XxywImoGs5F5DGIZQ1dy16OkOGwm5W7R2tgNuVa1BNu2m9MOSVRjGJ71Iie7O72bRg nBuqPUCggWSAIDCSrJZJIE4/j7aBCnjPvl2r2wHcoksjBmWrBLdkGCgyoU9OyiKMT8mI 1q3G5bnuZ346avPSJduZwZLnaDgAvTCpnBBFaFm87Lnhr/6nUw6Rg3EXT97OTMZEbIhP QGplUsxa5O+9kU8309AqlCMoKvmcAfob9kMgFxsc8fLaybNKDRYLMea8Nquq3M5ftYuq Bdgc04X41SIb3BE2ln/RgkivjY4ZFL2x6FfIHabSyfzFvd3Q8eGAVprzfXPWyz08qu6h VhiQ== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":JHskdESlcvGJlcww5P8kEdDfB60eDdbwg2z1BLI60U5wCzf09BLZZsSKYxPQaavhGO/kap91D/OoCoP2QrxBY8ct0jBjyQ6QTgS1" X-RZG-CLASS-ID: mo00 Original-Received: from [IPv6:2a09:8e40:1b4d:a200:156a:299a:44c4:5337] by smtp.strato.de (RZmta 47.41.1 AUTH) with ESMTPSA id U40bf1y2KAJqAn1 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sun, 20 Mar 2022 11:19:52 +0100 (CET) In-Reply-To: Received-SPF: none client-ip=81.169.146.219; envelope-from=hw@adminart.net; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:136691 Archived-At: On Sun, 2022-03-20 at 08:29 +0100, tomas@tuxteam.de wrote: > On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote: > > On Sat, 2022-03-19 at 10:58 +0100, Michael Albinus wrote: > > > hw writes: > > > > > > Hi, > > > > > > > For example, I may edit a file '/usr/local/bin/example.pl' which is > > > > owned by foo:foo because I made that so. The directory > > > > '/usr/local/bin/' is owned by root. How do you expect emacs to create > > > > a backup file there? For remote files, I have set > > > > tramp-auto-save-directory to a local directory, and I'm missing an > > > > equivalent option for local files. > > > > > > There is the user option auto-save-file-name-transforms, which gives you > > > this feature also for local files. > > > > Thanks! > > > > Its value is > > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t)) > > > > Ah, hm, what is that regexp supposed to match? All files with at > > least a ':', a bunch of slashes and some optional brackets? Who puts > > bracktes into file names, that shouldn't be allowed. > > The colon is to match remote files. That's the default. Tramp remote > files for Emacs have a prefix with a colon. > > And the brackets are regexp metacharacters, [^/]* meaning zero or > more non-slashes (i.e. one path component) > > Or do you mean the parentheses ()? Those are for grouping. Due to > Emacs's regexp syntax (not ERE) you have to escape them. The extra > backslash is for the string syntax. Yes --- I didn't see that because that expression is so unreadable. Forcing remote auto-save files into being saved into a volatile directory is worse than not saving them at all. > > Apprently that leads to puttting some files into /tmp, and I would > > consider it a bug to put auto-save files into /tmp because doing that > > totally defeats the auto-saving because /tmp is volatile. > > One person's bugs are other person's features. That's why you can > change it, after all. How do I change that /tmp to not being volatile and keep it that way? > I don't know why the default is as it is, but knowing Emacs I guess > there has been some discussion. I'll leave it to you to *POLITELY* > (hint, hint) ask around here if you are interested. Or it has been decided some time ago when /tmp wasn't volatile and wasn't changed. > > I don't > > know who made the utterly stupid decision to make /tmp volatile, > > Careful. You can change that, too, if you want. Someone thought > it to be useful. Like how? > I'm around for long enough that I remember the > time before (for Gnu/Linux, anyway). I got along the change. It > has up- and downsides. Throwing "stupid" around won't change those > things :) Some things, like making /tmp volatile, are still stupid. I understand and somewhat appreciate that it can be useful to use a RAM-disk for some temporary files, yet that doesn't mean that breaking things for everyone would be useful or a good idea. IIUC, the purpose of making /tmp volatile wasn't even making it volatile but making things faster, so whoever did that could and should have introduced an additional directory for this purpose. Over time, software could and probably would have adapted to use either the new directory or not. For users, it would have been an easy choice to make because they could simply symlink /tmp to /volatile (or to whatever that new directory would be called), or the other way round. It would also been an option to decide between not keeping and keeping temporary files. But no, it was just forced upon us with no choice, and we weren't even told about such an important change. I'm sure that some people did loose their data because of it. Someone who is in the position to make important decisions like this needs make better decisions, not stupid ones like this ones. > > but > > it's the way it is since quite a while now. This default needs to be > > changed, or /tmp needs to go back to be a useful directory. > > That depends on whether you want that auto-save file to persist > across operating system sessions or not. Not everybody agrees with > you (or me) on what a nice behaviour is. That not everyone agrees with everything doesn't mean that deciding and thus breaking things for everyone would be a good idea, especially not when better alternatives are available which accomodate everyone or at least a lot more people than otherwise. > > Why didn't they just make a directory /volatile in addition to /tmp? > > Because someone would argue that when something must not be saved, > > then don't save it to begin with? > > > > But then, the auto-save files for buffers not visiting files show up > > in the directories the files are in from which the buffers not > > visiting these files were created. > > In a way, yes. It's whatever the value of `default-directory' is, > I guess, unless you give it an absolute path. Well, why is above regexp apparently ignoring the value of `default-directory'? Its description doesn't really describe it in that it doesn't say what it is being used for. So what is it being used for? It's even global and defined in C source code and buffer-local as well. Shouldn't it be used to (help) decide what the default-directory for auto-save files is? What happens when I change it from it's global value of nil to some directory? Why is it nil while the docstring says it should be "an absolute directory name"? > > That is very confusing. > > That's perhaps because there are not many people auto-saving > buffers without an associated file: not many around for testing! No, that a regexp like that is confusing doesn't have anything to do with how many people are auto-saving buffers not visiting files. Besides, IIUC, auto-save-mode is enabled by default for pretty much every buffer, so everone who changes the contents of buffers, visiting files or not, is subject to have their buffers auto-saved eventually unless they change the default. That's probably a lot of people.