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
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
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
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 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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
