Re: message.el user References control

S> IIRC, the order is fixed by the relevant RFC, so we can't really let the S> user mess it up. > We demand shoot-feet control. Actually here we are smarter than the > RFC. RFC? bah! KFChicken. Since you use a length of 1, I'm wondering why you'd care about the ordering. Or are you saying that wh

Re: message.el user References control

S> IIRC, the order is fixed by the relevant RFC, so we can't really let the S> user mess it up. We demand shoot-feet control. Actually here we are smarter than the RFC. RFC? bah! KFChicken. S> As for making 21 customizable, well it seems like a good value, what S> with it being half of 42 and

Re: Two Tramp .el files executable

>> lisp/net/tramp-fish.el and tramp-gw.el both are executable files: >> >> $ ls -l lisp/net/tramp-{fish,gw}.el >> -rwxr-xr-x 1 yavor yavor 44432 2007-07-18 00:10 >> src/emacs/lisp/net/tramp-fish.el >> -rwxr-xr-x 1 yavor yavor 11756 2007-07-10 05:03 >> src/emacs/lisp/net/tramp-gw.el >> >> I thin

Re: message.el user References control

> In message.el, the user should be given some variables in case he > wishes to have some control over the wads of References, and their > order. IIRC, the order is fixed by the relevant RFC, so we can't really let the user mess it up. As for making 21 customizable, well it seems like a good

Re: Two Tramp .el files executable

ÏÒÞà ´ÞÓÐÝÞÒ <[EMAIL PROTECTED]> writes: > lisp/net/tramp-fish.el and tramp-gw.el both are executable files: > > $ ls -l lisp/net/tramp-{fish,gw}.el > -rwxr-xr-x 1 yavor yavor 44432 2007-07-18 00:10 > src/emacs/lisp/net/tramp-fish.el > -rwxr-xr-x 1 yavor yavor 11756 2007-07-10 05:03 src/emacs/lis

message.el user References control

In message.el, the user should be given some variables in case he wishes to have some control over the wads of References, and their order. < "Trim REFERENCES to be 21 Message-ID long or less, and fold them. --- > "Trim REFERENCES to be jidanni:1 Message-ID long or less, and fold them. < (le

Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space

In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: > Warning (initialization): Building Emacs overflowed pure space. (See > the node Pure Storage in the Lisp manual for details.) I've just done "cvs update" and "make" but, the pure space was not overflowed. % make [...] Dumping und

[2007-07-24] Unicode2 -- Building Emacs overflowed pure space

Warning (initialization): Building Emacs overflowed pure space. (See the node Pure Storage in the Lisp manual for details.) HTH, -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http:/

CVS build on Suse 10.0 failed

CVS build of today failed with following errors: Required feature `thai-word' was not provided make[2]: [finder-date] Fehler 255 Leaving directory ... lisp [bootstrap-build] Fehler 2 ;; Suse 10.0 HOSTTYPE=i386 CPU=i686 LANG=de_DE.UTF-8 OSTYPE=linux LESS_ADVANCED_PREPROCESSOR=no MACHTYPE

On startup contents get inserted into buffer on x86_64

Hello, I just came across a problem in the CVS version of GNU Emacs. When starting my copy of Emacs which I just fetched from CVS contents get inserted into the active buffer. The problem does not only seem to exist when starting Emacs without passing a filename on the commandline but also when

Two Tramp .el files executable

lisp/net/tramp-fish.el and tramp-gw.el both are executable files: $ ls -l lisp/net/tramp-{fish,gw}.el -rwxr-xr-x 1 yavor yavor 44432 2007-07-18 00:10 src/emacs/lisp/net/tramp-fish.el -rwxr-xr-x 1 yavor yavor 11756 2007-07-10 05:03 src/emacs/lisp/net/tramp-gw.el I think there is no reason for this