bug#754: Can't cancel dabbrev-expand (M-/) with C-g

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

Hello,

If I have many buffers open (284 at the moment) and if I run
dabbrev-expand (M-/) to expand the word under my buffers then it
searches through every buffer and takes an understandably long
time. If I mispelled the word fragment then it never has a hope of
finding it and I'd like to cancel the operation. But C-g does not work
for some reason and so I have to wait a good 5 to 10 seconds for it to
finish scanning all my buffers. This gets very frustrating after the
third or fourth time.

During the scan the current buffer is updating in the minibuffer with
the "Scanning `buffer'" message which I assume means it *should* be
able to handle the quit signal during the scan, and I've looked in the
dabbrev.el file and I don't see anything that looks like it's
explicitly blocking the quit signal, but I'm really no elisp expert.

I believe this happens on my Mac OS (in a window) Emacs as well as my
Debian Emacs. I didn't have as many buffers open in the Debian Emacs
so it was harder to tell since it only gave me about a second to hit
C-g.

Thanks,
   David

In GNU Emacs 22.2.1 (i386-apple-darwin9.2.2, Carbon Version 1.6.0)
  of 2008-03-28 on black.local
Windowing system distributor `Apple Inc.', version 10.5.4
configured using `configure  '--without-x' '--prefix=/usr/local''

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: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
   encoded-kbd-mode: t
   shell-dirtrack-mode: t
   auto-insert-mode: t
   delete-selection-mode: t
   show-paren-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
d _ p r o m p M-/ C-h k M-/ <help-echo> <down-mouse-1>
<mouse-1> <double-down-mouse-1> <mouse-movement> <mouse-movement>
<double-drag-mouse-1> s-c <left> <left> <left> <left>
<left> <down> <right> <right> <right> <right> <right>
<right> <right> <right> C-e <left> <left> <left> <left>
<left> <left> <return> C-a C-x 1 <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> C-a C-a C-e C-a <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> C-s c a n c
e l C-s C-s C-s C-g C-g C-g C-h k C-g C-x 1 C-s q u
i t C-s C-s C-s C-g C-g <down> <down> <down> <down>
<down> <down> <down> <down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> <M-down> <M-down>
<M-down> <M-down> <M-down> <M-down> M-x r e p o r t
- e m a c s - b u g <return>

Recent messages:
Type C-x 1 to remove help window.
Auto-saving...done
uncompressing dabbrev.el.gz...done
Note: file is write protected
Quit [2 times]
Type C-x 1 to remove help window.
Quit
Loading emacsbug...done
exchange-point-and-mark: No mark set in this buffer
End of buffer [4 times]


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 304 bytes --]

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[Chong Yidong]

> If I have many buffers open (284 at the moment) and if I run
> dabbrev-expand (M-/) to expand the word under my buffers then it
> searches through every buffer and takes an understandably long
> time. If I mispelled the word fragment then it never has a hope of
> finding it and I'd like to cancel the operation. But C-g does not work
> for some reason and so I have to wait a good 5 to 10 seconds for it to
> finish scanning all my buffers. This gets very frustrating after the
> third or fourth time.

I don't see why C-g wouldn't work here.  Could you apply the following
patch and see if the problem persists?  (This is not a fix; it's an
attempt to diagnose the problem.  As far as I know, quitting should not
be inhibited here.)

*** emacs/lisp/dabbrev.el.~1.83.2.3.~	2008-01-06 21:44:58.000000000 -0500
--- emacs/lisp/dabbrev.el	2008-08-21 11:43:59.000000000 -0400
***************
*** 777,783 ****
  	     (setq dabbrev--friend-buffer-list
  		   (dabbrev--make-friend-buffer-list))))
         ;; Walk through the buffers till we find a match.
!        (let (expansion)
  	 (while (and (not expansion) dabbrev--friend-buffer-list)
  	   (setq dabbrev--last-buffer (pop dabbrev--friend-buffer-list))
  	   (set-buffer dabbrev--last-buffer)
--- 777,784 ----
  	     (setq dabbrev--friend-buffer-list
  		   (dabbrev--make-friend-buffer-list))))
         ;; Walk through the buffers till we find a match.
