Re: mail-mode doesn't encode Subject
I note message-mode makes Subject: =?utf-8?B?5Y+w5Lit5biC6Ieq55Sx6Lev6YKj6bq85aSn?= whereas mail-mode just puts the raw utf-8 there. Isn't that improper or something? Maybe it depends on whose standard you are following. I find that encoding a super pain in the neck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-mode doesn't encode Subject
Dan Jacobson wrote: I note message-mode makes Subject: =?utf-8?B?5Y+w5Lit5biC6Ieq55Sx6Lev6YKj6bq85aSn?= whereas mail-mode just puts the raw utf-8 there. Isn't that improper or something? Yes. If the following hook function works for you, perhaps it could be adapted and called directly from mail-send or sendmail-send-it: (defun mail-encode-subject-field () Encode the Subject field according to RFC 2047. (save-excursion (when (mail-position-on-field Subject t) (let* ((field-end (point)) (case-fold-search t) (field-beg (progn (re-search-backward ^Subject: [ \t]*) (match-end 0))) (subject (buffer-substring field-end field-beg))) (when (string-match [^\000-\177] subject) (delete-region field-beg field-end) (goto-char field-beg) (insert (rfc2047-encode-string subject))) (add-hook 'mail-send-hook 'mail-encode-subject-field) -- Kevin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(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: gnus: incorrect conversion of Subject and From field from utf-8 to koi8-r
On Thu, 13 Oct 2005 20:26:54 +0200 Reiner Steib wrote: On Thu, Oct 13 2005, Boris B. Samorodov wrote: [ On emacs-pretest. Cc-ing Ding ] Symptoms: I do have a letter with the next Subject: - Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?= - In command-line mode I can do... $ echo W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQnyDRgtC10YHRgg== | base64 -d | iconv -f utf-8 ...and receive the answer: [ipt.ru #163] АвтоОтвет: МСК: СП тест But gnus (from cvs as emacs) shows the next line... Subject: [ipt.ru #163] АвтоОтвет: МСК: СП тест This line really was: [ipt.ru #163] АвтоОтвет: МСК: С\XYZ\ABC тест ...which is wrong. I don't see any difference. Maybe I'm misunderstanding what you mean. It was really an eccident at my bug-letter format. I saw \XYZ\ABC at my subject string (hexadecimal strings). I did a cut-and-paste. After formatting the letter to UTF-8, they appeared to be good letters. Nevertheless, the problem is now solved at gnus.cvs HEAD. I included my confirmation of this fact at the end of the current letter. The problem was with decoding UTF-8 string that was encoded at non-character boundary. Thank you for cooperation and sorry for misformatting the initial report. The bug appeared to be at illegal concatenation of =?UTF-8?foo =?UTF-8?bar parts of the Subject. Whitespace between adjacent encoded words have to be ignored according to RFC 2047: ,[ rfc2047.txt ] |(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) | |White space between adjacent 'encoded-word's is not |displayed. | |(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)(ab) | | Even multiple SPACEs between 'encoded-word's are ignored | for the purpose of display. | |(=?ISO-8859-1?Q?a?= (ab) |=?ISO-8859-1?Q?b?=) | |Any amount of linear-space-white between 'encoded-word's, |even if it includes a CRLF followed by one or more SPACEs, |is ignored for the purposes of display. ` = From: Boris Samorodov [EMAIL PROTECTED] Subject: Re: gnus: incorrect conversion of Subject and From field from utf-8 to koi8-r To: Katsumi Yamaoka [EMAIL PROTECTED] Cc: Kenichi Handa [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Tue, 18 Oct 2005 22:20:37 +0400 User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) On Sat, 15 Oct 2005 19:06:52 +0900 Katsumi Yamaoka wrote: In [EMAIL PROTECTED] Handa-san wrote: 5. Use of encoded-words in message headers [...] The 'encoded-text' in an 'encoded-word' must be self-contained; 'encoded-text' MUST NOT be continued from one 'encoded-word' to another. This implies that the 'encoded-text' portion of a B 'encoded-word' will be a multiple of 4 characters long; for a Q 'encoded-word', any = character that appears in the 'encoded-text' portion will be followed by two hexadecimal characters. The encoded-words that Boris B. Samorodov presented comes just under this case. Even so, should Gnus support such encodings? Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?= This example doesn't violate the above restriction. Each 'encoded-word' is surely multiple of 4 characters long. Please note that the above restriction is for 'encoded-text', not for the underlining coded character set. So, I think the above document doesn't prohibit diviging UTF-8 byte sequence at non-character boundary. I agree. Thank you for clarifying it. I've committed your patch to cvs.gnus.org with small modifications. It will be propagated to Emacs soon. This is to confirm that the latest revision 7.43 from HEAD for gnus/lisp/rfc2047.el from gnus cvs is fine with Subject and From fields. Thank you all who helped to investigate and unbreak the case! = Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ WBR -- bsam ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gnus: incorrect conversion of Subject and From field from utf-8 to koi8-r
On Thu, Oct 13 2005, Boris B. Samorodov wrote: [ On emacs-pretest. Cc-ing Ding ] Symptoms: I do have a letter with the next Subject: - Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?= - In command-line mode I can do... $ echo W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQnyDRgtC10YHRgg== | base64 -d | iconv -f utf-8 ...and receive the answer: [ipt.ru #163] АвтоОтвет: МСК: СП тест But gnus (from cvs as emacs) shows the next line... Subject: [ipt.ru #163] АвтоОтвет: МСК: СП тест ...which is wrong. I don't see any difference. Maybe I'm misunderstanding what you mean. The bug appeared to be at illegal concatenation of =?UTF-8?foo =?UTF-8?bar parts of the Subject. Whitespace between adjacent encoded words have to be ignored according to RFC 2047: ,[ rfc2047.txt ] |(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) | |White space between adjacent 'encoded-word's is not |displayed. | |(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)(ab) | | Even multiple SPACEs between 'encoded-word's are ignored | for the purpose of display. | |(=?ISO-8859-1?Q?a?= (ab) |=?ISO-8859-1?Q?b?=) | |Any amount of linear-space-white between 'encoded-word's, |even if it includes a CRLF followed by one or more SPACEs, |is ignored for the purposes of display. ` Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ 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)
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)
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)
调情药剂令你轻松自然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)
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)
___ 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
Re: Subject: Emacs CVS loops on evaluation of badly formed Elisp code
2) Put this code in a buffer: (defun url-dl-callback-save(to-file url) (when (= 0 (buffer-size)) (url-dl-do-redir))) (goto-char (point-min)) (let ((redirsts (search-forward-regexp \\(300\\|301\\|302\\|307\\|303\\) 20 t))) )) 3) M-x eval-buffer = Emacs loops. That's because it executes (goto-char (point-min)) and starts reading again from the beginning. It is not an Emacs bug. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Subject: Emacs CVS loops on evaluation of badly formed Elisp code
1) Start with emacs -Q 2) Put this code in a buffer: (defun url-dl-callback-save(to-file url) (when (= 0 (buffer-size)) (url-dl-do-redir))) (goto-char (point-min)) (let ((redirsts (search-forward-regexp \\(300\\|301\\|302\\|307\\|303\\) 20 t))) )) 3) M-x eval-buffer = Emacs loops. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2005-06-20 on W2ONE Distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.2) --cflags -Id:/g/include' ___ 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
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
