Bug 7061
Summary: | mode line clock tracks only forward system time changes | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Joe Harrington <jhmail> |
Component: | apmd | Assignee: | Trond Eivind Glomsrxd <teg> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | jhmail |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-08-09 02:53:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joe Harrington
1999-11-16 22:55:11 UTC
Sorry, we are not able to fix that. To quote RMS: ************************************************* I don't know how to fix this. Emacs timers are controlled by the clock; Emacs arranges to update the time display at a specified time, calculated as one minute after now. I don't know if there is a way to do something after a minute of real time without relying on the system clock. ************************************************* Sorry. Please don't give up so easily. Most other programs handle clock updates just fine. You don't have to base everything exclusively on timers. Putting an update hook into, say, the file-save routine or something else that gets called pretty regularly but not with each keystroke would work fine. All it would have to do is check the clock and test whether it was within a minute of the internal emacs time representation, and update the timers if it isn't. I'm sure there are many more-elegant solutions. Every program that I know of and that has a time display seems to handle this just fine. I'm sure Richard could come up with elegant solutions if he gave it half a thought. Tell him MSword does it better than emacs. --jh-- The problem is apmd, not emacs - the time of the system should't go backward. In an ideal world, the system time is always increasing. We don't live in one. I can imagine only about half a dozen other ways the time could shift. The user keeps the system clock in local time for compatibility with a dual-boot OS, travels, and changes timezone. A time server on the net has a bug and adjusts the time forward and then back. Someone makes a mistake typing to the date command and subsequently fixes it. Apmd has to do weird machinations to deal with strange BIOSs. I could go on. The point is that if everyone makes just the bare minimalist assumptions, the system falls apart. Right now emacs is doing that. No other program I know does it that way, and for good reason: it doesn't work in the real world. A nod to robustness is required, and it's nearly trivial to add, in this case. See my previous post. I wish you would stop trying to shift the blame on others and just fix the problem, or hand it to someone who will. This bug has sat idle here for five months! --jh-- |