* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
@ 2011-07-24 12:07 Kenichi Handa
2011-08-23 4:49 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-07-24 12:07 UTC (permalink / raw)
To: 9160
The previous try of sending this report failed by this error:
smtpmail-send-it: Sending failed; no recipients
This is the second try with the same Emacs session.
The latest trunk Emacs freezes in *shell* buffer in the
following scenario.
% emacs -Q
M-x shell RET
.. in *shell* buffer
% mkdir tmp (or if you already have tmp dir, % rm -rf tmp; mkdir tmp)
% cd tmp
% touch '0 a' '0-a'
% ls 0<TAB>
.. here <TAB> is a single tab and *Completions* buffer is
shown with this contents ...
------------------------------------------------------------
Click <mouse-2> on ...
In this buffer, ...
Possible completions are:
0 a
0-a
------------------------------------------------------------
.. then type \ (backshash), and Emacs freezes. C-g doesn't
work (perhaps because inhibit-quit is non-nil).
The backtrace is this:
(gdb) bt full
#0 0x0818250c in buf_charpos_to_bytepos (b=0x896ae40, charpos=20)
at marker.c:129
tail = 0x7de100
best_above = 16843009
best_above_byte = 16843009
best_below = 16843009
best_below_byte = 16843009
#1 0x081c82fa in Fchar_after (pos=80) at editfns.c:1180
pos_byte = 192
#2 0x082195ce in exec_byte_code (bytestr=141135289, vector=144648053,
maxdepth=28, args_template=0, nargs=0, args=0xbfffd1a8) at bytecode.c:1400
count = 11
op = 102
vectorp = 0x89f2778
stack = {
pc = 0x89f4c29 "\305=\203\065",
byte_string = 141135289,
byte_string_start = 0x89f4c00 "\212\300\301!\210`)`\301\211\212\003b\210`\003W\203H",
constants = 144648053,
next = 0xbfffd1fc
}
top = 0xbfffce94
result = -1073753864
#3 0x081d87cb in funcall_lambda (fun=144667045, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 1
syms_left = 0
next = -1
lexenv = 16777215
count = 11
i = 0
optional = 0
rest = 1
#4 0x081d8351 in Ffuncall (nargs=1, args=0xbfffd1a4) at eval.c:3058
fun = 144667045
original_fun = 144439418
funcar = 142613314
numargs = 0
lisp_numargs = -1073753720
val = -1073746940
backtrace = {
next = 0xbfffd468,
function = 0xbfffd1a4,
args = 0xbfffd1a8,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x400
i = 138774272
#5 0x08217ff4 in exec_byte_code (bytestr=141135145, vector=139161413,
maxdepth=48, args_template=1024, nargs=1, args=0xbfffd4d8)
at bytecode.c:785
count = 11
op = 0
vectorp = 0x84b6f48
stack = {
pc = 0x89f4c8a "\211\205", <incomplete sequence \312>,
byte_string = 141135145,
byte_string_start = 0x89f4c88 "\b \211\205", <incomplete sequence \312>,
constants = 139161413,
next = 0xbfffd51c
}
top = 0xbfffd1a4
result = -1073753160
#6 0x081d87cb in funcall_lambda (fun=144668029, nargs=1, arg_vector=0x400)
at eval.c:3174
val = 0
syms_left = 1024
next = 138875314
lexenv = 139022274
count = 11
i = 136905861
optional = 139017306
rest = 144745980
#7 0x081d8351 in Ffuncall (nargs=2, args=0xbfffd4d0) at eval.c:3058
fun = 144668029
original_fun = 144439490
funcar = 144745980
numargs = 1
lisp_numargs = 6
val = -1073752912
backtrace = {
next = 0xbfffd788,
function = 0xbfffd4d0,
args = 0xbfffd4d4,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x0
i = 1
#8 0x08217ff4 in exec_byte_code (bytestr=141149337, vector=144663293,
maxdepth=20, args_template=0, nargs=0, args=0xbfffd804) at bytecode.c:785
count = 11
op = 1
vectorp = 0x89f6300
stack = {
pc = 0x89f51eb "\205\063",
byte_string = 141149337,
byte_string_start = 0x89f51e8 "\306\b!\205\063",
constants = 144663293,
next = 0xbfffda3c
}
top = 0xbfffd4d0
result = -1073752376
#9 0x081d87cb in funcall_lambda (fun=144664909, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 192
syms_left = 0
next = 144244604
lexenv = 138765568
count = 11
i = -1073752248
optional = -1073751832
rest = 138763420
#10 0x081d8351 in Ffuncall (nargs=1, args=0xbfffd800) at eval.c:3058
fun = 144664909
original_fun = 144664909
funcar = -1073752048
numargs = 0
lisp_numargs = -1073752072
val = 138909954
backtrace = {
next = 0xbfffd86c,
function = 0xbfffd800,
args = 0xbfffd804,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0xbfffd800
i = 140358225
#11 0x081d6ded in eval_sub (form=142311374) at eval.c:2329
vals = 0xbfffd800
argnum = 1
sa_count = 11
sa_must_free = 0
numargs = 4
args_left = 138875314
i = -1073752064
maxargs = -1073744428
argvals = {0, 0, 0, 0, 1, 64, 1028, -1073751912}
fun = 138537901
val = 138875314
original_fun = 138989594
original_args = 142311382
funcar = -1073751320
backtrace = {
next = 0xbfffdca8,
function = 0xbfffd8d0,
args = 0xbfffd800,
nargs = 1,
debug_on_exit = 0
}
gcpro1 = {
next = 0xbfffd8c8,
var = 0x81bf2bc,
nvars = 139008810
}
gcpro2 = {
next = 0x8491b28,
var = 0x87b882e,
nvars = 140358225
}
gcpro3 = {
next = 0xbfffd8e8,
var = 0xbfffd800,
nvars = 1
}
#12 0x081d52f1 in internal_catch (tag=144439058, func=0x81d698a <eval_sub>,
arg=142311374) at eval.c:1247
c = {
tag = 144439058,
val = 138875314,
next = 0xbfffe178,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, -1073744136, -1073744428, -1073751576,
1957156673, -1313861074},
__mask_was_saved = 0,
__saved_mask = {
__val = {144427396, 144688469, 3221216332, 14095296, 1688,
14095344, 1168, 14095296, 14090228, 3221215480, 4294967275,
3221215460, 3221215456, 3221215656, 135213689, 144722430,
102, 3221215656, 136019157, 144958808, 18, 144722403, 21,
144722421, 4294967284, 3221216328, 135976766, 138768676,
144715544, 0, 138766192, 16}
}
}},
backlist = 0xbfffdca8,
handlerlist = 0xbffff0e8,
lisp_eval_depth = 8,
pdlcount = 11,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0xbfffda3c
}
#13 0x08218a50 in exec_byte_code (bytestr=141149401, vector=144481013,
maxdepth=12, args_template=0, nargs=0, args=0xbfffdd14) at bytecode.c:966
v1 = 142311374
count = 11
op = 141
vectorp = 0x89c9af8
stack = {
pc = 0x89f51e1 "\207",
byte_string = 141149401,
byte_string_start = 0x89f51dc "\300\301\302D\215\207",
constants = 144481013,
next = 0xbfffdd7c
}
top = 0xbfffda00
result = -1073751048
#14 0x081d87cb in funcall_lambda (fun=142961805, nargs=0, arg_vector=0x0)
at eval.c:3174
val = -1073750228
syms_left = 0
next = 139022274
lexenv = 144152643
count = 11
i = 0
optional = 139022274
rest = 144683398
#15 0x081d8351 in Ffuncall (nargs=1, args=0xbfffdd10) at eval.c:3058
fun = 142961805
original_fun = 144439058
funcar = 138877288
numargs = 0
lisp_numargs = -1
val = 144715544
backtrace = {
next = 0xbfffdfe8,
function = 0xbfffdd10,
args = 0xbfffdd14,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x0
i = 144092736
#16 0x08217ff4 in exec_byte_code (bytestr=141111881, vector=144442541,
maxdepth=56, args_template=0, nargs=0, args=0xbfffe064) at bytecode.c:785
count = 3
op = 0
vectorp = 0x89c04b0
stack = {
pc = 0x89f4546 "`\bGZ\310 ]\211`{\002\205\210",
byte_string = 141111881,
byte_string_start = 0x89f4530 "Ɖ\030\031Ɖ\032\033Ɖ\034\035\016 \036 \016!\036!\307 `\bGZ\310 ]\211`{\002\205\210",
constants = 144442541,
next = 0xbfffe29c
}
top = 0xbfffdd10
result = -1073750216
#17 0x081d87cb in funcall_lambda (fun=144648341, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 136520635
syms_left = 0
next = 13
lexenv = 13
count = 3
i = -1073749976
optional = 142593753
rest = 144745980
#18 0x081d8351 in Ffuncall (nargs=1, args=0xbfffe060) at eval.c:3058
fun = 144648341
original_fun = 144648341
funcar = 144683398
numargs = 0
lisp_numargs = 140358129
val = 13
backtrace = {
next = 0xbfffe0cc,
function = 0xbfffe060,
args = 0xbfffe064,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0xbfffe060
i = 13
#19 0x081d6ded in eval_sub (form=142311390) at eval.c:2329
vals = 0xbfffe060
argnum = 1
sa_count = 3
sa_must_free = 0
numargs = 4
args_left = 138875314
i = -1073749920
maxargs = -1073744428
argvals = {144764256, 144764256, 144764256, -1073749720, 136515748,
144764256, 144764256, 21}
fun = 138537901
val = 21
original_fun = 138989594
original_args = 142311398
funcar = -1073749672
backtrace = {
next = 0xbfffe508,
function = 0xbfffe130,
args = 0xbfffe060,
nargs = 1,
debug_on_exit = 0
}
gcpro1 = {
next = 0x0,
var = 0x15,
nvars = 1
}
gcpro2 = {
next = 0x14,
var = 0xbfffe020,
nvars = -1
}
gcpro3 = {
next = 0x0,
var = 0xbfffe060,
nvars = 1
}
#20 0x081d52f1 in internal_catch (tag=144439034, func=0x81d698a <eval_sub>,
arg=142311390) at eval.c:1247
c = {
tag = 144439034,
val = 138875314,
next = 0xbffff020,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, -1073744136, -1073744428, -1073749432,
1960253249, -1313861074},
__mask_was_saved = 0,
__saved_mask = {
__val = {64, 138875314, 141415013, 144763011, 0, 3221217816,
136155012, 142313510, 144466536, 3221218568, 3221217844,
3221217848, 1, 144466536, 138875314, 142313486, 136083321,
0, 1, 144421906, 139016874, 136905429, 8249600, 0, 1,
144433773, 138875314, 3221223160, 3221222868, 3221218376,
136413307, 3}
}
}},
backlist = 0xbfffe508,
handlerlist = 0xbffff0e8,
lisp_eval_depth = 5,
pdlcount = 3,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0xbfffe29c
}
#21 0x08218a50 in exec_byte_code (bytestr=142621345, vector=143511205,
maxdepth=12, args_template=0, nargs=0, args=0xbfffe6a8) at bytecode.c:966
v1 = 142311390
count = 3
op = 141
vectorp = 0x88dcea8
stack = {
pc = 0x89f4519 "\207",
byte_string = 142621345,
byte_string_start = 0x89f4514 "\300\301\302D\215\207",
constants = 143511205,
next = 0xbfffe6dc
}
top = 0xbfffe260
result = 138875314
#22 0x081d87cb in funcall_lambda (fun=144650733, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 142314326
syms_left = 0
next = 1
lexenv = 132
count = 3
i = 239
optional = 330
rest = 194
#23 0x081d8351 in Ffuncall (nargs=1, args=0xbfffe6a4) at eval.c:3058
fun = 144650733
original_fun = 144439010
funcar = 144050528
numargs = 0
lisp_numargs = -1073748648
val = 138875314
backtrace = {
next = 0xbfffe638,
function = 0xbfffe6a4,
args = 0xbfffe6a8,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x0
i = 0
#24 0x081d79b1 in run_hook_with_args (nargs=1, args=0xbfffe6a4,
funcall=0x81d7dd2 <Ffuncall>) at eval.c:2715
global_vals = 138875314
sym = 144050530
val = 140177678
ret = 138875314
gcpro1 = {
next = 0x8554076,
var = 0x94f319,
nvars = 19371980
}
gcpro2 = {
next = 0x54,
var = 0x874ed3a,
nvars = 9756455
}
gcpro3 = {
next = 0x0,
var = 0x85fbf6c,
nvars = 84
}
#25 0x081d774d in Frun_hook_with_args_until_success (nargs=1, args=0xbfffe6a4)
at eval.c:2596
No locals.
#26 0x081d8055 in Ffuncall (nargs=2, args=0xbfffe6a0) at eval.c:2991
fun = 138537805
original_fun = 138989642
funcar = 142313950
numargs = 1
lisp_numargs = -1073748248
val = 0
backtrace = {
next = 0xbfffe948,
function = 0xbfffe6a0,
args = 0xbfffe6a4,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x0
i = 137564781
#27 0x08217ff4 in exec_byte_code (bytestr=140357737, vector=144161493,
maxdepth=8, args_template=0, nargs=0, args=0xbfffe9b4) at bytecode.c:785
count = 3
op = 1
vectorp = 0x897bad8
stack = {
pc = 0x89bcbbf "\207",
byte_string = 140357737,
byte_string_start = 0x89bcbbc "\300\301!\207",
constants = 144161493,
next = 0xbfffe9ec
}
top = 0xbfffe6a0
result = 84
#28 0x081d87cb in funcall_lambda (fun=139636493, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 136412603
syms_left = 0
next = 138875314
lexenv = 138875314
count = 3
i = 1
optional = 20
rest = 144092736
#29 0x081d8351 in Ffuncall (nargs=1, args=0xbfffe9b0) at eval.c:3058
fun = 139636493
original_fun = 142592922
funcar = 138905722
numargs = 0
lisp_numargs = 138751940
val = 144182806
backtrace = {
next = 0xbfffec58,
function = 0xbfffe9b0,
args = 0xbfffe9b4,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x0
i = 144745980
#30 0x08217ff4 in exec_byte_code (bytestr=137349761, vector=142987797,
maxdepth=8, args_template=0, nargs=0, args=0xbfffecc4) at bytecode.c:785
count = 3
op = 0
vectorp = 0x885d218
stack = {
pc = 0x83dd9a4 "\242\300=\207",
byte_string = 137349761,
byte_string_start = 0x83dd9a2 "\301 \242\300=\207",
constants = 142987797,
next = 0xbfffecfc
}
top = 0xbfffe9b0
result = 40
#31 0x081d87cb in funcall_lambda (fun=142988685, nargs=0, arg_vector=0x0)
at eval.c:3174
val = 136083538
syms_left = 0
next = -1073744428
lexenv = -1073744136
count = 3
i = -1073746776
optional = -1073744136
rest = 144092736
#32 0x081d8351 in Ffuncall (nargs=1, args=0xbfffecc0) at eval.c:3058
fun = 142988685
original_fun = 142988685
funcar = 20
numargs = 0
lisp_numargs = 0
val = 0
backtrace = {
next = 0xbfffef68,
function = 0xbfffecc0,
args = 0xbfffecc4,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x40
i = 0
#33 0x08217ff4 in exec_byte_code (bytestr=137348961, vector=137348981,
maxdepth=12, args_template=0, nargs=0, args=0xbfffeff4) at bytecode.c:785
count = 3
op = 0
vectorp = 0x82fc778
stack = {
pc = 0x83ddcbe "\206-",
byte_string = 137348961,
byte_string_start = 0x83ddc97 "\b\206-",
constants = 137348981,
next = 0x0
}
top = 0xbfffecc0
result = 0
#34 0x081d87cb in funcall_lambda (fun=137348933, nargs=0, arg_vector=0x0)
at eval.c:3174
val = -1073746176
syms_left = 0
next = 0
lexenv = 0
count = 3
i = 0
optional = 0
rest = 0
#35 0x081d8351 in Ffuncall (nargs=1, args=0xbfffeff0) at eval.c:3058
fun = 137348933
original_fun = 140266706
funcar = 0
numargs = 0
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0xbfffeff0,
args = 0xbfffeff4,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x84711b2
i = 8192
#36 0x081d7a86 in call0 (fn=140266706) at eval.c:2763
ret_ungc_val = 0
gcpro1 = {
next = 0x0,
var = 0x0,
nvars = 0
}
#37 0x08155a0e in safe_run_hooks_1 () at keyboard.c:1868
No locals.
#38 0x081d5803 in internal_condition_case (bfun=0x81559f5 <safe_run_hooks_1>,
handlers=138875338, hfun=0x8155a10 <safe_run_hooks_error>) at eval.c:1493
val = 136049314
c = {
tag = 138875314,
val = 138875314,
next = 0xbffff2c0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {138875314, -1073744136, -1073744428, -1073745656,
1962276673, -1313174482},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 13 times>, 8192, 0 <repeats 18 times>}
}
}},
backlist = 0x0,
handlerlist = 0xbffff388,
lisp_eval_depth = 0,
pdlcount = 3,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 138875338,
var = 138875314,
chosen_clause = 0,
tag = 0xbffff020,
next = 0xbffff388
}
#39 0x08155c28 in safe_run_hook_funcall (nargs=1, args=0xbffff1c0)
at keyboard.c:1923
No locals.
#40 0x081d79b1 in run_hook_with_args (nargs=1, args=0xbffff1c0,
funcall=0x8155bcb <safe_run_hook_funcall>) at eval.c:2715
global_vals = 138875314
sym = 138900098
val = 142341494
ret = 138875314
gcpro1 = {
next = 0x8477282,
var = 0x84711b2,
nvars = 1
}
gcpro2 = {
next = 0xbffff188,
var = 0x81d8ec7,
nvars = 138988378
}
gcpro3 = {
next = 0x84711b2,
var = 0xbffff6f8,
nvars = -1073744428
}
#41 0x08155c7c in safe_run_hooks (hook=140266706) at keyboard.c:1940
count = 2
#42 0x08154d88 in command_loop_1 () at keyboard.c:1586
cmd = 138899954
keybuf = {368, 138988880, 12721664, -1073743712, -1073745320,
136155277, 138988882, 138875314, 138988880, 0, -1208099712,
-1073807358, 1172880, 138988882, 138875314, 0, 0, 138875314,
139150642, 139126646, 137199973, 8249600, 0, 0, 138875314,
138875314, -1073744136, -1073744428, -1073745272, 136145288}
i = 1
prev_modiff = 130
prev_buffer = 0x896ae40
already_adjusted = 0
#43 0x081d5803 in internal_condition_case (bfun=0x8154608 <command_loop_1>,
handlers=138906194, hfun=0x8153fc9 <cmd_error>) at eval.c:1493
val = 139126646
c = {
tag = 138875314,
val = 138875314,
next = 0xbffff3e8,
gcpro = 0x0,
jmp = {{
__jmpbuf = {-1073743712, -1073744136, -1073744428, -1073744984,
1961932609, -1313174482},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 0, 32, 14095296, 14090228, 14095296, 12738336, 0,
3221222304, 3221222232, 3221222244, 134545800, 1231096, 0,
3086867584, 3221159938, 134544848, 134544138, 3086887576,
1228788, 12704204, 34, 3221222012, 1150886, 16232436,
138818752, 3221222548, 12721664, 3086887672, 2, 4294967295,
1228788}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 138906194,
var = 138875314,
chosen_clause = 1,
tag = 0xbffff2c0,
next = 0x0
}
#44 0x08154359 in command_loop_2 (ignore=138875314) at keyboard.c:1156
val = -1073743712
#45 0x081d52f1 in internal_catch (tag=138904170,
func=0x8154335 <command_loop_2>, arg=138875314) at eval.c:1247
c = {
tag = 138904170,
val = 138875314,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {-1073743712, -1073744136, -1073744428, -1073744712,
1962047297, -1313861074},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>, 13138350, 0, 0, 0, 138875314,
3221222584, 136050488, 138551388, 138875314, 138894944,
136485039, 142436960, 3221223584, 138551388, 138894944,
138551388}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#46 0x08154315 in command_loop () at keyboard.c:1135
No locals.
#47 0x08153c02 in recursive_edit_1 () at keyboard.c:756
count = 1
val = -1073744568
#48 0x08153d53 in Frecursive_edit () at keyboard.c:820
count = 0
buffer = 138875314
#49 0x081522df in main (argc=2, argv=0xbffff944) at emacs.c:1701
dummy = -1073743720
stack_bottom_variable = 8 '\b'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8388608,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
Lisp Backtrace:
"pcomplete-parse-comint-arguments" (0xbfffd1a8)
"pcomplete-parse-arguments" (0xbfffd4d4)
0x89f6948 There is no member named size.
(gdb) pp globals.f_Vinhibit_quit
(post-command-hook . completion-in-region--postch)
(gdb) fin
Run till exit from #0 0x0818250c in buf_charpos_to_bytepos (b=0x896ae40,
charpos=20) at marker.c:129
0x081c82fa in Fchar_after (pos=80) at editfns.c:1180
Value returned is $9 = 20
(gdb) fin
Run till exit from #0 0x081c82fa in Fchar_after (pos=80) at editfns.c:1180
0x082195ce in exec_byte_code (bytestr=141135289, vector=144648053,
maxdepth=28, args_template=0, nargs=0, args=0xbfffd1a8) at bytecode.c:1400
Value returned is $10 = 368
(gdb) fin
Run till exit from #0 0x082195ce in exec_byte_code (bytestr=141135289,
vector=144648053, maxdepth=28, args_template=0, nargs=0, args=0xbfffd1a8)
at bytecode.c:1400 C-c C-z
Program received signal SIGTSTP, Stopped (user).
0x0820826a in skip_chars (forwardp=1, string=141135209, lim=84,
handle_iso_classes=1) at syntax.c:1739
(gdb)
In GNU Emacs 24.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
of 2011-07-19 on ubuntu
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
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: ja_JP.utf8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: C/l
Minor modes in effect:
shell-dirtrack-mode: t
display-time-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
abbrev-mode: t
Recent input:
<backspace> SPC d d d d d d d d d d d d d d d d d d
d d d d d d d d C-p d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d C-k d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
C-p d d d d d d d d d d n d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d s y s <help-echo>
<help-echo> C-x o C-x g r u n SPC - Q <return> C-c
C-z b t <return> M-v M-v M-v M-v <escape> C-v C-x o
C-v C-x o C-v C-v C-v C-v <escape> > C-x o C-x m C-x
k <return> M-x e p <backspace> <backspace> r e p o
r t <tab> <return>
Recent messages:
Showing message 968...done
Erase deleted messages from Rmail file? (y or n) y
Expunging deleted messages...done
Computing summary lines...done
Saving file /home/handa/RMAIL...
Wrote /home/handa/RMAIL [2 times]
Computing summary lines...done
(No changes need to be saved)
Computing summary lines...done
Mark set
Load-path shadows:
/usr/local/work/emacs/stable/lisp/textmodes/table hides ~/emacslisp/table
/usr/local/work/emacs/stable/lisp/language/thai-word hides ~/emacslisp/thai-word
/usr/local/work/emacs/stable/lisp/textmodes/tex-mode hides ~/emacslisp/tex-mode
/usr/local/work/emacs/stable/lisp/emacs-lisp/syntax hides ~/emacslisp/syntax
/usr/local/work/emacs/stable/lisp/progmodes/prolog hides ~/emacslisp/prolog
Features:
(shadow sort mail-extr emacsbug gnus-util qp rmailkwd
rmailmm message format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader
mail-parse rfc2231 grep etags find-func pp help-fns gud
easy-mmode cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs help-mode view
compile multi-isearch vc-bzr add-log pcmpl-unix ansi-color
shell pcomplete comint ring time sendmail regexp-opt
rmail-sa rmail-spam-filter easymenu rmailsum rmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date
japan-util 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 dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
emacs)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-07-24 12:07 bug#9160: 24.0.50; Emacs freezes in *shell* buffer Kenichi Handa
@ 2011-08-23 4:49 ` Stefan Monnier
2011-08-25 0:52 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2011-08-23 4:49 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160
> The latest trunk Emacs freezes in *shell* buffer in the
> following scenario.
> % emacs -Q
> M-x shell RET
> .. in *shell* buffer
> % mkdir tmp (or if you already have tmp dir, % rm -rf tmp; mkdir tmp)
> % cd tmp
> % touch '0 a' '0-a'
> % ls 0<TAB>
> .. here <TAB> is a single tab and *Completions* buffer is
> shown with this contents ...
> ------------------------------------------------------------
> Click <mouse-2> on ...
> In this buffer, ...
`ls 0\ TAB' hangs as well, but with the advantage that it can be stopped
with C-g, making it easier to debug.
I've installed the patch below which should fix the immediate problem as
well as improve completion behavior when you use "&&", pipes, or ";".
Stefan
=== modified file 'lisp/pcomplete.el'
--- lisp/pcomplete.el 2011-06-17 18:52:46 +0000
+++ lisp/pcomplete.el 2011-08-23 04:44:56 +0000
@@ -811,15 +811,19 @@
(while (< (point) end)
(skip-chars-forward " \t\n")
(push (point) begins)
- (let ((skip t))
- (while skip
- (skip-chars-forward "^ \t\n")
- (if (eq (char-before) ?\\)
- (skip-chars-forward " \t\n")
- (setq skip nil))))
+ (while
+ (progn
+ (skip-chars-forward "^ \t\n\\")
+ (when (eq (char-after) ?\\)
+ (forward-char 1)
+ (unless (eolp)
+ (forward-char 1)
+ t))))
(push (buffer-substring-no-properties (car begins) (point))
args))
(cons (nreverse args) (nreverse begins)))))
+(make-obsolete 'pcomplete-parse-comint-arguments
+ 'comint-parse-pcomplete-arguments "24.1")
(defun pcomplete-parse-arguments (&optional expand-p)
"Parse the command line arguments. Most completions need this info."
=== modified file 'lisp/shell.el'
--- lisp/shell.el 2011-06-17 18:52:46 +0000
+++ lisp/shell.el 2011-08-23 04:46:07 +0000
@@ -383,6 +383,21 @@
:group 'shell
:type '(choice (const nil) regexp))
+(defun shell-parse-pcomplete-arguments ()
+ "Parse whitespace separated arguments in the current region."
+ (let ((begin (save-excursion (shell-backward-command 1) (point)))
+ (end (point))
+ begins args)
+ (save-excursion
+ (goto-char begin)
+ (while (< (point) end)
+ (skip-chars-forward " \t\n")
+ (push (point) begins)
+ (looking-at "\\(?:[^\s\t\n\\]\\|'[^']*'\\|\"\\(?:[^\"\\]\\|\\\\.\\)*\"\\|\\\\.\\)*\\(?:\\\\\\|'[^']*\\|\"\\(?:[^\"\\]\\|\\\\.\\)*\\)?")
+ (goto-char (match-end 0))
+ (push (buffer-substring-no-properties (car begins) (point))
+ args))
+ (cons (nreverse args) (nreverse begins)))))
(defun shell-completion-vars ()
"Setup completion vars for `shell-mode' and `read-shell-command'."
@@ -396,8 +411,7 @@
(set (make-local-variable 'comint-dynamic-complete-functions)
shell-dynamic-complete-functions)
(set (make-local-variable 'pcomplete-parse-arguments-function)
- ;; FIXME: This function should be moved to shell.el.
- #'pcomplete-parse-comint-arguments)
+ #'shell-parse-pcomplete-arguments)
(set (make-local-variable 'pcomplete-termination-string)
(cond ((not comint-completion-addsuffix) "")
((stringp comint-completion-addsuffix)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-08-23 4:49 ` Stefan Monnier
@ 2011-08-25 0:52 ` Kenichi Handa
2011-08-28 5:16 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-08-25 0:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9160
In article <jwv4o18pwdr.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > The latest trunk Emacs freezes in *shell* buffer in the
> > following scenario.
> > % emacs -Q
> > M-x shell RET
> > .. in *shell* buffer
> > % mkdir tmp (or if you already have tmp dir, % rm -rf tmp; mkdir tmp)
> > % cd tmp
> > % touch '0 a' '0-a'
> > % ls 0<TAB>
> > .. here <TAB> is a single tab and *Completions* buffer is
> > shown with this contents ...
> > ------------------------------------------------------------
> > Click <mouse-2> on ...
> > In this buffer, ...
> `ls 0\ TAB' hangs as well, but with the advantage that it can be stopped
> with C-g, making it easier to debug.
> I've installed the patch below which should fix the immediate problem as
> well as improve completion behavior when you use "&&", pipes, or ";".
Thank you I confirmed that the above test case now works.
But, found another bug. If I use `rm' command instead of
`ls':
% rm 0\ TAB
the completion doesn't work and I just see a message "No
match".
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-08-25 0:52 ` Kenichi Handa
@ 2011-08-28 5:16 ` Stefan Monnier
2011-09-06 6:19 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2011-08-28 5:16 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160
> Thank you I confirmed that the above test case now works.
> But, found another bug. If I use `rm' command instead of
> `ls':
> % rm 0\ TAB
> the completion doesn't work and I just see a message "No
> match".
If there's not space after the backslash, then that's a bug that's
already in Emacs-23, and I don't know yet how to fix it.
When there is a space after the backslash, we indeed have a bug and
I think I've fixed it with the patch below.
Stefan
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog 2011-08-27 08:41:23 +0000
+++ lisp/ChangeLog 2011-08-28 05:14:29 +0000
@@ -1,3 +1,7 @@
+2011-08-28 Stefan Monnier <monnier@iro.umontreal.ca>
+
+ * shell.el (shell-parse-pcomplete-arguments): Unquote args (bug#9160).
+
2011-08-27 Alan Mackenzie <acm@muc.de>
* progmodes/cc-menus.el (cc-imenu-c++-generic-expression): Make it
=== modified file 'lisp/shell.el'
--- lisp/shell.el 2011-08-23 05:25:17 +0000
+++ lisp/shell.el 2011-08-28 04:21:05 +0000
@@ -393,10 +393,28 @@
(while (< (point) end)
(skip-chars-forward " \t\n")
(push (point) begins)
- (looking-at "\\(?:[^\s\t\n\\]\\|'[^']*'\\|\"\\(?:[^\"\\]\\|\\\\.\\)*\"\\|\\\\.\\)*\\(?:\\\\\\|'[^']*\\|\"\\(?:[^\"\\]\\|\\\\.\\)*\\)?")
+ (let ((arg ()))
+ (while (looking-at
+ (eval-when-compile
+ (concat
+ "\\(?:[^\s\t\n\\\"']+"
+ "\\|'\\([^']*\\)'?"
+ "\\|\"\\(\\(?:[^\"\\]\\|\\\\.\\)*\\)\"?"
+ "\\|\\\\\\(\\(?:.\\|\n\\)?\\)\\)")))
(goto-char (match-end 0))
- (push (buffer-substring-no-properties (car begins) (point))
- args))
+ (cond
+ ((match-beginning 3) ;Backslash escape.
+ (push (if (= (match-beginning 3) (match-end 3))
+ "\\" (match-string 3))
+ arg))
+ ((match-beginning 2) ;Double quote.
+ (push (replace-regexp-in-string
+ "\\\\\\(.\\)" "\\1" (match-string 2))
+ arg))
+ ((match-beginning 1) ;Single quote.
+ (push (match-string 1) arg))
+ (t (push (match-string 0) arg))))
+ (push (mapconcat #'identity (nreverse arg) "") args)))
(cons (nreverse args) (nreverse begins)))))
(defun shell-completion-vars ()
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-08-28 5:16 ` Stefan Monnier
@ 2011-09-06 6:19 ` Kenichi Handa
2011-09-20 1:10 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-09-06 6:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9160
In article <jwvr546azo6.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > Thank you I confirmed that the above test case now works.
> > But, found another bug. If I use `rm' command instead of
> > `ls':
> > % rm 0\ TAB
> > the completion doesn't work and I just see a message "No
> > match".
> If there's not space after the backslash, then that's a bug that's
> already in Emacs-23, and I don't know yet how to fix it.
> When there is a space after the backslash, we indeed have a bug and
> I think I've fixed it with the patch below.
I confirmed that that above test case is fixed now. But, I
found several other bugs related completions. All the
following testcases are with the latest trunk Emacs with -Q
argument, and they don't happen with Emacs 23.3.
(1) SPC not escaped in *Completions* buffer
% mkdir tmp
% cd tmp
% touch '0 a' '0-a'
% rm 0<tab>
Now the the *Completions* buffer is:
<...>
Possible completions are:
0 a
0-a
Note that SPC is not escapsed in '0 a'. So, when I click
it, *shell* buffer becomes this:
% rm 0 a
This happens with 'ls' command too.
(2) The second arg to rm command is not completed.
% mkdir tmp
% cd tmp
% touch abc def
% rm a<tab>
% rm abc d<tab>
Now just "No match" is shown instead of "d" completed to
"def". This DOES NOT happen with 'ls' command.
(3) Error in post-command-hook for *.tar.gz file.
% mkdir tmp
% cd tmp
% echo abc > abc
% echo def > def
% tar cfz temp.tar.gz abc def
% tar tfz temp<tab>
Now the command line is correctly completed to:
% tar tfz temp.tar.gz
But, this error is signaled:
Error in post-command-hook (completion-in-region--postch): (wrong-type-argument listp [tar-header #<marker at 513 in *tar-data temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa 0 0 nil])
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-09-06 6:19 ` Kenichi Handa
@ 2011-09-20 1:10 ` Stefan Monnier
2011-09-20 5:16 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2011-09-20 1:10 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160
> I confirmed that that above test case is fixed now. But, I
> found several other bugs related completions. All the
> following testcases are with the latest trunk Emacs with -Q
> argument, and they don't happen with Emacs 23.3.
> (1) SPC not escaped in *Completions* buffer
> % mkdir tmp
> % cd tmp
> % touch '0 a' '0-a'
> % rm 0<tab>
> Now the the *Completions* buffer is:
> <...>
> Possible completions are:
> 0 a
> 0-a
> Note that SPC is not escapsed in '0 a'. So, when I click
Yes, that by design.
> it, *shell* buffer becomes this:
> % rm 0 a
That's a known (to me) bug.
Making escaping (aka quoting) interact correctly with completion styles
like partial-completion and substring is actually a nasty problem.
The old code used to escape the strings returned by all-completions (so
the *Completions* buffer would show the escaped names), which solves
some of the problematic cases, but has the following downsides:
- it's aesthetically unpleasant (the *Completions* buffer does not need
that kind of escaping).
- it's inefficient (requires escaping all elements of all-completions).
- more problematic: it doesn't actually solve the problem in all cases,
because the user may have typed "a\bc" but the escaping code cannot
know that the user decided to (unnecessarily) escape "b" so it won't
escape "b" and we're back at the problem that the completion will fail
because the output from all-completions doesn't actually match the
user's input, even tho it should.
We have related problems with $ escaping in find-file (they manifest in
different ways because we half-solved the issues differently).
I'm still not quite sure yet how to best solve those problems, but it
seems that a real solution will have to handle a more general problem,
e.g. cases such as "/u-$b-c" in find-file, where "$b" is an env var that
expands to (say) "c/d".
> (2) The second arg to rm command is not completed.
> % mkdir tmp
> % cd tmp
> % touch abc def
> % rm a<tab>
> % rm abc d<tab>
> Now just "No match" is shown instead of "d" completed to
> "def". This DOES NOT happen with 'ls' command.
I think I just fixed it with the patch below.
> (3) Error in post-command-hook for *.tar.gz file.
> % mkdir tmp
> % cd tmp
> % echo abc > abc
> % echo def > def
> % tar cfz temp.tar.gz abc def
> % tar tfz temp<tab>
> Now the command line is correctly completed to:
> % tar tfz temp.tar.gz
> But, this error is signaled:
> Error in post-command-hook (completion-in-region--postch):
> (wrong-type-argument listp [tar-header #<marker at 513 in *tar-data
> temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa
> 0 0 nil])
I cannot reproduce this error. Has it been fixed in the mean time?
Stefan
--- lisp/minibuffer.el 2011-09-02 00:36:58 +0000
+++ lisp/minibuffer.el 2011-09-20 01:00:12 +0000
@@ -322,14 +322,15 @@
(test-completion string table pred2))
(t
(or (complete-with-action action table string
- (if (null pred2) pred1
+ (if (not (and pred1 pred2))
+ (or pred1 pred2)
(lambda (x)
;; Call `pred1' first, so that `pred2'
;; really can't tell that `x' is in table.
- (if (funcall pred1 x) (funcall pred2 x)))))
+ (and (funcall pred1 x) (funcall pred2 x)))))
;; If completion failed and we're not applying pred1 strictly, try
;; again without pred1.
- (and (not strict)
+ (and (not strict) pred1 pred2
(complete-with-action action table string pred2))))))
(defun completion-table-in-turn (&rest tables)
@@ -1774,7 +1775,7 @@
(defun completion-file-name-table (string pred action)
"Completion table for file names."
- (ignore-errors
+ (with-demoted-errors
(cond
((eq action 'metadata) '(metadata (category . file)))
((eq (car-safe action) 'boundaries)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-09-20 1:10 ` Stefan Monnier
@ 2011-09-20 5:16 ` Kenichi Handa
2011-10-17 17:12 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-09-20 5:16 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9160
In article <jwv4o08jkpf.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> That's a known (to me) bug.
> Making escaping (aka quoting) interact correctly with completion styles
> like partial-completion and substring is actually a nasty problem.
> The old code used to escape the strings returned by all-completions (so
> the *Completions* buffer would show the escaped names), which solves
> some of the problematic cases, but has the following downsides:
> - it's aesthetically unpleasant (the *Completions* buffer does not need
> that kind of escaping).
> - it's inefficient (requires escaping all elements of all-completions).
> - more problematic: it doesn't actually solve the problem in all cases,
> because the user may have typed "a\bc" but the escaping code cannot
> know that the user decided to (unnecessarily) escape "b" so it won't
> escape "b" and we're back at the problem that the completion will fail
> because the output from all-completions doesn't actually match the
> user's input, even tho it should.
> We have related problems with $ escaping in find-file (they manifest in
> different ways because we half-solved the issues differently).
> I'm still not quite sure yet how to best solve those problems, but it
> seems that a real solution will have to handle a more general problem,
> e.g. cases such as "/u-$b-c" in find-file, where "$b" is an env var that
> expands to (say) "c/d".
I agree that there are many problems behind. But, my
testcase is a fairly simple one. Even if we can't solve all
the related problem at the moment, I think there should be
some workaround for such a simple case as far as it's a
regression. For instance, is it difficult to escape all
necessary characters on inserting a clicked item into
*shell* buffer?
> > (2) The second arg to rm command is not completed.
> > % mkdir tmp
> > % cd tmp
> > % touch abc def
> > % rm a<tab>
> > % rm abc d<tab>
> > Now just "No match" is shown instead of "d" completed to
> > "def". This DOES NOT happen with 'ls' command.
> I think I just fixed it with the patch below.
I confirmed that it's fixed, thank you.
> > (3) Error in post-command-hook for *.tar.gz file.
> > % mkdir tmp
> > % cd tmp
> > % echo abc > abc
> > % echo def > def
> > % tar cfz temp.tar.gz abc def
> > % tar tfz temp<tab>
> > Now the command line is correctly completed to:
> > % tar tfz temp.tar.gz
> > But, this error is signaled:
> > Error in post-command-hook (completion-in-region--postch):
> > (wrong-type-argument listp [tar-header #<marker at 513 in *tar-data
> > temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa
> > 0 0 nil])
> I cannot reproduce this error. Has it been fixed in the mean time?
No. I still see that error with the above testcase.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-09-20 5:16 ` Kenichi Handa
@ 2011-10-17 17:12 ` Stefan Monnier
2011-12-02 12:06 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2011-10-17 17:12 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160
> I agree that there are many problems behind. But, my
> testcase is a fairly simple one. Even if we can't solve all
> the related problem at the moment, I think there should be
> some workaround for such a simple case as far as it's a
> regression. For instance, is it difficult to escape all
> necessary characters on inserting a clicked item into
> *shell* buffer?
We could use a hack that affects choose-completion when inserting into
a comint-mode or shell-mode buffer, but that's hackish and is likely to
introduce new problems. In the mean time I did get "the right way" to
work (so quoting interacts well with completion-styles) and based on
this experience (which was not traumatic but requires a few changes
which shouldn't make it into 24.1 so late in the game) I decided that
for 24.1 we'll just revert to the 23 behavior of quoting the output of
all-completions for those shell completion tables.
>> > (3) Error in post-command-hook for *.tar.gz file.
>> > % mkdir tmp
>> > % cd tmp
>> > % echo abc > abc
>> > % echo def > def
>> > % tar cfz temp.tar.gz abc def
>> > % tar tfz temp<tab>
>> > Now the command line is correctly completed to:
>> > % tar tfz temp.tar.gz
>> > But, this error is signaled:
>> > Error in post-command-hook (completion-in-region--postch):
>> > (wrong-type-argument listp [tar-header #<marker at 513 in *tar-data
>> > temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa
>> > 0 0 nil])
>> I cannot reproduce this error. Has it been fixed in the mean time?
> No. I still see that error with the above testcase.
I still cannot reproduce it from "emacs -Q" following your above recipe.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-10-17 17:12 ` Stefan Monnier
@ 2011-12-02 12:06 ` Kenichi Handa
2011-12-02 14:45 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-12-02 12:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9160
In article <jwvzkgzpwqf.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> > (3) Error in post-command-hook for *.tar.gz file.
>>> > % mkdir tmp
>>> > % cd tmp
>>> > % echo abc > abc
>>> > % echo def > def
>>> > % tar cfz temp.tar.gz abc def
>>> > % tar tfz temp<tab>
>>> > Now the command line is correctly completed to:
>>> > % tar tfz temp.tar.gz
>>> > But, this error is signaled:
>>> > Error in post-command-hook (completion-in-region--postch):
>>> > (wrong-type-argument listp [tar-header #<marker at 513 in *tar-data
>>> > temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa
>>> > 0 0 nil])
>>> I cannot reproduce this error. Has it been fixed in the mean time?
> > No. I still see that error with the above testcase.
> I still cannot reproduce it from "emacs -Q" following your above recipe.
I found that the culprit is large-file-warning-threshold.
When I set it to nil, the above error is signaled.
The docstring of large-file-warning-threshold is this:
------------------------------------------------------------
Maximum size of file above which a confirmation is requested.
When nil, never request confirmation.
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 22.1 of Emacs.
------------------------------------------------------------
So nil is a valid value for this variable.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-12-02 12:06 ` Kenichi Handa
@ 2011-12-02 14:45 ` Stefan Monnier
2011-12-04 13:41 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2011-12-02 14:45 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160
> I found that the culprit is large-file-warning-threshold.
> When I set it to nil, the above error is signaled.
I've installed the patch below which should hopefully help.
Can you confirm?
Stefan
=== modified file 'lisp/pcmpl-gnu.el'
--- lisp/pcmpl-gnu.el 2011-10-02 01:04:01 +0000
+++ lisp/pcmpl-gnu.el 2011-12-02 14:42:41 +0000
@@ -309,7 +309,8 @@
(let* ((fa (file-attributes (pcomplete-arg 1)))
(size (nth 7 fa)))
(and (numberp size)
- (< size large-file-warning-threshold))))
+ (or (null large-file-warning-threshold)
+ (< size large-file-warning-threshold)))))
(let ((file (pcomplete-arg 1)))
(completion-table-dynamic
(lambda (_string)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-12-02 14:45 ` Stefan Monnier
@ 2011-12-04 13:41 ` Kenichi Handa
2011-12-04 15:38 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2011-12-04 13:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9160
In article <jwvobvr8244.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > I found that the culprit is large-file-warning-threshold.
> > When I set it to nil, the above error is signaled.
> I've installed the patch below which should hopefully help.
> Can you confirm?
Yes, I've just confimed that the bug was fixed. Thank you.
---
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
2011-12-04 13:41 ` Kenichi Handa
@ 2011-12-04 15:38 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2011-12-04 15:38 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 9160-done
>> > I found that the culprit is large-file-warning-threshold.
>> > When I set it to nil, the above error is signaled.
>> I've installed the patch below which should hopefully help.
>> Can you confirm?
> Yes, I've just confimed that the bug was fixed. Thank you.
Great, thanks,
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-12-04 15:38 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-24 12:07 bug#9160: 24.0.50; Emacs freezes in *shell* buffer Kenichi Handa
2011-08-23 4:49 ` Stefan Monnier
2011-08-25 0:52 ` Kenichi Handa
2011-08-28 5:16 ` Stefan Monnier
2011-09-06 6:19 ` Kenichi Handa
2011-09-20 1:10 ` Stefan Monnier
2011-09-20 5:16 ` Kenichi Handa
2011-10-17 17:12 ` Stefan Monnier
2011-12-02 12:06 ` Kenichi Handa
2011-12-02 14:45 ` Stefan Monnier
2011-12-04 13:41 ` Kenichi Handa
2011-12-04 15:38 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).