(no subject)
In article <[EMAIL PROTECTED]>, Dan Jacobson <[EMAIL PROTECTED]> writes: > One can "set coding system for the next command" to dired a mounted > CDROM directory in the proper charset (big5 in my case). But the > moment one types g to refresh the dired, the dired is back in the > default charset. > So emacs is very clever in detecting the coding systems of files, but > not very cooperative for directories full of filenames all in a > particular coding system. Detecting a coding system of filenames in a directory is difficult to implement, but it won't be that difficult to respect a coding system explicitly specified by C-x C-m c for dired. Perhaps, it can be done by locally setting file-name-coding-system of that buffer and making dired-revert to pay attention to that value. As I've never touch the code of dired.el, I'm not sure how such a change is safe. So, shall I try it in emacs-unicode-2 branch? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier <[EMAIL PROTECTED]> * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) "Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \"+\" is allowed to be a folder name corresponding to `mh-user-path'." (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp "^[+/]") (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
I rebuilt Emacs as Cheng Gao did and all worked fine afterwards. $ make clean $ make Harald ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
> This bug has been around (partially) for at least several weeks though - I > have been procrastinating re sending it off. > When visiting a file that is under Subversion control I get the following in > the *Messages* buffer and whilst the file is loaded into Emacs, it doesn't > become visible until I switch buffers to it: > Loading vc-svn...done > Loading vc...done > vc-do-command: Running svn...FAILED (status 1) Can you try to set debug-on-error (or maybe debug-on-signal) and get a backtrace? Also, what does "svn status -v" say when you run it on the command line. Supposingly, it should give some kind of error message and return a status code of 1. > But what does appear to be a "new" aspect of this bug is that when I modify > the buffer and attempt to save the file, I get the same error message and > the write does not happen i.e. Emacs will nolonger allow me to save the > file. (well, I think this is "new" - it is quite possible that in the past I > have plugged in the svn repository and made it available prior to attempting > to save the file - see below) Getting a backtrace for this case would be very helpful. For the other case I think I know where the problem lies, but for this one, I have no idea. > The issue that is exposing the "bug" here is that the Subversion repository > is on a USB Flash Disk and is not actually plugged into the PC when Emacs > access to the file is attempted. Of course, when the repository is > "available" then the problem does not arise, file access works as it should. But Emacs always uses "svn status -v" which tells SVN to work locally without contacting the repository. Isn't it a bug in SVN, then? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
Yes same for me.So I rebuilt Emacs and then it works. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
Hi all, I've just installed the latest security update for Tiger (2005-008) and now my CVS emacs segfaults at startup. Has anyone else experienced this? Is there a fix? After poking around in gdb, I suspect it's crashing when trying to execute: lisp/term/mac-win.el: (format "org.gnu.Emacs.% d.selection.PRIMARY" (emacs-pid It seems to get into sprintf and then dies. The crash log looks like: Command: Emacs Path:/Users/nem/lisp/work/emacs/mac/Emacs.app/Contents/MacOS/Emacs Parent: bash [18992] Version: 22.0.50 (1.1) PID:18993 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x100b5908 Thread 0 Crashed: 0 libSystem.B.dylib 0x9002532c sprintf$LDBL128 + 204 1 org.gnu.Emacs 0x000d8fb4 Fformat + 2116 (editfns.c:3608) 2 org.gnu.Emacs 0x000df820 Ffuncall + 1252 (eval.c:2928) 3 org.gnu.Emacs 0x0010f71c Fbyte_code + 2248 (bytecode.c:690) 4 org.gnu.Emacs 0x000de9d8 Feval + 956 (eval.c:2209) 5 org.gnu.Emacs 0x000fa888 readevalloop + 972 (lread.c:1400) 6 org.gnu.Emacs 0x000fb644 Fload + 2172 (lread.c:915) 7 org.gnu.Emacs 0x000df69c Ffuncall + 864 (eval.c:2874) 8 org.gnu.Emacs 0x0010f71c Fbyte_code + 2248 (bytecode.c:690) 9 org.gnu.Emacs 0x000de9d8 Feval + 956 (eval.c:2209) 10 org.gnu.Emacs 0x000e1454 Fcondition_case + 524 (eval.c:1400) 11 org.gnu.Emacs 0x00110104 Fbyte_code + 4784 (bytecode.c:868) 12 org.gnu.Emacs 0x000df1bc funcall_lambda + 808 (eval.c:3047) 13 org.gnu.Emacs 0x000df804 Ffuncall + 1224 (eval.c:2915) 14 org.gnu.Emacs 0x0010f71c Fbyte_code + 2248 (bytecode.c:690) 15 org.gnu.Emacs 0x000df1bc funcall_lambda + 808 (eval.c:3047) 16 org.gnu.Emacs 0x000df2d4 apply_lambda + 244 (eval.c:2972) 17 org.gnu.Emacs 0x000deadc Feval + 1216 (eval.c:2245) 18 org.gnu.Emacs 0x000dd538 internal_condition_case + 300 (eval.c:1453) 19 org.gnu.Emacs 0x00074530 top_level_1 + 84 (keyboard.c:1335) 20 org.gnu.Emacs 0x000dd3e4 internal_catch + 232 (eval.c:1211) 21 org.gnu.Emacs 0x000741b0 command_loop + 124 (keyboard.c:1297) 22 org.gnu.Emacs 0x000742d0 recursive_edit_1 + 168 (keyboard.c:991) 23 org.gnu.Emacs 0x0007441c Frecursive_edit + 212 (keyboard.c:1053) 24 org.gnu.Emacs 0x00073e70 main + 3932 (emacs.c:1785) 25 org.gnu.Emacs 0x23a8 _start + 344 (crt.c:272) 26 org.gnu.Emacs 0x224c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x9002532c srr1: 0x0200f930 vrsave: 0x cr: 0x4484242c xer: 0x0004 lr: 0x90025320 ctr: 0x r0: 0xbfffd620 r1: 0xbfffd460 r2: 0x100b8778 r3: 0xbfffd55c r4: 0x007c r5: 0x0010 r6: 0x7374656d r7: 0x r8: 0x0003 r9: 0xbfffd5dc r10: 0x0007 r11: 0xa00063c0 r12: 0x9011dec0 r13: 0xbfffd740 r14: 0x0002 r15: 0xbfffd6c0 r16: 0x0001 r17: 0x0482da0a r18: 0x r19: 0xbfffd8c0 r20: 0xbfffd640 r21: 0x0482d9e8 r22: 0x000e r23: 0x r24: 0xbfffd8c4 r25: 0x0482d9f6 r26: 0xbfffd64e r27: 0x0004 r28: 0x0482d9f8 r29: 0xbfffd49c r30: 0x r31: 0x000d8778 Binary Images Description: 0x1000 - 0x16bfff org.gnu.Emacs 22.0.50 (1.1) /Users/nem/lisp/work/emacs/mac/Emacs.app/Contents/MacOS/Emacs 0x54d000 - 0x578fff libncurses.5.dylib /sw/lib/ncurses/libncurses.5.dylib 0x8fe0 - 0x8fe51fff dyld 43.1/usr/lib/dyld 0x9000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x90204000 - 0x90257fff com.apple.CoreText 1.0.0 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x90284000 - 0x90335fff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x90364000 - 0x9069dfff com.apple.CoreGraphics 1.256.14 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x90728000 - 0x90801fff com.apple.CoreFoundation 6.4.3 (368.12) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x9084a000 - 0x9084afff com.apple.CoreServices 10.4 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x9084c000 - 0x9094efff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x909a8000 - 0x90a2cfff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90a560
Re: (no subject)
> This bug report pertains to a build of Emacs from the CVS nightly backup > repository date stamped with 20-Sep-2005 7:36. The version is "GNU Emacs > 22.0.50.1 (i386-mingw-nt5.0.2195) of 2005-09-16 on BURROWYE" > This bug has been around (partially) for at least several weeks though - I > have been procrastinating re sending it off. > When visiting a file that is under Subversion control I get the following in > the *Messages* buffer and whilst the file is loaded into Emacs, it doesn't > become visible until I switch buffers to it: > Loading vc-svn...done > Loading vc...done > vc-do-command: Running svn...FAILED (status 1) Hmm... we have a bug indeed. I'll take a look at it. Thanks, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
This bug report pertains to a build of Emacs from the CVS nightly backup repository date stamped with 20-Sep-2005 7:36. The version is "GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2005-09-16 on BURROWYE" This bug has been around (partially) for at least several weeks though - I have been procrastinating re sending it off. When visiting a file that is under Subversion control I get the following in the *Messages* buffer and whilst the file is loaded into Emacs, it doesn't become visible until I switch buffers to it: Loading vc-svn...done Loading vc...done vc-do-command: Running svn...FAILED (status 1) But what does appear to be a "new" aspect of this bug is that when I modify the buffer and attempt to save the file, I get the same error message and the write does not happen i.e. Emacs will nolonger allow me to save the file. (well, I think this is "new" - it is quite possible that in the past I have plugged in the svn repository and made it available prior to attempting to save the file - see below) The issue that is exposing the "bug" here is that the Subversion repository is on a USB Flash Disk and is not actually plugged into the PC when Emacs access to the file is attempted. Of course, when the repository is "available" then the problem does not arise, file access works as it should. I consider this a "bug" because I move my work between home and office, so rather than keep multiple copies of the repository, I keep the repository on a USB Flash Disk - Emacs shouldn't stop me from visiting and changing the file just because the repository isn't available at the time of reading/writing. Regards, Peter Peter Milliken Software Engineer ResMed Phone: +61 2 9886-5059 Fax: +61 2 9878-5564 Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in,the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 9886 5000 Sydney, Australia. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
Since find-func.el has been a part of Emacs for a long time now, can the entry just be removed please? Ok, I did. I wonder what else in that file should be deleted. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
Quantier IP Ranger 320 SIP Phone 「功能特色」 * 支持同时两线来电,不错失任何一笔电话,做到一机多号 * 2个RJ-45以太网络端口（可同时接网络与计算机） * 支持话筒、内置双向免提听筒与接耳机模式 * 电话处理功能包括：保留、静音、来电显示、来电等待、转接、拒绝来电、重拨、来电回复与勿干扰 * 通话历史纪录（已接来电、未接来电与已拨出号码，各10笔） * 指定转接（忙线、无人应答、勿干扰与出差模式） * 三方通话,可扩充多方会谈,实现多点高质量会议,操作简便 * HTTP可视化设定,引导式菜单设定（支持Telnet） * 可存储500笔地址电话簿 * 个人化设定：速拨键设定、屏蔽来电（20组）、自动重拨、是否自动跟随转接、8组可设定式个人化功能键 * 可设定时区、日光节约时间并自动与网络时间校准 * 最多可同时支持两组不同的ISP号码、无ISP时可自动定位或以点对点直接通讯 * 支持NAT与防火墙穿透 * 话机可设定密码锁定,增强安全性 * 支持自动在线更新升级 * 支持PPPoE和简易路由 * 可经由网络供电(Power over LAN) (见量生产) 「质量一流」 * 硬件及芯片使用高质量进口元器件:Agere * 高度的适应能力和稳定性 * 高精度磨砂外壳,抗压,抗震,耐温,耐湿 * 有专门的技术支持技能机构和研发团队,可提供完善的售后服务及技术支持 「外观精美」 * 采用欧美流线形风格设计,样式精美大方(白色/深蓝两种颜色) * Smart数位按键 「产品规格」 * Flash Memory:2Mbytes * SDRAM:16Mbytes * 2x16 单色LCD显示 * 2个RJ-45以太网络端口（可同时接网络与计算机） * Power Adapter:AC:100~240V,47~63Hz DC:9V,1.1A * 语音处理： * G.711 (A-law与Mu-law)、G.723.1A、G.729AB * Voice Activity Detection and Comfort Noise Generation * Acoustic Echo Cancellation * CNG(CNG for G.711 as well) * DHCP 或固定式IP。 * 支持SIP 2.0 (RFC3261与RFC2543) * 支持RTP/RTCP(RFC1889/RFC1890) * 支持SDP（RFC2327）与通话能力协商（RFC3264） * 支持RTP/RTCP语音传输，并支持IP ToS与 802.1Q优先级语音传送 * 支持RFC2833-Out-band DTMF over RTP与In-band DTMF over RTP * 支持自动定位SIP 服务器（RFC3263、RFC2782） * 支持电话号码与SIP AoR的 ENUM解析（RFC2916） * 支持以TFTP设定话机与软件更新 * 支持Telnet远端设定 * 支持SNMPv2网络管理:MIB2(RFC1213) * SNTP校准网络时间 * 支持固定的NAT设定或以STUN（RFC3489）动态识别并通过NAT * 墙壁挂孔 * 大小规格:228mm×201mm×115mm Quantier Communication Inc. www.QuantierTech.com ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
本公司创办于1995年，现己发展家族式箱包行业,有箱包各种配件及成品(价格便宜) 现本公司这里是生产各种系列旅行箱、拉杆箱、公文箱、拖拉包和产品的设计、开发的专业化企业。我公司享有独厚的便利交通条件，离上海虹桥机场仅50公里，离上海浦东国际机场仅20公里。 从创办以来企业在技术和生产规模上都有了很大的发展。目前我们已拥有工业平缝机、双针机、高头机、EVA压模机、铆钉机、商标装钉机等数拾台先进水平的设备。在我公司100余名 员工和各层领导的努力下，我们以提高产品档次，保证产品质量，完善售后服务为已任。以人为本，以市场为导向，以技术促发展，以严格有序的管理求效益，自强、自立、自信，是本公司的精神理念。4000多平方米的厂房，3条先进水平的流水生产线，我们的实力告诉我们，我们可以作到真诚到永远。我公司的产品远销欧州、美州和东南亚地区。 欢迎垂询，来访及洽谈合作事宜。 公司名称：上海赤豹箱包有限公司 公司地址：上海市奉贤区奉城镇陈桥村261号 联 系 人：刘恭捷 联系电话：021-57514038 13918268466 传真：021-57513362 http://www.sh-chibao.com E-mail: [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
调情药剂令你轻松自然http://www.diaochan.net/n274c36.aspx 完美的性爱由舌头开始 http://www.diaochan.net/n273c36.aspx 做个调情情高手http://www.diaochan.net/n272c36.aspx 一吻定乾坤http://www.diaochan.net/n271c36.aspx 性爱技巧：把男人压在身下 http://www.diaochan.net/n270c36.aspx 善于把握女子性高潮周期 http://www.diaochan.net/n266c36.aspx ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
From: Jens Petersen <[EMAIL PROTECTED]> To: emacs-pretest-bug@gnu.org Subject: MORE.STUFF find-func link I just noticed that find-func.el is listed in MORE.STUFF with an broken url at a place I was working at about 8 years ago. Since find-func.el has been a part of Emacs for a long time now, can the entry just be removed please? Thanks, Jens ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
Am 07.06.2005 um 14:24 schrieb Richard Stallman: With C-x d I opened a directory with TeX sources etc. I sorted by time and saw a missfont.log file. I opened it with v, read its contents, At this point, if you switch back to the dired buffer, has its font changed already? Instantly When Aquamacs has launched it uses its default: Fontset: -*-lucida grande*-medium-r-normal--14-*-*-*-*-*-fontset-lucida14 When I open the dired buffer, now a new fontset is chosen: Fontset: -apple-monaco*-medium-r-normal--12-*-*-*-*-*-fontset-monaco12 And when I now type v or e on the TeX file it opens in Fontset: -apple-monaco*-medium-r-normal--12-*-*-*-*-*-fontset-monaco12 Then it happened, when I returned to the dired buffer, that it used the default lucida14 fontset. Aquamacs has some other peculiarities too. For example I saved the fontset descriptions into files. Since the buffers contained non-ASCII characters, a *Warning* buffer opened in its own new frame -- but in the minibuffer of the other frame, that one containing the fontset description, I was prompted to select a coding system. Same happens when you try to let Aquamacs complete for example the file name into which to save the fontset description. A new frame opens or is re-used completely for the *Completions* buffer, while the minibuffer in the other frame ... I think you know already! Using Aquamacs you get easily confused ... Can you provide us with a complete self-contained test case? I think you actually don't need to care that much about error descriptions on Aquamacs, that are very specific to it. David Reitter mentioned that we users should use the 'Send Bug Report...' menu item. I tried it for the first time and he corrected the issue and correct the Aquamacs distribution too. If he would make the *Warning* and *Help* and *Completions* buffers appear in the same frame, not taking away the prompt from the minibuffer ... -- Greetings Pete If you're not confused, you're not paying attention ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (no subject)
With C-x d I opened a directory with TeX sources etc. I sorted by time and saw a missfont.log file. I opened it with v, read its contents, At this point, if you switch back to the dired buffer, has its font changed already? Can you provide us with a complete self-contained test case? Please read the Bugs section in the Emacs manual, which provides guidelines on how to write a bug report to give us the necessary information so we can fix the bug. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired / view buffer / wrong theme (was: no subject)
On 6 Jun 2005, at 16:19, Peter Dyballa wrote: With C-x d I opened a directory with TeX sources etc. I sorted by time and saw a missfont.log file. I opened it with v, read its contents, and closed it with q. Now the dired buffer is not anymore held in a monospaced font, but in the Lucida Grande default proportional font ... Good, that has been fixed now; the frame theme is updated to reflect the buffer-specific theme now. (This has been bound to menu-bar-update-hook.) Thanks for reporting this. [ This was specific to the Aquamacs distribution. ] Dave ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please give this e-mail an appropriate subject line! Please describe exactly what actions triggered the bug and the precise symptoms of the bug: With C-x d I opened a directory with TeX sources etc. I sorted by time and saw a missfont.log file. I opened it with v, read its contents, and closed it with q. Now the dired buffer is not anymore held in a monospaced font, but in the Lucida Grande default proportional font ... In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0) of 2005-06-04 on madonna - Aquamacs Distribution 0.9.2 beta-7 Distributor `Apple Computers' version (10 3 9) . configured using `configure '--without-x' '--prefix=/usr/local'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Dired by date Minor modes in effect: display-time-mode: t show-paren-mode: t cua-mode: t mouse-sel-mode: t aquamacs-tool-bar-mode: t smart-frame-positioning-mode: t recentf-mode: t encoded-kbd-mode: t osx-key-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol -- Mit friedvollen Grüßen Pete "One person with a belief is a social power equal to ninety-nine who have only interests." - John Stuart Mill ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
I'm using Aquamacs 0.9.2b5 on a new G4 PowerBook running 10.4.1. I find that Option-u doesn't generate a M-u key sequence and therefore doesn't run uppercase-word. I say it doesn't generate a key sequence because if I do C-h c and then type Option-u at the prompt, nothing happens, it's as if I didn't type anything. Works fine for other key combinations (e.g., Option-c). Also I find the new two finger scrolling on the trackpad doesn't do anything. Both of these fail in the same way with the latest Carbon Emacs from http://home.att.ne.jp/alpha/z123/emacs-mac-e.html I'm sure two finger scrolling worked on Panther with earlier builds and I think Option-u worked as well, but am not 100% sure. Howard In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.1.0) of 2005-06-01 on madonna - Aquamacs Distribution 0.9.2 beta-5 Distributor `Apple Computers' version (10 4 1) . configured using `configure '--without-x' '--prefix=/usr/local'' 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: nil locale-coding-system: iso-latin-1 default-enable-multibyte-characters: nil Major mode: Emacs-Lisp Minor modes in effect: eldoc-mode: t outline-minor-mode: t iswitchb-mode: t which-function-mode: t msb-mode: t show-paren-mode: t delete-selection-mode: t pc-selection-mode: t cua-mode: t aquamacs-tool-bar-mode: t smart-frame-positioning-mode: t recentf-mode: t encoded-kbd-mode: t osx-key-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol view-mode: t Recent input: C-x C-f d o c SPC f i SPC c r a SPC SPC C-f C-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f H-u H-a C-h c H-c C-h k H-c C-z k C-x k C-a C-h c C-h f t o g g l e - o n Recent messages: For information about the GNU Project and its goals, type C-h C-p. Mark set [2 times] H-c runs the command cua-copy-region runs the command toggle-oneonone Note: file is write protected Loading outline...done Loading eldoc...done View mode: type C-h for help, h for commands, q to quit. Loading font-lock...done Loading jit-lock...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
