crash-proof emacs use

crash-proof emacs use

[Samuel Wales]

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

Re: crash-proof emacs use

[Stefan Monnier via Users list for the GNU Emacs text editor]

> 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.

It probably depends on lots of things, but AFAIK the normal way Emacs
solves this is by treating everything between two `C-x C-s` as a kind of
transaction, so until you `C-x C-s` all the changes in your buffer
are transient.

Of course, it doesn't help you in cases such as:

- kill, with the intent to yank elsewhere
- forget all about it
- save

If you're worried about that, then most likely you're also worried
about:

- kill, with the intent to replace it with something else
- forget all about it
- save

tho admittedly, in such a case you can easily workaround the problem by
first typing in the replacement, then killing the old version (so that,
if you forget all about it in the middle, you just get both versions
and no info is lost).

FWIW, I fairly often do that kind of "insert first" (or copy first) and
only delete the original code later on.


        Stefan

Re: crash-proof emacs use

[Jean Louis]

* Samuel Wales <samologist@gmail.com> [2022-09-12 05:14]:
> 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.

I have something similar where I am entering text in Emacs, then
killing the text and yanking in other window. I don't like those texts
to disappear, for that reason I am logging them with `rcd-general-log'
below. They go into the database.

(defun read-to-clipboard ()
  (interactive)
  (set-input-method my-default-input-method)
  (let ((clipboard (rcd-ask "Insert into clipboard: "))
	(title (concat "Clipboard: " (rcd-timestamp))))
    ;; Here 
    (rcd-general-log title clipboard 1 nil nil nil 4) 
    (kill-new clipboard)
    (rcd-message "Killed: %s" (rcd-substring-soft clipboard 0 40))))

I have different log types:

 1          Default
 2          Word Lookup
 3          E-mail
 4          Clipboard
 5          DB Column

Thus any time later I can revert back to the log and see what was
entered in the clipboard.

 19459 emacs: message sent                                                    Default
 19460 Word query: censuring                                                  Word Lookup
 19461 Clipboard: 2022-06-25-17:03:15                                         Clipboard
 19462 Clipboard: 2022-06-25-17:05:56                                         Clipboard
 19463 Clipboard: 2022-06-25-17:06:31                                         Clipboard
 19464 Clipboard: 2022-06-25-17:07:46                                         Clipboard

Emacs in development version has now SQLite database built-in, it is
worth using it to capture pieces of information.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: crash-proof emacs use

[Yuri Khan]

On Mon, 12 Sept 2022 at 09:13, Samuel Wales <samologist@gmail.com> wrote:

> 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.

Microsoft Excel and Google Sheets do this. (LibreOffice Calc, for some
reason, doesn’t — deletes on cut immediately.) Various file managers,
too.

Re: crash-proof emacs use

[Marcin Borkowski]

On 2022-09-12, at 04:13, Samuel Wales <samologist@gmail.com> wrote:

> 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.

> [...]

That is a _very_ interesting idea!  I might be tempted to code something
like this (assuming nobody did it earlier, which would not surprise me).

That said, for a similar reason (it is easy to delete something in Org
and not notice because of all the hiding), I developed a habit of
committing my org-mode files to Git (almost) every day (at least 0.8
times per day on average, to be more precise).  That helps.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: crash-proof emacs use

[Samuel Wales]

thanks!

i'd say stefan's example here is more or less the canonical/cynosure
one for non-crash-proof editing, but i am open to other
crash-proof-ness:

- kill, with the intent to yank elsewhere
- forget all about it
- save

knowing that i have to remmber and that i might forget or some other
thing is stressful and cognitively burdensome even if i do not forget.
computers shold be able to do some of that kind of organizing for me.
at least that is the idea.

editing some part of a sentence doesn't do this to me as much.
sending paragraphs elsewhere does.

or
perhaps it extends to complex org/elisp/bash editing or various types
of linking, perhaps ones where stuff has to be kept in sync or all
bases need covering.  i think it might be related to the "keeping a
stack of state in one's head" kind of thing, including cases where it
is too inconvenient/bad for rsi to literally keep on top of one's org capture
stack.  n.b. i always use only one window.  but it also has to be
convenient and low rsi.

idk, lots of possibilities.  kill, then hit an f key to say "this kill
has to be yanked someplace", maybe.  idk.


p.s. i just thought of another example of crash-proof-ness.  suppose
you decide that bef and aft are not sortable, and same with start and
end, and start and finish, so you decide to canonicalize on beg and
end.  and for times, bt and et.

so you use query-replace-regexp, which has 2 problems here.  one is
that you want it for multiple files, which wgrep can help with.
although it could perhaps treat all of its matches as if they were in
one file.

the other is the example.  you want to replace all those with beg and
all those with end at the same time.  you don't want to forget to do
the end part for any one of those start parts that you changed.

thus, as an example, a crash-proof query-replace-regexp would allow
multiple pairs of replacements.  perhaps with different colors, one
per pair.  but this is a less common need than crash-proof moving.
btw i am not on this list i think.


On 9/12/22, Marcin Borkowski <mbork@mbork.pl> wrote:
>
> On 2022-09-12, at 04:13, Samuel Wales <samologist@gmail.com> wrote:
>
>> 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.
>
>> [...]
>
> That is a _very_ interesting idea!  I might be tempted to code something
> like this (assuming nobody did it earlier, which would not surprise me).
>
> That said, for a similar reason (it is easy to delete something in Org
> and not notice because of all the hiding), I developed a habit of
> committing my org-mode files to Git (almost) every day (at least 0.8
> times per day on average, to be more precise).  That helps.
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>


-- 
The Kafka Pandemic

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

Re: crash-proof emacs use

[Marcin Borkowski]

On 2022-09-15, at 04:49, Samuel Wales <samologist@gmail.com> wrote:

> thanks!

Here: http://mbork.pl/2022-09-17_Safe_killing_with_Emacs

Note: as mentioned in the mode docstring and in the blog post itself,
this is not really "safe" - you can still lose text in various ways when
using this code.  However, if you stick to the the basic kill/yank cycle
(so, no M-y, no undoing the yank...), you should be good.

I am convinced that making this code /really/ "safe" (read: make it
impossible to lose text) is impossible.  After all, sometimes deleting
is what you actually /want/. ;-)  Also, it seems not to like
`append-next-kill'.  Still, as a PoC it seems to work pretty nice.

Best,

--
Marcin Borkowski
http://mbork.pl