Forwarding mail from RMAIL
I was dealing with e-mail -- I use RMAIL. I tried to forward a message with full headers, as I have been doing for years. t to get headers f to forward I get a message that RMAIL is readonly. It does create a *mail* buffer with the header info, but it is not displayed. Earlier I tried m to send mail and that created the *mail* but did not show it, and I had to search for it. This was OK yesterday with first build of 22.0.96.3 In GNU Emacs 22.0.96.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-03-21 on cardew Windowing system distributor `The X.Org Foundation', version 11.0.70199902 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: show-paren-mode: t display-time-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-k C-k C-k C-c C-c SPC 0 SPC return d SPC d SPC d d SPC d SPC d d SPC d SPC d SPC d SPC d d SPC d SPC d SPC d SPC SPC prior prior t f escape f y C-x b return down-mouse-2 mouse-2 C-_ C-x b return C-v escape f y help-echo M-m t y u M-x b i g tab backspace backspace u g tab tab backspace backspace backspace e m a tab b tab backspace r tab C-h a b u g return help-echo help-echo help-echo down-mouse-1 mouse-2 C-x k return y e s C-g down-mouse-1 mouse-1 C-x k return down-mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 help-echo help-echo help-echo down-mouse-1 mouse-2 help-echo help-echo help-echo help-echo help-echo help-echo C-x k return C-x o C-x k return down t f M-x r e p o r t tab return Recent messages: Please answer y or n. Unsent message being composed; erase it? (y or n) Auto save file for draft message exists; consider M-x mail-recover Quit Loading apropos...done Type C-x 4 C-o RET to restore the other window. [2 times] Quit Type C-x 4 C-o RET to restore the other window. Auto save file for draft message exists; consider M-x mail-recover rmail-summary-forward: Buffer is read-only: #buffer RMAIL Loading emacsbug...done ==John ffitch ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Stefan Monnier [EMAIL PROTECTED] writes: Sigh. Seems like a magic string for the TeXshop TeX editor. But I think just ruling out [VT] is still asking for trouble. I think a bug report to the TeXshop is in order. Uh, you people are joking, right? Nope! It is not a bug in TeXshop if Emacs' magic-mode-alist goes out of control and calls everything PostScript. The %! thingy is not Emacs's invention. It's how postscript was specified. The only relevant standard I can find starts off with %!PS-Adobe. In contrast, %! is far too generic to be useful. It may be a heuristic for a PostScript interpreter to decide whether it is getting fed PostScript on stdin. But it does not sound like a useful heuristic for a text editor to decide whether a named file contains PostScript code or anything else. And for that reason `file greek-utf8.tex' agrees with Emacs. This said, I'd be happy to see the %! entry removed from magic-mode-alist, because I think magic-mode-alist should really be kept to its absolute strictest minimum. I don't think that %!PS has comparable potential to do accidental harm. Whether it does noticeable good is a different question altogether. However, dvips -i produces PostScript files where the extension is replaced by a serial number. Those will not be recognized as PostScript without magic number detection. %!PS is completely sufficient for that purpose, however. I think that little except hand-crafted PostScript would ever start with %! alone, and hand-crafted PostScript will have a proper file name. Even if one uses dvips -N (which disabled structured comments) the file starts with %!PS (but not EPSF; comments have been disabled) So I think that %!PS _does_ have some usefulness, and it is clearly not as overboard as %!. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Juanma Barranquero [EMAIL PROTECTED] writes: On 3/21/07, Stefan Monnier [EMAIL PROTECTED] wrote: because I think magic-mode-alist should really be kept to its absolute strictest minimum. Certainly, it should only be used for file formats which are often found without a telling file extension. Alas, it seems like Postscript is one of those. Do you have an example for a Postscript file on your system that is neither identified by the magic string %!PS nor an appropriate extension? -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
On 3/21/07, David Kastrup [EMAIL PROTECTED] wrote: Do you have an example for a Postscript file on your system that is neither identified by the magic string %!PS nor an appropriate extension? No. But I don't understand your question. I was agreeing with you (yeah, it happens sometimes). Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Juanma Barranquero [EMAIL PROTECTED] writes: On 3/21/07, David Kastrup [EMAIL PROTECTED] wrote: Do you have an example for a Postscript file on your system that is neither identified by the magic string %!PS nor an appropriate extension? No. But I don't understand your question. I was agreeing with you (yeah, it happens sometimes). Basically, we have three proposals (partly proposed by previously existing code): a) accept %! as magic PostScript override (previous behavior) b) accept %!PS as magic override (what I proposed and checked in) c) don't accept any magic postscript override When arguing against c), it is not clear whether you agree with a) being a sufficiently bad idea. I had one example file causing problems with option a), and I already gave examples for files requiring b) (those produced using dvips -i don't have an extension, but in all cases start with %!PS). My point of view is that b) nowadays appears like the most pragmatically useful option, judging from problematic cases I have seen. If people can live with that, I suggest we leave it at that. While there are arguments for the other choices, we had them mentioned (Stefan's argument that magic should be kept to a minimum certainly _is_ valid) and, I believe, considered. Repeating them will just waste time. If people feel that they have been weighed wrongly, the way to resolve this is not repeating arguments, but vote on the resolution. Anybody who feels that the current solution b) as checked in by myself is not the best solution? If so, I'd want to either hear new arguments or have a vote. Everything else seems like a waste of time. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
In contrast, %! is far too generic to be useful. It may be a heuristic for a PostScript interpreter to decide whether it is getting fed PostScript on stdin. But it does not sound like a useful heuristic for a text editor to decide whether a named file contains PostScript code or anything else. Complete agreement. But it still means that TeXshop should avoid the %! magic characters because they have a conflicting meaning in some contexts. I don't claim that TeXshop should change for the sake of Emacs: it should change because its choice is fundamentally wrong, whether that bites Emacs users or not is irrelevant. This said, I'd be happy to see the %! entry removed from magic-mode-alist, because I think magic-mode-alist should really be kept to its absolute strictest minimum. I don't think that %!PS has comparable potential to do accidental harm. Whether it does noticeable good is a different question altogether. Obviously using a stricter regexp is good in my book since it means that magic-mode-alist is used less often. However, dvips -i produces PostScript files where the extension is replaced by a serial number. Those will not be recognized as PostScript without magic number detection. %!PS is completely sufficient for that purpose, however. Well, I find the likelihood of someone trying to edit with Emacs the output of dvips -i sufficiently low that it doesn't justify in my eye the use of a magic-mode-alist entry for it. That's just an opinion. Maybe a better solution is to make dvips output file names of the form foo.NNN.ps rather than foo.ps.NNN. So I think that %!PS _does_ have some usefulness, and it is clearly not as overboard as %!. We agree that it's a step in the right direction. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Daniel, do you remember why you put an entry (%![^V] . ps-mode) in magic-mode-alist? Did it just seem like a good idea or was there some particular (set of) circumstances you had bumped into that called for it? Stefan Juanma == Juanma Barranquero [EMAIL PROTECTED] writes: On 3/21/07, Stefan Monnier [EMAIL PROTECTED] wrote: Who put this entry in magic-mode-alist, and why? It's there since the beginning, at least according to ViewCVS (files.el, revision 1.720) and lisp/ChangeLog.11: 2004-11-03 Daniel Pfeiffer [EMAIL PROTECTED] * files.el (xml-based-modes): Delete var. (magic-mode-alist): New more general var. (set-auto-mode): Use it. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.gif image fails to display correctly
http://i.iinfo.cz/urs-att/gif2_e-115572866858321.gif is an example of a .gif image which contains more than 256 colours. It does this by using multiple frames with a 0ms separation between them. Emacs only displays the first frame. This may well be something that isn't worth fixing in Emacs, but I thought I should mention it anyway. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Recentf customization too late
1. Let your ~/.emacs file contain only this line: (recentf-mode 1) 2. Start Emacs without any command line arguments. The File menu contains a submenu Open Recent, and this contains no files (the value of recentf-list is nil). 3. Visit several files. These will now be listed in the Open Recent menu (and in the list value of recentf-list). 4. Click on the Options item in the Open Recent menu (or type M-x customize-group RET recentf RET) and in the customization buffer change the value of recentf-save-file, e.g. to ~/.recentfoo, and then click `Save for Future Sessions'. 5. Kill Emacs. From the shell you can confirm that your ~/.emacs contains the customization of recentf-save-file, and that ~/.recentfoo exists and contains the list of files you visited, as the value of recentf-list. 6. Start Emacs without any command line arguments. The Open Recent still contains no files (the value of recentf-list is nil), although the value of recentf-save-file is what you had set (e.g. ~/.recentfoo). The following patch (modelled on the recent fix by Glenn Morris to analogous problems in calendar.el and diary-lib.el) fixes this bug. (I haven't checked whether other defcustoms in recentf.el are also susceptible to this bug, so I kept the fix local to recentf-save-file, rather than introducing a separate function, as Glenn did.) *** recentf.el~1.55~2007-01-21 23:44:40.0 +0100 --- recentf.el 2007-03-21 16:20:11.0 +0100 *** *** 72,78 (defcustom recentf-save-file ~/.recentf *File to save the recent list into. :group 'recentf ! :type 'file) (defcustom recentf-save-file-modes 384 ;; 0600 Mode bits of recentf save file, as an integer, or nil. --- 72,85 (defcustom recentf-save-file ~/.recentf *File to save the recent list into. :group 'recentf ! :type 'file ! :initialize 'custom-initialize-default ! :set (lambda (symbol value) !(let ((oldvalue (eval symbol))) ! (custom-set-default symbol value) ! (and (not (equal value oldvalue)) ! recentf-mode ! (recentf-load-list) (defcustom recentf-save-file-modes 384 ;; 0600 Mode bits of recentf save file, as an integer, or nil. In GNU Emacs 22.0.96.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-03-21 on escher Windowing system distributor `The X.Org Foundation', version 11.0.70199902 configured using `configure '--with-x-toolkit=gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Summary Minor modes in effect: tabbar-mwheel-mode: t tabbar-mode: t recentf-mode: t display-time-mode: t show-paren-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: identity Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo f1 M-x r e c e tab f tab C-g C-c r C-g M-x r e c e tab q backspace f tab l o tab return C-c r C-g C-c r r e return C-c , j r tab q next next down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-3 mouse-3 down-mouse-1 mouse-1 down-mouse-1 mouse-1 down-mouse-1 mouse-1 down-mouse-1 mouse-1 backspace down-mouse-1 mouse-1 C-x C-s C-c r . e m a right right right C-g C-c r t e s return C-, C-x C-s C-x d ~ return down down down down down down down down down down down down down down down down down down down down down down up up up down R M-n . o r i g return down down R M-n M-backspace backspace return end g prior help-echo select-window help-echo g up up up up up up up up up up up up up d x y e s return C-c j e tab return help-echo down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-3 mouse-3 C-x C-s down-mouse-1 mouse-1 help-echo help-echo select-window help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo M-x g u return J j y down down down down down down down down down down down up M-g return return C-s C-q C-j SPC . right SPC u f1 down down down down down down up SPC down SPC down SPC n SPC n n n SPC n n SPC f1 prior M-x r e p o tab r tab return Recent messages: Loading gnus-async...done Loading smiley...done Loading gnus-cite...done Parsing BBDB... (frobnicating...done) Loading flow-fill...done Auto-saving...done Auto-saving...done Auto-saving...done Making completion list... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Forwarding mail from RMAIL
Can you provide a complete, self-contained test case? (If you include an RMAIL file, please uuencode it!) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: complete.el 1.53/1.54 (More partial completion)
This part of revision 1.53, complete.el, was undone by revision 1.54, but the removal wasn't mentioned in the log. Was this intentional? It was most likely an oversight of Eli when he installed the next patch. Thanks for spotting it, I've re-installed the patch. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: complete.el 1.53/1.54 (More partial completion)
From: Stefan Monnier [EMAIL PROTECTED] Date: Wed, 21 Mar 2007 15:23:51 -0400 Cc: emacs-pretest-bug@gnu.org This part of revision 1.53, complete.el, was undone by revision 1.54, but the removal wasn't mentioned in the log. Was this intentional? It was most likely an oversight of Eli when he installed the next patch. What oversight? what next patch? Please provide some minimal details. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
set-face-attribute doesn't set default for new frames
Hi, set-face-attribute doesn't set the default for new frames with todays CVS. Instead, the value used in custom-set-faces is used instead even though I specify nil for the frame (all current frames and future frames) in set-face-attribute. I have custom vars set up for various faces and then some machine specific overrides (using set-face-attribute) for when the normal face doesn't look very good. I've managed to reduce the steps needed to reproduce the bug to the following: 1. Make .emacs contain only the following: (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(variable-pitch ((t (:weight normal :height 1.0 :width normal :family Bitstream Vera Sans ) ; set the machine specific face (set-face-attribute 'variable-pitch nil :family DejaVu Sans) 2. Start emacs 3. Type M-x describe-face RET variable-pitch RET The face family will be shown as DejaVu Sans 4. Create a new frame with M-x make-frame RET 5. Type M-x describe-face RET variable-pitch RET The face family will be incorrectly shown as Bitstream Vera Sans The variable-pitch face will have the incorrect Bitstream Vera Sans family on all other frames. This is different to the behaviour with my last build of emacs (2006-12-01) which showed the correct behaviour of keeping DejaVu Sans on all frames. Regards Rob Walker (Please ensure I am CC'd in any replies as I'm not subscribed to the emacs-pretest-bug list) In GNU Emacs 22.0.96.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on arm04507-etch Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/local_home/rwalker/local/emacs-20070320' '--with-gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x d e s c r i b e - f a c e return v a r i a b l e - p i t c h return M-x m a k e - f r a m e return switch-frame M-x d e s c r i b e - f r a backspace backspace a c e return v a r i a b l e - p i t c h return M-x r e p o r t b u tab backspace backspace backspace tab return Recent messages: (emacs) For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading thingatpt...done Loading help-mode...done Loading help-fns...done Type C-x 1 to remove help window. [2 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: complete.el 1.53/1.54 (More partial completion)
This part of revision 1.53, complete.el, was undone by revision 1.54, but the removal wasn't mentioned in the log. Was this intentional? It was most likely an oversight of Eli when he installed the next patch. What oversight? what next patch? Please provide some minimal details. Check the diff of 1.53 and and the diff of 1.54 and you'll understand. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`inhibit-point-motion-hooks' isn't configurable
In a regular *shell* buffer, I see that C-a doesn't go to the beginning of a line like it does in other buffers. I explore this by describing the key binding. I see that: C-a runs the command move-beginning-of-line and: To ignore intangibility, bind `inhibit-point-motion-hooks' to t. That sounds like it might be what I want to do, so I click on the link to see the docs for inhibit-point-motion-hooks. To my surprise, there's no you can customize this variable link, and since I'm so used to being mollycoddled by Emacs, I don't know how to customize it manually. I think we need to decide whether to mention this variable and make it customizable, or not mention it at all. As it stands, the new user is left with a variable which they can discover but not change. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`move-beginning-of-line' doesn't move to beginning of line
In *shell* buffers, C-h k C-a tells me that: C-a runs the command move-beginning-of-line Move point to beginning of current line as displayed. However, when I hit C-a, the cursor stays at the end of the prompt, not at the beginning of the line. This may be desired behaviour (although I find it annoying; I often want to go to the beginning of the prompt) but it isn't the documented behaviour. The documentation should match the behaviour one way or the other. In GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-20 on trpaslik Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: .gif image fails to display correctly
Chris Moore [EMAIL PROTECTED] writes: http://i.iinfo.cz/urs-att/gif2_e-115572866858321.gif is an example of a .gif image which contains more than 256 colours. It does this by using multiple frames with a 0ms separation between them. Emacs only displays the first frame. This may well be something that isn't worth fixing in Emacs, but I thought I should mention it anyway. Animated gifs aren't supported in Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
David Kastrup [EMAIL PROTECTED] writes: a) accept %! as magic PostScript override (previous behavior) b) accept %!PS as magic override (what I proposed and checked in) c) don't accept any magic postscript override ... My point of view is that b) nowadays appears like the most pragmatically useful option, judging from problematic cases I have seen. I agree. (b) is the conservative change. % is a common enough comment character that I can see %! as being slightly risky, but %!PS is far less so. -Miles -- 1971 pickup truck; will trade for guns ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `move-beginning-of-line' doesn't move to beginning of line
Chris Moore [EMAIL PROTECTED] writes: C-a runs the command move-beginning-of-line Move point to beginning of current line as displayed. ... The documentation should match the behaviour one way or the other. I would suggest adding something like: This function constrains point to the current field in a similar manner to `beginning-of-line' (see that function for details). to the docstring. -Miles -- Fast, small, soon; pick any 2. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: complete.el 1.53/1.54 (More partial completion)
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Stefan Monnier [EMAIL PROTECTED] Date: Wed, 21 Mar 2007 17:55:14 -0400 What oversight? what next patch? Please provide some minimal details. Check the diff of 1.53 and and the diff of 1.54 and you'll understand. But since you already understood that, why not tell it and save me some time? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
