Re: [PATCH] 21.1.4-mule: auto save doubles escape chars

Kyle> Ben Wing writes: But you can't do what the user wants anyway, since typically the buffer changes between the autosave and the crash. So it's a question of how much work does the user have to do to recover the exact state he was in when he lost the buffer. External utilities as Kyle mentions below can be very helpful. Kyle> I'm not convinced that this is the best approach. MULE is Kyle> willing to guess the coding system when you first visit a Kyle> file. I don't see that situation at auto-save recovery time Kyle> is any different. But the user may not have accepted the guess the first time. What do you do then? IIRC recover-file does not take a coding system argument. We need to do something about that. Kyle> If you can accurately guess the coding sstem at find-file Kyle> time, you should be able to guess it at file recovery time. We can't manage such accuracy. I use C-u C-x C-f a fair amount. However, you can take a hint from the coding-system that the user actually used to visit the file. (This is the most common case; I don't think I've ever invoked recover-file anywhere but from the VM toolbar). It's nearly certain that that corresponds to the coding system in force when the buffer was lost, and therefore auto-saving in the current coding system should do the right thing nearly 100% of the time. Kyle> Also, by using the current buffer's Kyle> coding system for auto-saves, the auto-save file hits the Kyle> disk in a format that can be used by programs other than Kyle> XEmacs. The user can do "diff #foo# foo" and see the real Kyle> differences without the extra escape-quoted induced Kyle> differences. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.