bug#10195: 24.0.92; M-w may no longer provide visual feedback

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Jay Berkenbilt]

Type some text.  Save it in the kill ring with

C-a C-SPC M-f M-w

Then do this again:

M-w

In emacs 23, the cursor would bounce between the point and the mark the
second time M-w was pressed, since the highlighting of the region turned
off after the first time.  Or, if transient-mark-mode is nil, then the
first M-w would bounce the cursor between the point and mark.  In
emacs24, M-w seems to never cause the cursor to bounce between the point
and mark.  I don't see anything in NEWS about this change, and I don't
see anything in the documentation of kill-ring-save that discusses this
or how to influence this behavior.  I personally do not use transient
mark mode, so this cursor movement is the only visual feedback I have
that I have selected the region I intended to select.  While I've been
using GNU emacs since 1987 and this behavior is a relatively recent
addition, I had no idea how much I've become accustomed to it!


In GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.6)
 of 2011-12-01 on jberkenbilt-linux
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
configured using `configure  '--prefix=/opt/emacs-24.0.92''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Outline

Minor modes in effect:
  shell-dirtrack-mode: t
  which-function-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  view-mode: t

Recent input:
k i l l - r i n g C-s C-s C-a C-r c l i p b o a r d 
C-r C-r C-r C-a M-x m a n <return> x t e r m <return> 
C-x o C-s c l i p b o a r d C-s C-s C-s C-s C-s C-s 
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-a C-s c l i p 
b o a r d C-s C-s C-a C-x C-f ~ / C-g C-f C-g C-x C-g 
C-g C-x o C-x 1 C-x C-l C-s y a n k C-a C-x b * s c 
<tab> <return> C-y <C-backspace> <down-mouse-1> <mouse-1> 
<down-mouse-1> <mouse-1> C-y C-x b s s <tab> <return> 
C-s r a s C-g C-s r s a C-s C-a C-s p k c s 1 2 C-s 
C-s C-s C-s C-s C-s C-a C-s p i c C-g C-g C-r p k c 
s 1 2 SPC C-s C-s M-x m a n <return> p k c s 1 2 <return> 
C-x o C-s k e y C-a C-s - o u t C-s C-x 1 C-x # C-x 
o C-s k C-a C-x o C-s k e y C-s C-s C-a C-x o C-s C-s 
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s 
C-a C-x k <return> C-a C-SPC M-f M-w C-h c M-w C-h 
f k i l l SPC r i n <tab> <return> M-w M-w C-a C-SPC 
M-f M-w C-h n C-x 1 C-s d e l e t i o n C-s C-s C-a 
C-v C-s k i l l C-s C-s C-s C-s M-< C-s C-s C-s C-s 
C-s C-s C-a M-x r e p o r t SPC e b <backspace> m SPC 
b SPC <return>

Recent messages:
Mark saved where search started
When done with a buffer, type C-x #
Mark saved where search started [3 times]
Mark set
M-w runs the command kill-ring-save
Type C-x 1 to delete the help window.
Mark activated
Mark saved where search started [2 times]
Mark set
Mark saved where search started

Load-path shadows:
/home/ejb/elisp/startup hides /opt/emacs-24.0.92/share/emacs/24.0.92/lisp/startup

Features:
(shadow sort flyspell ispell mail-extr emacsbug man noutline outline
easy-mmode multi-isearch tabify vc-rcs add-log cc-mode cc-fonts cc-guess
cc-menus cc-cmds shell pcomplete grep dired help-mode view vc-svn vc
ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult
ediff-init ediff vc-dispatcher qmime qmime-compose qmime-view which-func
imenu filecache server uniquify warnings compile ange-ftp comint ring
message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cc-styles cc-align
cc-engine cc-vars cc-defs smtpmail auth-source eieio byte-opt bytecomp
byte-compile cconv macroexp assoc gnus-util password-cache sendmail
regexp-opt rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
project advice help-fns advice-preload jka-compr cus-edit easymenu
wid-edit cus-start cus-load edmacro kmacro cl time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer loaddefs button faces cus-face files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Jay Berkenbilt <ejb@ql.org>
> Date: Fri, 02 Dec 2011 11:09:53 -0500
> 
> Type some text.  Save it in the kill ring with
> 
> C-a C-SPC M-f M-w
> 
> Then do this again:
> 
> M-w
> 
> In emacs 23, the cursor would bounce between the point and the mark the
> second time M-w was pressed, since the highlighting of the region turned
> off after the first time.  Or, if transient-mark-mode is nil, then the
> first M-w would bounce the cursor between the point and mark.  In
> emacs24, M-w seems to never cause the cursor to bounce between the point
> and mark.

It still does that to me, in the current trunk tip.

Does it work in "emacs -Q" for you?

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jay Berkenbilt <ejb@ql.org>
>> Date: Fri, 02 Dec 2011 11:09:53 -0500
>> 
>> Type some text.  Save it in the kill ring with
>> 
>> C-a C-SPC M-f M-w
>> 
>> Then do this again:
>> 
>> M-w
>> 
>> In emacs 23, the cursor would bounce between the point and the mark the
>> second time M-w was pressed, since the highlighting of the region turned
>> off after the first time.  Or, if transient-mark-mode is nil, then the
>> first M-w would bounce the cursor between the point and mark.  In
>> emacs24, M-w seems to never cause the cursor to bounce between the point
>> and mark.
>
> It still does that to me, in the current trunk tip.
>
> Does it work in "emacs -Q" for you?
>

It appears to be inconsistent.  Sometimes it will happen, sometimes it
will not.  I first noticed this many months ago, but at the time
couldn't cause it to happen on command, and as such forgot about it for
a while.  Today, I tried again with emacs -Q built from bzr revno
106562.  I definitely see this behavior, without fail.

  emacs -Q
  (In *scratch* buffer)
  C-p C-p C-p C-SPC C-e M-w

It's a lot more noticeable with tmm off.

GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, X toolkit) of 2011-11-30 on maru

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Cc: Jay Berkenbilt <ejb@ql.org>,  10195@debbugs.gnu.org
> Date: Sat, 03 Dec 2011 00:31:36 -0500
> 
> >> Type some text.  Save it in the kill ring with
> >> 
> >> C-a C-SPC M-f M-w
> >> 
> >> Then do this again:
> >> 
> >> M-w
> >> 
> >> In emacs 23, the cursor would bounce between the point and the mark the
> >> second time M-w was pressed, since the highlighting of the region turned
> >> off after the first time.  Or, if transient-mark-mode is nil, then the
> >> first M-w would bounce the cursor between the point and mark.  In
> >> emacs24, M-w seems to never cause the cursor to bounce between the point
> >> and mark.
> >
> > It still does that to me, in the current trunk tip.
> >
> > Does it work in "emacs -Q" for you?

For the record, Jay replied off-list that "emacs -Q" has the same
problem for him.

> It appears to be inconsistent.  Sometimes it will happen, sometimes it
> will not.  I first noticed this many months ago, but at the time
> couldn't cause it to happen on command, and as such forgot about it for
> a while.  Today, I tried again with emacs -Q built from bzr revno
> 106562.  I definitely see this behavior, without fail.
> 
>   emacs -Q
>   (In *scratch* buffer)
>   C-p C-p C-p C-SPC C-e M-w

This is not the right recipe.  The first M-w does NOT show the region
by momentarily moving point to its other end, because the default is
to have transient-mark-mode on, which already shows the region.  You
need to type M-w twice or more in a row to see point move.

Anyway, I don't see it on any machine to which I have access, FWIW.  I
tried both unoptimized and optimized builds, on Windows and on
GNU/Linux, and they all behave as expected.

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@md5i.com>
>> Cc: Jay Berkenbilt <ejb@ql.org>,  10195@debbugs.gnu.org
>> Date: Sat, 03 Dec 2011 00:31:36 -0500
>> 
>> >> Type some text.  Save it in the kill ring with
>> >> 
>> >> C-a C-SPC M-f M-w
>> >> 
>> >> Then do this again:
>> >> 
>> >> M-w
>> >> 
>> >> In emacs 23, the cursor would bounce between the point and the mark the
>> >> second time M-w was pressed, since the highlighting of the region turned
>> >> off after the first time.  Or, if transient-mark-mode is nil, then the
>> >> first M-w would bounce the cursor between the point and mark.  In
>> >> emacs24, M-w seems to never cause the cursor to bounce between the point
>> >> and mark.
>> >
>> > It still does that to me, in the current trunk tip.
>> >
>> > Does it work in "emacs -Q" for you?
>
> For the record, Jay replied off-list that "emacs -Q" has the same
> problem for him.
>
>> It appears to be inconsistent.  Sometimes it will happen, sometimes it
>> will not.  I first noticed this many months ago, but at the time
>> couldn't cause it to happen on command, and as such forgot about it for
>> a while.  Today, I tried again with emacs -Q built from bzr revno
>> 106562.  I definitely see this behavior, without fail.
>> 
>>   emacs -Q
>>   (In *scratch* buffer)
>>   C-p C-p C-p C-SPC C-e M-w
>
> This is not the right recipe.  The first M-w does NOT show the region
> by momentarily moving point to its other end, because the default is
> to have transient-mark-mode on, which already shows the region.  You
> need to type M-w twice or more in a row to see point move.

Sorry, I forgot to type the second M-w.  I usually use emacs without
tmm, and that is why I made that error.

> Anyway, I don't see it on any machine to which I have access, FWIW.  I
> tried both unoptimized and optimized builds, on Windows and on
> GNU/Linux, and they all behave as expected.

I just tried this again in a random buffer in my running non -Q emacs.
The first M-w caused the cursor to bounce, the second did not, the third
did, the fourth and fifth did not.  This is why I called the behavior
inconsistent.  I just tried it in emacs -Q again, and had it bounce
three times out of 15 tries.  When it does bounce, and the mark and
point are on different lines, I also see the line indicator change along
with the bounce.  When it does not bounce, the line indicator does not
change.

I am running in an unoptimized debug build with assertions turned on,
and am familiar with gdb.  If there is any way I can help debug this,
please let me know.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@md5i.com> writes:

> I just tried this again in a random buffer in my running non -Q emacs.
> The first M-w caused the cursor to bounce, the second did not, the third
> did, the fourth and fifth did not.  This is why I called the behavior
> inconsistent.  I just tried it in emacs -Q again, and had it bounce
> three times out of 15 tries.  When it does bounce, and the mark and
> point are on different lines, I also see the line indicator change along
> with the bounce.  When it does not bounce, the line indicator does not
> change.

I should mention that when I say I tries this N times, I mean without
moving the mark or point.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Cc: ejb@ql.org,  10195@debbugs.gnu.org
> Date: Sat, 03 Dec 2011 10:19:06 -0500
> 
> I just tried this again in a random buffer in my running non -Q emacs.
> The first M-w caused the cursor to bounce, the second did not, the third
> did, the fourth and fifth did not.  This is why I called the behavior
> inconsistent.  I just tried it in emacs -Q again, and had it bounce
> three times out of 15 tries.

Does "C-h l" show all the 15 M-w keystrokes you did?

> I am running in an unoptimized debug build with assertions turned on,
> and am familiar with gdb.  If there is any way I can help debug this,
> please let me know.

M-w calls sit-for after bouncing point to the position of mark; the
default waiting period is 1 sec.  How about instrumenting sit-for with
calls to `message' and seeing what's going on there?  One possibility
is that some input event terminates the wait immediately (see
sit-for's code).  Another possibility is that something happens in
read-event, in which case you will need to use GDB.  But I think it
would be good to see what's going on in sit-for before you go to the C
level.

Another idea is to replace the call to sit-for in kill-ring-save with
a call to sleep-for, and see if that changes anything.  If it does,
the probably culprit is sit-for and whatever it calls.

Thanks.

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> Date: Sat, 03 Dec 2011 18:38:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 10195@debbugs.gnu.org, ejb@ql.org
> 
> M-w calls sit-for after bouncing point to the position of mark; the
> default waiting period is 1 sec.  How about instrumenting sit-for with
> calls to `message' and seeing what's going on there?

Of course `message' enters redisplay, so it could obscure the
problem...

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@md5i.com>
>> Cc: ejb@ql.org,  10195@debbugs.gnu.org
>> Date: Sat, 03 Dec 2011 10:19:06 -0500
>> 
>> I just tried this again in a random buffer in my running non -Q emacs.
>> The first M-w caused the cursor to bounce, the second did not, the third
>> did, the fourth and fifth did not.  This is why I called the behavior
>> inconsistent.  I just tried it in emacs -Q again, and had it bounce
>> three times out of 15 tries.
>
> Does "C-h l" show all the 15 M-w keystrokes you did?
>
>> I am running in an unoptimized debug build with assertions turned on,
>> and am familiar with gdb.  If there is any way I can help debug this,
>> please let me know.

Yes, and the region does end up in the kill ring.

> M-w calls sit-for after bouncing point to the position of mark; the
> default waiting period is 1 sec.  How about instrumenting sit-for with
> calls to `message' and seeing what's going on there?  One possibility
> is that some input event terminates the wait immediately (see
> sit-for's code).  Another possibility is that something happens in
> read-event, in which case you will need to use GDB.  But I think it
> would be good to see what's going on in sit-for before you go to the C
> level.
>
> Another idea is to replace the call to sit-for in kill-ring-save with
> a call to sleep-for, and see if that changes anything.  If it does,
> the probably culprit is sit-for and whatever it calls.

I'm away from home until late tonight.  I'll give this (or something
similar) a try then.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> M-w calls sit-for after bouncing point to the position of mark; the
> default waiting period is 1 sec.  How about instrumenting sit-for with
> calls to `message' and seeing what's going on there?  One possibility
> is that some input event terminates the wait immediately (see
> sit-for's code).  Another possibility is that something happens in
> read-event, in which case you will need to use GDB.  But I think it
> would be good to see what's going on in sit-for before you go to the C
> level.
>
> Another idea is to replace the call to sit-for in kill-ring-save with
> a call to sleep-for, and see if that changes anything.  If it does,
> the probably culprit is sit-for and whatever it calls.

FWIW, I can see this problem, and the following workaround seems to do
the trick.  Your pending input explanation is probably right.

=== modified file 'lisp/simple.el'
*** lisp/simple.el	2011-11-19 19:49:56 +0000
--- lisp/simple.el	2011-12-04 02:25:33 +0000
***************
*** 3251,3256 ****
--- 3251,3257 ----
  	      ;; Swap point and mark.
  	      (set-marker (mark-marker) (point) (current-buffer))
  	      (goto-char other-end)
+ 	      (redisplay t)
  	      (sit-for blink-matching-delay)
  	      ;; Swap back.
  	      (set-marker (mark-marker) other-end (current-buffer))

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Michael Welsh Duggan]

Chong Yidong <cyd@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> M-w calls sit-for after bouncing point to the position of mark; the
>> default waiting period is 1 sec.  How about instrumenting sit-for with
>> calls to `message' and seeing what's going on there?  One possibility
>> is that some input event terminates the wait immediately (see
>> sit-for's code).  Another possibility is that something happens in
>> read-event, in which case you will need to use GDB.  But I think it
>> would be good to see what's going on in sit-for before you go to the C
>> level.
>>
>> Another idea is to replace the call to sit-for in kill-ring-save with
>> a call to sleep-for, and see if that changes anything.  If it does,
>> the probably culprit is sit-for and whatever it calls.
>
> FWIW, I can see this problem, and the following workaround seems to do
> the trick.  Your pending input explanation is probably right.

Yes, this seems to do the trick for me as well.

> === modified file 'lisp/simple.el'
> *** lisp/simple.el	2011-11-19 19:49:56 +0000
> --- lisp/simple.el	2011-12-04 02:25:33 +0000
> ***************
> *** 3251,3256 ****
> --- 3251,3257 ----
>   	      ;; Swap point and mark.
>   	      (set-marker (mark-marker) (point) (current-buffer))
>   	      (goto-char other-end)
> + 	      (redisplay t)
>   	      (sit-for blink-matching-delay)
>   	      ;; Swap back.
>   	      (set-marker (mark-marker) other-end (current-buffer))
>

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Michael Welsh Duggan <md5i@md5i.com>,  10195@debbugs.gnu.org,  ejb@ql.org
> Date: Sun, 04 Dec 2011 10:29:16 +0800
> 
> Your pending input explanation is probably right.

The question is: what input is pending?

Looking at the event queue should reveal that.  If that shows nothing
appropriate, then try looking lower at the socket read.

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Your pending input explanation is probably right.
>
> The question is: what input is pending?

It's an X selection request event.  I'm not sure where the request is
coming from---Gnome's clipboard manager, maybe.  Setting
interprogram-cut-function to nil also inhibits the problem.

OTOH, I don't see why the pending input doesn't trigger for Emacs 23,
since M-w copies to the primary selection there too.  Maybe it's a
subtle effect of one of the changes to the primary selection code a few
months ago.

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: md5i@md5i.com,  10195@debbugs.gnu.org,  ejb@ql.org
> Date: Sun, 04 Dec 2011 16:11:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Your pending input explanation is probably right.
> >
> > The question is: what input is pending?
> 
> It's an X selection request event.  I'm not sure where the request is
> coming from---Gnome's clipboard manager, maybe.

Looks like readable_events should filter out a few more event types,
when passed READABLE_EVENTS_FILTER_EVENTS in `flags'?  I could think
of additional events that should not end sit-for, e.g. keyboard
language switch.

> OTOH, I don't see why the pending input doesn't trigger for Emacs 23,
> since M-w copies to the primary selection there too.

?? Doesn't M-w copy to the clipboard now?

> Maybe it's a subtle effect of one of the changes to the primary
> selection code a few months ago.

Probably.  But selection requests shouldn't interrupt sit-for
regardless, since (AFAIR) they can come in out of Emacs's control.

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> It's an X selection request event.  I'm not sure where the request is
>> coming from---Gnome's clipboard manager, maybe.
>
> Looks like readable_events should filter out a few more event types,
> when passed READABLE_EVENTS_FILTER_EVENTS in `flags'?  I could think
> of additional events that should not end sit-for, e.g. keyboard
> language switch... selection requests shouldn't interrupt sit-for
> regardless, since (AFAIR) they can come in out of Emacs's control.

I don't think sit-for should ignore selection requests.  If so, doing
(sit-for 10) would cause Emacs to stop responding to selection requests
from other applications for 10 seconds.  That doesn't sound right.

The workaround of putting the (redisplay t) in kill-ring-save works
because Fredisplay calls swallow_events(), which has code in it to
process selection request events.

I think the right fix is for input-pending-p to call swallow_events(),
as below.  Thoughts?

*** src/keyboard.c	2011-12-01 18:27:52 +0000
--- src/keyboard.c	2011-12-04 15:58:03 +0000
***************
*** 10522,10527 ****
--- 10522,10528 ----
        || !NILP (Vunread_input_method_events))
      return (Qt);
  
+   swallow_events (0);
    get_input_pending (&input_pending,
  		     READABLE_EVENTS_DO_TIMERS_NOW
  		     | READABLE_EVENTS_FILTER_EVENTS);

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: md5i@md5i.com,  10195@debbugs.gnu.org,  ejb@ql.org
> Date: Sun, 04 Dec 2011 23:59:15 +0800
> 
> I don't think sit-for should ignore selection requests.  If so, doing
> (sit-for 10) would cause Emacs to stop responding to selection requests
> from other applications for 10 seconds.  That doesn't sound right.

What happens if an application receives a selection request while it
is busy with some long calculation? won't the response be delayed in
that case as well?

> I think the right fix is for input-pending-p to call swallow_events(),
> as below.  Thoughts?

I'm no expert on this, but it looks OK.  It only swallows selection
requests, though; are these the only ones that can cause this kind of
problems?

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Stefan Monnier]

> What happens if an application receives a selection request while it
> is busy with some long calculation? won't the response be delayed in
> that case as well?

Yes, and that's a problem as well.


        Stefan

bug#10195: 24.0.92; M-w may no longer provide visual feedback

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm no expert on this, but it looks OK.  It only swallows selection
> requests, though; are these the only ones that can cause this kind of
> problems?

They are the only ones I can think of.  I'll go ahead and check in a fix
along those lines.

The READABLE_EVENTS_FILTER_EVENTS looks pretty sketchy to me; it's not
clear that disregarding focus events like that is the right thing to do.
But I'd rather not touch that part of the code now.