Re: mail-extract-address-components bug
In [EMAIL PROTECTED] Kenichi Handa wrote: In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes: [...] and the patch[1] I posted first is better. But please don't merge it hastily if you have a doubt even if it is little. I don't know about the code of mail-extr.el nor the detailed format of a mail address (RFC-822?). So, I can't be sure, either. It must be checked by someone who knows both of them. I'm anxious for such a person. Otherwise... Or, should we just install the change and see what happens? I hope to install the patch to only the Emacs CVS trunk, since I think it needs time to be tested widely. I'm not well informed about RFC2822 and what mail-extr.el does (especially the voodoo operation, which is disabled by default for Japanese names), too. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
facemenu-get-face removed? Replacement?
In GNU Emacs 22.1.50.1 (i386-msvc-nt5.1.2600) of 2007-05-14 on CLEOPATRA Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-msvc (13.10)' Hi, obviously facemenu-get-face was removed. I did not found an entry in one of the NEWS files. Is there a replacement? As workaround i copied the function and some other needed functions from emacs 19.15. Best regards, Christoph ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
core dump
I met a weird bug and I don't know if it is due to emacs-w3m or emacs. To reproduce, in Emacs: 0. start Emacs in urxvt¹ 1. M-x w3m 2. Key `g' and type in url: ftp://ftp.gnu.org/gnu/hyperbole 3. Key `^' and see emacs hang 4. Key `C-g' and Emacs asks: i. Auto-save (y/n) ii. Core dump (y/n) I am using the unicode-2 branch of Emacs with cvs checkout 2007-05-16. Emacs-w3m cvs checkout date: 2007-05-16. Footnotes: ¹ http://software.schmorp.de/pkg/rxvt-unicode.html HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) Starting program: /home/emacs/src/emacs -nw [Thread debugging using libthread_db enabled] [New Thread -1208932672 (LWP 30965)] [Switching to Thread -1208932672 (LWP 30965)] Program received signal SIGTSTP, Stopped (user). 0x00a34402 in __kernel_vsyscall () #0 0x00a34402 in __kernel_vsyscall () #1 0x49b8d396 in kill () from /lib/libc.so.6 #2 0x0811478d in sys_suspend () at sysdep.c:806 #3 0x080ff466 in interrupt_signal (signalnum=2) at keyboard.c:10656 #4 signal handler called #5 ccl_driver (ccl=0xbff1fac4, source=0xbff1eac8, destination=0xbff2fb60, src_size=1023, dst_size=0, charset_list=137595081) at ccl.c:872 #6 0x080b367f in decode_coding_ccl (coding=0xbff2fcdc) at coding.c:4524 #7 0x080b13fe in decode_coding (coding=0xbff2fcdc) at coding.c:6282 #8 0x080b2401 in decode_coding_object (coding=0xbff2fcdc, src_object=177708387, from=0, from_byte=0, to=24020, to_byte=24020, dst_object=137595129) at coding.c:6925 #9 0x080b2a0e in code_convert_string (string=177708387, coding_system=177964345, dst_object=137595129, encodep=0, nocopy=0, norecord=0) at coding.c:8078 #10 0x080b2b42 in Fdecode_coding_string (string=177708387, coding_system=177964345, nocopy=137595081, buffer=137595081) at coding.c:8120 #11 0x081647c1 in Ffuncall (nargs=3, args=0xbff2fe90) at eval.c:3007 #12 0x0818fcb2 in Fbyte_code (bytestr=139816779, vector=140157116, maxdepth=80) at bytecode.c:679 #13 0x0816420a in funcall_lambda (fun=140157508, nargs=3, arg_vector=0xbff2ffd4) at eval.c:3184 #14 0x08164611 in Ffuncall (nargs=4, args=0xbff2ffd0) at eval.c:3054 #15 0x0818fcb2 in Fbyte_code (bytestr=139647371, vector=139648020, maxdepth=32) at bytecode.c:679 #16 0x0816420a in funcall_lambda (fun=139648156, nargs=3, arg_vector=0xbff300f4) at eval.c:3184 #17 0x08164611 in Ffuncall (nargs=4, args=0xbff300f0) at eval.c:3054 #18 0x0818fcb2 in Fbyte_code (bytestr=139703091, vector=175539500, maxdepth=40) at bytecode.c:679 #19 0x0816420a in funcall_lambda (fun=175539700, nargs=4, arg_vector=0xbff30224) at eval.c:3184 #20 0x08164611 in Ffuncall (nargs=5, args=0xbff30220) at eval.c:3054 #21 0x0818fcb2 in Fbyte_code (bytestr=177827787, vector=177828508, maxdepth=64) at bytecode.c:679 #22 0x0816420a in funcall_lambda (fun=177828820, nargs=9, arg_vector=0xbff30394) at eval.c:3184 #23 0x08164611 in Ffuncall (nargs=10, args=0xbff30390) at eval.c:3054 #24 0x08165f59 in Fapply (nargs=10, args=0xbff30390) at eval.c:2430 #25 0x08163e75 in Feval (form=174586349) at eval.c:2301 #26 0x0816406f in Fprogn (args=-1074660668) at eval.c:447 #27 0x081642e4 in funcall_lambda (fun=174586368, nargs=1, arg_vector=0xbff304f4) at eval.c:3177 #28 0x08164611 in Ffuncall (nargs=2, args=0xbff304f0) at eval.c:3054 #29 0x0818fcb2 in Fbyte_code (bytestr=177553995, vector=169830652, maxdepth=48) at bytecode.c:679 #30 0x0816420a in funcall_lambda (fun=169830924, nargs=2, arg_vector=0xbff30624) at eval.c:3184 #31 0x08164611 in Ffuncall (nargs=3, args=0xbff30620) at eval.c:3054 #32 0x08165e68 in Fapply (nargs=2, args=0xbff30670) at eval.c:2485 #33 0x08165fa4 in apply1 (fn=140158233, arg=173083021) at eval.c:2749 #34 0x0819243d in read_process_output_call (fun_and_args=173083029) at process.c:4960 #35 0x08163028 in internal_condition_case_1 ( bfun=0x8192420 read_process_output_call, arg=173083029, handlers=137634497, hfun=0x8192380 exec_sentinel_error_handler) at eval.c:1529 #36 0x081925f2 in exec_sentinel (proc=174611676, reason=173095027) at process.c:6633 #37 0x08192804 in status_notify (deleting_process=0x0) at process.c:6736 #38 0x08196c25 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137595081, wait_proc=0x0, just_wait_proc=0) at process.c:4461 #39 0x08053e60 in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6579 #40 0x08107ceb in read_char (commandflag=1, nmaps=7, maps=0xbff30e10, prev_event=137595081, used_mouse_menu=0xbff30ec8, end_time=0x0) at keyboard.c:2904 #41 0x08109a35 in read_key_sequence (keybuf=0xbff30f74, bufsize=30, prompt=137595081, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9135 #42 0x0810b553 in command_loop_1 () at keyboard.c:1618 #43 0x08163252 in internal_condition_case (bfun=0x810b3c0 command_loop_1, handlers=137634497, hfun=0x8105ed0
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. That's what I would expect. You're saying to emacsclient to no expect any answer, after all. You can always do: emacsclient -n -e (condition-case nil (my-bad-fun) (error (raise-frame) (backtrace))) or something like that if you want to see errors in the server. Would it not be easier if you get a normal backtrace if debug-on-error is t? Something like this can be used in server.el, server-process-filter: (if eval (let* (errorp (v (if debug-on-error (eval (car (read-from-string arg))) (condition-case errobj (eval (car (read-from-string arg))) (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) (when errorp (princ error: )) (pp v) (ignore-errors (process-send-region proc (point-min) (point-max))) I have just added the (if debug-on-error ...) here. Maybe there should be another, server specific variable too so that one can have debug-on-error t without getting a backtrace for this case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. It is not much, just two or three new lines actually. (The line numbers below are not correct.) *** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972RQU 2007-05-16 13:55:37.203125000 +0200 --- c:/emacs/p/070515/emacs/lisp/server.el 2007-05-16 13:32:13.328125000 +0200 *** *** 469,477 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v (condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj (when v (with-temp-buffer (let ((standard-output (current-buffer))) --- 482,493 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v ! (if debug-on-error ! (eval (car (read-from-string arg))) !(condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: core dump
In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes: In [emacs-w3m : No.09434] Leo wrote: I met a weird bug and I don't know if it is due to emacs-w3m or emacs. To reproduce, in Emacs: 0. start Emacs in urxvt¹ 1. M-x w3m 2. Key `g' and type in url: ftp://ftp.gnu.org/gnu/hyperbole 3. Key `^' and see emacs hang 4. Key `C-g' and Emacs asks: i. Auto-save (y/n) ii. Core dump (y/n) I am using the unicode-2 branch of Emacs with cvs checkout 2007-05-16. Emacs-w3m cvs checkout date: 2007-05-16. Footnotes: ¹ http://software.schmorp.de/pkg/rxvt-unicode.html First of all, emacs-w3m does not yet support Emacs 23 officially. Though it might work luckily with some urls, it needs to be much improved in order to work with Emacs 23 perfectly. In the future. The backtrace shows that Emacs is in infinite loop in ccl_driver. It seems that emacs-w3m does some code conversion by CCL programs defined by itself. And, it is very likely that those CCL programs depend heavily on the internal character representation. That must be changed for Emacs 23. To emacs-w3m developpers: Please explain why it does code conversion by its own CCL programs. I'll be able to suggest a better way for Emacs 23. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would emacsclient --eval BIG-MISTAKE cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. It is not much, just two or three new lines actually. Aha. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would emacsclient --eval BIG-MISTAKE cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. Two reasons: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. - If you use -n you will see nothing as it is now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to from emacsclient). - If you use -n you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to from emacsclient). Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. - If you use -n you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. It might not be the right thing to do in all cases. BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. I have no examples at hand, but the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. Sure, but see above. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) I am glad to read that ;-) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Then could it not easily happen that the source of the problem is not detected? Is not that an argument for beeing able to get a traceback the way I suggested? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(setq sgml-transformation 'upcase) has no effect
From textmodes/sgml-mode.el: If you like upcased tags, put (setq sgml-transformation-function 'upcase) in your `.emacs' file. To reproduce the problem: emacs -Q C-x C-f a.html RET M-x set-variable RET sgml-transformation-function RET upcase RET C-c C-t small RET what appears in the buffer is small/small rather than the expected SMALL/SMALL As far as I remember, this is an old bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly different, but do you really expect to have to debug much Emacs library code which fails in the context of emacsclient --eval? (I say Emacs library code because if the trouble is in the evaled string, the stderr message is already a good clue.) I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Then could it not easily happen that the source of the problem is not detected? That depends of what you're doing with emacsclient -n --eval. I'd expect the user (or client program) to detect that nothing is happening :) Is not that an argument for beeing able to get a traceback the way I suggested? Perhaps. All this is in the purely hypothetical realm right now. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly The complication seems very minor as I see it. I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Maybe the hardest thing is to convince me I am not easy to convince ... ;-) That depends of what you're doing with emacsclient -n --eval. I'd expect the user (or client program) to detect that nothing is happening :) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. Perhaps. All this is in the purely hypothetical realm right now. Yes, probably. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. I know. I was following the other thread too. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Yes, the important thing is of course that there is a way to make it easy to debug then. If such cases shows up my little patch can be used. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I hope for the best, we will see. Life is a long learning experience. :-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs goes unresponsive after saving remote file
Using native version of Emacs 22.0.50.1 on Windows XP, editing and saving
a file on a remote system using tramp/ftp (standard Windows FTP) results
in Emacs going unresponsive and not updating for a period of 1-2 minutes
after the file is saved. It has been verified that the files are being
transferred quickly, i.e., the new file shows up on the remote system
during this period of Emacs' being unresponsive.
A C-g will break the hung state, but will result in the buffer being still
marked as modified. A backtrace produced after the C-g in this situation
follows:
---
Debugger entered--Lisp error: (quit)
signal(quit nil)
byte-code(=8c1!=88=8c2=8c3=8c4\=87 [proc delete-process signal quit nil]
3)
ange-ftp-wait-not-busy(#process *ftp [EMAIL PROTECTED])
ange-ftp-raw-send-cmd(#process *ftp [EMAIL PROTECTED] quote mdtm
/home/wbp/.emacs nil (#[(result line host user cmd msg cont nowait) =84
=83=8c6 #=87=8c7=8c8
\n\ \f=8c9D
%=87 [cont result afsc-result line afsc-line host ange-ftp-call-cont
ange-ftp-raw-send-cmd ange-ftp-get-process #[... =84 =8c5
#=87 [cont result afsc-result line afsc-line ange-ftp-call-cont] 4] user cmd
msg nowait] 6] oak wbp quote mdtm /home/wbp/.emacs nil nil nil) nil)
ange-ftp-send-cmd(oak wbp (quote mdtm /home/wbp/.emacs))
ange-ftp-file-modtime(/ftp:[EMAIL PROTECTED]:/home/wbp/.emacs)
ange-ftp-write-region(1 17556 /ftp:[EMAIL PROTECTED]:/home/wbp/.emacs nil t)
apply(ange-ftp-write-region (1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t))
ange-ftp-hook-function(write-region 1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t)
apply(ange-ftp-hook-function write-region (1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t))
tramp-ftp-file-name-handler(write-region 1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t)
apply(tramp-ftp-file-name-handler write-region (1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t))
tramp-file-name-handler(write-region 1 17556 /ftp:[EMAIL
PROTECTED]:/home/wbp/.emacs nil t)
write-region(1 17556 /ftp:[EMAIL PROTECTED]:/home/wbp/.emacs nil t
/ftp:[EMAIL PROTECTED]:/home/wbp/.emacs)
basic-save-buffer-2()
basic-save-buffer-1()
basic-save-buffer()
save-buffer(1)
call-interactively(save-buffer)
recursive-edit()
byte-code(=8c6
@=8c7==83!=8c8=8c9=8ca\=88=8cb=8c9!=89A@)=8a2=8cc==83!=8c8=8cd=8ca\=88=8ce !=88=8cf
=88=8d0 !=88\f=83c=8d1ed\
V=83Web=88=8d2
=8a5y=88` db=88=8d2
=8a5
Zy=88 `|=88)=8d3c=88eb=88=8d4=8d5=8d6 \=88=8d7
=88=8d4=8d8!=88=8d9=8ca =8d4=8da!=88=8a=8db =88+=8d9=87
[unread-command-char debugger-args x debugger-buffer noninteractive
debugger-batch-max-lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5
pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 ...\n message
%s buffer-string kill-emacs nil recursive-edit middlestart
buffer-read-only standard-output] 4)
debug(error (quit))
byte-code(=8c1=8c2=8c3!=87 [quit-flag t eval (ignore nil)] 2)
read-passwd(Password for /pscp:[EMAIL PROTECTED]: )
tramp-read-passwd(wbp oak Password for /pscp:[EMAIL PROTECTED]: )
tramp-enter-password(#process *tramp/pscp [EMAIL PROTECTED] Password for
/pscp:[EMAIL PROTECTED]: wbp oak)
tramp-action-password(#process *tramp/pscp [EMAIL PROTECTED] nil pscp
wbp oak)
byte-code(=8c6=8c7=8c8=8c9$=89\nB =84=99=8ca\f=8cb\=88eb=88
[EMAIL PROTECTED]@[EMAIL PROTECTED] =89 !\X=83}=8ce=8cf=8d0
P #=88#=83}=8a=8d1$%'$q=88db=88n=84n=8d2c=88=8d3=8d4=8d5=8ce=8d6
#=8d7Q\)=88+=8d8 =8d9P=8c8=8da#=83 \f()*+%=82 ,=8c8=87
[with-timeout-tag with-timeout-timer with-timeout-timers found p actions
run-with-timer 60 nil with-timeout-handler tramp-accept-process-output 1 10
Looking for regexp \%s\ from remote shell apply message tramp:
tramp-get-debug-buffer \n tramp-insert-with-face italic # format \n
re-search-forward \\' t todo item pattern action args fmt-string level
tramp-verbose tramp-debug-buffer tramp-current-multi-method
tramp-current-method tramp-current-user tramp-current-host multi-method method
user host with-timeout-value] 8)
tramp-process-one-action(#process *tramp/pscp [EMAIL PROTECTED] nil pscp
wbp oak ((tramp-password-prompt-regexp tramp-action-password)
(tramp-login-prompt-regexp tramp-action-login) (shell-prompt-pattern
tramp-action-succeed) (tramp-shell-prompt-pattern tramp-action-succeed)
(tramp-wrong-passwd-regexp tramp-action-permission-denied)
(tramp-yesno-prompt-regexp tramp-action-yesno) (tramp-yn-prompt-regexp
tramp-action-yn) (tramp-terminal-prompt-regexp tramp-action-terminal)
(tramp-process-alive-regexp tramp-action-process-alive)))
byte-code(=8c6 \n \f
=88=8c7=87 [p multi-method method user host actions tramp-process-one-action
nil] 7)
tramp-process-actions(#process *tramp/pscp [EMAIL PROTECTED] nil pscp
wbp oak ((tramp-password-prompt-regexp tramp-action-password)
Re: core dump
In [emacs-w3m : No.09442] Kenichi Handa wrote: The backtrace shows that Emacs is in infinite loop in ccl_driver. It seems that emacs-w3m does some code conversion by CCL programs defined by itself. I reached to this conclusion yesterday, too. And, it is very likely that those CCL programs depend heavily on the internal character representation. That must be changed for Emacs 23. The code which makes emacs-w3m use the ccl programs for ftp urls is: (defun w3m-w3m-parse-header (url header) [...] (if (string-match \\`ftps?:.*/\\' url) (if w3m-accept-japanese-characters w3m-euc-japan w3m-iso-latin-1) The ccl coding systems `w3m-euc-japan' and `w3m-iso-latin-1' are defined in w3m-ccl.el and, for Emacs 21 and 22, redefined in w3m-ems.el. IIUC, they are used for communicating with the w3m command privately. Unfortunately I'm not skilled with those coding systems, but TSUCHIYA-san have ever explained what they are briefly in: http://emacs-w3m.namazu.org/ml/msg00872.html The problem is that we have no programs to redefine those coding systems for Emacs 23 in w3m-ems.el. To emacs-w3m developpers: Please explain why it does code conversion by its own CCL programs. I'll be able to suggest a better way for Emacs 23. Thank you very much for the offer. We welcome any improvement, suggestion, and comment. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Alias autodetection in grep-read-files is broken
I have added a cons to grep-file-aliases so that it's value is now: ((el . *.el) (ch . *.[ch]) (c . *.c) (h . *.h) (asm . *.[sS]) (m . [Mm]akefile*) (l . [Cc]hange[Ll]og*) (c++ . *.[ch] *.[ch]pp)) Notice that the C++ line has two aliases in it. This gets expanded by wildcard-to-regexp into [EMAIL PROTECTED] [EMAIL PROTECTED]'. It should get expanded into \\`\\(?:[EMAIL PROTECTED]|[EMAIL PROTECTED])\\'. Please fix this. -- MJF In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-06-04 on TPAD X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -O2 -march=i686 -mtune=i686 -ffast-math -IC:/gnuwin32/include_emacs -IC:/gnuwin32/lib -IC:/gnuwin32/src --ldflags -s ' 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: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Emacs-Lisp/lw Minor modes in effect: eldoc-mode: t global-balanced-mode: t balanced-mode: t hrule-mode: t c-subword-mode: t global-reveal-mode: t reveal-mode: t global-hi-lock-mode: t hi-lock-mode: t recentf-mode: t show-paren-mode: t global-c-subword-mode: t shell-dirtrack-mode: t cua-mode: t encoded-kbd-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 blink-cursor-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: up up up up up up up up up up up down down down down down down down down down down down prior up down down down down down down down down down down down down down up up up up up up up up up up up up up down right M-right M-right help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug help-echo select-window help-echo g r e p - backspace backspace backspace backspace backspace C-x C-g escape escape escape help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Display version number, copyright info, and basic help Lisp packages distributed separately for use in Emacs How to get latest versions of Emacs Show the Emacs license (GPL) How to get latest versions of Emacs Lisp packages distributed separately for use in Emacs Display version number, copyright info, and basic help Find packages and features by keyword Full documentation of Emacs features Send e-mail to Emacs maintainers ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
