* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
@ 2008-08-20 23:38 David Caldwell
0 siblings, 0 replies; 8+ messages in thread
From: David Caldwell @ 2008-08-20 23:38 UTC (permalink / raw
To: bug-gnu-emacs
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
@ 2008-08-21 15:48 Chong Yidong
2008-08-21 19:30 ` David Caldwell
0 siblings, 1 reply; 8+ messages in thread
From: Chong Yidong @ 2008-08-21 15:48 UTC (permalink / raw
To: David Caldwell; +Cc: 754
> 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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
2008-08-21 15:48 Chong Yidong
@ 2008-08-21 19:30 ` David Caldwell
2009-01-10 4:41 ` David Caldwell
0 siblings, 1 reply; 8+ messages in thread
From: David Caldwell @ 2008-08-21 19:30 UTC (permalink / raw
To: Chong Yidong; +Cc: 754
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
2008-08-21 19:30 ` David Caldwell
@ 2009-01-10 4:41 ` David Caldwell
2011-07-06 17:49 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: David Caldwell @ 2009-01-10 4:41 UTC (permalink / raw
To: Chong Yidong; +Cc: 754
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
2009-01-10 4:41 ` David Caldwell
@ 2011-07-06 17:49 ` Lars Magne Ingebrigtsen
2011-07-06 18:05 ` David Caldwell
0 siblings, 1 reply; 8+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-06 17:49 UTC (permalink / raw
To: David Caldwell; +Cc: Chong Yidong, 754
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
2011-07-06 17:49 ` Lars Magne Ingebrigtsen
@ 2011-07-06 18:05 ` David Caldwell
2011-07-07 17:53 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: David Caldwell @ 2011-07-06 18:05 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: Chong Yidong, 754
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#754: Can't cancel dabbrev-expand (M-/) with C-g
2011-07-06 18:05 ` David Caldwell
@ 2011-07-07 17:53 ` Lars Magne Ingebrigtsen
2011-07-07 18:29 ` David Caldwell
0 siblings, 1 reply; 8+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-07 17:53 UTC (permalink / raw
To: David Caldwell; +Cc: Chong Yidong, 754
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-07-07 18:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-20 23:38 bug#754: Can't cancel dabbrev-expand (M-/) with C-g David Caldwell
-- strict thread matches above, loose matches on Subject: below --
2008-08-21 15:48 Chong Yidong
2008-08-21 19:30 ` David Caldwell
2009-01-10 4:41 ` David Caldwell
2011-07-06 17:49 ` Lars Magne Ingebrigtsen
2011-07-06 18:05 ` David Caldwell
2011-07-07 17:53 ` Lars Magne Ingebrigtsen
2011-07-07 18:29 ` David Caldwell
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.