* crash-proof emacs use
@ 2022-09-12 2:13 Samuel Wales
2022-09-12 3:26 ` Stefan Monnier via Users list for the GNU Emacs text editor
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Samuel Wales @ 2022-09-12 2:13 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-12 2:13 crash-proof emacs use Samuel Wales
@ 2022-09-12 3:26 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-09-12 6:08 ` Jean Louis
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier via Users list for the GNU Emacs text editor @ 2022-09-12 3:26 UTC (permalink / raw
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-12 2:13 crash-proof emacs use Samuel Wales
2022-09-12 3:26 ` 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
3 siblings, 0 replies; 7+ messages in thread
From: Jean Louis @ 2022-09-12 6:08 UTC (permalink / raw
To: Samuel Wales; +Cc: help-gnu-emacs
* 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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-12 2:13 crash-proof emacs use Samuel Wales
2022-09-12 3:26 ` 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
3 siblings, 0 replies; 7+ messages in thread
From: Yuri Khan @ 2022-09-12 6:32 UTC (permalink / raw
To: Samuel Wales; +Cc: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-12 2:13 crash-proof emacs use Samuel Wales
` (2 preceding siblings ...)
2022-09-12 6:32 ` Yuri Khan
@ 2022-09-12 7:32 ` Marcin Borkowski
2022-09-15 2:49 ` Samuel Wales
3 siblings, 1 reply; 7+ messages in thread
From: Marcin Borkowski @ 2022-09-12 7:32 UTC (permalink / raw
To: Samuel Wales; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-12 7:32 ` Marcin Borkowski
@ 2022-09-15 2:49 ` Samuel Wales
2022-09-17 14:22 ` Marcin Borkowski
0 siblings, 1 reply; 7+ messages in thread
From: Samuel Wales @ 2022-09-15 2:49 UTC (permalink / raw
To: Marcin Borkowski; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: crash-proof emacs use
2022-09-15 2:49 ` Samuel Wales
@ 2022-09-17 14:22 ` Marcin Borkowski
0 siblings, 0 replies; 7+ messages in thread
From: Marcin Borkowski @ 2022-09-17 14:22 UTC (permalink / raw
To: Samuel Wales; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-09-17 14:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-12 2:13 crash-proof emacs use Samuel Wales
2022-09-12 3:26 ` 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
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).