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: Sat, 19 Mar 2022 07:24:19 +0100 Message-ID: <37e890d9c251b30d0caf83aa590bca1ad92ec5d4.camel@adminart.net> References: <019b7e509c29caa462ff1c30079ce9bfb8cdc668.camel@adminart.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28942"; 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 Sat Mar 19 07:25:02 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 1nVSWM-0007Iu-98 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 19 Mar 2022 07:25:02 +0100 Original-Received: from localhost ([::1]:41088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nVSWK-00036j-8n for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 19 Mar 2022 02:25:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVSVk-00036b-VT for help-gnu-emacs@gnu.org; Sat, 19 Mar 2022 02:24:25 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.25]:39395) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nVSVi-0005oB-OM for help-gnu-emacs@gnu.org; Sat, 19 Mar 2022 02:24:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1647671060; s=strato-dkim-0002; d=adminart.net; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=RbF4XPrnTJup9b4XoUTIfAMqmftmaOuGVB3rFNh9Nd0=; b=jsNpfT7COpMtFO6fQzucBWRtJ/8plcRzHhGnozIOiTDdpbWyZmZsuDl2XSxEwq12Un IbVn4gj/brHqKxgkrxUOgdhF+E0d9GjNWCNcYnv0cpsjMUEyspmfJ1JmytGUvTeg+a2J VKlhSoZyioSzg1rVv9AAsAiB04/ZscaXEDbL+9qBFKSsQ6rD6YbJyD0+zXTdzDowEQxk zN9xt8XpI8/Sa5Njtw5I+NoYtLhD7xLyYjM2SdrOJPmuOKQTqRD4RS96YDbqX6kswFhS snoeU9UQAZp+V6+SwvKAfXLdCS0EDn9hIG4K26xCUQ8o7Tkz4UWBSRdJ+hVYyYJSxcy+ wX2A== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":JHskdESlcvGJlcww5P8kEdDfB60eDdbwg2z1BLI60U5wCzf09BLZZsSKYxPQaavhGO/kap91D/dWqfBhiI8TiUGkp3xnRj2czRF+" X-RZG-CLASS-ID: mo00 Original-Received: from [IPv6:2a09:8e40:1b4d:a200:568e:bd16:d462:7329] by smtp.strato.de (RZmta 47.41.1 AUTH) with ESMTPSA id U40bf1y2J6OJ8rX (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Sat, 19 Mar 2022 07:24:19 +0100 (CET) In-Reply-To: <87ilsa61tn.fsf@web.de> Received-SPF: none client-ip=85.215.255.25; envelope-from=hw@adminart.net; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, 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:136672 Archived-At: On Sat, 2022-03-19 at 04:47 +0100, Michael Heerdegen wrote: > hw writes: > > > > But why isn't your code located in a buffer visiting a file? > > > > It is. The output of perltidy replaces it. > > Ok - but does it have to be auto-save? No, it doesn't. It only seemed to be an easy way to achieve what I wanted. > Why not just use normal backup files? Because I would need to delete them eventually, and IIRC, tramp doesn't necessarily delete them. Some (remote) directories are not writable by the user editing the file. 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. > You can explicitly force the creation of backup files. And keep > a lot of them around. I can't (actually I don't want to, but you get the idea, and then there is also NFS which would require me to go to lengths to force it, depending ...) force the creation of backup files in non-writable directories. I don't want to keep a lot of backup files around in directories like '/usr/local/bin/'. Going through all the overhead of using git when you have users waiting on you to fix a little problem isn't ideal when you don't want to turn '/usr/local/bin/' into a git repo. First fix the problem so the users can keep working and then bring the git repo up to date. > See (info "(emacs) Backup") Hm I keep forgetting that emacs makes only one backup file only once, which makes them pretty useless. And I can't be bothered to configure emacs on all machines and for all users and keep the configurations up to date. Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a file? > and (info "(emacs) Backup Deletion"). What happens when I edit the same file directly in instances of emacs running locally in a session of tmux accessed through ssh and indirectly in instances of emacs running remotely, visiting the file through tramp? Neither the versions of emacs, nor their configurations are identical. They are versions like 29.0.50 (Fedora, wayland version), 24.3.1 (Centos 7), 24.4.1 (a derelict Gentoo installation), 27.1 (Debian) ... How do you make sure that all obsolete backup files are being deleted without configuring about 20 instances of emacs on different machines for different users? > You can, for example, have hundred backups of each file you edit - > in a folder of your choice so that they don't clobber your working > directories. I don't want like 20000 backup files all over all the places :) When something goes wrong, you're basically guaranteed that either at least some of them will stick around or relevant ones will be deleted, or both, in which case you may be left with only the irrelevant ones. And which ones are the relevant ones? Can you tell by their numbers? > If you are familiar with git, I suggest to have a look at Magit and the > wip modes. Yes, I need to look into good ways to use git with emacs. > After some setup, you get a backup for every save - or even > two, if the original state of the file was not yet backed up. Due to > git's delta compression it doesn't waste much disk space. The interface > lets you browse the versions and diff them etc. > > "helm-backup.el" does something similar. You can use more than one > method to gain some protection by redundancy. The git based approaches > have one big disadvantage though: deleting old versions is not trivial, > you need to mess with git trees (that are not even branches) and > manipulate references "by hand". Not cool. Right, I wouldn't want to have obsolete copies cluttering the repos for every time I press C-x C-s or C-x s. I rather commit only the version that is working after it was modified, not countless intermediate versions. Emacs crashed a lot on the Atari ST, and I still automatically hit 'C-x s' almost as much as I used to. > I always wanted to implement a similar interface for making backups > using "bup" - which would offer efficient compression of subsequent > versions without the need of registering (tracking) the files, but > didn't start the task yet. With "bup" you can at least store backups in > different places, it's somewhat easier to handle. But it also doesn't > allow history manipulation in a simple way. But then you would have to configure all instances of emacs. > And then you can make redundant backups of these backups to disk so that > you finally can, without fear, rely on undo :-) In your case, undo > should normally work, and it should be the fastest way to get the > original contents back. Ok so I run perltidy to replace the contents of the buffer visiting the program I'm working on, save the buffer so I can run the program and the power goes out, the computer freezes, emacs crashes or something else goes wrong and it turns out that perltidy messed up my program. How do I undo the changes then? Undo only works when nothing goes wrong. Sure, it "normally works" when you ignore that swapping the buffer contents inevitably removes the undo information, which means it doesn't work. Yet "normally" is kinda boring, and backup files and auto-save files are precisely for when things get interesting and when we need to be smarter than boring.