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: Fri, 18 Mar 2022 09:28:10 +0100 Message-ID: <9f32ac59eb1bc186b015c0b6c5b94822e70d4135.camel@adminart.net> References: <019b7e509c29caa462ff1c30079ce9bfb8cdc668.camel@adminart.net> <87zglq200a.fsf@web.de> <8fffdb6b532a1fc1805229acfcf9510c3afe18ec.camel@adminart.net> <87wngsmdwp.fsf@web.de> 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="22371"; 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 Fri Mar 18 09:32:11 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 1nV81q-0005c9-49 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 18 Mar 2022 09:32:10 +0100 Original-Received: from localhost ([::1]:38858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nV81k-0002Rh-Me for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 18 Mar 2022 04:32:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nV7y6-0001Ix-9K for help-gnu-emacs@gnu.org; Fri, 18 Mar 2022 04:28:18 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:39627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nV7y1-00032W-7F for help-gnu-emacs@gnu.org; Fri, 18 Mar 2022 04:28:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1647592090; s=strato-dkim-0002; d=adminart.net; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=HvvGMrPmOvfRqi4l6iLHvYVCaeaVRd0ilDIvDkMlG5k=; b=pvheUmZogO/i4KT52B6aAmPizlip0GJTleUZzFlrcRV5QlBX1Ow6atfWwLb4VpB+fa h52qdS89i+qEztoM12Yjww5rk6QQ7FNi/MP05wQYo+WN308Ir+7bhRIrderuCG5a9cUy bYNpJ5oIRFaEunBs+VGmyY0YeH8/LaIjOR6wooRaFpbx2PyHkCiWzDfHwZa+bGtLaCPi JFngmNLlB6Xiv5UOiBgPr9k9rVpRHwZDQpOGvpSJY195Ail8rBDn+X1hkmg+Ffrbg9xB BZgQsahxpOkSn0GgQpjqV97H/F0KB38G18YyLkOAk2AG6bEM2u8Qm8iwOfy22gSt2VVu rhog== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":JHskdESlcvGJlcww5P8kEdDfB60eDdbwg2z1BLI60U5wCzf09BLZZsSKYxPQaavhGO/kap91D/tqxuwp7piPF9poSqa1YYPBvy5k" X-RZG-CLASS-ID: mo00 Original-Received: from [IPv6:2a09:8e40:1b4d:a200:93a0:9c63:a52c:54d8] by smtp.strato.de (RZmta 47.41.1 AUTH) with ESMTPSA id U40bf1y2I8SA5v6 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Fri, 18 Mar 2022 09:28:10 +0100 (CET) In-Reply-To: <87wngsmdwp.fsf@web.de> Received-SPF: none client-ip=81.169.146.163; 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_H3=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:136661 Archived-At: On Thu, 2022-03-17 at 23:07 +0100, Michael Heerdegen wrote: > hw writes: > > > Think it through: You can only undo when nothing goes wrong. With > > copies of buffers being autmatically saved to auto-save files, you > > can recover from the auto-save files when something does go wrong. > > When nothing goes wrong, these buffers and auto-save files automatically > > go away. > > What are these "something"s that make undo not work but have no effect > on your auto-saving? How do you check if "nothing goes wrong" and these > auto-save files can be deleted? Perltidy is a code formatter for perl, see [1]. It's not impossible that perltidy messes up the code, and you might find out only later when testing the program you're working on, which can be hours or days later, after you have been programming and been using perltidy lots of times. Your program may not always in a state where you could test or even run it at the time when you want to use perltidy. When you use perltidy only right before you want to run and test your program, you still want to have a backup from before you used perltidy so that, if you need to, can try the version that wasn't altered by perltidy to see if that makes a difference. Of course you can save backups manually, but it's nicer to have that automated. Swapping buffer contents removes the undo information. Even if you have all the undo information, how do you jump between different states of the contents of the buffer, like to yesterday morning? Undo goes only step by step, and you probably do not want to undo hours of programming step by step until you arrive at yesterday morning, save that state, try to run that version (which may be unfinished and won't run) and then redo all the steps. Undo wasn't made for that. It's great to be able to go back a couple steps, but not hundreds or thousands. All kinds of other things can go wrong. Emacs may crash, your computer may feeze or crash, your graphics card or your display may fail and leave you blind, or whatever. When the version of your program that wasn't altered by perltidy is lost due to things like that, you won't be able to undo that when it wasn't saved. The undo you have in mind only works when nothing goes wrong, and it goes only so far. > With only abstract "things that go wrong" and claiming auto save files > solve all problems and undo none, without being more specific, I can't > say much more. I can't possibly list all things that can go wrong. Maybe you have never experienced that a computer or software doesn't work as it should or that things can go wrong. If you want to find out, you might use wayland with sway and libreoffice because libreoffice loves to crash all the time then. Or use thunderbird and try to open attachments --- you'll find that some of them are garbled because thunderbird is currently buggy, while evolution lets you open them just fine. Other things have gone wrong in the past, and it's not unreasonable to expect that other things or the same ones will go wrong in the future. In any case, I never said that auto-save files would solve all problems. > If you want files and you feel safe with having them, nothing wrong with > that. > > And yes, Emacs could perform better with the information collected by > undo. "undo-tree.el" is one approach to achieve that. AFAIR it now > supports also saving undo histories. > > In your scenario however I would expect that when "something goes wrong" > you just hit undo and get the former buffer contents, and that's it. Why would you expect that perltidy will never ever damage your source code so that you do not need to keep a copy of what you used it on? That would be unreasonable. It's enough when you don't like the formatting it produces in some case and want to undo it. Without a copy, the undo you have in mind is at best pretty unwieldy for giving you back what you had before. My expectation is always that things can go wrong, and I never trust computers. I do not expect that files saved somewhere will be there and undamaged, only that they usually are and only because I don't see a better alternative. A long time ago I did experience that files got damaged when they were saved, and it was quite a nightmare and turned out to be due to a broken disc controller. Another time an xfs file system got damaged and I had to recover from the backup, and I never really found out why and can only suspect that I used wrong settings when mounting it. Just expect things to go wrong; sooner or later they will, always. Remember the story about why bugs are called bugs, and that alone kinda tells you all about things being able to go wrong. The function I created makes it very easy for me to use perltidy and minimizes the risk of things going wrong, and it has the side effect of giving me copies, which can be useful. If you have a better way, it'd be interesting to hear about it. A simple undo doesn't cut it, it only works when nothing goes wrong.