Juanma Barranquero | 1 Apr 04:44 2010
Picon

bug#5816: Cursor moves to end of completions in icomplete-mode

Version: 24.0.50

Doing

   emacs -Q -f icomplete-mode
   C-h v xa

- with the emacs-23 branch:

  Describe variable: xa<(>rgs-program)  [Matched]

- with the trunk:

  Describe variable: xa(rgs-program)  [Matched]<>

where <> marks the cursor position. Bisection seems to indicate the
bug appears in revid:eliz <at> gnu.org-20100330091307-ier2rhqfttgi90pr
(Initial support for bidirectional editing).

    Juanma

Ryan Thompson | 1 Apr 08:02 2010

bug#5802: emacsclient -c crashes emacs --daemon intermittently; have strace

On Tue, Mar 30, 2010 at 10:47 AM, Dan Nicolaescu <dann <at> gnu.org> wrote:
> Ryan Thompson <rct <at> thompsonclan.org> writes:
>
>> On Tue, Mar 30, 2010 at 8:46 AM, Dan Nicolaescu <dann <at> gnu.org> wrote:
>>> Ryan Thompson <rct <at> thompsonclan.org> writes:
>>>
>>>> I am trying to set myself up using emacs --daemon so that I can easily
>>>> manage multiple emacs frames within one process. However, I have hit a
>>>> significant stumbling block. If I run emacs --daemon (or emacs -nw and
>>>> then do (server-start) ) and then repeatedly run emacsclient -c and
>>>> clost the resulting window, emacs will randomly crash. Sometimes it
>>>> happens on the first time that I run emacsclient -c, sometimes on the
>>>> 20th.
>>>>
>>>> I use Ubuntu 9.10, and I have reported this bug in Launchpad. However,
>>>> I have also compiled both emacs 23.1 and trunk from vanilla sources,
>>>> and both of these exhibit the same bug as the Ubuntu-packaged
>>>> versions.
>>>>
>>>> I have generated some stack traces by the following procedure, as
>>>> described at https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/543611
>>>>
>>>> Open two terminals. In the first terminal, run the following commands
>>>> to start emacs with strace:
>>>>
>>>> $ mkdir -p /tmp/emacs-strace
>>>> $ strace -o /tmp/emacs-strace/trace-`date +%s`.log emacs -Q -nw
>>>>
>>>> When emacs has started, do M-x server-start so that emacsclient can
>>>> work. Now, in the second terminal, run the following command:
(Continue reading)

Jan Djärv | 1 Apr 09:43 2010
Picon

bug#5695: 23.1; wid-edit.el problems

One solution would be for widget-choose to use tmm-prompt.  Is that ok?

	Jan D.

Jan Djärv skrev:
> Dani Moncayo skrev:
>>
>> I've just noticed that the problem arises if (and only if) I start emacs
>> loading my .emacs file. So, i've been testing a bit and i've 
>> discovered that
>> the line that produces the problem is the one that sets the
>> next-screen-context-lines variable to 4.
> 
> Actually, it is the scroll-margin that does it.
> When the menu is created, point is at the last line.  Since you have 
> scroll-margin set to 1, it scrolls up.  You can't see that because you 
> have no indication, but on a graphical terminal you can see that the 
> scroll bar has moved a bit.  Unfortunately there is no way to scroll the 
> window, it is either select something or C-g.  wid-edit.el tries to set 
> a scroll-other-window command, but it somehow fails to work because of 
> the default binding to keyboard-quit.  And in any case, IT only scrolls 
> down, not up.
> 
> So, the menu created by wid-edit.el should either (or both)
> 
> 1) place point somewhere else, preferrably at the end of the first line.
> 2) provide a way to scroll the window. tmm-menubar does this so it can 
> be done.
> 
> Someone familiar with wid-edit.el must look at this.
(Continue reading)

Eli Zaretskii | 1 Apr 09:29 2010
Picon

bug#5816: Cursor moves to end of completions in icomplete-mode

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Thu, 1 Apr 2010 04:44:22 +0200
> Cc: 
> 
> Doing
> 
>    emacs -Q -f icomplete-mode
>    C-h v xa
> 
> - with the emacs-23 branch:
> 
>   Describe variable: xa<(>rgs-program)  [Matched]
> 
> - with the trunk:
> 
>   Describe variable: xa(rgs-program)  [Matched]<>
> 
> 
> where <> marks the cursor position. Bisection seems to indicate the
> bug appears in revid:eliz <at> gnu.org-20100330091307-ier2rhqfttgi90pr
> (Initial support for bidirectional editing).

