Re: philosophical question about frequent saving of files

I think auto-saving of files would be a lot more palatable if we have  
automatic local file history so I can go back, even if I happen to  
revert a file (e.g. lose undo history) or exit/restart the IDE and  
discover that some temporary changes I had made were saved).

E.g. every time you save a file, a copy is saved in a backup dir.  
(possibly in compressed form).
There's an easy way (for example, a Versions tab, like there's Source  
and Design today for some
Java files) to view save history (ordered by save time), diff them,  
revert to a particular version, etc.

This is not the same as CVS/VCS support. I don't want every save  
delta to be put into the repository. But I do want to be able to walk  
backwards in my save history, across IDE sessions.

Philosophically (perhaps as a previous emacs user) I feel  
uncomfortable with IDEs automatically saving my files, but I've  
gotten used to it. I use the Fix & Continue  (now called "Apply Code  
Changes") feature a lot, and it performs a Save All. Now and then it  
ends up compiling changes I was in the middle of making in a  
different file, and I have to comment the block, hit fix & continue  
to get my intended changes applied, then uncomment the block to  
continue my parallel work.

-- Tor


On Aug 24, 2005, at 2:55 PM, Ivan Soleimanipour wrote:

> Is it OK for a program/IDE to automatically/frequently save edited  
> docs?
>
> Traditional programmer editors on unix have buffers and require  
> explicit
> saving. None of them ever instituted auto-save (that I know of).
> So by one measure automatically saving a file to disk will violate
> many a programmers expectation.
> OTOH, in order to smooth flow IDEs will most commonly save
> files to disk before doing a build w/o asking the user any questions.
> Adding in on the fly compilation, fix and continue and all that the
> trend seems to be to _hide_ the fact that there is a continuum of
>     file in buffer
>     file saved to  disk
>     file compiled to .class/.o
>     file linker into .jar/a.out
>     file run as a process
>     file as a proxy in debugger symbol table
> by that measure there should be no distinction between file in  
> buffer and
> file saved to disk which would argue that an IDE should save anytime
> it chooses.
>
> The practical actual reason I'm pondering this question is that
> I need the external debugger engine to detect out-of-date src and
> oobject code and one way would be to have the IDE save src file edits
> at crucial times.
>
> Personally I know that I subconsciously save my vi buffers often and
> almost randomly apparently sticking to the second model. while others
> might be much more deliberate and aware of theur buffer saves.
>
> This almos might matter depending on what you're using.
> Could it be for example that if you're interacting with the bult-in
> editor you have one expectation while if you're interacting with the
> external emacs/vi you have a different expectation?
>
>