Re: Gratuitous user interface change risks losing user work
Gregory Stark <[EMAIL PROTECTED]> writes: > I think it will if it's the first time you're saving the buffer since you > created it. But I tend to keep my emacs processes live for weeks or even > months. So I get one backup file and then no protection from then on. Right. I was getting confused. A new backup is caused by using C-x C-v, but not until the next time you save the buffer, and then the version which gets backed up is the version you overwrote your work with, so that's no help to you in this situation. > I think what I want is an option to make this the default behaviour. What if you customise after-save-hook's value to include (lambda () (setq buffer-backed-up nil)) ? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
"Chris Moore" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: > >> No, it didn't; I looked. The latest backup file I had was a couple weeks old. > > OK. I didn't test this much, but I thought when I did that I saw it > make a backup at that point. I think it will if it's the first time you're saving the buffer since you created it. But I tend to keep my emacs processes live for weeks or even months. So I get one backup file and then no protection from then on. > Prefixed with two C-u's, unconditionally makes the previous version > into a backup file. I think what I want is an option to make this the default behaviour. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
Gregory Stark <[EMAIL PROTECTED]> writes: > "Chris Moore" <[EMAIL PROTECTED]> writes: > >> When you typed 'yes' and hit return to say you wanted to save your >> work, Emacs will have made a backup of the file you were overwriting >> in ~. > > No, it didn't; I looked. The latest backup file I had was a couple weeks old. OK. I didn't test this much, but I thought when I did that I saw it make a backup at that point. > On that note I was wondering if there was any option to have emacs make more > backup files. There's this: C-x C-s runs the command save-buffer By default, makes the previous version into a backup file if previously requested or if this is the first save. Prefixed with one C-u, marks this version to become a backup when the next save is done. Prefixed with two C-u's, unconditionally makes the previous version into a backup file. Prefixed with three C-u's, marks this version to become a backup when the next save is done, and unconditionally makes the previous version into a backup file. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
I am thinking about changing the C-x C-v query for a modified buffer back to the old way. The other changes are important for larger consistency, but this change is less important. I just thought this way would be better. Does anyone other than Nick Roberts and Gregory Stark have an opinion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
> I just got bit by this and I bet others will too. In previous versions
> of Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't
> saved the work in the current buffer and you used to have to press 'y'
> to discard it. *Now* it prompts you asking if you want to *save* your
> work. So if you use it to revert the buffer to the last saved version --
> something I do quite frequently and have become accustomed to hitting
> 'y' quite quickly -- the default action is to *overwrite* your work!
>
> Does it really happen that way? I just tried that case, and it used
> yes-or-no-p to ask for confirmation for overwriting. So if you type
> `y RET', it should ask you again whether to save.
>
> Did you respond semiconsciously by typing `y e s RET', thinking
> "Dammit I said yes"?
y alone doesn't seem to work and it does seem to need `y e s RET'. This is
a bit silly anyway if we have to make find-alternate-file foolproof when
^
the user wants to revert the buffer to an older version of the same file just
because it used to work a certain way.
I can see that you can lose data if your backup is older than your last saved
state because you lose all the undo information but, hey, if I hit myself
over the head with a hammer it hurts. Perhaps Emacs should carry a health
warning, just as everything else does these days.
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
A problem that causes loss of work is a serious problem. How to address this one will take some thought, because each of these changes has a good reason individually. I just got bit by this and I bet others will too. In previous versions of Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't saved the work in the current buffer and you used to have to press 'y' to discard it. *Now* it prompts you asking if you want to *save* your work. So if you use it to revert the buffer to the last saved version -- something I do quite frequently and have become accustomed to hitting 'y' quite quickly -- the default action is to *overwrite* your work! Does it really happen that way? I just tried that case, and it used yes-or-no-p to ask for confirmation for overwriting. So if you type `y RET', it should ask you again whether to save. Did you respond semiconsciously by typing `y e s RET', thinking "Dammit I said yes"? This is exacerbated by the documented regression in find-file to no longer allow the shortcut of simply hitting return to reread the current file. The reason for this change is to eliminate an anomaly. The new meaning (visit the directory) is useful, and the fact that it failed to work was the anomaly. It is just one extra character to get the old results: M-n. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
On that note I was wondering if there was any option to have emacs make more backup files. It seems it only does so when I first save the file after visiting it. But I normally only start a new Emacs when it crashes or I have to reboot my machine which isn't very often. So I end up without many backup files. There are manual ways to make backup files, but there is no automatic feature to do this. We could implement such a feature, given a good idea for a criterion for when to make another backup file. Not till after the release, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
> "Gregory" == Gregory Stark <[EMAIL PROTECTED]> writes: Gregory> On that note I was wondering if there was any option to have emacs Gregory> make more backup files. It seems it only does so when I first save Gregory> the file after visiting it. But I normally only start a new Emacs Gregory> when it crashes or I have to reboot my machine which isn't very Gregory> often. So I end up without many backup files. It's all documented in the emacs manual under "backup". Toto -- Contact information and PGP key at http://www-users.rwth-aachen.de/thorsten.bonow "The Prius is so slow, the child could run on the street, retrieve the ball and grow to puberty before you actually hit it." Jeremy Clarkson, Topgear ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
"Chris Moore" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: > >> This is awful. I just lost several days of work > > When you typed 'yes' and hit return to say you wanted to save your > work, Emacs will have made a backup of the file you were overwriting > in ~. No, it didn't; I looked. The latest backup file I had was a couple weeks old. On that note I was wondering if there was any option to have emacs make more backup files. It seems it only does so when I first save the file after visiting it. But I normally only start a new Emacs when it crashes or I have to reboot my machine which isn't very often. So I end up without many backup files. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
> I just got bit by this and I bet others will too. In previous versions of > Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't saved > the work in the current buffer and you used to have to press 'y' to discard > it. *Now* it prompts you asking if you want to *save* your work. So if you > use it to revert the buffer to the last saved version -- something I do > quite frequently and have become accustomed to hitting 'y' quite quickly -- > the default action is to *overwrite* your work! For a new version of Emacs it would be a good idea to read carefully what Emacs is asking you. Previously people presumably lost work by indavertantly discarding changes. To help avoid unpleasant surprises I have documented this change in NEWS. > This is awful. I just lost several days of work myself and I bet others will > come across this too. Randomly going around reversing the sense of questions > the user is asked is seriously disturbing. Such changes are not made randomly but after consideration. > This is exacerbated by the documented regression in find-file to no longer > allow the shortcut of simply hitting return to reread the current file. So > now find-file doesn't work as expected and the obvious substitute C-x C-v > actively destroys the user's work. The new behaviour provides consistency and AFAICS the old behaviour wasn't documented. Thanks fot the report. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Gratuitous user interface change risks losing user work
I just got bit by this and I bet others will too. In previous versions of Emacs C-x C-v (find-alternate-file) used to prompt you if you hadn't saved the work in the current buffer and you used to have to press 'y' to discard it. *Now* it prompts you asking if you want to *save* your work. So if you use it to revert the buffer to the last saved version -- something I do quite frequently and have become accustomed to hitting 'y' quite quickly -- the default action is to *overwrite* your work! This is awful. I just lost several days of work myself and I bet others will come across this too. Randomly going around reversing the sense of questions the user is asked is seriously disturbing. This is exacerbated by the documented regression in find-file to no longer allow the shortcut of simply hitting return to reread the current file. So now find-file doesn't work as expected and the obvious substitute C-x C-v actively destroys the user's work. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-08-24 on stark X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--enable-asserts' 'CFLAGS=-g -O0'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: SQL[ansi] Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-l C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-l C-n C-n C-p C-p C-x b * G S-SPC C-g x r e p o r t - e m c a s - e m a c s - b u g Recent messages: Auto-saving...done Undo! Redo! Undo! Redo! [2 times] Buffer number.sql is modified; save it first? (y or n) Kill and replace the buffer without saving it? (y or n) number.sql has auto save data; consider M-x recover-this-file Quit Loading emacsbug...done -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