Yes, that figures.  The function that positions the cursor is the only
one that was completely rewritten for the bidi support, because the
original code was designed around the assumption that display is
unidirectional.  All the other bidi changes are additions to the
existing code, and are not get executed except for buffers where the
bidi display option was turned on.

Thanks for the report and the test case, I will look into this ASAP.
(Continue reading)

Kenichi Handa | 1 Apr 09:59 2010

bug#5667: 23.1.93; cursor movement in Korean text is slow with xfonts-baekmuk

Very sorry for the late response on this matter.

In article <87ljeb7kpr.fsf <at> desy.de>, Jae-hyeon Park <jae-hyeon.park <at> desy.de> writes:

> I am sorry if you are seeing this report more than once as I have
> already posted about this problem to emacs-devel (which I suppose was
> not the right list for a bug report).

> I use the baekmuk bitmap font (available as the xfonts-baekmuk package
> in debian for instance) to display Korean characters in emacs.  When
> there are many Korean characters in a buffer, moving the cursor among
> the Korean characters takes a long time (like a few seconds on my laptop
> which is a fairly new hardware).  It is weird that this symptom occurs
> only if I use this particular font.  However, the same font causes no
> trouble when I am using emacs 22.

> How to reproduce:

> 1) Start emacs with

>     $ emacs -Q -xrm 'Emacs.FontBackend: x' &

> 2) In the scratch buffer, evaluate the following code

>     (create-fontset-from-fontset-spec
>      "-misc-fixed-medium-r-normal--15-140-75-75-c-90-fontset-baekmuk,
>       ascii:-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1")
>     (set-fontset-font "fontset-baekmuk" 'korean-ksc5601
>      "-baekmuk-gulim-medium-r-normal--18-180-75-75-m-180-ksc5601.1987-0")
>     (set-frame-font "fontset-baekmuk")
(Continue reading)

Jae-hyeon Park | 1 Apr 10:31 2010
Picon

bug#5667: 23.1.93; cursor movement in Korean text is slow with xfonts-baekmuk

Kenichi Handa, on 2010-04-01 09:59 +0200, said:

> Very sorry for the late response on this matter.

No problem.

> I've just confirmed this problem.  Strangely that slowness
> doesn't happen with the other fonts (e.g. daewoo-mincho).
> I'm now investigating what is wrong.

I have uploaded a patch to the bug tracker.  The difference between
baekmuk and daewoo is the xfont encoding registry.  Baekmuk has
ksx1001.1998 and daewoo has ksc5601.1987.  [xfonts-baekmuk package
installs also aliases with registry ksc5601.1987.]

Apart from the above temporary fix, another question is: I don't know
whether or not emacs is expected to slow down when it sees a font with
an unknown (to emacs) encoding.

Cheers,
Jae-hyeon

Dani Moncayo | 1 Apr 11:43 2010
Picon

bug#5695: 23.1; wid-edit.el problems

From my little experience with GNU Emacs (i'm yet starting to understand it), i think that the buffer created by tmm-menubar has basically the same function that the widget-choose buffer: To present a list of options to the user, and get the chosen one.

So... i agree with you, Jan. Why don't share the same mode for both buffers? Why to have different modes for each?


On Thu, Apr 1, 2010 at 9:43 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
One solution would be for widget-choose to use tmm-prompt.  Is that ok?

       Jan D.

Jan Djärv skrev:
Dani Moncayo skrev:

I've just noticed that the problem arises if (and only if) I start emacs
loading my .emacs file. So, i've been testing a bit and i've discovered that
the line that produces the problem is the one that sets the
next-screen-context-lines variable to 4.

Actually, it is the scroll-margin that does it.
When the menu is created, point is at the last line.  Since you have scroll-margin set to 1, it scrolls up.  You can't see that because you have no indication, but on a graphical terminal you can see that the scroll bar has moved a bit.  Unfortunately there is no way to scroll the window, it is either select something or C-g.  wid-edit.el tries to set a scroll-other-window command, but it somehow fails to work because of the default binding to keyboard-quit.  And in any case, IT only scrolls down, not up.

So, the menu created by wid-edit.el should either (or both)

1) place point somewhere else, preferrably at the end of the first line.
2) provide a way to scroll the window. tmm-menubar does this so it can be done.

