Re: ispell-change-dictionary does no SPC completion
Richard Stallman <[EMAIL PROTECTED]> writes: > M-x ispell-change-dictionary > SPC > > There is no completion of the *completions* buffer even though the > buffer does not fully display the alternatives. > > I do not understand those words. What do you mean by "completion of > the *completions* buffer"? > I'm sorry, I meant scrolling of the *completions* buffer (when there are more completions in the buffer than the window displays). -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: global-hl-line-mode doesn't work right in the *compilation* buffer]
Chong Yidong <[EMAIL PROTECTED]> writes: >> ./emacs -Q -D >> M-x global-hl-line-mode >> M-x cd ".." >> M-x compile "./configure" >> C-x o (into the *compilation* buffer) >> M-> (to the already hidden end of the *compilation* buffer) >> >> Emacs highlights now the buffer position where the cursor started up >> to the current cursor position instead of only the current cursor >> line. > > I can't reproduce this. Right, this time it didn't work for me as well at the first try, probably because I didn't wait until the window of the *compilation* buffer was completely filled. But even then you should see this effect when you type M-< and M-> repeatedly, or C-SPC and M-> while the compilation still grinds on. You should get a - as in my case - green background in the *compilation* buffer. Thanks -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
cursor after ispell-word remains over corrected word
CVS data from Sunday: This is only a suggestion of a grateful user (on the other hand I can't remember the following behaviour in 21.4, maybe it's even a bug): Sometimes my cursor happens to reside over a word (i. e. inside word boundaries) before doing `M-$' (or `M-TAB'), then the cursor remains at `(point)' and does not skip to either the word beginning or the word end (as is indicated when `ispell-word' shows its alternatives) of the corrected word. In my opinion this is annoying because it's very likely that one has unnecessarily to skip out of the corrected word. I think the described behaviour makes only sense for `C-;' (flyspell-auto-correct-previous-word). In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-07-23 on hans X server distributor `The X.Org Foundation', version 11.0.60802000 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: fr_FR.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: auto-fill-function: message-do-auto-fill mml-mode: t flyspell-mode: t display-time-mode: t shell-dirtrack-mode: t global-hl-line-mode: t auto-insert-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t 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 abbrev-mode: t Recent input: SPC m a i s o n SPC e t SPC c ` a SPC ' SPC e s t SPC p l u s SPC m e i e u x SPC SPC p a c d e r c e SPC q u e SPC j ' SPC a i s SPC SPC m i e w u x SPC u t i l s SPC M-$ 2 C-e SPC p o u r M-x r e p o r t - e b Recent messages: Making completion list... Ispell process killed Local Ispell dictionary set to francais Starting new Ispell process [francais] ... Checking spelling of CA... Type C-x 1 to remove help window. byte-code: Buffer is read-only: #> Checking spelling of J'ECRIS... Auto-saving...done Checking spelling of UTILS... -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tumme and killed dired buffer.
In GNU Emacs 22.0.50.81 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-07-24 on escpc40 X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--with-gtk'' The attached patch has two quick fixes for when the tumme associated dired buffer is killed. Thanks, Matt Index: tumme.el === RCS file: /sources/emacs/emacs/lisp/tumme.el,v retrieving revision 1.39 diff -u -r1.39 tumme.el --- tumme.el 24 Jul 2006 16:27:01 - 1.39 +++ tumme.el 25 Jul 2006 09:18:52 - @@ -1009,7 +1009,7 @@ (let ((old-buf (current-buffer)) (dired-buf (tumme-associated-dired-buffer)) (file-name (tumme-original-file-name))) -(when (and dired-buf file-name) +(when (and (buffer-live-p dired-buf) file-name) (setq file-name (file-name-nondirectory file-name)) (set-buffer dired-buf) (goto-char (point-min)) @@ -1134,7 +1134,7 @@ (format-spec tumme-display-properties-format (list -(cons ?b buf) +(cons ?b (or buf "")) (cons ?f file) (cons ?t (or (princ props) "")) (cons ?c (or comment "") ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
Am 25.07.2006 um 05:09 schrieb Richard Stallman: What is the value of d before line 561? That could mean something. I don't think that this can matter -- the error happens in this function as defined in floatfns.c: 551 DEFUN ("sqrt", Fsqrt, Ssqrt, 1, 1, 0, 552 doc: /* Return the square root of ARG. */) 553(arg) 554register Lisp_Object arg; 555 { 556 double d = extract_float (arg); 557 #ifdef FLOAT_CHECK_DOMAIN 558 if (d < 0.0) 559 domain_error ("sqrt", arg); 560 #endif 561 IN_FLOAT (d = sqrt (d), "sqrt", arg); 562 return make_float (d); 563 } If my understanding of (old) C still stands, d is a local variable inside the function's body. At line #556 a 'print d' tells: $1 = {} 0x901aea38 What value does extract_float return? 214 /* Extract a Lisp number as a `double', or signal an error. */ 215 216 double 217 extract_float (num) 218Lisp_Object num; 219 { 220 CHECK_NUMBER_OR_FLOAT (num); 221 222 if (FLOATP (num)) 223 return XFLOAT_DATA (num); 224 return (double) XINT (num); 225 } Do you mean to type x when gdb has reached line #225? I get for example (own input mostly deleted): Breakpoint 2, extract_float (num=5145654) at floatfns.c:220 0x1f0ebc : 0x80010078 resize_mini_window (w=0x15014e8, exact_p=0) at xdisp.c:8248 Breakpoint 2, extract_float (num=5146190) at floatfns.c:220 0x36f2c : 0x80010050 Fmake_hash_table (nargs=0, args=0xbfffd614) at fns.c:5270 Breakpoint 2, extract_float (num=4216608) at floatfns.c:220 (gdb) x 0x36f2c : 0x80010050 (gdb) n Fsqrt (arg=4216608) at floatfns.c:561 (gdb) n Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/ operand. 0x001f2828 in Fsqrt (arg=4216608) at floatfns.c:561 Breakpoint 6 at 0x1f27e4: file floatfns.c, line 561. (gdb) x 0x1f27e4 : 0x3c5f0020 It might be worth to find the Elisp file that uses sqrt with the argument of 4216608. *I* have no idea how to find that file ... A termscript shows this: Loading shell... done ansi-color... done Loading cal-move... done mule-util...done In the last gdb session, as shown above, the last "message" was the modeline of the *scratch* buffer (I had to fake TERM for gdb to be xterm-color to make GNU Emacs launch with no window inside a gud buffer in Emacs.app, the "NeXTStep" like application). -- Greetings Pete <\ \__ O __O | O\ _\\/\-%_`\<, '()-'-(_)--(_) (_)/(_) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
> If my understanding of (old) C still stands, d is a local variable > inside the function's body. At line #556 a 'print d' tells: > > $1 = {} 0x901aea38 That's odd because your previous post said you got 527076. > > What value does extract_float return? > > >214 /* Extract a Lisp number as a `double', or signal an error. */ >215 >216 double >217 extract_float (num) >218Lisp_Object num; >219 { >220 CHECK_NUMBER_OR_FLOAT (num); >221 >222 if (FLOATP (num)) >223 return XFLOAT_DATA (num); >224 return (double) XINT (num); >225 } > > Do you mean to type x when gdb has reached line #225? I get for > example (own input mostly deleted): > No. What value does the GDB command `finish' print if starting from extract_float, or equivalently, what do you get if you type `print d' after 556double d = extract_float (arg); i.e at 561IN_FLOAT (d = sqrt (d), "sqrt", arg); >... > (gdb) n > Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/ > operand. > 0x001f2828 in Fsqrt (arg=4216608) at floatfns.c:561 > Breakpoint 6 at 0x1f27e4: file floatfns.c, line 561. > (gdb) x > 0x1f27e4 :0x3c5f0020 > > > It might be worth to find the Elisp file that uses sqrt with the > argument of 4216608. *I* have no idea how to find that file ... A > termscript shows this: Actually Emacs is computing sqrt (527076) at this point (it's to do with the way Lisp Objects store numbers). sqrt (527076) = 726 I think in your case sqrt gets called by tty-color-off-gray-diag in tty-colors.el but it would be best to find out what goes wrong in Fsqrt. What happens if you start Emacs as a graphical application and evaluate (sqrt 527076) in the scratch buffer? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash when function-key-map is nil
Richard Stallman <[EMAIL PROTECTED]> writes: > emacs -Q > > (setq function-key-map) > > (Do you evaluate that?) Yes. Sorry. > Press a key => Segfault. > > It does not fail for me. Program received signal SIGSEGV, Segmentation fault. 0x00526211 in Fget (symbol=0, propname=9476017) at fns.c:2004 (gdb) bt full #0 0x00526211 in Fget (symbol=0, propname=9476017) at fns.c:2004 No locals. #1 0x004b74d0 in parse_modifiers (symbol=1) at keyboard.c:6147 elements = 4294967296 #2 0x004b77c0 in reorder_modifiers (symbol=1) at keyboard.c:6266 parsed = 9700501 #3 0x004c368a in access_keymap (map=11100261, idx=1, t_ok=1, noinherit=0, autoload=1) at keymap.c:527 val = 9411009 #4 0x004bbcee in access_keymap_keyremap (map=11100261, key=1, prompt=9410961, do_funcall=1) at keyboard.c:8374 next = 9410961 #5 0x004bbf7f in keyremap_step (keybuf=0x7f818780, bufsize=30, fkey=0x7f8184c0, input=1, doit=1, diff=0x7f81839c, prompt=9410961) at keyboard.c:8429 next = 9410961 key = 1 #6 0x004be35a in read_key_sequence (keybuf=0x7f818780, bufsize=30, prompt=9410961, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9386 gcpro1 = { next = 0x0, var = 0x0, nvars = 0 } gcpro3 = { next = 0x0, var = 0x0, nvars = 0 } done = 0 gcpro2 = { next = 0x0, var = 0x0, nvars = 0 } diff = 0 key = 9686017 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 local_first_binding = 0 from_string = 9410961 count = 2 t = 1 echo_start = 0 keys_start = 0 nmaps = 2 nmaps_allocated = 2 defs = (Lisp_Object * volatile) 0x7f818220 submaps = (Lisp_Object * volatile) 0x7f818240 orig_local_map = 12633525 orig_keymap = 9410961 localized_local_map = 0 first_binding = 1 first_unbound = 31 mock_input = 0 fkey = { map = 9410961, parent = 9410961, start = 31, end = 31 } keytran = { map = 11100261, parent = 11100261, start = 17, end = 18 } delayed_switch_frame = 9410961 original_uppercase = 0 original_uppercase_position = -1 dummyflag = 0 starting_buffer = (struct buffer *) 0x906600 fake_prefixed_keys = 9410961 gcpro1 = { next = 0x0, var = 0x0, nvars = 0 } #7 0x004ae0da in command_loop_1 () at keyboard.c:1535 cmd = 10223825 lose = 0 nonundocount = 0 keybuf = {9686017, 40, 140737480067088, 0, 140737480069288, 0, 140737480067008, 5367980, 140737480067088, 5367886, 4294967296, 8115972, 14849504, 8115968, 0, 140737480069288, 140737480069016, 1, 140737480067296, 5365576, 46912518591648, 678102311572810528, 2, 678102312996145280, 0, 14849504, 46912521232444, 46912521212752, 46912521165136, 22} i = 2 no_direct = 0 prev_modiff = 4 prev_buffer = (struct buffer *) 0x906600 was_locked = 0 already_adjusted = 0 #8 0x0051cd76 in internal_condition_case (bfun=0x4add64 , handlers=9494817, hfun=0x4ad7a0 ) at eval.c:1469 val = c = { tag = 9410961, val = 9410961, next = 0x7f818a90, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 140737480067696, 0, 140737480069288, 140737480069016, 1, 140737480067328, 5360889}, __mask_was_saved = 0, __saved_mask = { __val = {14119920, 14, 14, 140737480069288, 14848404, 46912521207496, 46912518592824, 2888375576, 6981624, 0, 140737480069288, 140737480069016, 1, 140737480068048, 46912496164043, 1} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 9494817, var = 9410961, chosen_clause = 9410961, tag = 0x7f818920, next = 0x0 } #9 0x004adbc3 in command_loop_2 () at keyboard.c:1326 val = 1 #10 0x0051c967 in internal_catch (tag=, func=0x4adba9 , arg=9410961) at eval.c:1210 c = { tag = 9482849, val = 9410961, next = 0x0, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 140737480068048, 0, 140737480069288, 140737480069016, 1, 140737480067712, 5359963}, __mask_was_saved = 0, __saved_mask = { __val = {0, 2888375576, 14119888, 18, 18, 140737480069288, 140737480067858, 1, 0, 46912499937712, 9747050, 9747048, 9753856, 9463296, 9753857, 9410961} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } #11 0x004adb7d in command_loop () at keyboard.c:1305 No locals. #12 0x004ad4b5 in recursive_ed
Re: tumme and killed dired buffer.
Matt Hodges <[EMAIL PROTECTED]> writes: > The attached patch has two quick fixes for when the tumme associated > dired buffer is killed. Thanks, I'd never dream of killing the dired buffer where I keep all (yes, all) my images, so I would never have found this :) I applied the patch. /Mathias ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 100% CPU usage for a few minutes when visiting large Unicode file
(gdb) Run till exit from #0 interrupt_signal (signalnum=2) at keyboard.c:10390 Warning: Cannot insert breakpoint 0. Error accessing memory address 0xe420: Input/output error. (gdb) Run till exit from #0 interrupt_signal (signalnum=2) at keyboard.c:10390 Warning: Cannot insert breakpoint 0. Error accessing memory address 0xe420: Input/output error. interrupt_signal is a signal handler. How did you stop Emacs? Did you do it by typing a command at Emacs? That is dumb -- it will interfere with what happens inside Emacs. You should stop Emacs by going to the window where GDB is running, and typing C-z. Anyway, it looks like GDB has a bug in returning from signal handler commands with `finish'. Please report the GDB bug, because we need to get it fixed. Meanwhile, you probably CAN proceed from this. Just use the `up' command to select the containing frame, and type `finish' in that one. If you get to an ordinary (non-signal-handler) frame this way, `finish' should work on it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tumme and killed dired buffer.
> Mathias Dahl writes: > Thanks, I'd never dream of killing the dired buffer where I keep > all (yes, all) my images, so I would never have found this :) Never expect others to use your packages as intended :-) > I applied the patch. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No default for describe-font, but one is advertised
> From: Kenichi Handa <[EMAIL PROTECTED]> > Date: Tue, 25 Jul 2006 15:46:34 +0900 > Cc: emacs-pretest-bug@gnu.org > > In article <[EMAIL PROTECTED]>, "Drew Adams" <[EMAIL PROTECTED]> writes: > > > I can't reproduce it in my environment. Please show me the > > result of this call. > > > (frame-parameter nil 'font) > > > "-outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1" > > Ummm, the font name contains a wild card. Strange. Perhaps > it is a problem specific to MS-Windows port. Could someone > who is working on Windows help? What help do you need? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
Am 25.07.2006 um 14:15 schrieb Nick Roberts: If my understanding of (old) C still stands, d is a local variable inside the function's body. At line #556 a 'print d' tells: $1 = {} 0x901aea38 That's odd because your previous post said you got 527076. Before I was working in Apple's Terminal. Then more details were demanded by RMS, so I needed to see the sources. The only solution that came to my mind was gdb in Emacs.app. And it has different geometry ... ? No. What value does the GDB command `finish' print if starting from extract_float, (gdb) step extract_float (num=2) at floatfns.c:219 (gdb) finish Run till exit from #0 extract_float (num=2) at floatfns.c:219 Breakpoint 2, extract_float (num=4216608) at floatfns.c:220 (gdb) finish Run till exit from #0 extract_float (num=4216608) at floatfns.c:220 0x001f27dc in Fsqrt (arg=4216608) at floatfns.c:556 Value returned is $7 = 527076 (gdb) finish Run till exit from #0 0x001f27dc in Fsqrt (arg=4216608) at floatfns.c:556 Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/ operand. 0x001f2828 in Fsqrt (arg=4216608) at floatfns.c:561 or equivalently, what do you get if you type `print d' after 556double d = extract_float (arg); Breakpoint 1, Fsqrt (arg=4216608) at floatfns.c:556 (gdb) print d $5 = 7.1699012343114344e-308 i.e at 561IN_FLOAT (d = sqrt (d), "sqrt", arg); (gdb) n Fsqrt (arg=4216608) at floatfns.c:561 (gdb) print d $1 = 527076 (gdb) fin Run till exit from #0 Fsqrt (arg=4216608) at floatfns.c:561 Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/ operand. 0x001f2828 in Fsqrt (arg=4216608) at floatfns.c:561 (gdb) print d $2 = 527076 What happens if you start Emacs as a graphical application and evaluate (sqrt 527076) in the scratch buffer? pete 317 /\ ./emacs -Q --debug-init Fatal error (4)Illegal instruction Between these two lines I let the X client compute the square root -- after some seconds it crashed! The GCC docs say about -mpowerpc-gpopt: The -mpowerpc option allows GCC to generate instructions that are found only in the 32-bit subset of the PowerPC architecture. Specifying -mpowerpc-gpopt implies -mpowerpc and also allows GCC to use the optional PowerPC architecture instructions in the General Purpose group, including floating-point square root. Specifying - mpowerpc-gfxopt implies -mpowerpc and also allows GCC to use the optional PowerPC architecture instructions in the Graphics group, including floating-point select. Freescale documents: The MPC7447A processor is a high-performance, low-power, 32-bit implementation of the PowerPC™ RISC architecture. Key architectural features include 512 KB of on-chip L2 cache, a 64-bit bus interface and a full 128-bit implementation of Freescale's AltiVec™ technology. MPC7447A processors are ideal for leading-edge computing, embedded network control and signal processing applications. Superscalar Microprocessor MPC7447A processors feature a high-frequency superscalar PowerPC core, capable of issuing four instructions per clock cycle (three instructions plus one branch) into 11 independent execution units: •Four integer units (three simple plus one complex) •Double-precision floating point unit • Four AltiVec technology units (simple, complex, floating and permute) •Load/store unit •Branch processing unit Since leaving away -mpowerpc-gpopt leads to an executable that runs without windows it must be either a bug in the (Apple) compiler or in my hardware, isn't it? (Configuring with the Fink supplied tools gcc 4.1.0, autoconf 2.60, automake 1.9 does not seem to work.) -- Greetings Pete Math illiteracy affects 7 out of every 5 Americans. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
> > What happens if you start Emacs as a graphical application and > > evaluate > > (sqrt 527076) in the scratch buffer? > > pete 317 /\ ./emacs -Q --debug-init > Fatal error (4)Illegal instruction > > Between these two lines I let the X client compute the square root -- > after some seconds it crashed! So calculating sqrt is the cause and not the symptom. > The GCC docs say about -mpowerpc-gpopt: > > The -mpowerpc option allows GCC to generate instructions that are > found only in the 32-bit subset of the PowerPC architecture. > Specifying -mpowerpc-gpopt implies -mpowerpc and also allows GCC to > use the optional PowerPC architecture instructions in the General > Purpose group, including floating-point square root. Specifying - > mpowerpc-gfxopt implies -mpowerpc and also allows GCC to use the > optional PowerPC architecture instructions in the Graphics group, > including floating-point select. My guess would be that your processor doesn't support -mpowerpc-gpopt >... > Since leaving away -mpowerpc-gpopt leads to an executable that runs > without windows it must be either a bug in the (Apple) compiler or in > my hardware, isn't it? (Configuring with the Fink supplied tools gcc > 4.1.0, autoconf 2.60, automake 1.9 does not seem to work.) I don't think -mpowerpc-gpopt should be needed for a graphical build but perhaps someone more familiar with Apple computers can comment. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
c++ font-lock bug
c++-mode does not correctly fontify variable declarations in for loops (or if's) the following code: int main( void ) { for( uint8 i = 0; i != 100; ++i ) { for( uint8* j = &i; j != &i + 1; ++j ) {// // This should be fontified as a variable declaration! printf( "BLAH!!!\n" ); } }} In theory, without knowledge if uint8 is a type or a variable, you can not correctly fontify theprevious code. But any code that overloads operator* and operator= such that the previous codemakes sense as a statement deserves much worse pain than minor incorrect fontification. ;) -- MJF In GNU Emacs 22.0.50.1(i386-mingw-nt5.1.2600) of 2006-06-04 on TPAD X server distributor `Microsoft Corp.', version5.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: C++/lw Minor modes in effect: hide-ifdef-hiding: t global-balanced-mode: t balanced-mode: t hrule-mode: t cua-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 hide-ifdef-mode: t semantic-idle-summary-mode: t semantic-idle-scheduler-mode: t global-c-subword-mode: t shell-dirtrack-mode: t semantic-show-parser-state-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 abbrev-mode: t Recent input: * SPC M-l u i n t 8 * SPC r u n . b y t e s ; SPC b y t e I t SPC ! = SPC Recent messages: Show the Emacs license (GPL)How to get latest versions of Emacs Lisp packages distributed separately for use in Emacs Displayversion number, copyright info, and basic help Find packages and features by keyword Fulldocumentation of Emacs features Send e-mail to Emacs maintainers Loading emacsbug...done mouse-1:major mode, mouse-2: major mode help, mouse-3: toggle minor modes funcall: End of buffer ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash when function-key-map is nil
#0 0x00526211 in Fget (symbol=0, propname=9476017) at fns.c:2004 No locals. SYMBOL looks wrong. Can you trace back where that value came from? #1 0x004b74d0 in parse_modifiers (symbol=1) at keyboard.c:6147 elements = 4294967296 #2 0x004b77c0 in reorder_modifiers (symbol=1) at keyboard.c:6266 parsed = 9700501 SYMBOL looks wrong here too. Can you trace back where that value came from? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
> What is the value of d before line 561? That could mean something. > I don't think that this can matter -- the error happens in this function as defined in floatfns.c: Yes, line 561 uses the value of d. We need to see what d was just before that line. If my understanding of (old) C still stands, d is a local variable inside the function's body. At line #556 a 'print d' tells: $1 = {} 0x901aea38 That is very strange. It isn't just a bad value, it is the wrong kind of output. The value looks like the address of something. You need a Mac wizard to help you figure out why those lines do not execute properly. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ispell-change-dictionary does no SPC completion
> M-x ispell-change-dictionary > SPC > > There is no completion of the *completions* buffer even though the > buffer does not fully display the alternatives. > > I do not understand those words. What do you mean by "completion of > the *completions* buffer"? > I'm sorry, I meant scrolling of the *completions* buffer (when there are more completions in the buffer than the window displays). That is not a bug. There is no feature to make SPC scroll in such situations. What led you to think that SPC would have this effect inside the minibuffer? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cursor after ispell-word remains over corrected word
M-$ never moves point as far as I can see. Why do you expect it would do so? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No default for describe-font, but one is advertised
In article <[EMAIL PROTECTED]>, Eli Zaretskii <[EMAIL PROTECTED]> writes: >> In article <[EMAIL PROTECTED]>, "Drew Adams" <[EMAIL PROTECTED]> writes: >> >> > I can't reproduce it in my environment. Please show me the >> > result of this call. >> >> > (frame-parameter nil 'font) >> >> > "-outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1" >> >> Ummm, the font name contains a wild card. Strange. Perhaps >> it is a problem specific to MS-Windows port. Could someone >> who is working on Windows help? > What help do you need? To figure out why describe-font doesn't work well on Windows. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash when function-key-map is nil
Richard Stallman <[EMAIL PROTECTED]> writes: > #0 0x00526211 in Fget (symbol=0, propname=9476017) at fns.c:2004 > No locals. > > > SYMBOL looks wrong. Can you trace back where that value came from? (I think GDB is lying here. If I set a breakpoint on Fget it displays "symbol=", and if I recompile fns.c without optimizations it changes to "symbol=1".) > #1 0x004b74d0 in parse_modifiers (symbol=1) at keyboard.c:6147 > elements = 4294967296 > #2 0x004b77c0 in reorder_modifiers (symbol=1) at keyboard.c:6266 > parsed = 9700501 > > > SYMBOL looks wrong here too. Can you trace back where that value came > from? The "1" comes from... #3 0x004c368a in access_keymap (map=11100261, idx=1, t_ok=1, noinherit=0, autoload=1) at keymap.c:527 val = 9411009 IDX here #4 0x004bbcee in access_keymap_keyremap (map=11100261, key=1, prompt=9410961, do_funcall=1) at keyboard.c:8374 next = 9410961 KEY here #5 0x004bbf7f in keyremap_step (keybuf=0x7f818780, bufsize=30, fkey=0x7f8184c0, input=1, doit=1, diff=0x7f81839c, prompt=9410961) at keyboard.c:8429 next = 9410961 key = 1 KEY here. KEY gets its value from key = keybuf[fkey->end++] #6 0x004be35a in read_key_sequence (keybuf=0x7f818780, bufsize=30, prompt=9410961, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9386 This is inside this loop: /* Look for this sequence in key-translation-map. Scan from keytran.end until we find a bound suffix. */ while (keytran.end < fkey.start) { struct gcpro gcpro1, gcpro2, gcpro3; int done, diff; GCPRO3 (fkey.map, keytran.map, delayed_switch_frame); done = keyremap_step (keybuf, bufsize, &keytran, max (t, mock_input), 1, &diff, prompt); UNGCPRO; if (done) { mock_input = diff + max (t, mock_input); /* Adjust the function-key-map counters. */ fkey.end += diff; fkey.start += diff; goto replay_sequence; } } -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
> On Wed, 26 Jul 2006 09:33:10 +1200, Nick Roberts <[EMAIL PROTECTED]> said: > My guess would be that your processor doesn't support > -mpowerpc-gpopt Most likely. /usr/include/gcc/darwin/4.0/ppc_intrnsics.h says: /* * __fsqrt - Floating-Point Square Root (Double-Precision) * * WARNING: Illegal instruction for PowerPC 603, 604, 750, 7400, 7410, * 7450, and 7455 */ /* * __fsqrts - Floating-Point Square Root Single-Precision * * WARNING: Illegal instruction for PowerPC 603, 604, 750, 7400, 7410, * 7450, and 7455 */ YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug