GNU bug report logs - #10195
24.0.92; M-w may no longer provide visual feedback

Previous Next

Package: emacs;

Reported by: Jay Berkenbilt <ejb <at> ql.org>

Date: Fri, 2 Dec 2011 16:11:01 UTC

Severity: normal

Found in version 24.0.92

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10195 in the body.
You can then email your comments to 10195 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Fri, 02 Dec 2011 16:11:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jay Berkenbilt <ejb <at> ql.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 02 Dec 2011 16:11:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jay Berkenbilt <ejb <at> ql.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.92; M-w may no longer provide visual feedback
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.  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)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Fri, 02 Dec 2011 16:25:01 GMT) Full text and rfc822 format available.

Message #8 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jay Berkenbilt <ejb <at> ql.org>
Cc: 10195 <at> debbugs.gnu.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Fri, 02 Dec 2011 18:23:00 +0200
> From: Jay Berkenbilt <ejb <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 05:33:01 GMT) Full text and rfc822 format available.

Message #11 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, Jay Berkenbilt <ejb <at> ql.org>
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 00:31:36 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jay Berkenbilt <ejb <at> 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 <at> md5i.com)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 07:11:01 GMT) Full text and rfc822 format available.

Message #14 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 09:09:29 +0200
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: Jay Berkenbilt <ejb <at> ql.org>,  10195 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 15:20:02 GMT) Full text and rfc822 format available.

Message #17 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 10:19:06 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: Jay Berkenbilt <ejb <at> ql.org>,  10195 <at> 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 <at> md5i.com)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 15:23:01 GMT) Full text and rfc822 format available.

Message #20 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 10:22:31 -0500
Michael Welsh Duggan <md5i <at> 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 <at> md5i.com)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 16:40:02 GMT) Full text and rfc822 format available.

Message #23 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 18:38:03 +0200
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: ejb <at> ql.org,  10195 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 17:08:01 GMT) Full text and rfc822 format available.

Message #26 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: md5i <at> md5i.com
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 19:05:42 +0200
> Date: Sat, 03 Dec 2011 18:38:03 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 10195 <at> debbugs.gnu.org, ejb <at> 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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sat, 03 Dec 2011 17:39:02 GMT) Full text and rfc822 format available.

Message #29 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 12:38:12 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: ejb <at> ql.org,  10195 <at> 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 <at> md5i.com)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 02:30:01 GMT) Full text and rfc822 format available.

Message #32 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, Michael Welsh Duggan <md5i <at> md5i.com>, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 10:29:16 +0800
Eli Zaretskii <eliz <at> 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))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 03:30:02 GMT) Full text and rfc822 format available.

Message #35 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <md5i <at> md5i.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sat, 03 Dec 2011 22:29:24 -0500
Chong Yidong <cyd <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> 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 <at> md5i.com)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 04:02:03 GMT) Full text and rfc822 format available.

Message #38 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 05:59:37 +0200
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Michael Welsh Duggan <md5i <at> md5i.com>,  10195 <at> debbugs.gnu.org,  ejb <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 08:12:01 GMT) Full text and rfc822 format available.

Message #41 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 16:11:20 +0800
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 11:27:02 GMT) Full text and rfc822 format available.

Message #44 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 06:25:49 -0500
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: md5i <at> md5i.com,  10195 <at> debbugs.gnu.org,  ejb <at> ql.org
> Date: Sun, 04 Dec 2011 16:11:20 +0800
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 16:00:02 GMT) Full text and rfc822 format available.

Message #47 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 23:59:15 +0800
Eli Zaretskii <eliz <at> 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);





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Sun, 04 Dec 2011 17:01:02 GMT) Full text and rfc822 format available.

Message #50 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 18:58:40 +0200
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: md5i <at> md5i.com,  10195 <at> debbugs.gnu.org,  ejb <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Mon, 05 Dec 2011 03:31:01 GMT) Full text and rfc822 format available.

Message #53 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, ejb <at> ql.org, Chong Yidong <cyd <at> gnu.org>
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Sun, 04 Dec 2011 22:29:35 -0500
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10195; Package emacs. (Mon, 05 Dec 2011 15:19:02 GMT) Full text and rfc822 format available.

Message #56 received at 10195 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10195 <at> debbugs.gnu.org, md5i <at> md5i.com, ejb <at> ql.org
Subject: Re: bug#10195: 24.0.92; M-w may no longer provide visual feedback
Date: Mon, 05 Dec 2011 23:17:25 +0800
Eli Zaretskii <eliz <at> 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.




bug closed, send any further explanations to 10195 <at> debbugs.gnu.org and Jay Berkenbilt <ejb <at> ql.org> Request was from Chong Yidong <cyd <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 05 Dec 2011 15:22:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 03 Jan 2012 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 88 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.