[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mouse-drags wait to call post-command-hook
From: |
Davis Herring |
Subject: |
Mouse-drags wait to call post-command-hook |
Date: |
Wed, 25 Aug 2004 10:05:04 -0600 (MDT) |
I think this may be its own issue, so I'll isolate it (and talk more about
X selections in later email):
> > They disagree a notable amount of the time, and `x-lost-selection-hooks'
> > is never called with PRIMARY as an argument unless the keyboard is used to
> > kill text. Meanwhile CLIPBOARD appears to call the hooks every time.
>
> I still can not reproduce this. You need to supply an explicit test case,
> i.e.
> a step by step description of how to reproduce this.
The mouse-dependence may be related to the fact that mouse-drags do not
call `post-command-hook' until another event is received.
emacs -q -f ielm
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (defvar pcm-counter 0
"Counter of `post-command-hook' executions.")
pcm-counter
ELISP> (defun pcm-message ()
"Count `post-command-hook' executions."
(message "PCM: %s" (setq pcm-counter (1+ pcm-counter))))
pcm-message
ELISP> (add-hook 'post-command-hook 'pcm-message)
(pcm-message)
ELISP>
Then drag-select some text in the buffer; no message is generated. But
then press C-f, and the counter increments twice. This leads me to
suspect that the drag isn't "finalized" in some way until the next
command, which would explain why the X selection behavior depends on
whether the most recent event was a mouse-drag.
Is there some reason for this behavior? If it's just a bug, perhaps
fixing it will fix (or make easier to fix) the X issues.
Davis Herring
--
This product is sold by volume, not by mass. If it seems too dense or too
sparse, it means mass-energy conversion has occurred during shipping.