`set-default-font' does not function anymore
`set-default-font' does not function anymore, I've got the following settings in my .emacs: (create-fontset-from-fontset-spec (concat -*-courier-medium-r-normal-*-14-*-*-*-*-*-fontset-courier, chinese-gb2312:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gb2312*-*, mule-unicode-0100-24ff:-*-simsun-medium-r-*-*-14-*-*-*-c-*-iso10646*-*, korean-ksc5601:-*-*-medium-r-*-*-14-*-*-*-*-*-ksc5601*-*, chinese-cns11643-5:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-6:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-7:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, sjis:-*-medium-r-normal--14-*-jisx0208*-*)) (set-default-font fontset-courier) but M-x describe-fontset RET RET shows the current frame still using `fontset-default', I don't know when does this happens, but the setting works fine several weeks ago. Same problem with Emacs 22 and the emacs-unicode-2 branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: More mode-line stuff
Nick Roberts [EMAIL PROTECTED] writes: If you move the mouse over the line=number indicator you get the tooltip: mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete this so you might expect mouse-3 to delete the indicator/turn off the mode and not the window. I think mouse-3 _should_ turn off the mode and that mouse-3 should also turn off the minor-mode when the mouse is over one of the minor-mode indicators grouped within the round brackets with the mayor mode (currently it pops up the list of minor modes (mode-line-menu-mode-1) just as it does over the mayor mode indicator). Let's not change the functionality at this stage. We can change the tooltip message to mouse-3: delete window, which should be clearer. Also (maybe because the default font size has changed) the message mouse-1: select (drag to resize), mouse-2: delete other windows, mouse-3: delete this window fits on one line in the tooltip (the comment in bindings suggests that at one time it didn't), That comment is referring to the commented-out message ;;\ ;; mouse-1: select window, mouse-2: delete others, mouse-3: delete, ;; drag-mouse-1: resize, C-mouse-2: split horizontally ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `set-default-font' does not function anymore
Zhang Wei [EMAIL PROTECTED] writes: `set-default-font' does not function anymore, I've got the following settings in my .emacs: (create-fontset-from-fontset-spec (concat -*-courier-medium-r-normal-*-14-*-*-*-*-*-fontset-courier, chinese-gb2312:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gb2312*-*, mule-unicode-0100-24ff:-*-simsun-medium-r-*-*-14-*-*-*-c-*-iso10646*-*, korean-ksc5601:-*-*-medium-r-*-*-14-*-*-*-*-*-ksc5601*-*, chinese-cns11643-5:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-6:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-7:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, sjis:-*-medium-r-normal--14-*-jisx0208*-*)) (set-default-font fontset-courier) but M-x describe-fontset RET RET shows the current frame still using `fontset-default', I don't know when does this happens, but the setting works fine several weeks ago. I can't reproduce this. With .emacs containing (create-fontset-from-fontset-spec (concat -*-courier-medium-r-normal-*-14-*-*-*-*-*-fontset-courier, chinese-gb2312:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gb2312*-*, mule-unicode-0100-24ff:-*-simsun-medium-r-*-*-14-*-*-*-c-*-iso10646*-*, korean-ksc5601:-*-*-medium-r-*-*-14-*-*-*-*-*-ksc5601*-*, chinese-cns11643-5:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-6:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, chinese-cns11643-7:-*-simsun-medium-r-*-*-14-*-*-*-c-*-gbk*-*, sjis:-*-medium-r-normal--14-*-jisx0208*-*)) (set-default-font fontset-courier) M-x describe-fontset RET RET gives Fontset: -*-courier-medium-r-normal-*-14-*-*-*-*-*-fontset-courier CHARSET or CHAR RANGE FONT NAME - - ascii -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1 [-Adobe-Courier-Bold-R-Normal--14-100-100-100-M-90-ISO8859-1] [-Adobe-Courier-Medium-R-Normal--14-100-100-100-M-90-ISO8859-1] ... Without those lines in .emacs, M-x describe-fontset RET RET gives Fontset: -*-*-medium-*-*-*-14-*-*-*-*-*-fontset-startup CHARSET or CHAR RANGE FONT NAME - - ascii -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 [-Misc-Fixed-Bold-R-Normal--14-130-75-75-C-70-ISO8859-1] [-Misc-Fixed-Medium-R-Normal--14-130-75-75-C-70-ISO8859-1] latin-iso8859-1 -misc-fixed-*-iso8859-1 latin-iso8859-2 -*-iso8859-2 So it does take effect. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ruler-mode/key-bindings
Ruler-mode, Emacs reports that mouse clicks in the header-line are undefined e.g header-line S-mouse-1 is undefined even though it is bound to ruler-mode-mouse-set-left-margin and performs that function. The commentary says: ;; ... It works only on Emacs 21. but presumably this is not true. -- Nick http://www.inet.net.nz/~nickrob ___ 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: More mode-line stuff
If you move the mouse over the line=number indicator you get the tooltip: mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete this so you might expect mouse-3 to delete the indicator/turn off the mode and not the window. I think mouse-3 _should_ turn off the mode and that mouse-3 should also turn off the minor-mode when the mouse is over one of the minor-mode indicators grouped within the round brackets with the mayor mode (currently it pops up the list of minor modes (mode-line-menu-mode-1) just as it does over the mayor mode indicator). Actually mouse-1 might be better, I forgot that I had bound it locally to goto-line. Let's not change the functionality at this stage. What stage? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: More mode-line stuff
Nick Roberts [EMAIL PROTECTED] writes: Let's not change the functionality at this stage. What stage? This one. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: `kinsoku processing' and `nospace-between-words' don't work
In article [EMAIL PROTECTED], Zhang Wei [EMAIL PROTECTED] writes: Zhang Wei [EMAIL PROTECTED] writes: `kinsoku processing' and `nospace-between-words' don't work with auto-fill-mode. It don't work with UTF-8 and Chinese-GBK language environment, but it work with Chinese-GB language envrionment, strange behavior. That's because Han characters are recognized as GBK in Chinese-GBK and as Unicode in UTF-8, but the those charsets were not recognized in fill.el. Would this patch be useful? That makes too many unnecessary calls of `kinsoku'. I've just installed a fix of the different way. Could you please try with the latest code? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Python mode and eldoc freeze
After some trial and error, I propose the following patch. I have verified that it makes the reported bug go away. Does anyone disagree with it? Looks good to me, Stefan who's never actually used Python ___ 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
It could be, although it would make sense to manipulate group names in encoded form, in the sense of not decoded. It could ``make sense'', but it's IMO a bad idea, since, as we both know, Emacs is not well suited to handling unibyte strings. Huh? Unibyte strings are perfectly well supported as far as I know. You have to be careful to remember which strings are unibyte and which are multibyte, so you don't decode multibyte strings or encode unibyte strings, and especially not implicitly (by inserting a unibyte string in a multibyte buffer or vice versa). So if you mean that it requires discipline, then I agree, but otherwise I don't know what you're referring to. To me, the second paragraph is precisely the meaning of ``not well suited'' and ``not perfectly supported''. What kind of ``well supported'' is that if I as a programmer need to carry with each string additional information, and make sure I know _exactly_ what primitives are invoked by every function I call, to take care that I don't inadvertently call something that deep inside assumes I passed a multibyte string? That way lies madness. Agreed, but note that this problem is as much on the unibyte side as it is on the multibyte side, so that seems to imply that you also thing that Emacs is not well suited to handling multibyte strings. This said, I agree that Emacs should help more. E.g. by signalling an error when trying to insert multibyte text into a unibyte buffer. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
I think (1) the timer should become an idle-timer, (2) quitting must be permitted, You can permit quitting by using with-local-quit. Want to do that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