Someone familiar with wid-edit.el must look at this.

   Jan D.





Eli Zaretskii | 1 Apr 14:45 2010
Picon

bug#5816: Cursor moves to end of completions in icomplete-mode

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Thu, 1 Apr 2010 04:44:22 +0200
> 
> Doing
> 
>    emacs -Q -f icomplete-mode
>    C-h v xa
> 
> - with the emacs-23 branch:
> 
>   Describe variable: xa<(>rgs-program)  [Matched]
> 
> - with the trunk:
> 
>   Describe variable: xa(rgs-program)  [Matched]<>

Actually, the problem was visible even with the standard completion,
not only with icomplete-mode.

I think I fixed it.  Please try again, and if there are still
problems, please reopen the bug.

Eli Zaretskii | 1 Apr 17:37 2010
Picon

bug#5813: remove __DJGPP__ version tests

> From: Dan Nicolaescu <dann <at> gnu.org>
> Date: Wed, 31 Mar 2010 15:33:03 -0400
> 
> Are the __DJGPP__ version tests still needed?
> Can we assume __DJGPP__ >= 2 is true?
> 
> Any reason not to remove them?

Yes, it's time to forget about DJGPP < 2.  Thanks for pointing this
out.

I removed all the tests for __DJGPP__.  There are still 3 tests for
__DJGPP_MINOR__, but they are in MSDOS-specific files (dosfns.c and
msdos.c).  I also updated CPP-DEFINES accordingly.

Chong Yidong | 1 Apr 17:31 2010

bug#5811: 23.1.94; Emacs Nextstep port crashes after graphical yes-or-no-p

Could you take a look at this bug report?  Thanks.

David, it would help if you compile Emacs without optimizations.  That
makes the stack trace easier to read.

David Engster <deng <at> randomsample.de> writes:

