Mouse-drags wait to call post-command-hook

[Davis Herring <herring@lanl.gov>]

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.