From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020625 Description of problem: If the hook function po-replace-revision-date is disabled by setting the variable po-auto-replace-revision-date to nil (which is a legal value according to the documentation), it is no longer possible to save the po file. Version-Release number of selected component (if applicable):21.2-10 How reproducible: Always Steps to Reproduce: 1.Start emacs on some po file: emacs x.po 2.Set the variable to nil M-x s e t - v a r i a b l e <return> <help-echo> p o - a u t o - r e p l a c e - r e v i s i o n - d a t e <return> n i l <return> 3.Do some editing of any message in the file. 4.Try to save (or verify) the file. Actual Results: The file isn't saved. If verifying, the original file is checked. If quitting po-mode, a second question comes up asking if the buffer should get killed although it's modified. Expected Results: The file should have been saved. Additional info: In the file po-mode.el, the hook function po-replace-revision-date is automatically added to write-contents-hook. Normally it updates the PO-Revision-Date. It is configurable, though, through the variable po-auto-replace-revision-date. According to the documentation, it can be nil, t, or ask, and is t by default. If this variable is nil, I believe the intention is to simply disable this function. But the function in this case ends with a call to the function message with the argument "". The return value of this call is also "", which becomes the value of the complete hook function. When the hooks in write-contents-hook is called, a non-nil value from any hook function is interpreted to mean that the file is already written. The net effect is that the po file never is written. I believe this is what would happen if po-auto-replace-revision-date is set to ask, and the question is asked with no, or if it is called somewhere where format-time-string is not available. I've not verified those last two assumptions though. I've reported this error upstreams. I'm submitting this bug in case you want to patch your distribution until it is fixed officially.
Verified. Waiting for upstream fix.
Should be fixed in emacs-21.2-29. Please confirm. I passed my patch on to upstream too.
I'm sorry for the long delay in replying. But now at last I've verified this indeed works fine with the current release emacs-21.3-6