> I've notice that Emacs didn't seem to correctly deal with graphical
> 'yes-or-no-p' question. When I've tried to further investigate this
> issue, I've got Emacs to crash upon the following code:
>
> * Emacs -Q
>
> * Evalute the following:
>
> (let ((last-nonmenu-event nil))
>   (yes-or-no-p "Question"))
>
> * Click on "No"
>
> Emacs crashes with EXC_BAD_ACCESS. 
>
> The above code runs fine when running Emacs under X11 on the same system.
>
> I'm using the latest pretest (23.1.94), configured only with
> "--with-ns", on Mac OS X 10.6.3., using the following gcc:
>
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror
--prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
>
> Here are the backtraces from running in gdb:
>
> -------------------------- Normal backtrace -------------------------------------
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000001800010
> print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
> 1739            register unsigned char *p = SDATA (SYMBOL_NAME (obj));
> (gdb) bt
> #0  print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
> #1  0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
> #2  0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3027
> #3  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
> #4  0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
> #5  0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
> #6  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
> #7  0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
> #8  0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
> #9  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
> #10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
> #11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
> #12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130,
keys=4317002904) at callint.c:869
> #13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3030
> #14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>,
arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable,
due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
> #15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
> #16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>,
handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
> #17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
> #18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to
optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
> #19 0x00000001000a3586 in command_loop () at keyboard.c:1339
> #20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
> #21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
> #22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
> ---------------------------------------------------------------------------------
>
>
> ---------------------------- Full Backtrace -------------------------------------
> (gdb) bt full
> #0  print_object (obj=25165834, printcharfun=4320133130, escapeflag=1) at print.c:1739
>         end = <value temporarily unavailable, due to optimizations>
>         c = <value temporarily unavailable, due to optimizations>
>         i_byte = <value temporarily unavailable, due to optimizations>
>         confusing = <value temporarily unavailable, due to optimizations>
>         p = <value temporarily unavailable, due to optimizations>
>         size_byte = <value temporarily unavailable, due to optimizations>
>         buf = " <at> Ö¿_ÿ\000\000hf4ÿ\000\000Ö¿_ÿ\000\000è\003\000\000\000\000\000\000`Ö¿_\001\000\000"
> #1  0x00000001001300f3 in Fprin1_to_string (object=25165834, noescape=4320133130) at print.c:792
>         old = (struct buffer *) 0x101502ac8
>         start_point = -1
>         start_point_byte = -1
>         free_print_buffer = 1
>         old_point = -1
>         old_point_byte = -1
>         printcharfun = 4320133130
>         save_deactivate_mark = 4320133130
>         previous = <value temporarily unavailable, due to optimizations>
> #2  0x0000000100111431 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3027
>         fun = <value temporarily unavailable, due to optimizations>
>         original_fun = <value temporarily unavailable, due to optimizations>
>         funcar = <value temporarily unavailable, due to optimizations>
>         numargs = 1
>         val = <value temporarily unavailable, due to optimizations>
>         backtrace = {
>   next = 0x7fff5fbfd9a0, 
>   function = 0x7fff5fbfd800, 
>   args = 0x7fff5fbfd808, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0x7fff5fbfd750
>         i = <value temporarily unavailable, due to optimizations>
> #3  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
>         count = 10
>         op = <value temporarily unavailable, due to optimizations>
>         vectorp = (Lisp_Object *) 0x10039d398
>         stack = {
>   pc = 0x100469da7 "*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$", 
>   top = 0x7fff5fbfd808, 
>   bottom = 0x7fff5fbfd800, 
>   byte_string = 4298756969, 
>   byte_string_start = 0x100469da0
"Æ\030\031Ç\n!*\v\f`Æ\035\036\016\030\031\036\017È\n!É\n!\036\020$", 
>   constants = 4298757005, 
>   next = 0x7fff5fbfda60
> }
>         top = (Lisp_Object *) 0x7fff5fbfd800
>         result = <value temporarily unavailable, due to optimizations>
> #4  0x0000000100110d8c in funcall_lambda (fun=4298756909, nargs=1, arg_vector=0x7fff5fbfda18) at eval.c:3211
>         val = <value temporarily unavailable, due to optimizations>
>         syms_left = <value temporarily unavailable, due to optimizations>
>         next = <value temporarily unavailable, due to optimizations>
>         i = 1
>         optional = 0
>         rest = 0
> #5  0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
>         fun = <value temporarily unavailable, due to optimizations>
>         original_fun = 4324698170
>         funcar = <value temporarily unavailable, due to optimizations>
>         numargs = 1
>         val = <value temporarily unavailable, due to optimizations>
>         backtrace = {
>   next = 0x7fff5fbfdb80, 
>   function = 0x7fff5fbfda10, 
>   args = 0x7fff5fbfda18, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0x7fff5fbfda18
>         i = <value temporarily unavailable, due to optimizations>
> #6  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
>         count = 8
>         op = <value temporarily unavailable, due to optimizations>
>         vectorp = (Lisp_Object *) 0x10039d2d8
>         stack = {
>   pc = 0x100469e10 ")", 
>   top = 0x7fff5fbfda18, 
>   bottom = 0x7fff5fbfda10, 
>   byte_string = 4298756777, 
>   byte_string_start = 0x100469e00 "\b\b", 
>   constants = 4298756813, 
>   next = 0x7fff5fbfdc40
> }
>         top = (Lisp_Object *) 0x7fff5fbfda10
>         result = <value temporarily unavailable, due to optimizations>
> #7  0x0000000100110d8c in funcall_lambda (fun=4298756709, nargs=1, arg_vector=0x7fff5fbfdbf8) at eval.c:3211
>         val = <value temporarily unavailable, due to optimizations>
>         syms_left = <value temporarily unavailable, due to optimizations>
>         next = <value temporarily unavailable, due to optimizations>
>         i = 1
>         optional = 0
>         rest = 0
> #8  0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
>         fun = <value temporarily unavailable, due to optimizations>
>         original_fun = 4324684746
>         funcar = <value temporarily unavailable, due to optimizations>
>         numargs = 1
>         val = <value temporarily unavailable, due to optimizations>
>         backtrace = {
>   next = 0x7fff5fbfdd60, 
>   function = 0x7fff5fbfdbf0, 
>   args = 0x7fff5fbfdbf8, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0x7fff5fbfdbf8
>         i = <value temporarily unavailable, due to optimizations>
> #9  0x000000010014dc1e in Fbyte_code (bytestr=<value temporarily unavailable, due to
optimizations>, vector=<value temporarily unavailable, due to optimizations>, maxdepth=<value
temporarily unavailable, due to optimizations>) at bytecode.c:680
>         count = 6
>         op = <value temporarily unavailable, due to optimizations>
>         vectorp = (Lisp_Object *) 0x10039d4c8
>         stack = {
>   pc = 0x100469d73 "\v)B\034A\n=
>                                 \033", 
>   top = 0x7fff5fbfdbf8, 
>   bottom = 0x7fff5fbfdbf0, 
>   byte_string = 4298757273, 
>   byte_string_start = 0x100469d66 "\b
>                                      \b", 
>   constants = 4298757309, 
>   next = 0x0
> }
>         top = (Lisp_Object *) 0x7fff5fbfdbf0
>         result = <value temporarily unavailable, due to optimizations>
> #10 0x0000000100110d8c in funcall_lambda (fun=4298757197, nargs=1, arg_vector=0x7fff5fbfde28) at eval.c:3211
>         val = <value temporarily unavailable, due to optimizations>
>         syms_left = <value temporarily unavailable, due to optimizations>
>         next = <value temporarily unavailable, due to optimizations>
>         i = 1
>         optional = 0
>         rest = 0
> #11 0x00000001001111d2 in Ffuncall (nargs=2, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3081
>         fun = <value temporarily unavailable, due to optimizations>
>         original_fun = 4321163482
>         funcar = <value temporarily unavailable, due to optimizations>
>         numargs = 1
>         val = <value temporarily unavailable, due to optimizations>
>         backtrace = {
>   next = 0x7fff5fbfe000, 
>   function = 0x7fff5fbfde20, 
>   args = 0x7fff5fbfde28, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0x7fff5fbfde28
>         i = <value temporarily unavailable, due to optimizations>
> #12 0x000000010010dd6e in Fcall_interactively (function=4321163482, record_flag=4320133130,
keys=4317002904) at callint.c:869
>         val = <value temporarily unavailable, due to optimizations>
>         args = (Lisp_Object *) 0x7fff5fbfde20
>         visargs = (Lisp_Object *) 0x7fff5fbfde00
>         specs = 4320133130
>         filter_specs = <value temporarily unavailable, due to optimizations>
>         teml = 1
>         up_event = 4320133130
>         enable = 4320133130
>         speccount = 3
>         next_event = 2
>         prefix_arg = 4320133130
>         string = <value temporarily unavailable, due to optimizations>
>         tem = (unsigned char *) 0x10019edf0 ""
>         varies = (int *) 0x7fff5fbfdde0
>         i = 1
>         j = 1
>         foo = <value temporarily unavailable, due to optimizations>
>         prompt1 = '\0' <repeats 99 times>
>         arg_from_tty = 0
>         key_count = 2
>         record_then_fail = 0
>         save_this_command = 4321163482
>         save_last_command = 4320190778
>         save_this_original_command = 4321163482
>         save_real_this_command = 4321163482
> #13 0x000000010011141c in Ffuncall (nargs=4, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3030
>         fun = <value temporarily unavailable, due to optimizations>
>         original_fun = <value temporarily unavailable, due to optimizations>
>         funcar = <value temporarily unavailable, due to optimizations>
>         numargs = 3
>         val = <value temporarily unavailable, due to optimizations>
>         backtrace = {
>   next = 0x0, 
>   function = 0x7fff5fbfe070, 
>   args = 0x7fff5fbfe078, 
>   nargs = 3, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0x7fff5fbfe078
>         i = <value temporarily unavailable, due to optimizations>
> #14 0x00000001001115c6 in call3 (fn=<value temporarily unavailable, due to optimizations>,
arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable,
due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>) at eval.c:2850
>         ret_ungc_val = 4296201300
>         args = {4320305978, 4321163482, 4320133130, 4320133130}
> #15 0x00000001000ab987 in command_loop_1 () at keyboard.c:1904
>         cmd = <value temporarily unavailable, due to optimizations>
>         lose = <value temporarily unavailable, due to optimizations>
>         keybuf = {96, 20, 140734799798792, 4297574704, 4611686018427404288, 4611686018427389952,
4300458264, 4300480048, 140734799798736, 4296082611, 140734799798592, 140734799861322, 0, 3,
140734799798792, 0, 140734800084000, 0, 140734799798688, 140734799883712, 0, 140734800069792, 0,
140734799798672, 140734799798416, 0, 4300526552, 4320133130, 4321264154, -8680165209918493533}
>         i = <value temporarily unavailable, due to optimizations>
>         prev_modiff = 264
>         prev_buffer = (struct buffer *) 0x101502ac8
>         already_adjusted = 0
> #16 0x000000010010f8a7 in internal_condition_case (bfun=0x1000ab4c0 <command_loop_1>,
handlers=4320204218, hfun=0x1000a3770 <cmd_error>) at eval.c:1490
>         val = <value temporarily unavailable, due to optimizations>
>         c = {
>   tag = 4320133130, 
>   val = 4320133130, 
>   next = 0x7fff5fbfe360, 
>   gcpro = 0x0, 
>   jmp = {5512632, 1, 1606411040, 32767, 1606410720, 32767, 5512472, 1, 5489576, 1, 5490968, 1, 5512752, 1,
1112097, 1, 530, 0, 8096, 895, 1606411136, 32767, 668720, 1, 5513384, 1, 5513328, 1, 2, 0, 0, 0, 0, 0,
6886400, 1, 0}, 
>   backlist = 0x0, 
>   handlerlist = 0x0, 
>   lisp_eval_depth = 0, 
>   pdlcount = 2, 
>   poll_suppress_count = 0, 
>   interrupt_input_blocked = 0, 
>   byte_stack = 0x0
> }
>         h = {
>   handler = 4320204218, 
>   var = 4320133130, 
>   chosen_clause = 3418355679867659105, 
>   tag = 0x7fff5fbfe200, 
>   next = 0x0
> }
> #17 0x00000001000a2af7 in command_loop_2 () at keyboard.c:1360
>         val = 4296201300
> #18 0x000000010010f9b0 in internal_catch (tag=<value temporarily unavailable, due to
optimizations>, func=0x1000a2ac0 <command_loop_2>, arg=4320133130) at eval.c:1226
>         c = {
>   tag = 4320197482, 
>   val = 4320133130, 
>   next = 0x0, 
>   gcpro = 0x0, 
>   jmp = {5512632, 1, 1606411328, 32767, 1606411088, 32767, 5512768, 1, 5489576, 1, 5490968, 1, 5512752, 1,
1112479, 1, 534, 0, 8096, 895, 0, 0, 344, 0, 1606411264, 22, -2026609048, 32767, 0, 10, 25412515, 1,
25416952, 1, 25412512, 1, 22031048}, 
>   backlist = 0x0, 
>   handlerlist = 0x0, 
>   lisp_eval_depth = 0, 
>   pdlcount = 2, 
>   poll_suppress_count = 0, 
>   interrupt_input_blocked = 0, 
>   byte_stack = 0x0
> }
> #19 0x00000001000a3586 in command_loop () at keyboard.c:1339
> No locals.
> #20 0x00000001000a39ef in recursive_edit_1 () at keyboard.c:954
>         val = <value temporarily unavailable, due to optimizations>
> #21 0x00000001000a3b8f in Frecursive_edit () at keyboard.c:1016
>         count = <value temporarily unavailable, due to optimizations>
>         buffer = 4320133130
> #22 0x0000000100099147 in main (argc=2, argv=0x7fff5fbfe688) at emacs.c:1833
>         dummy = 0
>         stack_bottom_variable = -106 ''
>         do_initial_setlocale = <value temporarily unavailable, due to optimizations>
>         skip_args = 0
>         rlim = {
>   rlim_cur = 8720000, 
>   rlim_max = 67104768
> }
>         no_loadup = 0
>         junk = 0x0
>         dname_arg = 0x0
>         dname_arg2 = "\000\000\000\000\000\000\000\000æ¿_ÿ\000\000\000\000\000\000\002\000\000\000\000\000\000\000\001\000\000\000\000\000À_ÿ\000\000\000\000\000\000\000\000\000\000ø\005À_ÿ\000\000\t\000\000\000\t\000\000\000¨ç¿_ÿ\000\000`\aÀ_ÿ\000"
> ----------------------------------------------------------------------------------


Gmane