New: In Memory Diff
`in-memory-diff` takes two source buffers and treats their content as a set of unordered lines, as one would expect for a file like `~/.authinfo.gpg`, for example. We don’t use diff(1) to diff the buffers and thus we don’t write temporary files to disk. The result is two buffers, `*A*` and `*B*`. Each contains the lines the other buffer does not contain. These files are in a major mode with the following interesting keys bindings:
In theory, using `c` and `k` on all the lines should result in the two source containing the same lines a subsequent call of `in-memory-diff` showing two empty buffers.
☯
Alternatively, a way to use `ediff` with process substitution such that ediff reads from two pipes would have been nice. Does anybody know how to do this?
#Emacs
(Please contact me if you want to remove your comment.)
⁂
I don’t think Emacs can do the equivalent of process substitution, because Lisp code cannot see the fd numbers of process objects produced by make-pipe-process.
Hacking around this using fifos seems possible: https://github.com/kensanata/in-memory-diff/compare/master...npostavs:diff-fifo
https://github.com/kensanata/in-memory-diff/compare/master...npostavs:diff-fifo
– npostavs 2017-12-14 14:22 UTC
---
Wow, this is super cool! I wondered whether I’d be able to get ediff to do just that and had given up. Thanks!
– Alex Schroeder 2017-12-14 19:03 UTC
---
Have a look at this item on stackexchange:
https://emacs.stackexchange.com/questions/27382/diff-of-two-buffers-without-creating-temporary-files
But do note that in-memory doesn’t necessarily prevent other processes from accessing the pipes as they are file system objects (at least that’s my understanding).
– Titus von der Malsburg 2017-12-19 11:15 UTC
---
That’s correct. I’m mostly worrying about temp files being left behind, or deleted temp files being resurrected. Assuming that the main attack vector I’m fearing is people stealing the disk where my encrypted file and decrypted temp files are on, I think pipes are good enough.
– Alex 2017-12-19 12:47 UTC