!        (let ((inhibit-quit nil)
! 	     expansion)
  	 (while (and (not expansion) dabbrev--friend-buffer-list)
  	   (setq dabbrev--last-buffer (pop dabbrev--friend-buffer-list))
  	   (set-buffer dabbrev--last-buffer)

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[David Caldwell]

Chong Yidong wrote:
>> If I have many buffers open (284 at the moment) and if I run
>> dabbrev-expand (M-/) to expand the word under my buffers then it
>> searches through every buffer and takes an understandably long
>> time. If I mispelled the word fragment then it never has a hope of
>> finding it and I'd like to cancel the operation. But C-g does not work
>> for some reason and so I have to wait a good 5 to 10 seconds for it to
>> finish scanning all my buffers. This gets very frustrating after the
>> third or fourth time.
> 
> I don't see why C-g wouldn't work here.  Could you apply the following
> patch and see if the problem persists?  (This is not a fix; it's an
> attempt to diagnose the problem.  As far as I know, quitting should not
> be inhibited here.)

>          ;; Walk through the buffers till we find a match.
> !        (let ((inhibit-quit nil)
> ! 	     expansion)

I tried the patch but Emacs behaved the same as without it.

-David

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[David Caldwell]

David Caldwell wrote:
> Chong Yidong wrote:
>>> If I have many buffers open (284 at the moment) and if I run
>>> dabbrev-expand (M-/) to expand the word under my buffers then it
>>> searches through every buffer and takes an understandably long
>>> time. If I mispelled the word fragment then it never has a hope of
>>> finding it and I'd like to cancel the operation. But C-g does not work
>>> for some reason and so I have to wait a good 5 to 10 seconds for it to
>>> finish scanning all my buffers. This gets very frustrating after the
>>> third or fourth time.
>>
>> I don't see why C-g wouldn't work here.

After further testing, I believe this is not really a bug in dabbrev.
C-g *does* cancel the operation, it's just that sometimes there is a
large lag before it cancels (though in my current tests I've never had
it go beyond 2 seconds). I have a ton of buffers open right this moment
and fulling scan them takes 15 to 20 seconds, so I can definitely tell
that it's canceling.

The 1 to 2 second lag is still a little frustrating, but it's much
better than the originally reported 5 to 10 second lag. I wonder if it
has to do with how the Mac handles the quit signal in windowed mode...

-David

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[Lars Magne Ingebrigtsen]

David Caldwell <david@porkrind.org> writes:

>>>> If I have many buffers open (284 at the moment) and if I run
>>>> dabbrev-expand (M-/) to expand the word under my buffers then it
>>>> searches through every buffer and takes an understandably long
>>>> time. If I mispelled the word fragment then it never has a hope of
>>>> finding it and I'd like to cancel the operation. But C-g does not work
>>>> for some reason and so I have to wait a good 5 to 10 seconds for it to
>>>> finish scanning all my buffers. This gets very frustrating after the
>>>> third or fourth time.

[...]

> After further testing, I believe this is not really a bug in dabbrev.
> C-g *does* cancel the operation, it's just that sometimes there is a
> large lag before it cancels (though in my current tests I've never had
> it go beyond 2 seconds). I have a ton of buffers open right this moment
> and fulling scan them takes 15 to 20 seconds, so I can definitely tell
> that it's canceling.
>
> The 1 to 2 second lag is still a little frustrating, but it's much
> better than the originally reported 5 to 10 second lag. I wonder if it
> has to do with how the Mac handles the quit signal in windowed mode...

Do you know if this bug is still present in newer Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On 7/6/11 10:49 AM, Lars Magne Ingebrigtsen wrote:
> David Caldwell <david@porkrind.org> writes:
> 
>>>>> If I have many buffers open (284 at the moment) and if I run
>>>>> dabbrev-expand (M-/) to expand the word under my buffers then it
>>>>> searches through every buffer and takes an understandably long
>>>>> time. If I mispelled the word fragment then it never has a hope of
>>>>> finding it and I'd like to cancel the operation. But C-g does not work
>>>>> for some reason and so I have to wait a good 5 to 10 seconds for it to
>>>>> finish scanning all my buffers. This gets very frustrating after the
>>>>> third or fourth time.
> 
> [...]
> 
>> After further testing, I believe this is not really a bug in dabbrev.
>> C-g *does* cancel the operation, it's just that sometimes there is a
>> large lag before it cancels (though in my current tests I've never had
>> it go beyond 2 seconds). I have a ton of buffers open right this moment
>> and fulling scan them takes 15 to 20 seconds, so I can definitely tell
>> that it's canceling.
>>
>> The 1 to 2 second lag is still a little frustrating, but it's much
>> better than the originally reported 5 to 10 second lag. I wonder if it
>> has to do with how the Mac handles the quit signal in windowed mode...
> 
> Do you know if this bug is still present in newer Emacs versions?

It's hard to tell--currently, it seems that scanning through all the
buffers is *really* fast. So it only takes about a second to scan
through my 600 buffers even if I don't cancel it. It doesn't really seem
like canceling makes the process any faster but my level of annoyance is
gone because of the search speedup.

I'm running a version built from bzr on 2011-06-09.

-David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 305 bytes --]

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[Lars Magne Ingebrigtsen]

David Caldwell <david@porkrind.org> writes:

> It's hard to tell--currently, it seems that scanning through all the
> buffers is *really* fast. So it only takes about a second to scan
> through my 600 buffers even if I don't cancel it. It doesn't really seem
> like canceling makes the process any faster but my level of annoyance is
> gone because of the search speedup.

Then this bug report can be closed, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#754: Can't cancel dabbrev-expand (M-/) with C-g

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On 7/7/11 10:53 AM, Lars Magne Ingebrigtsen wrote:
> David Caldwell <david@porkrind.org> writes:
> 
>> It's hard to tell--currently, it seems that scanning through all the
>> buffers is *really* fast. So it only takes about a second to scan
>> through my 600 buffers even if I don't cancel it. It doesn't really seem
>> like canceling makes the process any faster but my level of annoyance is
>> gone because of the search speedup.
> 
> Then this bug report can be closed, I guess?

Sure. i can always open a new one if the problem recurs.

-David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 305 bytes --]