you mean outside of the dump when acme is dies for reasons other than being killed/exited?
with win state, how are you going to handle the state of the shell? I can see why they're dynamic, it could be potentially misleading to see a changed namespace/rfork etc... and expect the shell to have the same environment as the history. I definitely like your restored from ideas. I wouldn't worry about getting the patch accepted or not. Just go for it. On Fri, Aug 7, 2009 at 5:42 PM, roger peppe<rogpe...@gmail.com> wrote: > the Include path. > contents of win buffers. > Undo/Redo history. > > ok, the last might be pushing it a bit, > but ideally i'd like to be able to dump > an acme session and restore it without > any loss of continuity, and the Undo/Redo history > is a very useful part of my acme context. > > while i'm about it, there are a few other dump > features i'd like to see: > - automatic dumping every 30s or so in case of a crash. > - Dump would dump to the restored-from file rather than > $home/acme.dump by default. > - atomic dump file creation - if, for some reason, > acme dies half-way through dumping, i don't > want the old dump file to be erased with a dud > new one. > > most of this should be fairly straightforward, > i've just not made space in my life to do it yet. > > and i doubt it would be accepted as a patch anyway. > > > 2009/8/7 Noah Evans <noah.ev...@gmail.com>: >> What other stuff are you thinking of? >> >> On Fri, Aug 7, 2009 at 4:02 PM, roger peppe<rogpe...@gmail.com> wrote: >>> 2009/8/7 Noah Evans <noah.ev...@gmail.com>: >>>> The dump doesn't preserve indent state >>> >>> personally, i think it should. >>> >>> and some other stuff as well. >>> >>> >> >> > >
