I emerged emacs, but when I run it it SEGVs. I did: # emerge sync # emerge --pretend system # emerge --pretend world # etc-update (fine, nothing to sync, build or config) # emerge search emacs * app-editors/emacs Latest version Available: 21.2-r1 Latest version Installed: [ Not Installed ] ... # emerge emacs ... >>> app-editors/emacs-21.2-r1 merged. When I run it I get: # emacs Fatal error (11).Segmentation fault If I strace it as root, it gets to: ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 access("/root/.terminfo/x/xterm", R_OK) = -1 ENOENT (No such file or directory) --- SIGSEGV (Segmentation fault) --- As a non-root user it's slightly different: ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, 0x5413, {ws_row=40, ws_col=134, ws_xpixel=0, ws_ypixel=0}) = 0 --- SIGSEGV (Segmentation fault) --- Running from gdb I get: Program received signal SIGSEGV, Segmentation fault. 0x404d7dcf in chunk_alloc () from /lib/libc.so.6 (gdb) where #0 0x404d7dcf in chunk_alloc () from /lib/libc.so.6 #1 0x404d7c24 in malloc () from /lib/libc.so.6 #2 0x0812f7a2 in re_set_registers () #3 0x404d7b71 in malloc () from /lib/libc.so.6 #4 0x0812f276 in re_set_registers () #5 0x08051b07 in XMapRaised () #6 0x0805896b in XMapRaised () #7 0x08057adb in XMapRaised () #8 0x080e2121 in XMapRaised () #9 0x4047e3c1 in __libc_start_main () from /lib/libc.so.6 My gcc is 2.95.3, my /etc/make.conf has: USE="apm arts avi berkdb crypt cups encode gdbm gif gphoto2 gpm gtk imap imlib ipv6 java jpeg kde libg++ libwww matrox mikmod mmx motif mpeg ncurses nls oggvorbis opengl pam pdflib perl png python qt qtmt quicktime readline sdl slang spell ssl sse svga tcpd truetype X xml xml2 xmms xv" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe" CXXFLAGS="-march=i686 -O3 -pipe" I had emacs running last week, but after some package cleanup and emerging of various packages (latest security related fixes, latest qt and remerging of kdelibs, and a round of fixing after I carelessly unmerged an old libpng) it no longer works. I found the SNDCTL_TMR_TIMEBASE from the strace in soundcard.h, so figured this maybe related to the soundcard. KDE happily plays mp3s through the card (after adding myself to the audio group), but I did see something strange in dmesg: emu10k1: EMU10K1 rev 7 model 0x8064 found, IO at 0xa400-0xa41f, IRQ 11 ac97_codec: AC97 Audio codec, id: 0x454d:0x4328 (Unknown) emu10k1: SBLive! 5.1 card detected devfs_register(1): could not append to parent, err: -17 devfs_register(a1): could not append to parent, err: -17 spurious 8259A interrupt: IRQ7. but that may well be completely unrelated. Suggestions?
Bug reproduced with:# emerge -e system && emerge -e emacs# emacsFatal error (11).Segmentation fault (core dumped)make.conf is the default, unaltered make.conf.I can confirm that emacs worked previously. I have copied a binary emacs from another distribution and it worked (when it got access to libXaw3d.so.7). So it seems the libraries that emacs.binary.copy uses is OK:The difference in libraries is:emacs.binary.copy: libXaw3d.so.7 => /lib/libXaw3d.so.7 (0x4001e000)emacs: libXm.so.2 => /usr/X11R6/lib/libXm.so.2 (0x40017000) (openmotif: last change 15 Jul 2002) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401d4000) (xfree: last change 29 Jul 2002) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40277000) (tiff-3.5.7-r1: last change 21 Mar 2002) libungif.so.4 => /usr/lib/libungif.so.4 (0x40336000) (libungif-4.1.0: last change 21 Mar 2002)My guess is that xfree is the culprit.I will try: emerge xfree-4.2.0-r11.ebuild && emerge emacsand see if that helps.I have just tried:emerge emacs-21.2.ebuildemerge emacs-21.1-r4.ebuildBoth dump core.# ldd /usr/bin/emacs libXm.so.2 => /usr/X11R6/lib/libXm.so.2 (0x40017000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x401c5000) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401d4000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x401dc000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401f2000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4023f000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40249000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40261000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40277000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402bc000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x402db000) libz.so.1 => /usr/lib/libz.so.1 (0x40308000) libm.so.6 => /lib/libm.so.6 (0x40315000) libungif.so.4 => /usr/lib/libungif.so.4 (0x40336000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4033e000) libncurses.so.5 => /lib/libncurses.so.5 (0x403fd000) libc.so.6 => /lib/libc.so.6 (0x40442000) libdl.so.2 => /lib/libdl.so.2 (0x4056a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)# ldd /root/emacs.binary.copy.from.other.distribution libXaw3d.so.7 => /lib/libXaw3d.so.7 (0x4001e000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40078000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4008e000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400db000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400e5000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400fd000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4010b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4012a000) libz.so.1 => /usr/lib/libz.so.1 (0x40158000) libm.so.6 => /lib/libm.so.6 (0x40165000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40186000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40195000) libncurses.so.5 => /lib/libncurses.so.5 (0x40254000) libc.so.6 => /lib/libc.so.6 (0x40298000) libdl.so.2 => /lib/libdl.so.2 (0x403c0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(Who fucked my layout up? I try again) Bug reproduced with: # emerge -e system && emerge -e emacs # emacs Fatal error (11).Segmentation fault (core dumped) make.conf is the default, unaltered make.conf. I can confirm that emacs worked previously. I have copied a binary emacs from another distribution and it worked (when it got access to libXaw3d.so.7). So it seems the libraries that emacs.binary.copy uses is OK: The difference in libraries is: emacs.binary.copy: libXaw3d.so.7 => /lib/libXaw3d.so.7 (0x4001e000) emacs: libXm.so.2 => /usr/X11R6/lib/libXm.so.2 (0x40017000) (openmotif: last change 15 Jul 2002) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401d4000) (xfree: last change 29 Jul 2002) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40277000) (tiff-3.5.7-r1: last change 21 Mar 2002) libungif.so.4 => /usr/lib/libungif.so.4 (0x40336000) (libungif-4.1.0: last change 21 Mar 2002) My guess is that xfree is the culprit. I will try: emerge xfree-4.2.0-r11.ebuild && emerge emacs and see if that helps. I have just tried: emerge emacs-21.2.ebuild emerge emacs-21.1-r4.ebuild Both dump core. # ldd /usr/bin/emacs libXm.so.2 => /usr/X11R6/lib/libXm.so.2 (0x40017000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x401c5000) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401d4000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x401dc000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401f2000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4023f000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40249000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40261000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40277000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402bc000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x402db000) libz.so.1 => /usr/lib/libz.so.1 (0x40308000) libm.so.6 => /lib/libm.so.6 (0x40315000) libungif.so.4 => /usr/lib/libungif.so.4 (0x40336000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4033e000) libncurses.so.5 => /lib/libncurses.so.5 (0x403fd000) libc.so.6 => /lib/libc.so.6 (0x40442000) libdl.so.2 => /lib/libdl.so.2 (0x4056a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) # ldd /root/emacs.binary.copy.from.other.distribution libXaw3d.so.7 => /lib/libXaw3d.so.7 (0x4001e000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40078000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4008e000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400db000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400e5000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400fd000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4010b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4012a000) libz.so.1 => /usr/lib/libz.so.1 (0x40158000) libm.so.6 => /lib/libm.so.6 (0x40165000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40186000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40195000) libncurses.so.5 => /lib/libncurses.so.5 (0x40254000) libc.so.6 => /lib/libc.so.6 (0x40298000) libdl.so.2 => /lib/libdl.so.2 (0x403c0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Work-around: emerge xfree-4.2.0-r11.ebuild It seems that the new xfree-port is indeed the culprit.
Sorry: I am mistaking. Downgrading xfree did not help.(It was just bash that was friendly and gave me the binary-copy instead.)
I had the same problem and solved it by recompiling it with -O2 (instead of -O3).
I tried using -O2 instead of -O3, but still get SEGV. I also emerged with USE="-X" and ldd gives #ldd /usr/bin/emacs libncurses.so.5 => /lib/libncurses.so.5 (0x15579000) libm.so.6 => /lib/libm.so.6 (0x155c0000) libc.so.6 => /lib/libc.so.6 (0x155e2000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x15556000) and it still crashes the same way. So it doesn't seem like an X related error either.
Martijn wrote:> I had emacs running last week, but after some package cleanup and emerging of various packages (latest security related fixes, latest qt and remerging of kdelibs, and a round of fixing after I carelessly unmerged an old libpng) it no longer works. Does Gentoo keep a history of what was emerged when (like Sorcery Linux does)? It sure would come in handy here as you would be able to narrow the search down to a few recently upgraded packages.
I don't know if there's any built-in way of finding out what was merged when, but what I tend to do is look in my distfiles directory and do #ls -l --sort=time --time=ctime | more total 189532 -rw-r--r-- 1 root root 4004289 Jul 31 13:38 galeon-1.2.5.tar.gz -rw-r--r-- 1 root root 152755 Jul 31 13:32 prozilla-1.3.6.tar.gz -rw-r--r-- 1 root root 20321444 Jul 31 13:13 emacs-21.1.tar.gz -rw-r--r-- 1 root root 398273 Jul 31 13:02 strace_4.4-1.tar.gz -rw-r--r-- 1 root root 1503169 Jul 31 12:41 groff-1.17.2.tar.gz -rw-r--r-- 1 root root 20288222 Jul 30 23:08 emacs-21.2.tar.gz -rw-r--r-- 1 root root 682065 Jul 30 21:40 ggv-1.99.9.tar.gz -rw-r--r-- 1 root root 874549 Jul 30 21:20 Linux-PAM-0.75.tar.gz -rw-r--r-- 1 root root 582702 Jul 30 11:55 man-pages-1.52.tar.bz2 -rw-r--r-- 1 root root 193480 Jul 30 11:54 man-1.5k.tar.gz -rw-r--r-- 1 root root 5983695 Jul 30 11:32 perl-5.6.1.tar.gz -rw-r--r-- 1 root root 1447807 Jul 30 11:28 groff-1.16.1.tar.gz -rw-r--r-- 1 root root 2085238 Jul 28 11:26 db-3.2.9.tar.gz -rw-r--r-- 1 root root 112214 Jul 26 19:00 which-2.14.tar.gz -rw-r--r-- 1 root root 1822852 Jul 26 18:55 sylpheed-0.8.1.tar.bz2 -rw-r--r-- 1 root root 604834 Jul 26 18:51 gpgme-0.3.6.tar.gz which at least gives me an idea of what's been downloaded and merged recently. I think that my emacs worked up until July 30th. But I don't know what I merged on that day or after that could have broken it.
I have just tried the following: 1. Emacs works 2. I run emerge rsync 3. Emacs works 4. I update a few packages manually 5. Emacs works 6. I update emacs 7. Emacs dumps core 8. I downgrade to the previous version of emacs 9. Emacs dumps core I am more confused than before. I still use default make.conf
I have now tried using: CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=i686 -O2 -pipe" CXXFLAGS="-mcpu=i686 -O2 -pipe" for emerge emacs. emacs still dumps core on startup. I have now tried: CC=gcc-3.1 CXX=g++-3.1 GCJ=gcj-3.1 for emerge emacs emacs still dumps core on startup. So -O2 is definitely not enough.
I tried "-O2", "-O2 -fno-unroll-loops -no-unroll-all-loops" (surely the same, but I wanted to be sure, given Spider's msg on gentoo-dev), and "-O", still crashes. I tried older ebuild files for ncurses along with USE-X, no joy. With "USE=-X" and "-O" gdb says: Program received signal SIGSEGV, Segmentation fault. 0x400ffdcf in chunk_alloc () from /lib/libc.so.6 (gdb) where #0 0x400ffdcf in chunk_alloc () from /lib/libc.so.6 #1 0x400ffc24 in malloc () from /lib/libc.so.6 #2 0x080d5c72 in re_compile_pattern () #3 0x400ffb71 in malloc () from /lib/libc.so.6 #4 0x080d58a6 in re_compile_pattern () #5 0x080d763a in re_compile_pattern () #6 0x080d5a4d in re_compile_pattern () #7 0x080d6da8 in re_compile_pattern () #8 0x080d6e19 in re_compile_pattern () #9 0x080d6f90 in re_compile_pattern () #10 0x0808be46 in strcpy () #11 0x080e98b5 in re_compile_pattern () #12 0x0808bc96 in strcpy () #13 0x0808d482 in strcpy () #14 0x080526be in strcpy () #15 0x08094cfb in abort () #16 0x400a63c1 in __libc_start_main () from /lib/libc.so.6 which I don't understand
I've determined that removing the "--host" parameter from ./configure stops the resulting emacs crashing. So I can do: emerge unmerge emacs b=/usr/portage/app-editors/emacs/emacs-21.2-r1.ebuild ebuild $b clean ebuild $b compile cd /var/tmp/portage/emacs-21.2-r1/work/emacs-21.2 ./configure -prefix=/usr --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info \ --with-x --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x-toolkit=motif make ebuild $b merge and have a working install, including X, without make.conf changes. Note that for your USE variables the ./configure arguments may differ; do a `head config.status` after the "ebuild compile" to see what portage gave you. I hope others will have time to figure out what the root cause is here; some gcc problem?
I can confirm that Martijns solution works.I cannot say what the root of the problem is, but I have just tried a rebuild of everything:emerge -u -e worldAnd it stops at gmp that complains on problems with CPU-VENDOR-OS:configure: error: --target is not appropriate for GMPUse --build=CPU-VENDOR-OS if you need to specify your CPU and/or systemexplicitly. Use --host if cross-compiling (see "Installing GMP" in themanual for more on this).so emacs is not the only one where something spooky is going on with --host.
Created attachment 2742 [details, diff] Patch for emacs-21.2-r1.ebuild
Yup, worked for me too. Good call, Martijn. What made you suspect that removing --host would fix it?
In response to Qian Wang: I manually built emacs from the tarball, with (./configure && make && src/emacs), which worked fine, so I knew it was an ebuild configuration issue rather than an application or library bug. So then I reduced the complexity of both builds by using "configure --without-x" on my build, and USE="-x -motif" on the ebuild, and confirmed that my build still worked, and the ebuild still didn't. Then I ran "ebuild $b unpack" rather than "emerge", so I could see what ebuild produced. In particular I compared config.cache, config.status and src/config.h against mine. The main difference was the presence of the --host argument in the ebuild. I knew from the make.conf that the --host is an optimisation flag, and given that some people reported that recompiling with -O2 worked for them, I figured that might tickle some bug in the compiler. So I took the configure command from config.status, removed the --host, ran it, did "make", and tested src/emacs, which now worked. Then it took me quite a while to get ebuild to actually do the merge; because the method in the FAQ didn't work (see separately filed bug 5898), but since portage is written in Python and you have source, I was able to find a way around it. And in this whole process there were countless other compiles, file inspections, strace'ing, gdb stack traces, blind alleys, pulling out of hair, fruitless begging on #gentoo, etc, but I shan't bore you with all that. Glad it worked for you too, and I hope someone will be able to get to the bottom of this. :-)
what compiler are you people using and please post your cflags. the problem may not be what you think it is.
I use the default gcc and the default make.conf. It is probably # gcc --version 2.95.3
CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe" CXXFLAGS="-march=i686 -O3 -pipe" Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release)
>>> Regenerating /etc/ld.so.cache... >>> app-editors/emacs-21.2-r1 merged. * Regenerating GNU info directory index... * Processed 85 info files. gentoo root # emacs Fatal error (11).Segmentation fault gentoo root # gdb emacs GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)... (gdb) r Starting program: /usr/bin/emacs (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x405006fa in chunk_alloc () from /lib/libc.so.6 (gdb) where #0 0x405006fa in chunk_alloc () from /lib/libc.so.6 #1 0x40500532 in malloc () from /lib/libc.so.6 #2 0x08148fcc in re_compile_pattern () #3 0x40500495 in malloc () from /lib/libc.so.6 #4 0x40475166 in _nc_home_terminfo () from /lib/libncurses.so.5 #5 0x4047bd72 in _nc_read_entry () from /lib/libncurses.so.5 #6 0x40476a9e in grab_entry () from /lib/libncurses.so.5 #7 0x40476484 in setupterm () from /lib/libncurses.so.5 #8 0x40476b4e in tgetent () from /lib/libncurses.so.5 #9 0x080a536c in XMapRaised () #10 0x08055224 in XMapRaised () #11 0x080f1ab9 in XMapRaised () #12 0x404a9142 in __libc_start_main () from /lib/libc.so.6 gentoo root # grep ^C /etc/make.conf CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CXXFLAGS="-march=pentium3 -O3 -pipe" Then, # FEATURES=-sandbox emerge emacs >>> app-editors/emacs-21.2-r1 merged. * Regenerating GNU info directory index... * Processed 85 info files. gentoo root # emacs File Edit Options Buffers Tools Help Welcome to GNU Emacs, one component of a Linux-based GNU system. ... Ole Tange's run emacs while emerging something else is the hint. It's possible this is a another strange interaction of the sandbox (xemacs had this problem a while ago) So, i'll fix this (hopeully in CVS in a moment) and provide a version bump since it's affectes everyone. Thanks for ther bug report everyone. Matt
The problem is how the sandbox and glibc interact with the compiler. If sandboxing is enabled during the ebuild, then the resulting binary will segv. For months, sandbox has been explicitly disabled so that emerge actually produces emacs and xemacs binaries which don't segv while an alternate solution is researched. Lately, the mechanism used to disable the sandbox (DISABLE_SANDBOX=1) was removed from portage. This act left emacs and xemacs broken again. Bug #5950 should restore the sandbox diable mechanism once resolved. In the meantime, the work around is this: # FEATURES='-sandbox' emerge emacs
*** Bug 5869 has been marked as a duplicate of this bug. ***
*** Bug 6040 has been marked as a duplicate of this bug. ***
hi... please test emerge rsync emerge unmerge emacs emerge emacs also test emerge rsync emerge unmerge emacs emerge emacs (then test the binary, then) emerge emacs (then test the binary, again) and let me know if you still get a seg faulting emacs binary. also, make sure you're using the latest portage (2.0.25). testing is totally appreciated for this change -- the more people the better! Matt
> emerge rsync > emerge unmerge emacs > emerge emacs > (then test the binary, then) > emerge emacs > (then test the binary, again) Tested. It works.
thanks! more reports to come in soon i hope Ole, btw i see you in bugzilla a lot, do you hang out on irc much?
IRC: No. I do have a client open now and then. The reason you see me in bugzilla is that I bugreport aggressively: If I as a seasoned Linux user cannot get something to work, then newbies will be totally lost. Maybe we should continue via private email?
> emerge rsync > emerge unmerge emacs > emerge emacs > (then test the binary, then) > emerge emacs > (then test the binary, again) Works for me. Thanks.
you need to update your portage, i did it and it worked
Matthew: works for me.
Worked for me as well. Thanks for the fix, Matt.
thanks for the testing everyone! I will close this and the related xemacs and xemacs-gtk segv bugs. I'll create a new bug shortly describing what we know about the sandbox/glibc/gcc(?) problem which causes our beloved editor to behave this way. Matt
after unmerging emacs and remerging it, it works. thanks!
