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
