[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.")
ELISP> (defun pcm-message ()
         "Count `post-command-hook' executions."
         (message "PCM: %s" (setq pcm-counter (1+ pcm-counter))))
ELISP> (add-hook 'post-command-hook 'pcm-message)


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]