unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: crash-proof emacs use
Date: Sun, 11 Sep 2022 19:13:32 -0700	[thread overview]
Message-ID: <CAJcAo8vAtN1-bQOK1qd_OBos8r_6N_mxjzkL_ERVyCDwg5FMag@mail.gmail.com> (raw)

suppose you want to move something from one place to another.  in org,
you can often use org-refile.  that is more or less an atomic
operation.  but suppose that for whatever reason you cannot do that,
so you use traditional emacs.

which is to say you kill and then yank.  this is not stateless.  if
you have short-term memory issues [a big one] or computer issues or
get interrupted or whatever, there are possible failure states where
you lose data.

this can be detected with git, rsnapshot, zfs, auto-save files, backup
files, diff, and the like, but i was thinking, i wonder if anybody has
thought about this problem, especially the stm part, and implemented
some kind of crash-proof moving.

this is open-ended, but would mean something like, you kill some text
with a "about to move" command so that killing is not conflated with
moving, and it gets marked as "move operation started".  then you go
to the location to yank to, and you [if your stm is operating ok] yank
in the new place with a message that this is supposed to be
crash-proof.  as part of that yanking, the old text gets deleted.
this is just a silly example.

there are many flaws in that design, but it is an examlpe of something
i was wondering if anybody has thought about.  it is an issue i deal
with frequently.  detecting after the fact is ok but there are edge
cases where it is insufficient.

so it is an open-ended q about whether anybody has implemented
crash-proof moving, or follows some kind of discipline /all the time/,
or some kind of non-theoretical sw for this, and it doesn't require
detecting after the fact.

idk if this will lead to anything but perhaps there is something out
there that works really well for those who have stm issues.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com



             reply	other threads:[~2022-09-12  2:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12  2:13 Samuel Wales [this message]
2022-09-12  3:26 ` crash-proof emacs use Stefan Monnier via Users list for the GNU Emacs text editor
2022-09-12  6:08 ` Jean Louis
2022-09-12  6:32 ` Yuri Khan
2022-09-12  7:32 ` Marcin Borkowski
2022-09-15  2:49   ` Samuel Wales
2022-09-17 14:22     ` Marcin Borkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8vAtN1-bQOK1qd_OBos8r_6N_mxjzkL_ERVyCDwg5FMag@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).