bug#2895: 23.0.92; Tooltip persists with tooltip-mode off (new syndrome)
Bob Rogers <[email protected]>
| Newsgroups | gmane.emacs.bugs,gmane.emacs.pretest.bugs |
|---|---|
| Message-ID | <[email protected]> |
This can be reproduced in trunk, built as of a few hours ago, and requires circumstances different from bug#2680, though the buggy symptom is similar: A tooltip is redisplayed in the message area after moving the mouse to a spot where it no longer applies. To reproduce: 1. "emacs -Q" 2. "M-x tooltip-mode RET". This is on by default, so it should display "Tooltip mode disabled" in the message area. 3. Invoke "C-e" (or whatever) in order to clear the message area; the bug doesn't manifest reliably if something is already displayed there. 4. Move the mouse into the "-----" part of the right edge of the "*scratch*" buffer mode line. The message area will show the tooltip correctly, combined into a single line and (if the frame is narrow enough) truncated at the right. 5. Slide the mouse to the left until it enters the "Lisp Interaction" area, without taking the mouse out of the mode line. The message area will change to show a different tooltip for the highlighted "Lisp Interaction" area. It is important that the two mouse-sensitive areas be adjacent, with no intervening "dead" area, so not all mode line components are suitable for this. 6. Now move the mouse back into either the *scratch* buffer or the message area. Instead of reverting the message area to the pre-tooltip message, the tooltip for "-----" will be redisplayed. I was able to fix this superficially, but the resulting code was subject to timing problems, and it eventually lost any previous message, so no patch this time. FWIW, one timing problem happened when mouse jitter appeared to make the cursor move from mode line to message area and back three times in an eyeblink; the result was a regression of bug#2680. I managed to reproduce this twice, after lots of trying. It looks like it could be due to a failure to execute tooltip-show-help-non-mode atomically, which makes me think I don't understand enough about how mouse motion events are processed to produce a solid fix. -- Bob Rogers http://www.rgrjr.com/