As you may know, when CVS stopped working on our old Alioth repository,
so did the updates to www.xemacs.org. With some great help from Mats
(thanks!) I was finally able to set up write access to www.xemacs.org
again via the xemacsweb repository on:
https://bitbucket.org/xemacs/xemacsweb/
Right now, when you make a change, you're supposed to rsync the changes
directly to tux. There's a script you can run in
etc/update-tux.sh
that does this for you. Now, this requires ssh access to tux - the
procedure Adrian had put in place for CVS had the ssh key squirreled
away on Alioth. I haven't found an easy way to do that from bitbucket
yet. Right now, I'm having notifications on xemacsweb sent to me, and
I'll update the site if necessary. Suggestions for improvement welcome!
Vin graciously did some work on updating the docs on Mercurial.
Polishing that is also on my list, but I thought I'd make this available
right now so we can breathe some air into the web site.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Happy new year to all of you!
I sorrily forgot the passphrase of my old GPG key ... I shouldn't have
changed it, should I?
Therefore, I've created a new key which I have uploaded to a key
server (it may take some time to spread). I've attached the ascii
export to this message.
pub 1024D/C3910FB7 2012-01-04
uid Norbert Koch (XEmacs Package-Release Manager - 2012) <viteno(a)xemacs.org>
In the future, I'll sign the package-index with this new key. I've also
updated the key on tux.
Sorry for the mess!
I'll try to get hold of all the package changes in the coming days.
Best regards,
norbert.
--
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Greetings!
I recently came upon the following bug.
M-x perl-mode leads to the following backtrace:
Debugger entered--Lisp error: (wrong-type-argument integerp nil)
substring("$Revision$" nil nil)
(let ((v "$Revision$")) (string-match ":\\s *\\([0-9.]+\\)" v)
(substring v (match-beginning 1) (match-end 1)))
(defvar cperl-version (let (...) (string-match ":\\s *\\([0-9.]+\\)"
v) (substring v ... ...)) "Version of IZ-supported CPerl package this
file is based on.")
load-internal("cperl-mode" nil nil nil undecided)
load("cperl-mode" nil nil nil)
command-execute(perl-mode t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
The reason for this error is that the following keyword is not
expanded in cperl-mode.el:
(defvar cperl-version
(let ((v "$Revision$"))
(string-match ":\\s *\\([0-9.]+\\)" v)
(substring v (match-beginning 1) (match-end 1)))
"Version of IZ-supported CPerl package this file is based on.")
Replacing "$Revision$" with "$Revision: 6.2 $" makes this particular
problem go away, but there are many occurrences of CVS keywords in the
package sources and not all of them are in comments. What should we
do about this?
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Simon Josefsson <simon(a)josefsson.org> writes:
> Are you sure? All nnimap backends I've seen uses imap.el for IMAP
> protocol parsing.
The new nnimap does not use imap.el for protocol parsing...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
ads.pheedo.com serves 1x1 gif images that are not 100% correct,
resulting in the following type of error when using gnus:
(3) (image/warning) error: (image-conversion-error (GIF error: read
failed [gif :data GIF89aÿÀÀÀ!ù,D]))
and a very long and verbose *Warnings* backtrace, which messes up
article display.
Should we not bail out much earlier when we actually read in the gif
(and silently)?
GIF attached.
Robert
PS Emacs has a similar issue, vide
http://news.gmane.org/find-root.php?message_id=%3cm3hbidtph4.fsf%40quimbi...
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
[CC'd xemacs-beta]
Simon Josefsson <simon(a)josefsson.org> writes:
> Have you tried setting the imap-client-eol and/or imap-server-eol
> server variables?
I am using the nnimap backend, which doesn't seem to rely on imap.el.
The interaction between various IMAP related packages and imap.el is a
mystery that I have no intention to tackle.
FWIW, both variables are set to "\r\n".
Also, IMAP unrelated stuff breaks. `tls-end-of-info' (tls.el) includes
hard coded EOL, which easy enough to fix in that one case, but you get
the idea.
Another observation shows that gnutls-cli appears to convert LF into
CRLF, even though the server sends CRLF terminated IMAP information
already.
,----
| 191 OK UID STORE completed^M^M
`----
Interesting that the TLS handshaking preamble sent by the server is
LF-only terminated. Gaah!
I tried tinkering with `process-coding-system-alist'[1] to no avail.
`default-process-coding-system' didn't seem to have an effect either.
Should a coding-system like "convert-eol-crlf" solve the issue?
Thanks
Marcus
Footnotes:
[1] Documentation issue: `process-coding-system-alist' claims
PATTERN were a program name, while #'start-process says that the
process name is used as key. Note the subtile difference.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Aiden,
We made a repository for icon-themes on bitbucket:
https://bitbucket.org/skm/icon-themes
We made it public, hope that is sufficient to let everybody access who
wants to.
Not sure how to make it so anyone in this group can write to it.
Directions welcome.
Suggestions welcome.
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
whilst looking at my gif problem, I was getting complaints from the
jpeg library about mismatching structure sizes (which seems not
uncommon, judging by various comments in the sources). The problem
appears to be that jpeglib is compiled with
boolean == int
and XEmacs is using
boolean == unsigned char
(because of the windows api headers)
This results in XEmacs' and jpeglibs ideas about structure layout
disagreeing. I guess previously 'boolean' was not used in jpeglib's
structures, so the difference didn't matter.
I currently have a hack in place that avoids including the windows api
headers from glyphs-eimage.c, but was wondering if someone could
suggest a cleaner solution. For reference, here's what I'm doing:
diff --git a/src/glyphs-eimage.c b/src/glyphs-eimage.c
--- a/src/glyphs-eimage.c
+++ b/src/glyphs-eimage.c
@@ -52,6 +52,7 @@
#include "opaque.h"
#include "window.h"
+#define NO_SYSWINDOWS_H
#include "sysfile.h"
#ifdef HAVE_PNG
@@ -118,9 +119,9 @@
/* And another one... jmorecfg.h defines the 'boolean' type as int,
which conflicts with the standard Windows 'boolean' definition as
unsigned char. Ref: http://www.asmail.be/msg0054688232.html */
-#ifndef __RPCNDR_H__ /* don't conflict if rpcndr.h already read */
-typedef unsigned char boolean;
-#endif
+ //#ifndef __RPCNDR_H__ /* don't conflict if rpcndr.h already re
+typedef int boolean;
+//#endif
#define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
#endif
diff --git a/src/sysfile.h b/src/sysfile.h
--- a/src/sysfile.h
+++ b/src/sysfile.h
@@ -91,7 +91,7 @@
/* Needed for ITEXT_TO_TSTR, MAX_XETCHAR_SIZE below; but syswindows.h
depends on lisp.h being previously included. */
-#if defined (WIN32_ANY) && defined (emacs)
+#if defined (WIN32_ANY) && defined (emacs) && !defined (NO_SYSWINDOWS_H)
# include "syswindows.h"
#endif
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta