Red Hat Bugzilla – Bug 65346
mouse-avoidance-fancy-hook needs guarding
Last modified: 2007-04-18 12:42:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; Q312461)
Description of problem:
[This is, IMO, an upstream bug, which I've reported a couple of times to the
upstream maintainers, without any luck.]
If I use mouse-avoidance-fancy-hook in my post-command-hook, I sometimes get
errors causing post-command-hook to be set to nil (most annoying). I think this
is really due to a bug in mouse-avoidance-fancy-hook, but can't be bothered to
dig it out, since it seems to cause no ill effects (and mouse-avoidance is
purely a cosmetic thing).
I do have a fix: simply wrap mouse-avoidance-fancy-hook's body in(condition-
case nil ... (error nil)), i.e. ignore any errors generated inside it. I've
been using this fix for months with no ill effects.
mouse-avoidance-fancy-hook is in xemacs-packages/lisp/edit-utils/avoid.el.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actually reproducing the bug in normal use is tricky. Try something like:
1. Add mouse-avoidance-fancy-hook to your post-command-hook
2. Use XEmacs a lot, closing buffers from time to time (C-x k)
3. Eventually, you should get an error, caused by a position being out of
range. I think it's because mouse-avoidance-fancy-hook is trying to examine
part of a buffer that has just been killed. This will set post-command-hook to
Actual Results: post-command-hook was set to nil and I got an error
Expected Results: Neither: it should Just Work (TM)
*** Bug 65349 has been marked as a duplicate of this bug. ***
Heard anything more from upstream? That's really where a fix should go in... for
the problem, not the symptom
I've reopened this one upstream, and so far had the response "your patch isn't
really a fix, so we'll put it on the todo list." i.e. no ETA for a real fix.
I'm trying to convince them that since it's a cosmetic problem, a cosmetic fix is
acceptable, at least in the interim (since ATM it's simply broken). But no response
to this yet.
Do you know which function in `mouse-avoidance-fancy-hook'
is causing the problem? Is it 'mouse-avoidance-too-close-p'?
Perhaps you could try catching the error there instead to see
if that is the case?
Catching the error in mouse-avoidance-too-close-p seems also to fix the problem, though I suspect the real problem is that the value in mouse-avoidance-point-position can be out of date by the time it is used. I notice that it says in the code that the definition of mouse-avoidance-point-position is different in FSF Emacs.
But as I said before, it's just a cosmetic problem that needs fixing, not a real bug...
Well, I guess the definition of `mouse-avoidance-point-position'
is different from in Emacs, because there is no `window-edges' function
It's not possible to get a backtrace of when `mouse-avoidance-fancy-hook'
flakes out, is it? It would be nice to know exactly why its going wrong.
I don't really see why the value from `mouse-avoidance-point-position' or
`mouse-position' being out of date should cause any error, but I'm probably
The bug occurs fairly rarely, but I've switched on Options->Troubleshooting->Stack trace on error. It's a little irritating, because it causes stack traces fairly regularly, but I'll try to stick it out until I get the fancy-hook error (I've tried to provoke it but without success so far).
Adding a condition-case to next xemacs-sumo build.
Should be fixed in xemacs-sumo-20030629-1.