Re: Emacs trunk needs to increase PURESIZE
> Richard Stallman wrote: > Please add 1 to the value. Done. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: commandp
> Stefan Monnier wrote: > Actually formerly it returned either nil or non-nil, where the non-nil value > was sometimes t and other times the interactive form. >> Because of this, `defadvice' makes interactive Lisp functions non- >> interactive. See the `ad-interactive-form' function. > Looks like a bug in advice.el. I've just installed the patch below which > should hopefully fix it. Thank you for the fix. It looks better than to make the return value of `commandp' too implicative. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs trunk needs to increase PURESIZE (was Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space)
Hi, The value of PURESIZE needs to be increased for at least the Fedora 7 system: [...] Dumping under names emacs and emacs-22.1.50.1 emacs:0:Pure Lisp storage overflow (approx. 1120140 bytes needed) 144 pure bytes used [...] The following change solves it, however it seems to become insufficient sooner or later. *** puresize.h~ Thu Jul 26 07:42:09 2007 --- puresize.h Mon Jul 30 00:13:23 2007 *** *** 46 ! #define BASE_PURESIZE (112 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) --- 46 ! #define BASE_PURESIZE (1121000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) Is this the right fix? If so, how much margin should it have? Or is there another cause that requires it to be increased? Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
>>>>> Tassilo Horn wrote: > Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> --- puresize.h~ 2007-01-14 03:24:37 + >> +++ puresize.h 2007-07-25 23:58:10 + >> @@ -46 +46 @@ >> -#define BASE_PURESIZE (112 + SYSTEM_PURESIZE_EXTRA + >> SITELOAD_PURESIZE_EXTRA) >> +#define BASE_PURESIZE (1121000 + SYSTEM_PURESIZE_EXTRA + >> SITELOAD_PURESIZE_EXTRA) > I updated my working copy one minute ago (22.1.50), but this patch has > not been applied so far. Sorry, it's only a workaround I tried personally. I don't know what makes it need to be increased, so I'm not sure it is the right fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
> On 2007-07-26 01:13 +0100, Katsumi Yamaoka wrote: >> I got no problem in building Unicode2 of today: >> Dumping under names emacs and emacs-23.0.0.1 >> 1116860 pure bytes used >> ./emacs -q -batch -f list-load-path-shadows >>>>> Leo wrote: > I still get "overflowed pure space" after make bootstrap in Unicode2. IIUC, the value of PURESIZE defined in src/puresize.h needs to be larger than the one actually used. What's that in your case? You can find it in the log that was made by `make' like the following: make ...options...| tee LOG ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
commandp
Hi, In the latest Emacs trunk the built-in function `commandp' returns t or nil while it returned an interactive form or nil formerly. Because of this, `defadvice' makes interactive Lisp functions non- interactive. See the `ad-interactive-form' function. Here is an example of what it causes: (defun foo () (interactive) (message "Hello")) => foo (commandp 'foo) => t (let ((ad-default-compilation-action 'never)) (defadvice foo (around testing activate) "testing" (message "Good-bye"))) => foo (commandp 'foo) => nil (pp (symbol-function 'foo)) => (lambda nil "$ad-doc: foo$" t (let (ad-return-value) (message "Good-bye") ad-return-value)) Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
>>>>> Katsumi Yamaoka wrote: > Dumping under names emacs and emacs-22.1.50.1 > emacs:0:Pure Lisp storage overflow (approx. 1120088 bytes needed) > 88 pure bytes used > ./emacs -q -batch -f list-load-path-shadows It has been solved by this change: --- puresize.h~ 2007-01-14 03:24:37 + +++ puresize.h 2007-07-25 23:58:10 + @@ -46 +46 @@ -#define BASE_PURESIZE (112 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) +#define BASE_PURESIZE (1121000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) > It was produced in the Fedora 7 Linux that is the same as Leo > uses. I'm going to verify it with Unicode2 too... I got no problem in building Unicode2 of today: Dumping under names emacs and emacs-23.0.0.1 1116860 pure bytes used ./emacs -q -batch -f list-load-path-shadows ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
> Kenichi Handa wrote: >> Warning (initialization): Building Emacs overflowed pure space. (See >> the node Pure Storage in the Lisp manual for details.) > In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: > I've just done "cvs update" and "make" but, the pure space > was not overflowed. > % make > [...] > Dumping under names emacs and emacs-23.0.0.19 > 1116287 pure bytes used > ./emacs -q -batch -f list-load-path-shadows > [...] I got the following when building the Emacs trunk: Dumping under names emacs and emacs-22.1.50.1 emacs:0:Pure Lisp storage overflow (approx. 1120088 bytes needed) 88 pure bytes used ./emacs -q -batch -f list-load-path-shadows It was produced in the Fedora 7 Linux that is the same as Leo uses. I'm going to verify it with Unicode2 too... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no set button in Custom buffer
>>>>> Katsumi Yamaoka wrote in the pretest-bug list: > When I run `customize-option', I don't see the Set button in > the Custom buffer. Maybe this is caused by the recent changes > in cus-edit.el. It's funny that it occurs only when running Emacs on X, not on the terminal. Here are examples that I got when I performed `M-x customize-option RET file-coding-system-alist RET': emacs -Q , | Editing a setting changes only the text in this buffer. | Currently, these settings cannot be saved for future Emacs sessions, | possibly because you started Emacs with `-q'. | For details, see Saving Customizations in the Emacs manual. | | | File Coding System Alist: Hide Value ` emacs -nw -Q , | Editing a setting changes only the text in this buffer. | Currently, these settings cannot be saved for future Emacs sessions, | possibly because you started Emacs with `-q'. | For details, see [Saving Customizations] in the [Emacs manual]. | | | Operate on all settings in this buffer that are not marked HIDDEN: | [Set for current session] | [Undo edits] [Reset to saved][Exit] | | File Coding System Alist: [Hide Value] ` I haven't yet looked into the code. Sorry. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
no set button in Custom buffer
When I run `customize-option', I don't see the Set button in the Custom buffer. Maybe this is caused by the recent changes in cus-edit.el. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfmt crashes Emacs
> Richard Stallman wrote: > If you revert the recent byte-opt.el patch, does this crash stop? Yes, it solves the problem. And I confirmed it has been fixed in the Emacs CVS. Thank you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: texinfmt crashes Emacs
>>>>> Katsumi Yamaoka wrote: > I noticed the recent change in texinfmt.el crashes Emacs when > formatting a Japanese Info. Sorry, that is not a texinfmt.el bug. I verified that it happens even if I use texinfmt.el of Emacs 22.1. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
texinfmt crashes Emacs
Hi, I noticed the recent change in texinfmt.el crashes Emacs when formatting a Japanese Info. The Lisp program that reproduces the crash is: (load-file "infohack.el") (let (enable-local-variables) (infohack-texi-format "gnus-ja.texi")) Where infohack.el, gnus-ja.texi and the other requirements are in: http://cvs.m17n.org/viewcvs/root/gnus-doc-ja.tar.gz?view=tar or http://www.jpl.org/gnus-doc-ja/ngnus-0.6-doc-ja.tar.gz The backtrace is below. In GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-07-05 on pastis Windowing system distributor `The X.Org Foundation', version 11.0.1030 configured using `configure '--verbose' '--with-x-toolkit=lucid'\ '--with-gpm' '--without-xim'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C value of $LC_CTYPE: ja_JP.eucjp value of $LC_MESSAGES: C value of $LC_MONETARY: C value of $LC_NUMERIC: C value of $LC_TIME: C value of $LANG: C locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t GNU gdb Red Hat Linux (6.6-15.fc7rh) [...] (gdb) r Starting program: emacs-22.1.50/src/emacs -geometry 80x40+0+0 [Thread debugging using libthread_db enabled] [New Thread 1074018784 (LWP 10474)] [Switching to Thread 1074018784 (LWP 10474)] Breakpoint 3 at 0x80c9fd6: file xterm.c, line 7861. [Detaching after fork from child process 10478. (Try `set detach-on-fork off'.)] Breakpoint 1, abort () at emacs.c:431 431 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at emacs.c:431 #1 0x0817f516 in Fbyte_code (bytestr=148564811, vector=148412564, maxdepth=40) at bytecode.c:1666 #2 0x0815578a in funcall_lambda (fun=150202988, nargs=0, arg_vector=0xbff48d24) at eval.c:3184 #3 0x08155b91 in Ffuncall (nargs=1, args=0xbff48d20) at eval.c:3054 #4 0x081807ea in Fbyte_code (bytestr=148563795, vector=148584420, maxdepth=24) at bytecode.c:679 #5 0x0815578a in funcall_lambda (fun=146959484, nargs=0, arg_vector=0xbff48e44) at eval.c:3184 #6 0x08155b91 in Ffuncall (nargs=1, args=0xbff48e40) at eval.c:3054 #7 0x081807ea in Fbyte_code (bytestr=148563603, vector=148583948, maxdepth=40) at bytecode.c:679 #8 0x0815578a in funcall_lambda (fun=148584140, nargs=0, arg_vector=0xbff48f74) at eval.c:3184 #9 0x08155b91 in Ffuncall (nargs=1, args=0xbff48f70) at eval.c:3054 #10 0x081807ea in Fbyte_code (bytestr=148556115, vector=148418740, maxdepth=32) at bytecode.c:679 #11 0x0815578a in funcall_lambda (fun=148418948, nargs=2, arg_vector=0xbff49094) at eval.c:3184 #12 0x08155b91 in Ffuncall (nargs=3, args=0xbff49090) at eval.c:3054 #13 0x081807ea in Fbyte_code (bytestr=148563571, vector=148560180, maxdepth=24) at bytecode.c:679 #14 0x0815578a in funcall_lambda (fun=148419124, nargs=0, arg_vector=0xbff49150) at eval.c:3184 #15 0x08155986 in apply_lambda (fun=148419124, args=137480393, eval_flag=1) at eval.c:3108 #16 0x08155062 in Feval (form=150149413) at eval.c:2370 #17 0x081555ef in Fprogn (args=148311987) at eval.c:447 #18 0x08155417 in Feval (form=150152069) at eval.c:2275 #19 0x081577ff in internal_lisp_condition_case (var=137811049, bodyform=150152069, handlers=150148957) at eval.c:1426 #20 0x0815788b in Fcondition_case (args=150152061) at eval.c:1367 #21 0x08155417 in Feval (form=150152053) at eval.c:2275 #22 0x081555ef in Fprogn (args=148311987) at eval.c:447 #23 0x08157abd in Flet (args=150152045) at eval.c:1064 #24 0x08155417 in Feval (form=150151957) at eval.c:2275 #25 0x081555ef in Fprogn (args=148311987) at eval.c:447 #26 0x08155864 in funcall_lambda (fun=150149000, nargs=1, arg_vector=0xbff49580) at eval.c:3177 #27 0x08155986 in apply_lambda (fun=150149005, args=148510629, eval_flag=1) at eval.c:3108 #28 0x08155062 in Feval (form=148510637) at eval.c:2370 #29 0x081555ef in Fprogn (args=148311987) at eval.c:447 #30 0x08157abd in Flet (args=148510645) at eval.c:1064 #31 0x08155417 in Feval (form=148510661) at eval.c:2275 #32 0x08155ce1 in Ffuncall (nargs=2, args=0xbff49790) at eval.c:2997 #33 0x081807ea in Fbyte_code (bytestr=136626563, vector=136626580, maxdepth=64) at bytecode.c:679 #34 0x0815578a in funcall_lambda (fun=136626524, nargs=1, arg_vector=0xbff498c4) at eval.c:3184 #35 0x08155b91 in Ffuncall (nargs=2, args=0xbff498c0) at eval.c:3054 #36 0x081807ea in Fbyte_code (bytestr=136627059, vector=136627076, maxdepth=32) at bytecode.c:679 #37 0x0815578a in funcall_lambda (fun=136627020, nargs=1, arg_vector=0xbff499e4) at eval.c:3184 #38 0x08155b91 in Ffuncall (nargs=2, args=0xbff499e0) at eval.c:3054 #39 0x081807ea in Fbyte_code (bytestr=136625307, vector=136625324, maxdepth=16) at bytecode.c:679 #40 0x0815578a in funcall_lambda (fun=136625276, nargs=0, arg_vector=0xbff49b04) at eval.c:3184 #41 0x08155b91 in Ffuncall (nargs=1, args=0xbff49b00) at eval.c:3054 #42 0x08157539 in apply1 (fn=138345049, arg=137480393) at eval.c:2738 #43 0x08152d96 in Fcall_interactively (function=138345049, record_flag=1374
Re: Symbol's value as variable is void: cl-struct-tramp-file-name-tags
> In <[EMAIL PROTECTED]> > Chris Moore wrote: > On 6/12/07, Chris Moore <[EMAIL PROTECTED]> wrote: >> Running: >> emacs -Q /[EMAIL PROTECTED]:/ >> to attempt to use tramp to FTP, I see an error message. > I fixed the problem by running a "make clean && make bootstrap", so > maybe my previous message should be ignored. The cause is that you used Lisp programs having been byte-compiled with Emacs 22.1 or earlier, that use at least one of the following five Tramp functions: tramp-file-name-multi-method tramp-file-name-method tramp-file-name-user tramp-file-name-host tramp-file-name-localname In Emacs 22.1 or earlier, those functions are provided using cl's `defstruct' macro and have the `cl-compiler-macro' property which uses the `cl-struct-tramp-file-name-tags' variable (which is defined in tramp.elc in Emacs 22.1 or earlier). But now Tramp does not use such a cl resource. What you did is the best if such Lisp programs are the parts of Emacs. Otherwise, re-compiling your Lisp programs by the most recent Emacs solves the problem. (I was actually troubled with my Lisp program that uses those Tramp functions. ;-) Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
> In <[EMAIL PROTECTED]> > Richard Stallman <[EMAIL PROTECTED]> wrote: > Thank you for the reply. But I don't have a write access to the > Emacs CVS, so I ask someone to install it. > Please email the patch and change log to emacs-devel > and ask someone to install it. It has already been committed thanks to Kenichi Handa. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
> In <[EMAIL PROTECTED]> > Richard Stallman <[EMAIL PROTECTED]> wrote: > Please install your patch in the trunk. If it proves correct, > we can install it in 22.2. Thank you for the reply. But I don't have a write access to the Emacs CVS, so I ask someone to install it. Thanks in advance. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
> In <[EMAIL PROTECTED]> Lennart Borgman (gmail) wrote: >> (require 'cl) >> without (eval-when-compile ...). Is not that incorrect? > More files doing this: [...] > tramp.el tramp.el doesn't seem to need cl at run time. Actually I have no problem on ftp and ssh connections using the following workaround in my ~/.emacs file: (let ((features (cons 'cl features))) (require 'tramp)) (provide 'tramp) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
> In <[EMAIL PROTECTED]> Richard Stallman wrote: > The way I posted, to make the syntax of all non-ASCII characters > `word', has a weakness. It is not effective to charsets that > are created after loading mail-extr.el. > So, what about the first proposed fix? > The one that patched this particular function? I want someone to verify, whichever is used. Although I believe the first patch[1] does the right thing, is harmless, and can be used also in the emacs-unicode-2 branch, it is possible to make a mistake in any change and it might be able to improve further. I still think it is easier to verify the first patch than the second one. If no one turns up, I want the fix (whichever) to be installed in the trunk and the emacs-unicode-2 branch, not the EMACS_22_BASE branch. Regards, [1] <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
>>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> The way I posted, to make the syntax of all non-ASCII characters >> `word', has a weakness. It is not effective to charsets that >> are created after loading mail-extr.el. > As a syntax table is just a char-table, we can set the > default value of a syntax table to "word". But, I don't > think we should do such a thing now. I think we must study mail-extr.el entirely in order to verify the rightfulness of the change(s) if we modify the syntax tables. It is certain that it takes time to do it no matter who does. OTOH, it seems to be easier to verify the patch I proposed first. Because what we should do in that case is only to verify the code recognizes non-ASCII characters as `word'. Of course, I can agree not to do it in Emacs 22.1. Such problems will probably seldom happen, except for my colleague (who often receives mails having funny headers). And now we have a workaround which doesn't require modifying of mail-extr.el. > In emacs-unicode-2, all characters (0..0x3) exists from > the start. Creating a charset means just to add a mapping > rule between the code-point in the charset and Emacs' > character. And, the argument CHAR of modify-syntax-entry > can be a cons (MIN-CHAR . MAX-CHAR). > So, we can make a syntax table, modify it for all characters > to be word, then modify it for each special characters. Thank you for the information. I will be able to make a workaround also for Emacs 23 if necessary. ;-) Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes: >> If people have doubts that changing that syntax table is generally >> correct, what about the previous patch that alters just the >> particular function? > At the moment, I don't have a time to study the code and his > patch. So, I can't doubt nor be sure on anything. > But, in general, I think we can treat all non-ASCII > characters as the same way in a mail address. And, if > mail-extr.el utilizes a syntax table to parse a mail > address, I think setting all non-ASCII characters to the > same syntax (in the current case, word) is the right thing. > So, my suggestion it to do that and see if it works well if > no one can investigate the code and RFC-822. The way I posted, to make the syntax of all non-ASCII characters `word', has a weakness. It is not effective to charsets that are created after loading mail-extr.el. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: core dump
> In [emacs-w3m : No.09442] Kenichi Handa wrote: > The backtrace shows that Emacs is in infinite loop in > ccl_driver. It seems that emacs-w3m does some code > conversion by CCL programs defined by itself. I reached to this conclusion yesterday, too. > And, it is > very likely that those CCL programs depend heavily on the > internal character representation. That must be changed for > Emacs 23. The code which makes emacs-w3m use the ccl programs for ftp urls is: (defun w3m-w3m-parse-header (url header) [...] (if (string-match "\\`ftps?:.*/\\'" url) (if w3m-accept-japanese-characters "w3m-euc-japan" "w3m-iso-latin-1") The ccl coding systems `w3m-euc-japan' and `w3m-iso-latin-1' are defined in w3m-ccl.el and, for Emacs 21 and 22, redefined in w3m-ems.el. IIUC, they are used for communicating with the w3m command privately. Unfortunately I'm not skilled with those coding systems, but TSUCHIYA-san have ever explained what they are briefly in: http://emacs-w3m.namazu.org/ml/msg00872.html The problem is that we have no programs to redefine those coding systems for Emacs 23 in w3m-ems.el. > To emacs-w3m developpers: > Please explain why it does code conversion by its own CCL > programs. I'll be able to suggest a better way for Emacs > 23. Thank you very much for the offer. We welcome any improvement, suggestion, and comment. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: core dump
> In [emacs-w3m : No.09434] Leo wrote: > I met a weird bug and I don't know if it is due to emacs-w3m or emacs. > To reproduce, in Emacs: > 0. start Emacs in urxvt¹ > 1. M-x w3m > 2. Key `g' and type in url: ftp://ftp.gnu.org/gnu/hyperbole > 3. Key `^' and see emacs hang > 4. Key `C-g' and Emacs asks: >i. Auto-save (y/n) >ii. Core dump (y/n) > I am using the unicode-2 branch of Emacs with cvs checkout 2007-05-16. > Emacs-w3m cvs checkout date: 2007-05-16. > Footnotes: > ¹ http://software.schmorp.de/pkg/rxvt-unicode.html First of all, emacs-w3m does not yet support Emacs 23 officially. Though it might work luckily with some urls, it needs to be much improved in order to work with Emacs 23 perfectly. In the future. Well, try setting `w3m-async-exec' to nil. It might make it possible to display the url in question, though emacs-w3m becomes not to working smoothly. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
>>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> [...] and the patch[1] I posted first is better. >> But please don't merge it hastily if you have a doubt even if it >> is little. > I don't know about the code of mail-extr.el nor the detailed > format of a mail address (RFC-822?). So, I can't be sure, > either. It must be checked by someone who knows both of > them. I'm anxious for such a person. Otherwise... > Or, should we just install the change and see what happens? I hope to install the patch to only the Emacs CVS trunk, since I think it needs time to be tested widely. I'm not well informed about RFC2822 and what mail-extr.el does (especially the voodoo operation, which is disabled by default for Japanese names), too. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
>>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > Sorry for the late response on this matter. Please don't mind, since the most important thing now is to release Emacs 22.1. > In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >>> I hope this is fixed in Emacs 22.2 (or possibly 22.1). I've been >>> annoyed that `mail-extract-address-component' sometimes fails to >>> parse addresses containing non-ASCII names correctly. Japanese >>> people often use their native names in the From header. Since >>> they sometimes use non-ASCII letters which are not specified as >>> words in the syntax table, Gnus, for example, fails to build the >>> recipient address when replying. >> [...] >>> The causes are >> [...] >>> and `m-e-a-c' uses `forward-word' to try to skip them even if >>> they are not words. >> I found another solution, which doesn't need to modify mail-extr.el: >> ;; Set the syntax of all non-ASCII characters to `word' >> ;; in the syntax tables that mail-extr.el uses. > If it solves the problem, should mail-extr.el be modified to > setup syntax tables as you did below? >> (eval-after-load "mail-extr" I don't want it to be merged in mail-extr.el. It influences all the mail-extr processes but I'm not sure whether setting the syntax of all non-ASCII characters to `word' does not have a side effect. I consider it is no more than a workaround to be used before `m-e-a-c' is fixed, and the patch[1] I posted first is better. But please don't merge it hastily if you have a doubt even if it is little. [1] It has to be fixed slightly. See <[EMAIL PROTECTED]>. >> BTW, I think it should be documented that `modify-syntax-entry' >> allows the generic character of a charset as the first argument, >> as it is mentioned in the doc string of `make-char'. > I'm not sure. It surely accepts a generic character now, > but the concept of generic character is deleted in > emacs-unicode-2 branch (and in comming Emacs 23). So even > if we describe that feature now, it should be reverted quite > soon. I see. I withdraw the request. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > I hope this is fixed in Emacs 22.2 (or possibly 22.1). I've been > annoyed that `mail-extract-address-component' sometimes fails to > parse addresses containing non-ASCII names correctly. Japanese > people often use their native names in the From header. Since > they sometimes use non-ASCII letters which are not specified as > words in the syntax table, Gnus, for example, fails to build the > recipient address when replying. [...] > The causes are [...] > and `m-e-a-c' uses `forward-word' to try to skip them even if > they are not words. I found another solution, which doesn't need to modify mail-extr.el: ;; Set the syntax of all non-ASCII characters to `word' ;; in the syntax tables that mail-extr.el uses. (eval-after-load "mail-extr" '(let ((tables '(mail-extr-address-syntax-table mail-extr-address-comment-syntax-table mail-extr-address-domain-literal-syntax-table mail-extr-address-text-comment-syntax-table mail-extr-address-text-syntax-table)) table charsets generic-char) (while tables (setq table (symbol-value (car tables)) tables (cdr tables) charsets charset-list) (while charsets (setq generic-char (make-char (car charsets)) charsets (cdr charsets)) (if (>= generic-char 128) (modify-syntax-entry generic-char "w" table)) This form also modifies the syntax of the Latin-1 nbsp character to `word' but it doesn't seem to be a problem. BTW, I think it should be documented that `modify-syntax-entry' allows the generic character of a charset as the first argument, as it is mentioned in the doc string of `make-char'. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-extract-address-components bug
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > *** mail-extr.el~ Sun Jan 21 21:57:52 2007 > --- mail-extr.el Mon May 14 03:16:51 2007 [...] > !(not (eq (char-after ? )) Sorry, this line has to be corrected into: ! (not (eq (char-after) ? ) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mail-extract-address-components bug
Hi,
I hope this is fixed in Emacs 22.2 (or possibly 22.1). I've been
annoyed that `mail-extract-address-component' sometimes fails to
parse addresses containing non-ASCII names correctly. Japanese
people often use their native names in the From header. Since
they sometimes use non-ASCII letters which are not specified as
words in the syntax table, Gnus, for example, fails to build the
recipient address when replying. Here are examples:
(mail-extract-address-components "阿部 晋三 <[EMAIL PROTECTED]>")
=> ("阿部 晋三 ")
=> ("阿部 晋三 ◆ ")
=> ("阿部 晋三 (しんちゃん" "[EMAIL PROTECTED]")
The causes are " " (wide space) and "◆" in the name portion
and `m-e-a-c' uses `forward-word' to try to skip them even if
they are not words. I tried fixing of this problem as follows:
(NOTE: it contains Latin-1 nbsp characters encoded with utf-8.)
*** mail-extr.el~ Sun Jan 21 21:57:52 2007
--- mail-extr.elMon May 14 03:16:51 2007
***
*** 873,879
(mail-extr-nuke-char-at (point))
(forward-char 1))
(t
! (forward-word 1)))
(or (eq char ?\()
;; At the end of first address of a multiple address header.
(and (eq char ?,)
--- 873,889
(mail-extr-nuke-char-at (point))
(forward-char 1))
(t
! ;; Do `(forward-word 1)', recognizing non-ASCII characters
! ;; except Latin-1 nbsp as words.
! (while (progn
! (skip-chars-forward "^\000-\177 ")
! (and (not (eobp))
! (eq ?w (char-syntax (char-after)))
! (progn
! (forward-word 1)
! (and (not (eobp))
! (> (char-after) ?\177)
! (not (eq (char-after ? ))
(or (eq char ?\()
;; At the end of first address of a multiple address header.
(and (eq char ?,)
I appreciate someone looking into it.
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Frame doesn't get focused
> In <[EMAIL PROTECTED]> Jan Djärv wrote: > See http://bugzilla.gnome.org/show_bug.cgi?id=392889. My last comment > was that we may enable _NET_ACTIVATE_WINDOW, but it has been postponed > to after the release. Thank you for the followup. So, I've prepared a workaround as follows: (when (and (not (featurep 'xemacs)) (featurep 'gtk)) (defadvice select-frame (around set-input-focus (frame) activate) "Run `select-frame-set-input-focus'." (setq ad-return-value (and (framep frame) (frame-live-p frame))) (ad-deactivate 'select-frame) (unwind-protect (select-frame-set-input-focus frame) (ad-activate 'select-frame Best regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Frame doesn't get focused
I stripped [Unicode-2] from the subject line because I realized now the problem is also in Emacs 22. It is due to the --with-gtk build option and probably to the Fecora Core 6 Linux which runs the metacity window manager. Anyway I must apologize for having reported it vaguely. > In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> --8<---cut here---start->8--- (defun test () (interactive) (let ((frame (make-frame))) (select-frame frame) (select-window (frame-first-window frame))) (switch-to-buffer "*foo*")) (local-set-key [f1] 'test) >> --8<---cut here---end--->8--- >> To reproduce the problem, select the frame by clicking the mouse >> on the rim (not on an Emacs buffer) of the frame after selecting >> another X-frame, and type the [f1] key (not `M-x test RET'). >> In my case, the new frame is neither selected nor focused. Let me correct it; the problem happens with Emacs 22 and 23 built with the --with-gtk option and run in the Fedora Core 6 Linux (which I update every day). >>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > That's very strange because Emacs 22 and 23 should not be > different in the codes handling that kind of thing. Handa-san, thank you for the comment. The reason I misunderstood that it occurs only with Emacs 23 is that I only tested it with Emacs 23 built with GTK and Emacs 22 built with LUCID then (I usually use Emacs 22 LUCID). >> A solution is to use `select-frame-set-input-focus' instead of >> `select-frame'. So, I'd like to modify gnus-win.el so as to use >> `select-frame-set-input-focus'[1] if it is not a bug of Emacs 23. It will arise to all those who use GTK Emacs and at least the Fedora Core Linux, so such a workaround is quite insufficient. While I don't have a skill to fix this unfortunately, I hope it is solved before releasing. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Unicode-2] frame doesn't get focused
Hi, First of all, this problem might happen only with the Fedora Core systems which run the metacity window manager. I tested it with the latest Emacs 23 and the following form: --8<---cut here---start->8--- (defun test () (interactive) (let ((frame (make-frame))) (select-frame frame) (select-window (frame-first-window frame))) (switch-to-buffer "*foo*")) (local-set-key [f1] 'test) --8<---cut here---end--->8--- To reproduce the problem, select the frame by clicking the mouse on the rim (not on an Emacs buffer) of the frame after selecting another X-frame, and type the [f1] key (not `M-x test RET'). In my case, the new frame is neither selected nor focused. It often happens actually when I write a mail in a new message frame of Gnus. Emacs 22 works as expected, though. A solution is to use `select-frame-set-input-focus' instead of `select-frame'. So, I'd like to modify gnus-win.el so as to use `select-frame-set-input-focus'[1] if it is not a bug of Emacs 23. WDYT? Best regards, [1] *** gnus-win.el~Sun Jan 21 21:57:16 2007 --- gnus-win.el Mon Mar 19 12:24:19 2007 *** *** 363,369 (incf i)) ;; Select the frame that has the selected buffer. (when fresult ! (select-frame (window-frame fresult) ;; This is a normal split. (t (when (> (length subs) 0) --- 363,369 (incf i)) ;; Select the frame that has the selected buffer. (when fresult ! (select-frame-set-input-focus (window-frame fresult) ;; This is a normal split. (t (when (> (length subs) 0) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch for non-ASCII text
> In <[EMAIL PROTECTED]> Stefan Monnier wrote: > Thanks I ended up with the same diagnostic and have installed a similar fix. Thanks. So, Lennart, now you can apply this change safely. ;-) 2007-03-01 Lennart Borgman <[EMAIL PROTECTED]> * isearch.el (isearch-message-prefix): Use minibuffer-prompt-properties. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch for non-ASCII text
> In <[EMAIL PROTECTED]> Stefan Monnier wrote:
>> Debugger entered--Lisp error: (text-read-only)
>> read-from-minibuffer(#("Search: " 0 8 (read-only t face
>> minibuffer-prompt))...
>> byte-code(...
>> isearch-edit-string()
>> isearch-exit()
>> call-interactively(isearch-exit)
> This seems to indicate a bug elsewhere.
> This backtrace is not enough to pin it down. Maybe a C backtrace would be
> more enlightening.
I'm not skillful with C debugging and don't know how to break
the program by such an error, sorry. But the cause of the problem
is obvious now; that is, Fread_minibuf tries to put some text
properties to the prompt string even if it has the read-only
property. Although I'm not quite sure this should really be
fixed, the attached patch makes the following program work with
no error.
(read-from-minibuffer (propertize "Prompt: " 'read-only t))
--8<---cut here---start->8---
*** minibuf.c~ Wed Feb 21 21:58:15 2007
--- minibuf.c Wed Mar 7 00:58:56 2007
***
*** 711,716
--- 711,718
Finsert (1, &minibuf_prompt);
if (PT > BEG)
{
+ int count1 = SPECPDL_INDEX ();
+ specbind (Qinhibit_read_only, Qt);
Fput_text_property (make_number (BEG), make_number (PT),
Qfront_sticky, Qt, Qnil);
Fput_text_property (make_number (BEG), make_number (PT),
***
*** 719,724
--- 721,727
Qfield, Qt, Qnil);
Fadd_text_properties (make_number (BEG), make_number (PT),
Vminibuffer_prompt_properties, Qnil);
+ unbind_to (count1, Qnil);
}
minibuf_prompt_width = (int) current_column (); /* iftc */
--8<---cut here---end--->8---
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch for non-ASCII text
> In <[EMAIL PROTECTED]> Kim F. Storm wrote: > Thanks. I have reverted the patch. Thank you for fixing it so quickly. > In <[EMAIL PROTECTED]> Lennart Borgman wrote: > Thanks Kim. Emacs is full of surprises. I would be glad for an > explanation of what happens with non-ASCII text. > Are there any other properties that could interfere with non-ASCII > text? Could other properties from minibuffer-prompt-properties still > be applied to the isearch prompt? I realized the problem is irrelevant to non-ASCII text. The cause is simply that the prompt string, the first argument, given to `read-from-minibuffer' has the `read-only' property. For instance, the following form causes the same error: (read-from-minibuffer (propertize "Prompt: " 'read-only t)) I guess `r-f-m' has a need to add some text property to the prompt string. It might just be `read-only'. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't isearch for non-ASCII text
> In the gmane.emacs.diffs newsgroup, Kim F. Storm wrote:
> Index: isearch.el
> ===
> RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
> retrieving revision 1.294
> retrieving revision 1.295
> diff -u -b -r1.294 -r1.295
> --- isearch.el15 Feb 2007 16:54:09 - 1.294
> +++ isearch.el1 Mar 2007 22:28:14 - 1.295
> @@ -1957,8 +1957,9 @@
> (concat " [" current-input-method-title "]: ")
>": ")
> )))
> -(propertize (concat (upcase (substring m 0 1)) (substring m 1))
> - 'face 'minibuffer-prompt)))
> +(apply 'propertize
> +(concat (upcase (substring m 0 1)) (substring m 1))
> +minibuffer-prompt-properties)))
This change disables me from searching for non-ASCII text because
of the `read-only' property in `minibuffer-prompt-properties'.
When I type `C-s RET C-\' in order to enter Japanese text to
search for, I get the following error[1]:
Debugger entered--Lisp error: (text-read-only)
read-from-minibuffer(#("Search: " 0 8 (read-only t face minibuffer-prompt))...
byte-code(...
isearch-edit-string()
isearch-exit()
call-interactively(isearch-exit)
Since this is a popular way to enter at least Japanese text for
isearch, please fix it.
[1] To get this error, I eval'd the form:
(put 'text-read-only 'error-conditions '(text-read-only error))
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom bug
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > (defcustom foo 'foo > "doc string" > :type '(choice (const foo) (const bar))) > When I chose `bar', the value disappears in the screen. There was already this issue in another board: http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=17034/force_load=t Sorry for the noise. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
custom bug
Hi, Please try customizing the following option: (defcustom foo 'foo "doc string" :type '(choice (const foo) (const bar))) When I chose `bar', the value disappears in the screen. Even if I press the [Set for Current Session] button or the [Save for Future Sessions] button, the value is still hidden. I need to press the [Hide Value] button twice or the [Erase Customization] button to see the value. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Hi, Thank you very much for investigating this. >>>>> In <[EMAIL PROTECTED]> Jan Djärv wrote: >> Katsumi Yamaoka skrev: >>> To reproduce it, eval the form1 first and eval the form2 several >>> times. (I've made a similar code in the emacs-w3m CVS, however I >>> might have to delete it.) (I've fixed emacs-w3m so that it may necessarily select the frame when changing the value of `tool-bar-button-margin'. Now the frame flickers not so much. If you have an interest in it, you can download the latest snapshot from: http://cvs.namazu.org/emacs-w3m.tar.gz?view=tar The code in question is in the defcustom form of `w3m-toolbar-configurations' defined in w3m-e21.el and w3m-e23.el.) >>> --8<---cut here---start->8--- >>> ;; form1 >>> (let ((buf (get-buffer-create "*testing*")) >>> (cur (selected-frame))) >>> (select-frame (make-frame)) >>> (switch-to-buffer buf) >>> (make-local-variable 'tool-bar-button-margin) >>> (select-frame-set-input-focus cur)) >>> >>> ;; form2 >>> (with-current-buffer "*testing*" >>> (setq tool-bar-button-margin (random 10))) >>> --8<---cut here---end--->8--- >>> >>> This is a special case anyway, so I don't mind even though it is >>> not fixed. >> >> It seems that wen random returns 4 or less (i.e. Gtk+ margin 0) I get no >> flickering. But everything above 4 gives some flickering. I'll see if I can >> find it. It might not make it to the release though. >> > It seems as update_frame_tool_bar is called several times with different > buffers. So for example, the minibuffer still has margin 0, but your other > buffer has (say) 5. Then the redraw flickers between 5 and 0 for a while. > You really need frame local variables here. I'm not quite sure the frame local variables is really useful. For Gnus running with XEmacs, the tool bar position can be chosen from `top', `bottom', `right', and `left'. Even in that case, I made the tool bar spec have different value per buffer. Best regards, P.S. I'm sorry I will not be active in the net in weekends. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
> In <[EMAIL PROTECTED]> Jan Djärv wrote: >> (make-local-variable 'tool-bar-button-margin) > Doesn't this use different tool-bar-button-margins for different > buffers? It should really be per frame. Yes, I wanted just to use different tool bar appearance for different frames. That there doesn't seem to be the way to do it in per frame (XEmacs has it) is the reason I used buffer local variables. For the moment I have no plan of a useful feature that uses it, though. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > Oops. Now I don't see the tool bar flickering, and all seem to be > going well. I will report if I find the condition to reproduce it. I found. I attached two Lisp forms below. To reproduce it, eval the form1 first and eval the form2 several times. (I've made a similar code in the emacs-w3m CVS, however I might have to delete it.) --8<---cut here---start->8--- ;; form1 (let ((buf (get-buffer-create "*testing*")) (cur (selected-frame))) (select-frame (make-frame)) (switch-to-buffer buf) (make-local-variable 'tool-bar-button-margin) (select-frame-set-input-focus cur)) ;; form2 (with-current-buffer "*testing*" (setq tool-bar-button-margin (random 10))) --8<---cut here---end--->8--- This is a special case anyway, so I don't mind even though it is not fixed. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
>>>>> In <[EMAIL PROTECTED]> Jan Djärv wrote: > Katsumi Yamaoka skrev: >> Although it takes time to settle the shape when I change the value >> of `tool-bar-button-margin', and the value 4 or less seems to be >> treated as 0. That's ok. > I can't see any "settling" at all when changing > tool-bar-button-margin. It is very fast. Maybe there is a difference > in Gtk+-versions? Oops. Now I don't see the tool bar flickering, and all seem to be going well. I will report if I find the condition to reproduce it. I use the Fedora Core 6 linux which I update every day. The value of `gtk-version-string' is "2.10.8". > The default tool-bar-button-margin is 4 for the native tool bar, but > that looks horrible with the Gtk tool bar. So 4 and below is really > 0. 5 is really 1 and so on. I see. Thanks. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
> In <[EMAIL PROTECTED]> Jan Djärv wrote: > tool-bar-button-relief will probably not bel implemented for the Gtk version > of Emacs. The main point for having Gtk in Emacs in the first place, IMHO, is > that it looks like the rest of the Gtk/Gnome applications, and shall reflect > the theme you choose on a desktop level. We are not quite there yet. I sse. I may want to customize the ~/.emacs.d/gtkrc file. > tool-bar-button-margin to zero was a bug, I've fixed that. However, the > default for Gtk is 0, it looks best. Thank you for fixing it. Although it takes time to settle the shape when I change the value of `tool-bar-button-margin', and the value 4 or less seems to be treated as 0. That's ok. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Hi, I recently built Emacs configured with the --with-gtk option and noticed I must not set `tool-bar-button-margin' to zero (I do so for LUCID Emacs to make the tool bar compact). It causes Emacs to go on and off wildly. If you try it, launch another Emacs. Although it might be impossible to make `tool-bar-button-margin' and `tool-bar-button-relief' affect the GTK tool bar, I hope it is improved in the future. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: artifacts in GNU CVS branch emacs-unicode-2
> In [emacs-w3m : No.09139] Trent Buck wrote: > On Mon, Jan 29, 2007 at 06:04:24AM +1100, [EMAIL PROTECTED] wrote: >> I start Emacs with a proportional font: >> >> emacs --enable-font-backend --font 'DejaVu Sans-8' --eval >> '(w3m-browse-url "http://en.wikipedia.org/";)' >> >> I scroll up and down (C-v, M-v). I see 2 pixel underline to the right >> of some lines. The underlines should not be there; they are rendering >> artifacts. > Screenshot attached. I guess the cause of this is that Emacs doesn't support the Telugu language or the Telugu font is missing. I got a similar result[ScreenShot1] in the Fedora Core 6 system by running the most recent Emacs 23 and setting the language environment to English. When I set the language environment to Japanese, those garbage lines don't appear but an improper font is chosen for the Telugu text[ScreenShot2]. Even if you don't have emacs-w3m installed, you will see it by: 1. Start Emacs 23 using the options: -Q --enable-font-backend --font 'DejaVu Sans-8' 2. Set the language environment to English. 3. Eval the following form: --8<---cut here---start->8--- (let* ((default-enable-multibyte-characters t) (buffer (get-buffer-create "*Telugu*")) (text (decode-coding-string "\ Suomi\302\267\340\260\244\340\261\206\340\260\262\340\261\201\ \340\260\227\340\261\201\302\267T\303\274rk\303\247e\302\267\ \320\243\320\272\321\200\320\260\321\227\320\275\321\201\321\ \214\320\272\320\260\n" 'utf-8))) (switch-to-buffer buffer) (erase-buffer) (dotimes (i (* 3 (window-height))) (insert text)) (goto-char (point-min))) --8<---cut here---end--->8--- Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
>>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> uudecode.el bundled with Gnus now doesn't work with Emacs 21 and >> XEmacs because of `string-to-multibyte'. [...] >> + (defalias 'uudecode-string-to-multibyte [...] > Yes. Please install your change. I've installed it in both the Gnus trunk and the v5-10 branch. The later will be merged into Emacs CVS soon. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
> In <[EMAIL PROTECTED]> Kenichi Handa wrote: > In article <[EMAIL PROTECTED]>, Chris Moore <[EMAIL PROTECTED]> writes: >> Stefan Monnier <[EMAIL PROTECTED]> writes: Which function is it? >>> >>> I believe the function "at fault" is uudecode-decode-region >> Yes, it's uudecode-decode-region. > Ok, I've just installed a fix to make it work on a multibyte > buffer. I'm sorry for the late response but I noticed that uudecode.el bundled with Gnus now doesn't work with Emacs 21 and XEmacs because of `string-to-multibyte'. Since Gnus still supports those versions of Emacsen, we have the emulating function for it in mm-util.el as follows: --8<---cut here---start->8--- (defalias 'mm-string-to-multibyte (cond ((featurep 'xemacs) 'identity) ((fboundp 'string-to-multibyte) 'string-to-multibyte) (t (lambda (string) "Return a multibyte string with the same individual chars as string." (mapconcat (lambda (ch) (mm-string-as-multibyte (char-to-string ch))) string "") --8<---cut here---end--->8--- Is it possible to add a similar one to uudecode.el? I've tested the attached patch with Gnus v5.10.8 (aka v5.11). Thanks in advance. --8<---cut here---start->8--- *** uudecode.el~Sun Jan 21 21:53:53 2007 --- uudecode.el Wed Jan 24 08:15:57 2007 *** *** 128,133 --- 128,147 (message "Can not uudecode"))) (ignore-errors (or file-name (delete-file tempfile)) + (eval-and-compile + (defalias 'uudecode-string-to-multibyte + (cond + ((featurep 'xemacs) + 'identity) + ((fboundp 'string-to-multibyte) + 'string-to-multibyte) + (t + (lambda (string) + "Return a multibyte string with the same individual chars as string." + (mapconcat +(lambda (ch) (string-as-multibyte (char-to-string ch))) +string "")) + ;;;###autoload (defun uudecode-decode-region-internal (start end &optional file-name) "Uudecode region between START and END without using an external program. *** *** 206,212 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --- 220,226 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (uudecode-string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --8<---cut here---end--->8--- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
I'm sorry for the late response. > In <[EMAIL PROTECTED]> Kenichi Handa wrote: > I found what is wrong. In x_load_resources (xrdb.c), > default values of several X resources are set, but fontSet > is not set. But, in x_update_menu_appearance (xfaces.c) > which is called when you set `menu' face, the fontSet > resource is set. That's why executing > (set-face-font 'menu (face-font 'menu)) > makes the menu label display correctly. >> I hope it is fixed in Emacs 22.2 or 23. ;-) > I've just installed the attached patch for 23 > (emacs-unicode-2 branch). Could you please confirm that the > change surely fixes the problem in your environment too? I confirmed the change did the trick. I ran Emacs 23 with the -Q option and viewed the Japanese menu by evaluating the code that I posted first. Thank you. Although the X resources seems to be ignored now, I believe all will be fixed in the future. > By the way, I think the relevant code should be improved to > reflect a font specified for menu bar in a created fontset, > but, for the moment, I don't have a time to work on it, > sorry. Most of Japanese are busy at the year-end, so please do your own business. ;-) Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote:
>>>>> (let ((japanese (decode-coding-string "\e$B%F%9%H\e(B" 'iso-2022-jp)))
>>>>> (easy-menu-define testing-menu global-map "Testing."
>>>>> `("Testing"
>>>>> [,japanese (lambda nil (interactive) (message ,japanese)) t]))
>>>>> (easy-menu-add testing-menu global-map))
>>>>> In <[EMAIL PROTECTED]> Kenichi Handa wrote:
> I found a way to reproduce this problem. I have this X
> resource:
> *fontSet: -*-*-medium-r-normal--16-*-*-*
(I had removed all the X resources for Emacs because I wanted to
have a real vanilla Emacs, which can be launched by only the -q
option. I will configure it in the ~/.emacs file even if I need
to use customized ones. Although I have only two fontsets since
I don't know how to do it, I don't feel inconvenience with them.)
> When I remove the resource and run Emacs, I see incorrect
> menu label, and
>>>> (set-face-font 'menu (face-font 'menu))
> surely make the label displayed correctly.
Thank you for verifying it.
> And, starting emacs with:
> % emacs -xrm '*fontSet: -*-*-medium-r-normal--16-*-*-*'
> also displays the menu label correctly. Please try it by
> yourself.
I confirmed it makes Emacs display Japanese menu.
> Anyway, I suspect that somehow the menu widget is not
> created with a correct fontset. Though, I have not yet
> investigated the problem deeper.
I hope it is fixed in Emacs 22.2 or 23. ;-)
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
First of all, this issue is not necessarily serious at least for
me and Nomiya-san since we have a workaround to solve it. So,
you can let us wait. I have doubts that it doesn't work for us
even if it works for Handa-san, though.
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote:
>>>>>> In <[EMAIL PROTECTED]> Handa-san wrote:
>>> (let ((japanese (decode-coding-string "\e$B%F%9%H\e(B" 'iso-2022-jp)))
>>> (easy-menu-define testing-menu global-map "Testing."
>>> `("Testing"
>>> [,japanese (lambda nil (interactive) (message ,japanese)) t]))
>>> (easy-menu-add testing-menu global-map))
>> It works for me (my Emacs also uses LUCID) both in
>> ja_JP.EUC-JP and en_US.UTF-8. In which locale did you test
>> it?
> The locale command returns the following in the PCs, running
> Fedora Core 6 Linux, both in the office and home.
> LANG=ja_JP.eucjp
> LC_CTYPE=ja_JP.eucjp
[...]
> Those are set globally in the systems and I don't modify any of
> them in Emacs. I verified it doesn't work in both the PCs.
The menu bar doesn't display Japanese text but displays the one
looking like raw encoded data as shown in the attached image1
below. I also tried it with latest Emacs CVS in the Solaris 2.6
machine. But there was no difference.
Although it might be irrelevant to this issue, I found a funny
thing in relation to the `menu' face.
>>> I found the way to make it work. That is to re-set the font for
>>> the `menu' face as follows:
>>> (set-face-font 'menu (face-font 'menu))
It works, however it changes the font used in the menu bar. In
other words, the font that the form (face-font 'menu) returns is
not the font being actually used. Please compare image1 and 2.
Furthermore, I tried an X resource for setting the font for the
menu face as follows:
*menubar*Font: -*-helvetica-bold-o-normal--14-*-iso8859-1
It works and Emacs uses the oblique font in the menu bar.
However, (face-font 'menu) seems to always return
"-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1"
if the form (set-face-font 'menu "foo") has never been performed.
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
Thanks Handa-san for following up.
> In <[EMAIL PROTECTED]> Handa-san wrote:
>> (let ((japanese (decode-coding-string "\e$B%F%9%H\e(B" 'iso-2022-jp)))
>> (easy-menu-define testing-menu global-map "Testing."
>> `("Testing"
>> [,japanese (lambda nil (interactive) (message ,japanese)) t]))
>> (easy-menu-add testing-menu global-map))
> It works for me (my Emacs also uses LUCID) both in
> ja_JP.EUC-JP and en_US.UTF-8. In which locale did you test
> it?
The locale command returns the following in the PCs, running
Fedora Core 6 Linux, both in the office and home.
LANG=ja_JP.eucjp
LC_CTYPE=ja_JP.eucjp
LC_NUMERIC=C
LC_TIME=C
LC_COLLATE=C
LC_MONETARY=C
LC_MESSAGES=C
LC_PAPER=C
LC_NAME=C
LC_ADDRESS=C
LC_TELEPHONE=C
LC_MEASUREMENT=C
LC_IDENTIFICATION=C
LC_ALL=
Those are set globally in the systems and I don't modify any of
them in Emacs. I verified it doesn't work in both the PCs.
>> I found the way to make it work. That is to re-set the font for
>> the `menu' face as follows:
>> (set-face-font 'menu (face-font 'menu))
>> But I don't think this is the right way. WDYT?
> I have no idea why it makes any change.
I'll look into it further...
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't display Japanese text in menu bar
Hi,
I noticed that Japanese text cannot be displayed in the menu bar.
I use the LUCID menu bar, not the GTK version, and I don't have
X resources. You will be able to reproduce this by starting
Emacs with the -Q option and evaluating the following form:
(let ((japanese (decode-coding-string "\e$B%F%9%H\e(B" 'iso-2022-jp)))
(easy-menu-define testing-menu global-map "Testing."
`("Testing"
[,japanese (lambda nil (interactive) (message ,japanese)) t]))
(easy-menu-add testing-menu global-map))
I found the way to make it work. That is to re-set the font for
the `menu' face as follows:
(set-face-font 'menu (face-font 'menu))
But I don't think this is the right way. WDYT?
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Slow operations on buffers of tens of megabytes
> In <[EMAIL PROTECTED]> Richard Stallman wrote: > Scoring of the messages closer to the beginning of the buffer is fast, > but as we move to higher-numbered messages, that are closer to the end > of such big files/buffers, gnus will only score 2-3 messages per > minute, and that's what kills performance. > Does Gnus make lots of overlays? If so, maybe it needs to call > overlay-recenter from time to time. Could someone please try that > and see if it makes things fast? AFAIK, Gnus uses text properties here and there, but uses overlays not so much. The following one makes Gnus turn off almost overlays: (setq gnus-article-button-face nil gnus-signature-face nil gnus-summary-selected-face nil gnus-treat-highlight-citation nil gnus-treat-emphasize nil) If it makes Gnus fast, improving the performance will be worth trying. However, I didn't feel any difference, though it might be because I don't have huge mail folders. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
> In <[EMAIL PROTECTED]> Richard Stallman wrote: >> I'd say this design decision will certainly cause subtle bugs, such as >> the one we are discussing in this thread. I suggest to modify the >> design to not use encoded strings internally. > I hastened to change the nndoc code so as to use encoded group > names but I agree with you. Though to implement it will take > efforts and a long time, I think it is a subject to have to be > solved in the future anyway. > I don't entirely understand that statement. > Are you about to fix this now, or do you think it should be > delayed? I've already fixed the nndoc code in both the Gnus CVS trunk and the v5-10 branch (it will be merged into the Emacs CVS soon). Although I haven't yet changed the handling of non-ASCII group names (that is, Gnus still represents them in the utf-8 encoded style internally), it won't trouble users. I agree with making Gnus encode non-ASCII group names only when communicating with nntp servers, and I (or someone?) will try it in the future. I think it should be done in the Gnus trunk first, and it will take time for coding, testing, and possibly bug fixing. So, importing it into Emacs will probably be inevitably delayed. At the present time, I don't know whether it is days, weeks or years. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]> Eli Zaretskii wrote: >> Date: Fri, 20 Oct 2006 15:21:53 +0900 >> From: Katsumi Yamaoka <[EMAIL PROTECTED]> >> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] >> >> IIRC, nntp servers understand utf-8 encoded group names. So, >> someone might have considered making Gnus use them internally is >> convenient to communicate with nntp servers. > I'd say this design decision will certainly cause subtle bugs, such as > the one we are discussing in this thread. I suggest to modify the > design to not use encoded strings internally. I hastened to change the nndoc code so as to use encoded group names but I agree with you. Though to implement it will take efforts and a long time, I think it is a subject to have to be solved in the future anyway. BTW, I realized that I misunderstood Zhang Wei's case. The group name is encoded by gb2312, not utf-8, as Handa-san wrote. It might be the default of the nntp server that Zhang Wei uses, or the news administrator might have done something wrong. If it is utf-8, Gnus should work (in other words, there is currently no way to enable Gnus to handle gb2312 encoded group names). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]> Eli Zaretskii wrote: >> Date: Thu, 19 Oct 2006 18:03:55 +0900 >> From: Katsumi Yamaoka <[EMAIL PROTECTED]> >> Cc: Zhang Wei <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >> >> All group names should be utf-8 encoded for the internal use in Gnus > I don't know anything about Gnus, but is this sentence really right? > Gnus is part of Emacs, and Emacs normally doesn't use encoded strings > internally, it only encodes them when it writes them to a file or > sends them to a program. > Did you perhaps mean ``all group names should use characters from the > mule-unicode-* character set''? That would make sense to me. No, Gnus uses `(encode-coding-string "ｎａｍｅ" 'utf-8)' as a group name internally. IIRC, nntp servers understand utf-8 encoded group names. So, someone might have considered making Gnus use them internally is convenient to communicate with nntp servers. I'm not quite sure it is the best way even if the way was easy to enable Gnus to use non-ASCII group names. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote:
>>>>>> In <[EMAIL PROTECTED]> Chong Yidong wrote:
>> So what needs to be changed?
> I'm now looking into it. However, I think improving of nndoc
> might not help Zhang Wei because the problem looked caused by
> the nntp group. So, I'm not urged by myself so much.
>>>>>> In <[EMAIL PROTECTED]>
>>>>>> Zhang Wei <[EMAIL PROTECTED]> wrote:
> [...]
>> (setq gnus-newsrc-alist
>> '(("\301\367\320\30799.\261\276\265\330\262\342\312\324" 3 ((1 . 8)) ((seen
>> (1 . 8...
The following patch enables Gnus to use non-ASCII names in nndoc
groups. I've tested it with the "~/好" file containing mbox
data. After some other tests, I will install it to the Gnus
trunk and the v5-10 branch.
I don't think it solves Zhang Wei's problem anyway, though. I'm
unable to test with nntp groups of non-ASCII names, but IIRC,
Gnus has been completed to run with those groups a couple of
years ago (even if there might still be trivial difficulties).
--8<---cut here---start->8---
*** gnus-group.el~ Mon Jul 17 21:52:02 2006
--- gnus-group.el Fri Oct 20 05:15:50 2006
***
*** 2680,2692
(t (setq err (format "%c unknown. " char))
nil
(setq type found)))
! (let* ((file (expand-file-name file))
!(name (gnus-generate-new-group-name
! (gnus-group-prefixed-name
!(file-name-nondirectory file) '(nndoc "")
(gnus-group-make-group
! (gnus-group-real-name name)
! (list 'nndoc file
(list 'nndoc-address file)
(list 'nndoc-article-type (or type 'guess))
--- 2680,2697
(t (setq err (format "%c unknown. " char))
nil
(setq type found)))
! (setq file (expand-file-name file))
! (let ((name (gnus-generate-new-group-name
! (gnus-group-prefixed-name
! (file-name-nondirectory file) '(nndoc ""
! (encodable (mm-coding-system-p 'utf-8)))
(gnus-group-make-group
! (if encodable
!(mm-encode-coding-string (gnus-group-real-name name) 'utf-8)
!(gnus-group-real-name name))
! (list 'nndoc (if encodable
! (mm-encode-coding-string file 'utf-8)
! file)
(list 'nndoc-address file)
(list 'nndoc-article-type (or type 'guess))
--8<---cut here---end--->8---
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]> Chong Yidong wrote:
> Katsumi Yamaoka <[EMAIL PROTECTED]> writes:
>> I figured out a moment ago that that was wrong approach. All
>> group names should be utf-8 encoded for the internal use in
>> Gnus, so the value ((".*" . utf-8)) is necessary and sufficient.
>> IIUC, the difference between nnrss and nndoc is that the former
>> encodes a non-ASCII group name first.
> So what needs to be changed?
I'm now looking into it. However, I think improving of nndoc
might not help Zhang Wei because the problem looked caused by
the nntp group. So, I'm not urged by myself so much.
>>>>> In <[EMAIL PROTECTED]>
>>>>> Zhang Wei <[EMAIL PROTECTED]> wrote:
[...]
> (setq gnus-newsrc-alist
> '(("\301\367\320\30799.\261\276\265\330\262\342\312\324" 3 ((1 . 8)) ((seen
> (1 . 8...
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]>
>>>>> Reiner Steib wrote:
> On Thu, Oct 19 2006, Katsumi Yamaoka wrote:
>> Gnus uses utf-8 encoded non-ASCII group names internally, those
>> encoded names are saved in the .newsrc.eld file, and they are
>> decoded by utf-8 when displaying. I had no problem when I once
>> tried nnrss groups with Japanese names. So, I cannot imagine
>> what is happening with Zhang Wei, sorry.
> [...]
>> (push '("\\`nndoc\\(?:\\+[^:]+\\)?:")
>> gnus-group-name-charset-group-alist)
>>
>> In addition, just now I noticed it is insufficient to solve the
>> problem. Maybe we need to do the fix here and there in Gnus to
>> enable it to work with non-ASCII nndoc group names.
> The default value of `gnus-group-name-charset-group-alist' is ((".*"
> . utf-8)), so it should cover all groups, IIUC. Or am I
> misunderstanding the issue?
> Why is setting it to nil for nndoc necessary? Is nndoc handled
> differently than other backends?
I figured out a moment ago that that was wrong approach. All
group names should be utf-8 encoded for the internal use in
Gnus, so the value ((".*" . utf-8)) is necessary and sufficient.
IIUC, the difference between nnrss and nndoc is that the former
encodes a non-ASCII group name first.
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote:
> It can be fixed with the following:
> (push '("\\`nndoc\\(\\+?[^:]+\\)?:")
> gnus-group-name-charset-group-alist)
I mistyped it. Here's what I wanted to write.
(push '("\\`nndoc\\(?:\\+[^:]+\\)?:")
gnus-group-name-charset-group-alist)
In addition, just now I noticed it is insufficient to solve the
problem. Maybe we need to do the fix here and there in Gnus to
enable it to work with non-ASCII nndoc group names.
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
> In <[EMAIL PROTECTED]>
> Chong Yidong <[EMAIL PROTECTED]> wrote:
> Zhang Wei <[EMAIL PROTECTED]> writes:
>> `.newsrc.eld' can't save chinese group name in proper coding. When gnus
>> is restarted, all of the articles in groups with chinese name are marked
>> unread. But enter that group, you will find all of the articles are old
>> articles (marked by an `O'). The file in the attachment is the wrong
>> formatted `.newsrc.eld', hope that will be helpful.
> The problem seems to be that when a Chinese group name is given, e.g.
> "好", `gnus-group-insert-group-line' ends up calling
> (decode-coding-string "好" 'utf-8)
> which gives gibberish. Could either the coding systems experts
> (i.e. Handa) or Gnus experts tell us why this is the wrong thing to
> do?
Gnus uses utf-8 encoded non-ASCII group names internally, those
encoded names are saved in the .newsrc.eld file, and they are
decoded by utf-8 when displaying. I had no problem when I once
tried nnrss groups with Japanese names. So, I cannot imagine
what is happening with Zhang Wei, sorry.
> I think the way to reproduce this is as follows:
> 1. save an empty file with a Chinese filename:
>C-x C-f 好 RET RET C-x C-s
>(I simply copied the character into the minibuffer from the HELLO
>file.)
> 2. go to the Gnus group buffer:
>M-x gnus RET
> 3. Open that file as a Gnus group:
>G f
> => Gnus group line is shown in Gibberish
It is caused because of the default value of
`gnus-group-name-charset-group-alist'. It can be fixed with the
following:
(push '("\\`nndoc\\(\\+?[^:]+\\)?:")
gnus-group-name-charset-group-alist)
However, I'm not quite sure making it the new default is
generally good.
Regards,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SMTP Auth Failure
> In <[EMAIL PROTECTED]> Osamu Yamane wrote: > SMTP Auth fails when the authenticatin involves sending strings of > 77 characters or longer. This seems to be solved by applying the > following patch: > ** BEGINS HERE ** > *** smtpmail.el.orig Sat Aug 5 08:35:34 2006 > --- smtpmail.el Mon Aug 7 21:24:03 2006 [...] > *** 549,560 [...] > ! process (base64-encode-string (smtpmail-cred-user cred))) [...] > --- 549,560 [...] > ! process (base64-encode-string (smtpmail-cred-user cred) t)) The present code differs from Yamane-san's fix. Here's a correction: *** smtpmail.el~Thu Sep 28 21:59:30 2006 --- smtpmail.el Mon Oct 2 03:17:10 2006 *** *** 554,560 (>= (car ret) 400)) (throw 'done nil)) (smtpmail-send-command !process (base64-encode-string (smtpmail-cred-user cred t))) (if (or (null (car (setq ret (smtpmail-read-response process (not (integerp (car ret))) (>= (car ret) 400)) --- 554,560 (>= (car ret) 400)) (throw 'done nil)) (smtpmail-send-command !process (base64-encode-string (smtpmail-cred-user cred) t)) (if (or (null (car (setq ret (smtpmail-read-response process (not (integerp (car ret))) (>= (car ret) 400)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tramp-touch doesn't mind timezone
Hi, When I copy a file from Japan to US using Tramp+ssh, the modtime of the remote file gains 14 hours. It is because `tramp-touch' sets the modtime expressed in Japan time to the remote file. You will be able to reproduce it even with the local hosts by changing the value of TZ in the shell-rc file in either host. Here is a tiny patch to solve the problem: 2006-06-15 Katsumi Yamaoka <[EMAIL PROTECTED]> (tiny change) * net/tramp.el (tramp-touch): Use UTC to express time. *** tramp.el~ Thu May 11 08:20:52 2006 --- tramp.elThu Jun 15 10:41:29 2006 *** *** 5017,5031 (defun tramp-touch (file time) "Set the last-modified timestamp of the given file. TIME is an Emacs internal time value as returned by `current-time'." ! (let ((touch-time (format-time-string "%Y%m%d%H%M.%S" time))) (if (tramp-tramp-file-p file) (with-parsed-tramp-file-name file nil (let ((buf (tramp-get-buffer multi-method method user host))) (unless (zerop (tramp-send-command-and-check multi-method method user host ! (format "touch -t %s %s" touch-time ! localname))) (pop-to-buffer buf) (error "tramp-touch: touch failed, see buffer `%s' for details" buf --- 5017,5032 (defun tramp-touch (file time) "Set the last-modified timestamp of the given file. TIME is an Emacs internal time value as returned by `current-time'." ! (let ((touch-time (format-time-string "%Y%m%d%H%M.%S" time t))) (if (tramp-tramp-file-p file) (with-parsed-tramp-file-name file nil (let ((buf (tramp-get-buffer multi-method method user host))) (unless (zerop (tramp-send-command-and-check multi-method method user host ! (format "TZ=UTC; export TZ; touch -t %s %s" touch-time ! localname) ! t)) (pop-to-buffer buf) (error "tramp-touch: touch failed, see buffer `%s' for details" buf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-after-load bug
> In <[EMAIL PROTECTED]> Richard Stallman wrote: > (eval-after-load "w3m" FORM) [...] > While the FORM should be evaluated after the w3m.elc module is > loaded, it is done after the mime-w3m.elc module is loaded. > I think I fixed that. > Please test it. Works fine. Thank you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-after-load bug
> In <[EMAIL PROTECTED]> Richard Stallman wrote: > In addition to this, now it is hard to access a certain element > of `after-load-alist'. > It is very kludgy to edit `after-load-alist' in this way. > Even for one file of Gnus to communicate with another > using `after-load-alist' is kludgy. Don't do it that way! I agree. I've simply removed that section from the Gnus CVS repository (the changes will be propagated to Emacs soon). I had added it in order to make the after-load form be evaluated only once and reduce the size of `after-load-alist'. However, it is probably a needless affair. > The right way to do this sort of job is to defvar a hook variable, > and call it from the right place. Then you can edit it wherever > you want, and it will be clear. That is the best way. However, since the Mule-UCS package which provides the "un-define" module was widely used then, I chose to use such a kludgy way. > Please remove the use of `eval-after-load' and do that instead. Done. Thank you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-after-load bug
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote:
[...]
> I have the following after-load form:
> (eval-after-load "w3m" FORM)
> And now it is incorporated into `after-load-alist' as:
> ("\\ While the FORM should be evaluated after the w3m.elc module is
> loaded, it is done after the mime-w3m.elc module is loaded.
> Since the FORM requires some variables and functions that
> w3m.elc provides but it has not been loaded yet at that time,
> the FORM simply stops by an error. Any idea?
In addition to this, now it is hard to access a certain element
of `after-load-alist'. Formerly, we could extract an element
which is associated with "MODULE" as follows:
(assoc "MODULE" after-load-alist)
Actually gnus/mm-util.el does a similar thing. (It is done
only in XEmacs, though. So, it is not serious for the moment).
Here's an extract:
(defun mm-enrich-utf-8-by-mule-ucs ()
"docstring"
(unless (cdr (delete '(mm-enrich-utf-8-by-mule-ucs)
(assoc "un-define" after-load-alist)))
(setq after-load-alist
(delete '("un-define") after-load-alist)))
...)
(if (featurep 'xemacs)
(eval-after-load "un-define" '(mm-enrich-utf-8-by-mule-ucs))
...)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
eval-after-load bug
Hi,
I have a trouble that seems to be caused by this change:
2006-05-24 Alan Mackenzie <[EMAIL PROTECTED]>
[...]
* subr.el (eval-after-load): Fix the doc-string. Allow FILE to
match ANY loaded file with the right name, not just those in
load-path. Put a regexp matching the file name into
after-load-alist, rather than the name itself.
I have the following after-load form:
(eval-after-load "w3m" FORM)
And now it is incorporated into `after-load-alist' as:
("\\http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
re-search bug in emacs-unicode-2
Hi, In the latest emacs-unicode-2, re-search doesn't work with certain patterns. For instance: (with-temp-buffer (insert "i.") (goto-char (point-max)) (re-search-backward "i\\." nil t)) => nil (with-temp-buffer (insert "i.") (goto-char (point-min)) (re-search-forward "i\\." nil t)) => nil In GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-02-28 on pastis X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--verbose' '--without-xim'' Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `C-h c' always inserts results
> In <[EMAIL PROTECTED]> Richard M. Stallman wrote: > I will fix this. Sorry. Could you commit the fix? ;-) It seems to be the following. *** help.el~Tue Feb 14 21:51:35 2006 --- help.el Tue Feb 21 01:40:07 2006 *** *** 580,584 (list key ! (prefix-numeric-value current-prefix-arg) ;; If KEY is a down-event, read the corresponding up-event ;; and use it as the third argument. --- 580,584 (list key ! current-prefix-arg ;; If KEY is a down-event, read the corresponding up-event ;; and use it as the third argument. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`C-h c' always inserts results
Hi, The former interactive spec of `describe-key-briefly' was "kDescribe key briefly: \nP\np". However, the 2nd arg `insert' is now `(prefix-numeric-value current-prefix-arg)', which comes under "p". Because of this, `C-h c' inserts results into the current buffer even if a prefix arg is not given. Could you fix it? Thanks in advance. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp-complete-symbol is too loquacious in minibuffer
> In <[EMAIL PROTECTED]> Romain Francoise wrote: > Thanks, I resynchronized your patch and installed it. Thanks for your work so quickly. > And by the way, you do have papers for Emacs. Yes, I'll do it. :) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp-complete-symbol is too loquacious in minibuffer
> In <[EMAIL PROTECTED]> Richard M. Stallman wrote: > Please install your patch. Thanks, but I have a write access only to Gnus (in cvs.gnus.org which is gatewayed to Emacs CVS), I haven't worked on the paper to Emacs. Could anyone please take it on? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
lisp-complete-symbol is too loquacious in minibuffer
Hi, When I perform eval-expression in the minibuffer and complete some lisp symbol using the M-TAB key, the result is hidden by the message "Making completion list...done" for a while. That is annoying. It doesn't occur when I perform find-file, etc. Could it be modified as the following? Thanks in advance. --- lisp.el~2005-12-10 11:39:24 + +++ lisp.el 2005-12-21 06:08:50 + @@ -574,23 +574,27 @@ (delete-region beg end) (insert completion) (setq pattern completion)) - (message "Making completion list...") - (let ((list (all-completions pattern obarray predicate))) -(setq list (sort list 'string<)) -(or (eq predicate 'fboundp) -(let (new) - (while list -(setq new (cons (if (fboundp (intern (car list))) -(list (car list) " ") - (car list)) -new)) -(setq list (cdr list))) - (setq list (nreverse new -(if (> (length list) 1) -(with-output-to-temp-buffer "*Completions*" - (display-completion-list list pattern)) - (delete-windows-on "*Completions*"))) - (message "Making completion list...%s" "done"))) + (let ((minibuf-is-in-use + (eq (minibuffer-window) (selected-window +(unless minibuf-is-in-use + (message "Making completion list...")) +(let ((list (all-completions pattern obarray predicate))) + (setq list (sort list 'string<)) + (or (eq predicate 'fboundp) + (let (new) +(while list + (setq new (cons (if (fboundp (intern (car list))) + (list (car list) " ") +(car list)) + new)) + (setq list (cdr list))) +(setq list (nreverse new + (if (> (length list) 1) + (with-output-to-temp-buffer "*Completions*" +(display-completion-list list pattern)) +(delete-windows-on "*Completions*"))) +(unless minibuf-is-in-use + (message "Making completion list...%s" "done") ;;; arch-tag: aa7fa8a4-2e6f-4e9b-9cd9-fef06340e67e ;;; lisp.el ends here ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
DEL key doesn't kill mouse-dragged region
Hi, With the most recent Emacs CVS, NOMIYA Masaru reported he cannot delete the region that is made by dragging the mouse, using DEL key. I also confirmed Emacs 21.4 works but 22.0.50 doesn't. Not much many people might not know such a function, though (and I was not an exception). Isn't it a side effect of some change? Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tiny patch to ange-ftp
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > I noticed those changes cause some other problems. Please > ignore the patch I sent last. I will fix them, verify most of > features and send a new patch again, tomorrow maybe. Sorry. After perusing and testing Juri Linkov's patch, I realized that is the best solution at the present. So I merged them, tested it with various ways, and made a new patch. >>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: (A reply to Juri Linkov) > I tested it briefly. Accessing NetBSD's ftpd seems ok, but it > hangs up when uploading of files for the unknown reason... That was caused by my fault. I was trying to upload a file which contains space characters in the name then. I think there's no way to handle such files using ange-ftp, though it's not serious. 2005-08-11 Juri Linkov <[EMAIL PROTECTED]> * net/ange-ftp.el (ange-ftp-send-cmd): Don't concat ls switches and file name if switches aren't specified. (ange-ftp-ls): Retry to get file-listing without ls switches if the server seems to run NetBSD's ftpd or lukemftpd. 2005-08-11 Katsumi Yamaoka <[EMAIL PROTECTED]> (tiny change) * net/ange-ftp.el (ange-ftp-canonize-filename): Add comments. --8<---cut here---start->8--- --- ange-ftp.el~2005-08-09 21:56:54 + +++ ange-ftp.el 2005-08-11 03:12:01 + @@ -2333,8 +2333,14 @@ ;; `cd' is performed is a directory. (file-name-directory (nth 1 cmd)) 'noerror))) - ;; Concatenate the switches and the target to be used with `ls'. - (setq cmd1 (concat "\"" cmd3 " " cmd1 "\"" + (unless (equal cmd3 "") + ;; Concatenate the switches and the target to be used with `ls', and + ;; the command will be issued as `ls "-switches target" local_file'. + ;; Although this will make it impossible to get a file-listing from + ;; the server which runs some kind of ftpd, e.g., the NetBSD version, + ;; lukemftpd, or equivalent, `ange-ftp-ls' will retry it without + ;; using the switches, like `ls target local_file'. + (setq cmd1 (concat "\"" cmd3 " " cmd1 "\"") ;; First argument is the remote name ((progn @@ -2650,7 +2656,14 @@ ;; `DIR /some/file/.' which leads ange-ftp to ;; believe that /some/file is a directory ;-( nil - ange-ftp-ls-cache-res)) + (if (and (equal ange-ftp-ls-cache-res "") +(not (equal lsargs ""))) + ;; Some kind of ftpd, e.g., the NetBSD version, + ;; lukemftpd, or equivalent returns an empty + ;; file-listing when using non-empty lsargs. + ;; So try without ls arguments. + (ange-ftp-ls file "" parse no-error wildcard) + ange-ftp-ls-cache-res))) (if no-error nil (ange-ftp-error host user @@ -3127,12 +3140,22 @@ (rest (substring name (match-end 0))) (dir (ange-ftp-expand-dir host user tilda))) (if dir - (setq name (cond ((string-equal rest "") -dir) - ((string-equal dir "/") -rest) - (t -(concat dir rest + (setq name +(cond ((string-equal rest "") + ;; The case accessing ~ or ~user. + ;; `dir' may be chroot'ed. + dir) + ((string-equal dir "/") + ;; The case accessing ~/file or ~user/file + ;; in the chroot'ed environment. + ;; `rest' has the value "/file". + rest) + (t + ;; The case accessing ~/file or ~user/file + ;; but chroot is not applied there. `dir' + ;; has the expanded home directory, and + ;; `
Re: tiny patch to ange-ftp
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > Here's a new patch: > 2005-08-10 Katsumi Yamaoka <[EMAIL PROTECTED]> (tiny change) > * net/ange-ftp.el (ange-ftp-send-cmd): Withdraw the last change, > which made it impossible to connect to NetBSD's ftpd; make it work > even when accessing symlinks. > (ange-ftp-ls): Return a single line when listing a file. > (ange-ftp-canonize-filename): Add comments. I noticed those changes cause some other problems. Please ignore the patch I sent last. I will fix them, verify most of features and send a new patch again, tomorrow maybe. Sorry. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tiny patch to ange-ftp
> In <[EMAIL PROTECTED]> Juri Linkov wrote: > The patch below fixes ange-ftp.el to work with both ProFTPD and > lukemftpd (which is seemingly is the same as netbsd ftpd). > This is not a final patch: I like to test it more before installing. I tested it briefly. Accessing NetBSD's ftpd seems ok, but it hangs up when uploading of files for the unknown reason... ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tiny patch to ange-ftp
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > I confirmed it in the ftp.netbsd.org host, oops. I agree to > revert it, er,... I reverted it so that ange-ftp can be used with NetBSD's ftpd as well. Following up to it, I modified `ange-ftp-ls' so as to make it return a single line when listing a file, not a directory. It is necessary when uploading files: > AFAIK, the result of the `ls "-switches remote-file" local-file' > form is required only when updating the dired buffer just after > uploading a file. In addition, after reverting it, while I got another error when accessing symlinks, I already fixed it. Here's a new patch: 2005-08-10 Katsumi Yamaoka <[EMAIL PROTECTED]> (tiny change) * net/ange-ftp.el (ange-ftp-send-cmd): Withdraw the last change, which made it impossible to connect to NetBSD's ftpd; make it work even when accessing symlinks. (ange-ftp-ls): Return a single line when listing a file. (ange-ftp-canonize-filename): Add comments. --8<---cut here---start->8--- *** ange-ftp.el~Tue Aug 9 21:56:54 2005 --- ange-ftp.el Wed Aug 10 11:14:04 2005 *** *** 2328,2340 ;; We cd and then use `ls' with no directory argument. ;; This works around a misfeature of some versions of netbsd ftpd. (unless (equal cmd1 ".") ! (setq result (ange-ftp-cd host user ! ;; Make sure the target to which ! ;; `cd' is performed is a directory. ! (file-name-directory (nth 1 cmd)) ! 'noerror))) ! ;; Concatenate the switches and the target to be used with `ls'. ! (setq cmd1 (concat "\"" cmd3 " " cmd1 "\"" ;; First argument is the remote name ((progn --- 2328,2342 ;; We cd and then use `ls' with no directory argument. ;; This works around a misfeature of some versions of netbsd ftpd. (unless (equal cmd1 ".") ! (setq result (condition-case nil ! (ange-ftp-cd host user (nth 1 cmd)) !(error ! ;; The target `(nth 1 cmd)' might be a file, so ! ;; we attempt to cd to the parent directory. ! (ange-ftp-cd host user ! (file-name-directory (nth 1 cmd)) ! 'noerror) ! (setq cmd1 cmd3))) ;; First argument is the remote name ((progn *** *** 2638,2643 --- 2640,2663 ;; that is being queried is other than Unix i.e. VMS ;; returns an ls format that really sucks. (run-hooks 'ange-ftp-after-parse-ls-hook) + ;; If `file' is a file, we remove other lines. + (unless parse + (goto-char (point-min)) + (let ((re (concat "[\t ]+" (regexp-quote file) "$")) + lines) + (while (re-search-forward re nil t) + (push (cons (- (match-end 0) (match-beginning 0)) + (buffer-substring +(line-beginning-position) +(match-end 0))) + lines)) + (erase-buffer) + (insert + ;; There may be files of which names begin with SPC. + (if (> (length lines) 1) + (cdar (sort lines 'car-less-than-car)) +(or (cdar (last lines)) "")) + "\n"))) (setq ange-ftp-ls-cache-file key ange-ftp-ls-cache-lsargs lsargs ; For dumb hosts-types this is *** *** 3127,3138 (rest (substring name (match-end 0))) (dir (ange-ftp-expand-dir host user tilda))) (if dir ! (setq name (cond ((string-equal rest "") !dir) ! ((string-equal dir "/") !rest) ! (t !(concat dir rest (error "User \"%s\" is not known" (substring tilda
Re: tiny patch to ange-ftp
>>>>> In <[EMAIL PROTECTED]> Michael Albinus wrote: > Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> Recently, I located the causes of the problems and succeeded in >> fixing of them. The patch is below. Could anyone verify it? > I've committed your patch to Emacs CVS. Looks good to me. Thank you for applying it, anyway. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tiny patch to ange-ftp
> In <[EMAIL PROTECTED]> Stefan Monnier wrote: >> !;; Concatenate the switches and the target to be used with `ls'. >> !(setq cmd1 (concat "\"" cmd3 " " cmd1 "\"" > This looks wrong to me. NetBSD's ftpd does not accept two arguments to the > LS command, last I tried. Concatenating them and enclosing them in double > quotes won't make any difference either: it'll just consider that you want > to see the listing of the "-alF /foo" directory which probably > doesn't exist. I confirmed it in the ftp.netbsd.org host, oops. I agree to revert it, er, though I think it means no one can upload files rightly using ange-ftp. Sigh. AFAIK, the result of the `ls "-switches remote-file" local-file' form is required only when updating the dired buffer just after uploading a file. It seems to be substituted by replacing the whole dired buffer with the result of the `ls -switches' form (it is similar to the case where the `g' command is performed). It would be better since it will update not only the uploaded file but also the timestamp for the parent directory; moreover, the order of the remote files will also be updated (if the switches contain the `-t' option). I don't have a concrete plan now, though. >> ! (setq name (cond ((string-equal rest "") >> ! dir) >> !((string-equal dir "/") >> ! rest) >> !(t >> ! (concat dir rest > This looks OK, tho maybe it's worth trying to figure out whether it's > correct for `rest' to be empty here or whether it is the symptom of > another bug. If this patch is the right fix, then it should include > a comment explaining why and in which case `rest' can be empty. I'll look into it again precisely and post additional comments, later. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tiny patch to ange-ftp
Hi, While it is said that the plain ftp is not secure, it is still useful to be used in the intra net. Actually, I was using the old ange-ftp.el (w/ some modifications) in the office to manage remote files since it was pretty fast than tramp and ssh. There are two reasons why I used the old ange-ftp.el. One is that the recent one (which runs with tramp-ftp.el) issues the cd command for a remote file, not a directory, when I open two dired windows (one is for the local directory, the other is for the remote directory) and copy the local file to the remote directory using the C (dired-do-copy) command. It breaks the dired session even though the file copying is actually successful. For instance, it can be observed at the ftp session as follows when copying the local file "~/FILE" to the remote directory "/ftp:[EMAIL PROTECTED]:/tmp/". ftp> type binary 200 Switching to Binary mode. put /home/yamaoka/FILE /tmp/FILE ftp> 227 Entering Passive Mode (127,0,0,1,214,62) 150 Ok to send data. 226 File receive OK. type ascii ftp> 200 Switching to ASCII mode. cd /tmp/FILE ftp> 550 Failed to change directory. cd /tmp/FILE ftp> 550 Failed to change directory. The other is that Emacs reports errors when I open the home directory of the remote host in which the chroot is applied so as to change the home directory as the root directory. Two typical patterns can be reproduced even by accessing the anonymous ftp site as follows: M-x dired RET /ftp:[EMAIL PROTECTED]:~/ RET pattern 1 (this is normally observed at the first time) = 230-(220 GNU FTP server ready.) [...] 230 Login successful. hash ftp> Hash mark printing on (1024 bytes/hash mark). pwd ftp> 257 "/" cd /home/ ftp> 550 Failed to change directory. cd /home/ ftp> 550 Failed to change directory. cd /home/yamaoka/ ftp> 550 Failed to change directory. cd /home/yamaoka/ ftp> 550 Failed to change directory. pattern 2 (this is observed after trying it many times) = 230-(220 GNU FTP server ready.) [...] 230 Login successful. hash ftp> Hash mark printing on (1024 bytes/hash mark). pwd ftp> 257 "/" cd /ftp:[EMAIL PROTECTED]:/ ftp> 550 Failed to change directory. cd /ftp:[EMAIL PROTECTED]:/ ftp> 550 Failed to change directory. Recently, I located the causes of the problems and succeeded in fixing of them. The patch is below. Could anyone verify it? Thanks in advance. 2005-08-05 Katsumi Yamaoka <[EMAIL PROTECTED]> (tiny change) * net/ange-ftp.el (ange-ftp-send-cmd): Make it work properly with uploading files. (ange-ftp-canonize-filename): Handle file names beginning with ~ correctly. --8<---cut here---start->8--- *** ange-ftp.el~Fri Aug 5 14:08:14 2005 --- ange-ftp.el Fri Aug 5 14:44:11 2005 *** *** 2328,2335 ;; We cd and then use `ls' with no directory argument. ;; This works around a misfeature of some versions of netbsd ftpd. (unless (equal cmd1 ".") ! (setq result (ange-ftp-cd host user (nth 1 cmd) 'noerror))) ! (setq cmd1 cmd3))) ;; First argument is the remote name ((progn --- 2328,2340 ;; We cd and then use `ls' with no directory argument. ;; This works around a misfeature of some versions of netbsd ftpd. (unless (equal cmd1 ".") ! (setq result (ange-ftp-cd host user ! ;; Make sure the target to which ! ;; `cd' is performed is a directory. ! (file-name-directory (nth 1 cmd)) ! 'noerror))) ! ;; Concatenate the switches and the target to be used with `ls'. ! (setq cmd1 (concat "\"" cmd3 " " cmd1 "\"" ;; First argument is the remote name ((progn *** *** 3122,3129 (rest (substring name (match-end 0))) (dir (ange-ftp-expand-dir host user tilda))) (if dir ! (setq name (if (string-equal dir "/") ! rest (concat dir rest))) (error "User \"%s\" is not known" (substring tilda 1) --- 3127,3138 (rest (substring name (match-end 0))) (dir (ange-ftp-expand-dir host user tilda))) (if dir ! (setq name (cond ((string-equal rest "") !dir) ! ((string-equal dir "/") !rest) ! (t !(concat dir res
Re: Can't costomize font for the `menu' face
> In <[EMAIL PROTECTED]> Jan D. wrote: > Basically it is a font <=> locale problem. I suspect you have UTF-8 as > your locale coding, but X does not seem capable of using fonts in 10646 > coding in this case. So X needs fonts in many codings to cover UTF-8. That seems true, though I changed the locale from UTF-8 to ja_JP.eucjp since some applications don't support UTF-8. > Apparently fixing the font path made X find all those fonts it needed. > You can add font directories to /etc/X11/fs/config (or similar) and > restart the xfs (X font server) and keep unix/:7000 as font path. I've moved the fonts-to-add from ~/.Xclients to /etc/X11/fs/config just now. This is the best way for me. Thank you so much! ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: >> Thanks. I tried it, however I'm not still able to set the >> `menu' font. > Oops, your fix did the trick in the Solaris 2.6 display. I'm > using the Fedora Core 4 linux normally, and it will be a problem > of occurring only with FC4's X server (or the window manager). > I'll look into it, though I might be able to do nothing... Solved! The solution is quite basic; it is to add all the existing font directories to the font path in the proper order using the xset command. Formerly, the font path contained only `unix/:7100'. The reasons I forgot to do it are: The fonts which were used in normal Emacs buffers could be set correctly. Furthermore, all the fonts including the menu font could be set in Emacs 21.x. Before upgrading RHL9 to FC4 (a couple of weeks ago), there was no problem even in Emacs 22. The font path contained only a few directories which I had installed and `unix/:7100' then. I don't know the difference between RHL9 and FC4 in detail, but all's well that ends well. :) Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: descibe-mode problem
Hello, The beginning was a bug report submitted by Hiroshi Fujishima. The problem is that the `C-h m' command causes an error in the Gnus group buffer in which the topic mode is turned on. It happens only with Emacs CVS. You can find the report and the replies in: http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=8420 By the tests with Emacs 20.7 through 23.0.0 and XEmacs 21.1.14 through 21.5-b21, I realized the 5th arg of `add-minor-mode' is useless in Emacs and can be deleted, and I carried it out in the v5-10 branch and the trunk. If you encounter any trouble with those changes, please let me know. Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: descibe-mode problem
> In [semi-gnus-ja : No.13869] Richard M. Stallman wrote: > I'm confused. That is the same as the case where the 5th arg is > omitted. Does it mean that to specify the 5th arg of > `add-minor-mode' is meaningless? > I am not 100% sure, but the normal convention is that the > 5th arg should be the same as the 1st arg, and it is clearly > better to follow that convention. I agree with you basically. And now, I think the 5th arg is useless in Emacs since the function doesn't seem to be used anywhere. So, I'll make it nil for Emacs in Gnus v5.11 later. In XEmacs, I realized the function is incorporated into the menu which is opened by clicking of the mouse-3 on the minor-mode indicator in the mode-line. The code used in Gnus is as follows: (add-minor-mode 'gnus-topic-mode " Topic" gnus-topic-mode-map nil (lambda (&rest junk) (interactive) (gnus-topic-mode nil t))) The interactive spec of the `gnus-topic-mode' function is: (defun gnus-topic-mode (&optional arg redisplay) "Minor mode for topicsifying Gnus group buffers." (interactive (list current-prefix-arg t)) The 2nd arg `redisplay' should be t for the interactive use. I guess the 5th arg of `add-minor-mode' above is for only XEmacs, and it wasn't called interactively from the menu in the past maybe, while I confirmed the most recent XEmacsen call it interactively. So, I'll remove the 5th arg unconditionally in No Gnus v0.4, but remove it for only Emacs in Gnus v5.11 (which is included in Emacs CVS, but also supports old XEmacsen). ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > Oops, your fix did the trick in the Solaris 2.6 display. I'm > using the Fedora Core 4 linux normally, and it will be a problem > of occurring only with FC4's X server (or the window manager). > I'll look into it, though I might be able to do nothing... Well, there's no problem in Emacs 21.1 through 21.4 to set the menu font using: (set-face-font 'menu "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*") even in the Fedora Core 4 display. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > Thanks. I tried it, however I'm not still able to set the > `menu' font. Oops, your fix did the trick in the Solaris 2.6 display. I'm using the Fedora Core 4 linux normally, and it will be a problem of occurring only with FC4's X server (or the window manager). I'll look into it, though I might be able to do nothing... ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
>>>>> In <[EMAIL PROTECTED]> Jan D. wrote: > Katsumi Yamaoka wrote: >> I wrote in the ~/.emacs file as: >> >>(set-face-background 'menu "LemonChiffon2") >>(set-face-foreground 'menu "Brown") >>(set-face-font 'menu "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*") >> >>I expected them to set the menu bar appearance. In Emacs 21.4, >>the colors and the font were set as I hoped. However, in Emacs >>22, only the font is not set. > I assume you use the Lucid toolkit, but in the future, use M-x > report-emacs-bug so this information is included. You're right. I'm sorry not to have written the important information. > I have checked in a fix for this, please try it. Thanks. I tried it, however I'm not still able to set the `menu' font. The following works: (set-face-font 'default "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*") But for the `menu' face font, the menu-bar appearance is not different from the case where Emacs starts with the -q option, without X resources files. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: descibe-mode problem
> In [semi-gnus-ja : No.13861] Richard M. Stallman wrote: > I report this problem to semi-gnus-ja mailing-list. Yamaoka-san who > is one of Gnus developer said it seem to be Emacs's problem: Though > add-minor-mode's 5th argument in the definition of gnus-topic-mode > is lambda expression, describe-mode check it by fboundp. > The 5th arg should be the same as the 1st arg. I'm confused. That is the same as the case where the 5th arg is omitted. Does it mean that to specify the 5th arg of `add-minor-mode' is meaningless? If it is true, I'll scan Gnus and remove such ones. Actually, I couldn't find any function which refers the `:minor-mode-function' property. Otherwise, the following patch avoids that error at least. *** help.el~Tue Jul 5 21:54:43 2005 --- help.el Mon Jul 11 23:38:12 2005 *** *** 730,736 (dolist (mode minor-mode-list) ;; Document a minor mode if it is listed in minor-mode-alist, ;; non-nil, and has a function definition. ! (let ((fmode (or (get mode :minor-mode-function) mode))) (and (boundp mode) (symbol-value mode) (fboundp fmode) (let ((pretty-minor-mode --- 730,741 (dolist (mode minor-mode-list) ;; Document a minor mode if it is listed in minor-mode-alist, ;; non-nil, and has a function definition. ! (let ((fmode (get mode :minor-mode-function))) ! ;; FIXME: Currently it works properly only when the `fmode' ! ;; function specified as the 5th argument of `add-minor-mode' ! ;; is a function symbol. ! (unless (and fmode (symbolp fmode)) ! (setq fmode mode)) (and (boundp mode) (symbol-value mode) (fboundp fmode) (let ((pretty-minor-mode ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `insert' deactivates active region
> In [emacs-w3m : No.08280] Stefan Monnier wrote: > The way Emacs detects when to deactivate the mark is by making all > buffer-modifying functions set the deactivate-mark variable. This variable > is not buffer-local so a modification in one buffer can (incorrectly) > deactivate the mark in another, as in your example. > Until this is fixed, the typical workaround is to wrap your buffer > modification in (let (deactivate-mark) ...). Now I've just done so in the emacs-w3m CVS repository. Thank you. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `insert' deactivates active region
> In [emacs-w3m : No.08278] Richard M. Stallman wrote: > Please read and try the following Lisp code. In the *testing* > buffer, you may see you cannot activate the region by using > C-SPC and C-f, etc. Furthermore, M-w cannot be used to copy > text, either. > This is not a bug. Modifying the buffer deactivates the mark. I realized it thanks to Masatake YAMATO just now. Sorry for the noises. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `insert' deactivates active region
> In <[EMAIL PROTECTED]> Masatake YAMATO wrote: > Yamaoka-san, could you try this code? [...] > (insert "foo") > (setq deactivate-mark nil) [...] > or [...] > (let (deactivate-mark) > (insert "foo")) Oh, I didn't know such a special variable. That solution seems very good! I confirmed it is effective in Emacs 20 through 23. Thank you. > If you think this work-around is not enough, talk to emacs-devel. > I'll write a report my investigation about this bug. Is it really a bug? The docstring for the deactivate-mark variable says: If an editing command sets this to t, deactivate the mark afterward. The command loop sets this to nil before each command, and tests the value when the command returns. Buffer modification stores t in this variable. Now I came to think it is no wonder that `insert' sets `deactivate-mark', because `insert' really edits the buffer. The real trouble is that we didn't know it, isn't it? ;-) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `insert' deactivates active region
> In <[EMAIL PROTECTED]> Masatake YAMATO wrote: > I could reproduce this bug with your example. Thanks for the confirmation. > Here is a work-around: [...] > (set (make-local-variable 'mark-even-if-inactive) t) It enables users to copy or kill the region. However, that the region is not highlighted does not satisfy those who use the transient-mark-mode. The solution I'm testing now is: (let ((buffer (get-buffer-create "*testing*"))) (pop-to-buffer buffer) (erase-buffer) (insert "Hello World\n") (goto-char (point-min)) (set (make-local-variable 'transient-mark-mode) t) (add-hook 'post-command-hook (lambda nil (let ((mk (when (and transient-mark-mode mark-active) (mark (prog1 (with-temp-buffer (insert "foo") ) (when mk (run-at-time 1e-9 nil #'push-mark mk t t) nil t)) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`insert' deactivates active region
Hi, Please read and try the following Lisp code. In the *testing* buffer, you may see you cannot activate the region by using C-SPC and C-f, etc. Furthermore, M-w cannot be used to copy text, either. (let ((buffer (get-buffer-create "*testing*"))) (pop-to-buffer buffer) (erase-buffer) (insert "Hello World\n") (goto-char (point-min)) (set (make-local-variable 'transient-mark-mode) t) (add-hook 'post-command-hook (lambda nil (with-temp-buffer (insert "foo") )) nil t)) One of the ways to solve the problem I found is to remove the `(insert "foo")' line. This problem occurs not only with Emacs 22, but also 21 and 20. A similar code is used in emacs-w3m and we are discussing the solution which is effective on all Emacs versions (there's already a promising solution). Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
> In <[EMAIL PROTECTED]> Richard M. Stallman wrote: > With Emacs CVS, the following form doesn't produce the expected > result. > (set-face-font 'menu "-*-any-font-name-*") > What result would you expect from that input? > I don't expect it to exist. > Perhaps when you wrote "any-font-name" you meant to replace > it with some font name. If so, you've omitted important information. > Would you please provide one *precise* test case? I wrote in the ~/.emacs file as: (set-face-background 'menu "LemonChiffon2") (set-face-foreground 'menu "Brown") (set-face-font 'menu "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*") I expected them to set the menu bar appearance. In Emacs 21.4, the colors and the font were set as I hoped. However, in Emacs 22, only the font is not set. Although the font for the menu bar can be specified with the X resource as Emacs*menubar*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-* , I want to remove it from the resource file since only the one for Emacs is it. It enables me to run the real vanilla Emacs by only typing `emacs -q'. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`make-frame' makes taller frame than the specified height
Hi, Is it only to me? The height of the new frame grows by 3 when evaluating the following form: (let ((params (frame-parameters (selected-frame (make-frame (delq (assq 'minibuffer params) params))) It occurs only in Emacs which was built as: GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) Furthermore, I also tried it with: GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.7) That problem is not there. (However, the new frame is not created in the same position. It seems to be due to the window manager, though.) I did them in the Fedora Core 4 platform. Since `raise-frame' does nothing in this platform, I'm trying to advise it to be replaced with `delete-frame' and `make-frame' as follows: (defadvice raise-frame (around make-new-frame-in-the-same-place (&optional frame) activate) "Make it work." (unless frame (setq frame (selected-frame))) (let* ((params (frame-parameters frame)) (height (assq 'height params))) (setcdr height (- (cdr height) 3)) (make-frame (delq (assq 'minibuffer params) params)) (delete-frame frame))) Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't costomize font for the `menu' face
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > Is it a bug or is there another way to do that? Though I know the way to use the X resources, I want to manage all in Elisp. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't costomize font for the `menu' face
Hi, With Emacs CVS, the following form doesn't produce the expected result. (set-face-font 'menu "-*-any-font-name-*") Emacs sets an unknown font and issues a warning to the console as follows: Warning: Cannot convert string "-Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1,-Adobe-Courier-Medium-R-Normal--12-*-*-*-*-*-*-*,-*-*-Medium-R-Normal--12-*-*-*-*-*-*-*,-*-*-*-*-*-*-12-*-*-*-*-*-*-*" to type FontStruct Is it a bug or is there another way to do that? Thanks in advance. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adaptive-fill bug?
>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > I did the overstepping but I'll withdraw the changes in Gnus and > SEMI. I've withdrawn them. Thanks. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adaptive-fill bug?
> In [emacs-w3m : No.08172] Stefan Monnier wrote: > Does the patch below fix your problem? Very good. It seems to be a right course not to look back on paragraph-start in that situation. Furthermore, ignoring long prefix completes it. Could you please install it? >> Though we can solve it for that case by binding adaptive-fill-mode >> to nil, I'm hesitating to do so. I appreciate any comment. > I agree. Binding adaptive-fill-mode to nil is nothing more than > a workaround. I see. I did the overstepping but I'll withdraw the changes in Gnus and SEMI. Thank you. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adaptive-fill bug?
>>>>> In [emacs-w3m : No.08153] Katsumi Yamaoka wrote: > (with-temp-buffer > (insert-char ?- 70) > (let ((fill-column 70) > (adaptive-fill-mode t)) > (fill-region (point-min) (point-max > => "fill-prefix too long for specified width" > Is it reasonable that the form causes an error? Similar errors > have occurred when decoding the text/enriched MIME messages which > contain long dash lines. The enriched-decode function which runs > fill-region is performed then. > Though we can solve it for that case by binding adaptive-fill-mode > to nil, I'm hesitating to do so. I appreciate any comment. I've implemented it in Gnus and SEMI. Probably it is not necessary to turn on the adaptive-fill-mode to decode text/enriched messages. Regards, ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adaptive-fill bug?
>>>>> In [emacs-w3m : No.08153] Katsumi Yamaoka wrote: > (with-temp-buffer > (insert-char ?- 70) > (let ((fill-column 70) > (adaptive-fill-mode t)) > (fill-region (point-min) (point-max > => "fill-prefix too long for specified width" No problem in Emacs 21. The cause seems to be the following: 2001-10-30 Stefan Monnier <[EMAIL PROTECTED]> [...] (paragraph-start): Change default to the `text-mode' value. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
