Re: ps-print-buffer-with-faces doesn't use selected frame's background
* Vinicius Jose Latorre (2007-01-10 03:01 -0200) said: ^ Hi Leo, Thanks for the Emacs image. Welcome! [...] Thank you for the answer. However output from ps-print does not look good generally in a dark background? Is this a known problem? Ok, using the ps-default-bg default value (white) is not good when using a dark background. This is neither a problem nor a bug. You could set ps-default-bg and ps-default-fg to a suitable color. A dark background will waste a lot of ink if printed ;) But I think ps-print should choose a different color according to the background type: dark or light. One possible way to improve ps-default-bg initialization could be set it in ps-print with (frame-parameter nil 'background-color) The value of ps-default-fg and ps-default-bg variables are not changed when frame parameters change. Note that even the initialization above will not be good if the frame parameters (background-color and foreground-color) are changed dynamically. ps-print also allows face remapping, so, the initialization above could not be good depending on the colors used. Regards, Vinicius -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode-2 bootstrap failed on windows-xp
[...] Directory international Directory language Directory mail Directory mh-e Directory net Directory play Directory progmodes Directory term Directory textmodes Directory url Directory obsolete Generating cus-load.el... Saving file d:/emacs-unicode-2/lisp/cus-load.el... Loading vc-cvs... Wrote d:/emacs-unicode-2/lisp/cus-load.el Generating cus-load.el...done rm ./../bin/emacs.exe make[1]: Leaving directory `D:/emacs-unicode-2/lisp' make -C ../lib-src DOC make[1]: *** No rule to make target `stamp_BLD', needed by `DOC'. Stop. make[1]: Entering directory `D:/emacs-unicode-2/lib-src' make[1]: Leaving directory `D:/emacs-unicode-2/lib-src' make: *** [bootstrap-gmake] Error 2 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
eval-expression of arithmetic with prefix arg is less useful due to lisp verbosity
This change: Typing C-x C-e twice prints the value of the integer result in additional formats (octal, hexadecimal, character) specified by the new function `eval-expression-print-format'. The same function also defines the result format for `eval-expression' (M-:), `eval-print-last-sexp' (C-j) and some edebug evaluation functions. is awful for C-u M-: It makes it much harder to make keyboard macros that manipulate numbers in buffers since every time they insert the result they insert this garbage in the buffer. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
X protocol error:
GNU Emacs 22.0.92.5 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-01-08 on quant8 Just got this: Breakpoint 3, x_error_quitter (display=0x8589bd8, error=0xbfdab788) at xterm.c:7833 7833 if (error-error_code == BadName) (gdb) where #0 x_error_quitter (display=0x8589bd8, error=0xbfdab788) at xterm.c:7833 #1 0x080c915d in x_error_handler (display=0x8589bd8, error=0xbfdab788) at xterm.c:7798 #2 0xb7cbe9ea in _XError () from /usr/lib/libX11.so.6 #3 0xb7cc1141 in _XEventsQueued () from /usr/lib/libX11.so.6 #4 0xb7cacc02 in XPending () from /usr/lib/libX11.so.6 #5 0x080c8ecb in XTread_socket (sd=0, expected=1, hold_quit=0xbfdad3d0) at xterm.c:7042 #6 0x080f2fed in read_avail_input (expected=1) at keyboard.c:6823 #7 0x080f31da in handle_async_input () at keyboard.c:6969 #8 0x080596aa in change_frame_size_1 (f=0xa33f880, newheight=90, newwidth=80, pretend=1, delay=0, safe=0) at dispnew.c:6339 #9 0x080d6412 in Fx_create_frame (parms=178553229) at xfns.c:3368 #10 0x081527d1 in Ffuncall (nargs=2, args=0xbfdad758) at eval.c:2997 #11 0x0817d02d in Fbyte_code (bytestr=136221867, vector=136221884, maxdepth=40) at bytecode.c:679 #12 0x0815227a in funcall_lambda (fun=136221820, nargs=1, arg_vector=0xbfdad884) at eval.c:3184 #13 0x08152681 in Ffuncall (nargs=2, args=0xbfdad880) at eval.c:3054 #14 0x0817d02d in Fbyte_code (bytestr=136464803, vector=136464820, maxdepth=24) at bytecode.c:679 #15 0x0815227a in funcall_lambda (fun=136464756, nargs=1, arg_vector=0xbfdad940) at eval.c:3184 #16 0x0815247b in apply_lambda (fun=136464756, args=138031229, eval_flag=1) at eval.c:3108 #17 0x08151b52 in Feval (form=138039341) at eval.c:2370 #18 0x081520df in Fprogn (args=138031221) at eval.c:447 #19 0x08152354 in funcall_lambda (fun=138040080, nargs=0, arg_vector=0xbfdadac4) at eval.c:3177 #20 0x08152681 in Ffuncall (nargs=1, args=0xbfdadac0) at eval.c:3054 #21 0x08153b39 in call0 (fn=138040085) at eval.c:2761 #22 0x0809442a in Fdisplay_buffer (buffer=147867932, not_this_window=137459913, frame=137459913) at window.c:3696 #23 0x0810d045 in Fpop_to_buffer (buffer=147867932, other_window=137459913, norecord=137459913) at buffer.c:1765 #24 0x0815280a in Ffuncall (nargs=2, args=0xbfdadc34) at eval.c:3003 #25 0x08154009 in Fapply (nargs=2, args=0xbfdadc34) at eval.c:2430 #26 0x081529a5 in Ffuncall (nargs=3, args=0xbfdadc30) at eval.c:2978 #27 0x0817d02d in Fbyte_code (bytestr=140989259, vector=140991236, maxdepth=24) at bytecode.c:679 #28 0x0815227a in funcall_lambda (fun=140991364, nargs=1, arg_vector=0xbfdadd54) at eval.c:3184 #29 0x08152681 in Ffuncall (nargs=2, args=0xbfdadd50) at eval.c:3054 #30 0x0817d02d in Fbyte_code (bytestr=142927515, vector=142798948, maxdepth=56) at bytecode.c:679 #31 0x0815227a in funcall_lambda (fun=142799204, nargs=1, arg_vector=0xbfdade84) at eval.c:3184 #32 0x08152681 in Ffuncall (nargs=2, args=0xbfdade80) at eval.c:3054 #33 0x0817d02d in Fbyte_code (bytestr=142918547, vector=142884804, maxdepth=80) at bytecode.c:679 #34 0x08151d35 in Feval (form=142586477) at eval.c:2334 #35 0x0815137a in internal_catch (tag=142654257, func=0x8151970 Feval, arg=142586477) at eval.c:1222 #36 0x0817c2ab in Fbyte_code (bytestr=142918579, vector=142885204, maxdepth=16) at bytecode.c:854 #37 0x0815227a in funcall_lambda (fun=142885324, nargs=2, arg_vector=0xbfdae1a4) at eval.c:3184 #38 0x08152681 in Ffuncall (nargs=3, args=0xbfdae1a0) at eval.c:3054 #39 0x08153f14 in Fapply (nargs=2, args=0xbfdae1f0) at eval.c:2485 #40 0x08154054 in apply1 (fn=142653969, arg=147192021) at eval.c:2749 #41 0x0817f81d in read_process_output_call (fun_and_args=147211173) at process.c:4926 #42 0x08151098 in internal_condition_case_1 ( bfun=0x817f800 read_process_output_call, arg=147211173, handlers=137459913, hfun=0x817f7b0 read_process_output_error_handler) at eval.c:1529 ---Type return to continue, or q return to quit--- #43 0x0817f0c3 in read_process_output (proc=145084132, channel=Variable channel is not available. ) at process.c:5156 #44 0x0818314b in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137459913, wait_proc=0x0, just_wait_proc=0) at process.c:4766 #45 0x080f785d in read_char (commandflag=1, nmaps=2, maps=0xbfdaf940, prev_event=137459913, used_mouse_menu=0xbfdaf9e8, end_time=0x0) at keyboard.c:4016 #46 0x080f9e46 in read_key_sequence (keybuf=0xbfdafa94, bufsize=30, prompt=137459913, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9115 #47 0x080fb923 in command_loop_1 () at keyboard.c:1618 #48 0x081512c2 in internal_condition_case (bfun=0x80fb790 command_loop_1, handlers=137504569, hfun=0x80f6310 cmd_error) at eval.c:1481 #49 0x080f56d3 in command_loop_2 () at keyboard.c:1329 #50 0x0815137a in internal_catch (tag=137498553, func=0x80f56b0 command_loop_2, arg=137459913) at eval.c:1222 #51
Re: 4 week-old pretest bugs
Jan Djärv [EMAIL PROTECTED] writes: Thanks. Somehow the thread detection thingy isn't working correctly. While I try to figure this out, please try the patch suggested by YAMAMOTO Mitsuharu. That patch didn't appear to make any difference, but I've found one that fixes the bug for me. I have no idea why it works, but it does really seem to: --- src/blockinput.h2007-01-10 18:22:43.0 +0100 +++ src/new/blockinput.h2007-01-10 18:18:18.0 +0100 @@ -61,8 +61,10 @@ extern int pending_atimers; +static int mytmp; + /* Begin critical section. */ -#define BLOCK_INPUT (interrupt_input_blocked++) +#define BLOCK_INPUT (mytmp++, interrupt_input_blocked++) /* End critical section. I suppose this must be indicitive of some kind of race condition, since the mytmp++ doesn't do anything but delay the increment of interrupt_input_blocked by a very short amount of time. Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
* running the same build on the same debian sid machine under KDE * running the same build on the same debian sid machine with different GTK theme (tried Amaranth, Crux and Simple - all show the crash) So it's something specific to GNOME on this laptop. Is it a matter of running under GNOME, or a matter of building with GTK? In other words, when you run it under KDE, is that the GTK build of Emacs? Unfortunately, the comparison between the two machines is not very conclusive because so many things could be different between them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
TRAMP copies binary files incorrectly
I have a 1 byte file on a remote server. If I use 'scp' to copy the file to my local machine, it copies correctly, but if I use: $ emacs -Q (copy-file /ssh:[EMAIL PROTECTED]:~/file /tmp/file) C-j to copy it, then the resulting local file is 2 bytes long. I used hexl-mode to compare the two files: 1 byte correct version: : ce . 2 byte broken version: : 81ce .. Could it be that Emacs is doing some kind of character-encoding conversion? I don't want that to happen when all I'm doing is trying to copy a binary file. I originally noticed this problem when trying to copy a .jpg file from the remote machine. It grew from 92,349 bytes on the remote machine to 118,223 bytes locally, but given the recent issues with automatic image detection, I though it best to find a smaller test case. I tried the same thing copying the file from /ssh:[EMAIL PROTECTED]:/tmp/file1 to /tmp/file2 but that didn't exhibit the bug. Also, copying from the local machine to the remote machine works OK. In GNU Emacs 22.0.92.4 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-10 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Shell Minor modes in effect: shell-dirtrack-mode: t show-paren-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-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 line-number-mode: t transient-mark-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with transparent PNG image display
* Chris Moore (2007-01-10 01:49 +0100) said: ^^^ Download this image and open it in Emacs: http://tango-project.org/static/cvs/tango-art-tools/palettes/Tango-Palette.png The image has lots of transparent pixels. Using M-x set-background-colour RET and you'll see the background of the image changes with the background. Now use 'convert' from ImageMagick to make a copy of the image: $ convert Tango-Palette.png Tango-Palette-copy.png Open the new copy in Emacs and the transparent pixels show up as white pixels. Open the copy in The GIMP or gqview and you can see that the background really is still transparent. I'm using this version of convert: Version: ImageMagick 6.2.4 12/13/06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC In GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' I actually have noticed this a long time ago using Gnus' Face/X-Face feature. All transparent parts become black. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
hexl-mode's offer to Convert contents back to binary format? doesn't
$ emacs -Q M-x shell RET cd /tmp RET echo hello file RET C-x 4 f file RET M-x hexl-mode RET C-x o echo world file RET C-x 4 f file RET (File file changed on disk. Reread from disk? (yes or no)) yes RET (notice the contents of buffer 'file' are now in plain text, but the buffer is still in hexl-mode) (Convert contents back to binary format? (y or n)) y buffer 'file' is now in fundamental mode and contains one line: : 83 . So Emacs has inserted the plain file contents into a hexl-mode buffer, and then offered to unhexlify them. In GNU Emacs 22.0.92.4 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-10 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-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 line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
Nick Roberts wrote: Can you please find a way to get the full log? attached (this is with the CVS head build from this morning) gdb-debug-ring Description: Binary data elisp-backtrace Description: Binary data ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Date: Wed, 10 Jan 2007 21:04:19 +0100 From: Chris [EMAIL PROTECTED] I have a 1 byte file on a remote server. If I use 'scp' to copy the file to my local machine, it copies correctly, but if I use: $ emacs -Q (copy-file /ssh:[EMAIL PROTECTED]:~/file /tmp/file) C-j to copy it, then the resulting local file is 2 bytes long. I used hexl-mode to compare the two files: 1 byte correct version: : ce . 2 byte broken version: : 81ce .. Could it be that Emacs is doing some kind of character-encoding conversion? Tramp does some complicated encode/decode stuff to send the file on the wire (since ssh is just a filter, so binary stuff cannot be easily sent verbatim). However, I just tried this, and I cannot reproduce the problem with the current CVS: I get an exact replica of the original file on my local machine. Do _all_ files from that machine copy incorrectly? Or just some? Also, could you show the contents of the *Messages* buffer after the copy operation finishes? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman [EMAIL PROTECTED] writes: * running the same build on the same debian sid machine under KDE when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a .deb package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. Unfortunately, the comparison between the two machines is not very conclusive because so many things could be different between them. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! I arrived at that fix through a process of trial and error, not through any understand at all of what's going on. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with transparent PNG image display
Leo [EMAIL PROTECTED] writes: I actually have noticed this a long time ago using Gnus' Face/X-Face feature. All transparent parts become black. Interesting. They go white here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
Richard Stallman [EMAIL PROTECTED] writes: Thanks. While looking into this problem, I discovered that some in-line images can't be scrolled even after the emacs-w3m fix. I don't know whether to report it or not because it's already known that image support in Emacs is pretty flaky, but, just in case this isn't known, I will: 1. create an image, 500 pixels tall in /tmp/image.jpg 2. make a new fundamental-mode buffer 3. insert a few lines of text, leave point at the end and evaluate (insert-image-file /tmp/image.jpg) 4. go to the end of the buffer with M- 5. repeat steps 3 and 4 a few times 6. go to the start of the buffer with M- 7. resize the frame so that it's less than 500 pixels tall (ie. so that the image doesn't fit in the window) 8. scroll down repeatedly with C-v The first copy of the image will scroll properly, but scrolling gets stuck on the 2nd copy. the 2nd copy will scroll to the bottom and then jump back to the top. Hitting C-v very quickly (or holding it down) will eventually get past the 2nd copy, only to get stuck on the 3rd or 4th copy. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
Chris Moore wrote: I'm not confident about it. It seems to be working well for me still, but there's quite a lot of functionality available at the query-replace prompt which I neither understand nor use. All the replacement actions seem to work in my experience. The ones I tested were the ones in the help screen: Query replacing regexp foo with foo. Type Space or `y' to replace one match, Delete or `n' to skip to next, RET or `q' to exit, Period to replace one match and exit, Comma to replace but not move point immediately, C-r to enter recursive edit (C-M-c to get out again), C-w to delete match and recursive edit, C-l to clear the screen, redisplay, and offer same replacement again, ! to replace all remaining matches with no more questions, ^ to move point back to previous match, E to edit the replacement string End quote. This bug is really worth fixing. Otherwise, the lisp expression aspect of `query-replace-regexp' will behave /unnecessarily/ slow. Concerned, /a -- Computer Systems Specialist Leicester Central School Barstow Memorial School Rutland Northeast School District ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii [EMAIL PROTECTED] writes: Do _all_ files from that machine copy incorrectly? Or just some? No. Plain text files copy correctly for example. And I just noticed that using /scp:... instead of /ssh:... works fine, too. I only used ssh in the first place because I didn't have ssh-agent running and the scp method prompts for the password over and over. Also, could you show the contents of the *Messages* buffer after the copy operation finishes? Certainly, but I don't know how much it will help. You see I have 2 machine here, both running debian sid. On one I can copy the 1-byte file and on the other it turns into a 2-byte file. The *Messages* buffer is identical on the 2 machines (other than the name of the temporary file used, which looks to be random). Here it is: Loading tramp... Loading regexp-opt...done Loading tramp...done tramp: Opening connection for [EMAIL PROTECTED] using ssh... tramp: Waiting for prompts from remote shell tramp: Waiting 60s for prompt from remote shell tramp: Sending password tramp: Found remote shell prompt. tramp: Initializing remote shell Loading time-date...done tramp: Waiting 30s for remote `/bin/sh' to come up... tramp: Setting up remote shell environment tramp: Checking remote host type for `send-process-string' bug tramp: Determining coding system tramp: Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE' tramp: Waiting 30s for `set +o vi +o emacs' tramp: Waiting 30s for `unset MAIL MAILCHECK MAILPATH' tramp: Waiting 30s for `unset CDPATH' tramp: Setting shell prompt tramp: Remote `/bin/sh' groks tilde expansion, good tramp: Finding command to check if file exists tramp: Finding a suitable `ls' command tramp: Checking remote `/usr/xpg4/bin/ls' command for `-n' option tramp: Checking remote `/bin/ls' command for `-n' option tramp: Testing remote command `/bin/ls' for -n...okay tramp: Using remote command `/bin/ls' for getting directory listings tramp: Sending the Perl `mime-encode' implementations. tramp: Sending the Perl `mime-decode' implementations. tramp: Checking remote encoding command `mimencode -b' for sanity tramp: Checking remote encoding command `mmencode -b' for sanity tramp: Checking remote encoding command `recode data..base64' for sanity tramp: Checking remote encoding command `uuencode xxx' for sanity tramp: Checking remote decoding command `uudecode -o /dev/stdout' for sanity tramp: Checking to see if encoding/decoding commands work on remote host...done tramp: Sending the Perl script `tramp_file_attributes'...done. tramp: Encoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1 with function uudecode-decode-region... Loading uudecode...done Wrote /tmp/tramp.5003zUW tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1...done tramp: Inserting local temp file `/tmp/tramp.5003zUW'...done Wrote /tmp/file Loading dired...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
Aaron S. Hawley [EMAIL PROTECTED] writes: This bug is really worth fixing. Otherwise, the lisp expression aspect of `query-replace-regexp' will behave /unnecessarily/ slow. Sure, but I don't have access to commit the patch. Can someone who does please take a look and check it in if it's OK? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-expression of arithmetic with prefix arg is less useful due to lisp verbosity
This change: Typing C-x C-e twice prints the value of the integer result in additional formats (octal, hexadecimal, character) specified by the new function `eval-expression-print-format'. The same function also defines the result format for `eval-expression' (M-:), `eval-print-last-sexp' (C-j) and some edebug evaluation functions. is awful for C-u M-: It makes it much harder to make keyboard macros that manipulate numbers in buffers since every time they insert the result they insert this garbage in the buffer. Does this change do what you want? Does anyone have an argument against it? *** simple.el 05 Jan 2007 15:24:46 -0500 1.840 --- simple.el 10 Jan 2007 15:28:14 -0500 *** *** 1079,1085 (if eval-expression-insert-value (with-no-warnings (let ((standard-output (current-buffer))) ! (eval-last-sexp-print-value (car values (prog1 (prin1 (car values) t) (let ((str (eval-expression-print-format (car values --- 1079,1085 (if eval-expression-insert-value (with-no-warnings (let ((standard-output (current-buffer))) ! (prin1 (car values (prog1 (prin1 (car values) t) (let ((str (eval-expression-print-format (car values ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii [EMAIL PROTECTED] writes: I just tried this, and I cannot reproduce the problem with the current CVS: I get an exact replica of the original file on my local machine. I found what was causing the problem: I didn't have uudecode installed on the local machine, so TRAMP was using Emacs' Lisp version of uudecode, and using Emacs' write-region to save the results to a file. tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. write-region uses fileio.c's e_write(), and that does the following, copying the buffer's value of enable-multibyte-characters into the coding system, before using it to write the region: coding-src_multibyte = !NILP (current_buffer-enable_multibyte_characters); My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? This patch demonstrates that it is enable-multibyte-characters which causes the problem, but I suspect that the bug really needs fixing in the C code: --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. +(set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris [EMAIL PROTECTED] writes: I have a 1 byte file on a remote server. If I use 'scp' to copy the file to my local machine, it copies correctly, but if I use: $ emacs -Q (copy-file /ssh:[EMAIL PROTECTED]:~/file /tmp/file) C-j to copy it, then the resulting local file is 2 bytes long. I used hexl-mode to compare the two files: 1 byte correct version: : ce . 2 byte broken version: : 81ce .. Could it be that Emacs is doing some kind of character-encoding conversion? The byte sequence 0x81 0xCE looks like Emacs' internal character representation for ISO-8859-1 0xCE character. So, it seems that Emacs is doing character-DECODING conversion on reading that 1-byte file, and then it writes without encoding it back. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The problem is not really in write-region but in the code before: there's no way write-region can correctly write a multibyte char in binary. Write-region should probably just burp here rather than write something which is likely to be incorrect. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. That's not a problem per se as long as the region passed to write-region doesn't contain any multibyte char (i.e. non-ascii and non-eight-bit-*). My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? No. The problem seems to be that in uudecode.el the call to insert ends up internally converting the unibyte chars into multibyte chars (via unibyte-char-to-multibyte) when inserting them into the multibyte buffer. Basically, `insert' uses implicitly string-make-multibyte instead of string-to-multibyte. --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. + (set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) This patch looks correct, although I'd move the line earlier to right after `erase-buffer' where set-buffer-multibyte will be more efficient. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: I didn't have uudecode installed on the local machine, so TRAMP was using Emacs' Lisp version of uudecode, and using Emacs' write-region to save the results to a file. tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. I think that's the problem. How that buffer is created? How the contents was inserted in that buffer? write-region uses fileio.c's e_write(), and that does the following, copying the buffer's value of enable-multibyte-characters into the coding system, before using it to write the region: coding-src_multibyte = !NILP (current_buffer-enable_multibyte_characters); My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? In a multibyte buffer, raw byte data, say 0x81, is represented not by that byte itself but by 0x20 added and with preceding special byte 0x9E (so the byte sequence is 0x9E 0xA1) to distinguish it from a normal multibyte character (e.g. iso-8859-1's 0xC0 (A-grave) is represented by 0x81 0xC0). So, the writing process should convert 0x9E 0xA1 back to 0x81. The flag coding-src_multibyte tells if that kind of conversion is necessary or not. This patch demonstrates that it is enable-multibyte-characters which causes the problem, but I suspect that the bug really needs fixing in the C code: --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. + (set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) No. That change runs the function loc-dec in a unibyte buffer after 0x9E 0xA1 being converted back to 0x81 by (set-buffer-multibyte nil). That make the difference. But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
* running the same build on the same debian sid machine under KDE when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a .deb package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. How bizarre. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! This suggests to me that it has something to do with multithreading. I have a vague memory that GTK uses multithreading. Jan, do you get any ideas from this? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? I believe the function at fault is uudecode-decode-region, although personally I think the problem is much deeper, in the implicit use of unibyte-char-to-multibyte in `insert'. But independently from whether we fix it or not, I believe that making the buffer unibyte is the right thing to do since it will only ever contain bytes, and never chars: using a multibyte buffer here is inefficient and is asking for trouble. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes: But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? I believe the function at fault is uudecode-decode-region, although personally I think the problem is much deeper, in the implicit use of unibyte-char-to-multibyte in `insert'. Right. But independently from whether we fix it or not, I believe that making the buffer unibyte is the right thing to do since it will only ever contain bytes, and never chars: using a multibyte buffer here is inefficient and is asking for trouble. I agree. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
Can you please find a way to get the full log?
attached (this is with the CVS head build from this morning)
There's still something odd because the first entry (at the end) is:
(send-item #1# gdb-info-breakpoints-handler)
and all the initial commands at startup are missing (set height 0, set width 0
etc). Below is part of a typical log that I get. Also, for me, newlines are
printed with \n. Maybe this isn't an issue, but the start of the log must
exist somewhere.
--
Nick http://www.inet.net.nz/~nickrob
...
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\nNo breakpoints or watchpoints.\n)
(send-item server info breakpoints\n gdb-info-breakpoints-handler)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\n\n^Z^Zerror-begin\nNo stack.\n\n^Z^Zerror\n)
(send-item server info frame\n gdb-frame-handler)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\nCurrent source file is myprog.c\nCompilation
directory is /home/nickrob\nLocated in /home/nickrob/myprog.c\nContains 139
lines.\nSource language is c.\nCompiled with DWARF 2 debugging
format.\nIncludes preprocessor macro info.\n)
(send-item server info source\n gdb-source-info)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\n53 }\n54 \n55donowt (void)\n56 {\n57
int i;\n58 while (1)\n59 i = 4;\n60 }\n61 \n62main (int argc,
char** argv) {\n)
(send-item server list\n ignore)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\nSource files for which symbols have been read
in:\n\n\n\nSource files for which symbols will be read in on
demand:\n\n/home/nickrob/myprint.c, /home/nickrob/myprog.c\n)
(send-item server info sources\n gdb-set-gud-minor-mode-existing-buffers)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\n)
(send-item set width 0\n ignore)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . \n^Z^Zpost-prompt\n)
(send-item set height 0\n ignore)
(recv . \n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n)
(recv . ^Z^Zpost-prompt\n^error,msg=\Undefined mi command: stack-info-frame
(missing implementation)\\n(gdb) \n)
(recv . \n)
(send-item server interpreter mi -stack-info-frame\n gdb-get-version))
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev:
Richard Stallman [EMAIL PROTECTED] writes:
* running the same build on the same debian sid machine under KDE
when you run it under KDE, is that the GTK build of Emacs?
It's the same build in all cases. The same binary files. I make a
.deb package from the results of the build and install that same
package on both machines, and run that same package under the various
desktop environments. So in all cases it's using GTK.
Unfortunately, the comparison between the two machines is not very
conclusive because so many things could be different between them.
I don't know if you saw the silly patch for the problem which I posted
earlier today, but adding a static integer variable and incrementing
it before incrementing interrupt_input_blocked in the #define for
BLOCK_INPUT fixes the bug!
I arrived at that fix through a process of trial and error, not
through any understand at all of what's going on.
It is probably very timing related. A small change changes the timing. Can
you try the attachet patch?
Jan D.
Index: alloc.c
*** alloc.c.~1.405.~ 2007-01-01 19:19:05.0 +0100
--- alloc.c 2007-01-11 08:44:47.0 +0100
***
*** 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
pthread_mutex_lock (alloc_mutex); \
} \
while (0)
--- 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
***
*** 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT;\
} \
while (0)
--- 139,146
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
