downcase'ing wrt locale in smtpmail.el
Hi, In smtpmail.el, protocol messages are getting downcased with respect to current locale. For instance, it downcases AUTH methods (LOGIN, PLAIN, etc.) and then compares them with the related downcased symbols '(login plain ...). And in Turkish, a downcased I is ı (dotless i), not i. Therefore, comparison fails because of logın != login or plaın != plain. IMHO, downcased must be applied using en_US locale. To reproduce the problem, start emacs with LC_CTYPE=tr_TR prefix and try to send a mail via smtpmail package. Regards. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
On Wed, Mar 28 2007, Richard Stallman wrote: [ http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. ] That sounds good, if there is no copyright issue for the icon. Can we use it without a delay? This icon is already in Emacs (etc/images/exit.xpm) and used in Gnus. I'd suggest to move `Info-exit' to the right side of the tool bar. --8---cut here---start-8--- --- info.el 27 Mar 2007 22:21:02 - 1.498 +++ info.el 28 Mar 2007 17:39:05 - @@ -3244,7 +3248,6 @@ (defvar info-tool-bar-map (if (display-graphic-p) (let ((map (make-sparse-keymap))) - (tool-bar-local-item-from-menu 'Info-exit close map Info-mode-map) (tool-bar-local-item-from-menu 'Info-history-back left-arrow map Info-mode-map) (tool-bar-local-item-from-menu 'Info-history-forward right-arrow map Info-mode-map) (tool-bar-local-item-from-menu 'Info-prev prev-node map Info-mode-map) @@ -3254,6 +3257,7 @@ (tool-bar-local-item-from-menu 'Info-goto-node jump-to map Info-mode-map) (tool-bar-local-item-from-menu 'Info-index index map Info-mode-map) (tool-bar-local-item-from-menu 'Info-search search map Info-mode-map) + (tool-bar-local-item-from-menu 'Info-exit exit map Info-mode-map) map))) (defvar Info-menu-last-node nil) --8---cut here---end---8--- Here's a screen shot: message/external-body; name*=us-ascii''%2ftmp%2fste%2ftool-bar-exit.png; access-type=local-file: Unrecognized Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
On Wed, Mar 28 2007, Kim F. Storm wrote: Richard Stallman [EMAIL PROTECTED] writes: It is possible that the solution of discarding the last few global toolbar buttons to make room for the local ones can be implemented now. Would someone like to try? I don't think this is easy at all. Let's leave it alone for now. ACK BTW, setting tool-bar-button-margin to 0 gives room for more tool bar items. Maybe these variables should be customizable (after the release)? ,[ M-x apropos-variable RET ^tool-bar RET ] | tool-bar-border | Variable: *Border below tool-bar in pixels. | tool-bar-button-margin | Variable: *Margin around tool-bar buttons in pixels. | tool-bar-button-relief | Variable: *Relief thickness of tool-bar buttons. ` Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
Lennart Borgman (gmail) wrote: The variable is marked obsolete in the same file where it is used. I would expect that the new name where used in that file instead of the old. I would even expect the new name to be used everywhere in Emacs, leaving the old obsolete name only to external packages to use. I'm sorry, but your expectation is just wrong. Under your scheme, things would go from working in one release to not working in the next. Instead, it's working, working with an obsolete warning, then at some point not working. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
The variable above is marked as obsolete but used in font-core.el. Should it be that way? Obviously even obsolete variables have to be used _somewhere_, else they are not just obsolete but totally useless. Can you elaborate on your question? The variable is marked obsolete in the same file where it is used. I would expect that the new name where used in that file instead of the old. To clear the misunderstanding, let me put it differently: font-lock-defaults-alist is still *obeyed* by the current code (which is why it's obsolete and not removed), but it is not *used* by the current code. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
On 3/28/07, Stefan Monnier [EMAIL PROTECTED] wrote: To clear the misunderstanding, let me put it differently: font-lock-defaults-alist is still *obeyed* by the current code (which is why it's obsolete and not removed), but it is not *used* by the current code. Perhaps the trouble is that font-lock-mode's docstring doesn't stress its obsolete status: See the variable `font-lock-defaults-alist' for the Font Lock mode default settings. You can set your own default settings for some mode, by setting a buffer local value for `font-lock-defaults', via its mode hook. and neither does font-lock-set-defaults': Sets various variables using `font-lock-defaults' (or, if nil, using `font-lock-defaults-alist') and `font-lock-maximum-decoration'. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
Stefan Monnier wrote: The variable above is marked as obsolete but used in font-core.el. Should it be that way? Obviously even obsolete variables have to be used _somewhere_, else they are not just obsolete but totally useless. Can you elaborate on your question? The variable is marked obsolete in the same file where it is used. I would expect that the new name where used in that file instead of the old. To clear the misunderstanding, let me put it differently: font-lock-defaults-alist is still *obeyed* by the current code (which is why it's obsolete and not removed), but it is not *used* by the current code. It is used on line 204 in font-core.el. Or do I misunderstand you? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
Glenn Morris wrote: Lennart Borgman (gmail) wrote: The variable is marked obsolete in the same file where it is used. I would expect that the new name where used in that file instead of the old. I would even expect the new name to be used everywhere in Emacs, leaving the old obsolete name only to external packages to use. I'm sorry, but your expectation is just wrong. Under your scheme, things would go from working in one release to not working in the next. Instead, it's working, working with an obsolete warning, then at some point not working. There must be some misunderstanding. I do not expect the variable to be removed. I just expect that the Emacs code uses the new name for the variable. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mime decoding in rmail
From: [EMAIL PROTECTED] Date: Wed, 28 Mar 2007 07:54:27 -0400 I asked my admin if he could send you a sample mail mime encoded the same way I'd get one. He will send one with the subject Today's Dilbert. Thanks, I see the problem now: this message sends an inline GIF image, without using a multipart MIME email message format. Emacs 22 always decodes base-64 and QP encoded messages, if they are not multipart. I somehow got the impression that you were talking about a multipart message. The problem here is that Rmail is too naive: it assumes that such single-part messages are text, but it doesn't make sure that by looking at the Content-type header. I will try to at least make this decoding optional, so you could turn it off, and get the old v21.x behavior. If I find a safe way to decode only text messages, and leave non-text Content-type alone, I will; otherwise this will have to wait until after the release. Thanks for bringing this to our attention. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mime decoding in rmail
Shouldn't the resulting mail be able to be saved into a file and displayed via emacs or other gif viewer program? Does the base-64 decode not do the right thing with this kind of file? And I am not sure what a multipart message is (or even base-64 for that matter), sorry. What would be best , IMO, is have rmail decode things and display them as the image or whatever it is right there in rmail. Maybe a prompt to ask if you want it decoded and displayed? The 21.x behavior would solve my problem, I had code to detect such a message from the subject line (pretty weak, I know) write the rmail to a file, do a shell command to decode it with uudeview, then insert the resulting gif file back into the rmail and delete the original mime part. thanks for all your efforts! tom Eli Zaretskii [EMAIL PROTECTED] 03/28/2007 05:44 PM To [EMAIL PROTECTED] cc Please respond to emacs-pretest-bug@gnu.org Eli Zaretskii [EMAIL PROTECTED] Subject Re: Mime decoding in rmail From: [EMAIL PROTECTED] Date: Wed, 28 Mar 2007 07:54:27 -0400 I asked my admin if he could send you a sample mail mime encoded the same way I'd get one. He will send one with the subject Today's Dilbert. Thanks, I see the problem now: this message sends an inline GIF image, without using a multipart MIME email message format. Emacs 22 always decodes base-64 and QP encoded messages, if they are not multipart. I somehow got the impression that you were talking about a multipart message. The problem here is that Rmail is too naive: it assumes that such single-part messages are text, but it doesn't make sure that by looking at the Content-type header. I will try to at least make this decoding optional, so you could turn it off, and get the old v21.x behavior. If I find a safe way to decode only text messages, and leave non-text Content-type alone, I will; otherwise this will have to wait until after the release. Thanks for bringing this to our attention. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mime decoding in rmail
Cc: emacs-pretest-bug@gnu.org From: [EMAIL PROTECTED] Date: Wed, 28 Mar 2007 18:05:59 -0400 What would be best , IMO, is have rmail decode things and display them as the image or whatever it is right there in rmail. Maybe a prompt to ask if you want it decoded and displayed? Maybe this is the best, but I think it's beyond what can practically be done before 22.1 hits the ftp sites. Gnus already does what you ask, but Rmail was always much simpler and less chock-full of features. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Leo skrev: Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. You have a point, but changing things now will delay the release even further. Users have suffered with gnome 1.x icons for some time now. And I think the hope is that the next release will be done much faster than the time it has taken to do the upcoming release. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
