Xref: utzoo comp.editors:1266 gnu.emacs:2146 comp.unix.wizards:20211 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!sun-barr!decwrl!granite.pa.dec.com!mellon From: mellon@nigiri.pa.dec.com (Ted Lemon) Newsgroups: comp.editors,gnu.emacs,comp.unix.wizards Subject: Re: Mach and faulting in the file (Re: GNU Emacs, memory usage, releasing) Message-ID: Date: 10 Jan 90 08:08:26 GMT References: <1558@aber-cs.UUCP> <129799@sun.Eng.Sun.COM> <50359@bbn.COM> <2J+IH7ggpc2@ficc.uu.net> <94.639xds13@ficc.uu.net> Sender: news@decwrl.dec.com Organization: Digital Equipment Corporation Lines: 13 In-reply-to: peter@ficc.uu.net's message of 8 Jan 90 15:05:53 GMT > The problem is that unless you copy the file on disk you can't back > out of your edits at the last moment (:q! for vi people). If you're > going to copy the file you might as well copy it into vmem. Actually, this isn't a problem with a proper virtual memory system. If it's done right, you just implement a copy-on-write scheme with a different version number for the modified file, as with TOPS-20. BTW, I believe (perhaps wrongly) that Emacs under TOPS-20 mapped its files and did copy-on-write operations. TOPS-20 has a studly memory mapper. _MelloN_