[PATCH] cc-mode font-lock-pre-idle-hook error in XEmacs
20 years
Aidan Kehoe
Aidan Kehoe
1
Ar an t-aonú lá is triochad de mí Márta, scríobh Bill Rushmore:
> When I edit Java files and when I enter a new variable such as:
>
> int foo =
>
> I get the following message right after I type in the equals sign:
>
> (warning/warning) Error caught in `font-lock-pre-idle-hook': (error
> Invalid search limit (wrong side of point))
>
> This only seems to be an issue on Solaris, other platforms I use don't
> have the problem.
>
> Right now my work around is to use GNU Emacs for Java development
> (*sigh*).
Thank you for the report, Bill. The below patch fixes the issue for me,
though I’m not sure that I understand the package well enough to say it’s
The Right Way to do it. Martin?
xemacs-packages/cc-mode/ChangeLog addition:
2005-04-01 Aidan Kehoe <kehoea(a)parhasard.net>
* cc-engine.el (c-syntactic-re-search-forward): Before the first
call of re-search-forward in the function, make sure that the
bound is greater than or equal to (point). Fixes an error:
Error caught in `font-lock-pre-idle-hook': (error Invalid search
limit (wrong side of point))
that users of JDEE have been seeing for a long time.
XEmacs Packages source patch:
Diff command: cvs -q diff -u
Files affected: xemacs-packages/cc-mode/cc-engine.el
Index: xemacs-packages/cc-mode/cc-engine.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/cc-mode/cc-engine.el,v
retrieving revision 1.16
diff -u -u -r1.16 cc-engine.el
--- xemacs-packages/cc-mode/cc-engine.el 2004/08/11 16:30:15 1.16
+++ xemacs-packages/cc-mode/cc-engine.el 2005/03/31 21:58:00
＠＠ -2446,7 +2446,8 ＠＠
(and
(progn
(setq search-pos (point))
- (re-search-forward regexp bound noerror))
+ (if (>= bound (point))
+ (re-search-forward regexp bound noerror)))
(progn
(setq state (parse-partial-sexp
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 1 participants
- 0 comments
[COMMIT] Intrinsic.h. -> Intrinsic.h 1.248)
20 years
Aidan Kehoe
Aidan Kehoe
APPROVE COMMIT
Ar an triochadú lá de mí Márta, scríobh robert delius royar:
> Recent changes to configure.ac left a stray period behind, breaking builds
> of 21.5.b20 which used --with-athena=3d.
Indeed they did. Thank you for the bug report, and patch!
2005-03-30 Aidan Kehoe <kehoea(a)parhasard.net>
* configure: #include <X11/Intrinsic.h.> -> #include
<X11/Intrinsic.h>, thank you Robert Delius Royar.
Index: configure
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/configure,v
retrieving revision 1.248
diff -u -r1.248 configure
--- configure2005/03/27 04:21:091.248
+++ configure2005/03/30 19:50:09
＠＠ -23770,7 +23770,7 ＠＠
#if HAVE_X11_XFUNCPROTO_H
#include <X11/Xfuncproto.h>
#endif
-#include <X11/Intrinsic.h.>
+#include <X11/Intrinsic.h>
#include <X11/$athena_variant/XawInit.h>
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 2 participants
- 2 comments
[COMMIT] Fix Unicode conversion for control-1, prevent a segfault
20 years
Aidan Kehoe
Aidan Kehoe
APPROVE COMMIT
NOTE: This patch has been committed.
src/ChangeLog addition:
2005-03-31 Aidan Kehoe <kehoea(a)parhasard.net>
* unicode.c (set_unicode_conversion): Don't try to write to the
non-existent conversion tables for ASCII and control-1, in the
interest of not segfaulting.
* unicode.c (unicode_convert): The "position code" for a control-1
character has #xA0 added to it when encoded in Mule, unlike #x80
for all the other non-ASCII character sets ; take this into
account.
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: src/unicode.c
Index: src/unicode.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/unicode.c,v
retrieving revision 1.26
diff -u -u -r1.26 unicode.c
--- src/unicode.c 2005/02/28 23:36:32 1.26
+++ src/unicode.c 2005/03/31 14:46:45
＠＠ -857,6 +857,9 ＠＠
sledgehammer_check_unicode_tables (charset);
#endif
+ if (EQ(charset, Vcharset_ascii) || EQ(charset, Vcharset_control_1))
+ return;
+
/* First, the char -> unicode translation */
if (XCHARSET_DIMENSION (charset) == 1)
＠＠ -1921,7 +1924,13 ＠＠
{ /* Processing Non-ASCII character */
char_boundary = 1;
if (EQ (charset, Vcharset_control_1))
- encode_unicode_char (Vcharset_control_1, c, 0, dst,
+ /* See:
+
+ (Info-goto-node "(internals)Internal String Encoding")
+
+ for the rationale behind subtracting #xa0 from the
+ character's code. */
+ encode_unicode_char (Vcharset_control_1, c - 0xa0, 0, dst,
type, little_endian);
else
{
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 1 participants
- 0 comments
[PATCH21.5] Dumper overflow fix
20 years
Jerry James
Jerry James
Thank Uno for catching this. Some day I'll get the Uno framework set up
all the way ... This patch fixes an off-by-one error that could lead to
overflow of the static backtrace array. While we're at it, let's get
rid of those nasty magic numbers.
src/ChangeLog addition:
2005-03-26 Jerry James <james(a)xemacs.org>
* dumper.c (BACKTRACE_MAX): New constant defining length of static
backtrace array.
* dumper.c (pdump_bump_depth): Use it, and avoid buffer overflow
by fixing comparison.
xemacs-21.5 source patch:
Diff command: cvs -q diff -uN
Files affected: src/dumper.c
Index: src/dumper.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/dumper.c,v
retrieving revision 1.25
diff -d -u -r1.25 dumper.c
--- src/dumper.c 2005/02/04 03:01:20 1.25
+++ src/dumper.c 2005/03/27 04:35:55
＠＠ -520,12 +520,14 ＠＠
return 0;
}
+#define BACKTRACE_MAX 65536
+
static struct
{
struct lrecord_header *obj;
int position;
int offset;
-} backtrace[65536];
+} backtrace[BACKTRACE_MAX];
static int pdump_depth;
＠＠ -568,7 +570,7 ＠＠
pdump_bump_depth (void)
{
int me = pdump_depth++;
- if (me > 65536)
+ if (me >= BACKTRACE_MAX)
{
stderr_out ("Backtrace overflow, loop ?\n");
ABORT ();
--
Jerry James
http://www.ittc.ku.edu/~james/
- 1 participants
- 1 comments
[PATCH] Have VM figure out what MIME character set to use by coverage
20 years
Aidan Kehoe
Aidan Kehoe
Doesn’t look like this is going to get into a released VM in the immediate
future, nor anything else to fix the same bug :-( XEmacs-package-worthy?
xemacs-packages/vm/ChangeLog addition:
2005-03-24 Aidan Kehoe <kehoea(a)parhasard.net>
* vm-mime.el (vm-mime-charset-decode-region): If the TTY coding
system we're using can display a MIME charset, go ahead and decode
the message.
* vm-mime.el (vm-determine-proper-charset): Use latin-unity if
available, and other logic if not, to work out the appropriate
MIME character set to use for a region.
* vm-mime.el (vm-mime-tty-can-display-mime-charset): New.
* vm-mime.el (vm-mime-charset-internally-displayable-p): Add a
docstring, use vm-mime-tty-can-display-mime-charset now it's
available.
XEmacs Packages source patch:
Diff command: cvs -q diff -u
Files affected: xemacs-packages/vm/vm-mime.el
Index: xemacs-packages/vm/vm-mime.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/vm/vm-mime.el,v
retrieving revision 1.29
diff -u -u -r1.29 vm-mime.el
--- xemacs-packages/vm/vm-mime.el 2003/09/03 00:43:45 1.29
+++ xemacs-packages/vm/vm-mime.el 2005/03/24 01:46:03
＠＠ -33,6 +33,71 ＠＠
(put 'vm-mime-error 'error-conditions '(vm-mime-error error))
(put 'vm-mime-error 'error-message "MIME error"))
+;; A lot of the more complicated MIME character set processing is only
+;; practical under MULE.
+
+(when (or vm-xemacs-mule-p
+ (and vm-fsfemacs-mule-p enable-multibyte-characters))
+
+ ;; Load any unicode support that's available. (If we're running on 21.5,
+ ;; utf-8 is predefined as a coding system, so there's no need to load
+ ;; Mule-UCS.)
+ (and (not (coding-system-p (find-coding-system 'utf-8)))
+ (locate-library "un-define")
+ (require 'un-define)
+ (require 'unicode))
+
+ ;; If we can use latin-unity for sane treatment of the 8859-? charsets
+ ;; under MULE, go for it.
+ (and (locate-library "latin-unity")
+ (require 'latin-unity))
+
+ (let ((haveu8 (coding-system-p (find-coding-system 'utf-8))))
+
+ (if (featurep 'latin-unity)
+ (defvaralias 'vm-mime-ucs-list 'latin-unity-ucs-list)
+ (defcustom vm-mime-ucs-list
+ (or (and haveu8 '(utf-8 iso-2022-jp ctext escape-quoted))
+ '(iso-2022-jp ctext escape-quoted))
+ "*List of coding systems that can encode all characters known to emacs."
+ ))
+
+ ;; Define a list of coding systems that are to be preferred when sending
+ ;; a mail using MIME. This defaults to including UTF-8 when utf-8 exists
+ ;; as a coding system; otherwise, iso-8859-1 is its only element.
+ ;;
+ ;; If we can't use some element from this list, we default to
+ ;; iso-2022-jp as a last resort in the code.
+
+ (defcustom vm-coding-system-priorities
+ (or (and haveu8 '(iso-8859-1 utf-8))
+ '(iso-8859-1))
+ "*List of coding systems for VM-MIME to use, in order of preference. ")
+
+ ;; Add some extra charsets that may not have been defined onto the end
+ ;; of vm-mime-mule-charset-to-coding-alist.
+ (mapcar (lambda (x)
+ (and (coding-system-p (find-coding-system x))
+ ;; Not using vm-string-assoc because of some quoting
+ ;; weirdness it's doing.
+ (if (not (assoc
+ (format "%s" x)
+ vm-mime-mule-charset-to-coding-alist))
+ (add-to-list 'vm-mime-mule-charset-to-coding-alist
+ (list (format "%s" x) x)))))
+ '(utf-8 iso-8859-15 iso-8859-14 iso-8859-16))
+
+ ;; And make sure that the map back from coding-systems is good for
+ ;; those charsets.
+ (mapcar (lambda (x)
+ (or (assoc (car (cdr x)) vm-mime-mule-coding-to-charset-alist)
+ (add-to-list 'vm-mime-mule-coding-to-charset-alist
+ (list (car (cdr x)) (car x)))))
+ vm-mime-mule-charset-to-coding-alist)
+ ;; Whoops, doesn't get picked up for some reason.
+ (add-to-list 'vm-mime-mule-coding-to-charset-alist
+ '(iso-8859-1 "iso-8859-1"))))
+
(defun vm-make-layout (&rest plist)
(vector
(plist-get plist 'type)
＠＠ -236,6 +301,7 ＠＠
(cond ((or vm-xemacs-mule-p vm-fsfemacs-mule-p)
(if (or (and vm-xemacs-p (memq (device-type) '(x gtk mswindows)))
vm-fsfemacs-p
+ (vm-mime-tty-can-display-mime-charset charset)
nil)
(let ((buffer-read-only nil)
(cell (cdr (vm-string-assoc
＠＠ -1294,34 +1360,161 ＠＠
(defvar buffer-file-coding-system)
+;; Possible further work; integrate with the FSF's unify-8859-on-encoding-mode
+;; stuff.
+
(defun vm-determine-proper-charset (beg end)
+ "Work out what MIME character set to use for sending a message.
+
+Uses `us-ascii' if the message is entirely ASCII compatible. If MULE is not
+available, and the message contains contains non-ASCII characters, consults
+the variable `vm-mime-8bit-composition-charset' or uses `iso-8859-1.' if
+that is nil.
+
+Under MULE, `vm-coding-system-priorities' is searched, in order, for a
+coding system that will encode all the characters in the message. If none is
+found, `iso-2022-jp' is used, which will preserve information for all the
+character sets of which Emacs is aware--at the expense of being incompatible
+with the recipient's software, if that recipient is outside of East Asia."
(save-excursion
(save-restriction
(narrow-to-region beg end)
- (catch 'done
- (goto-char (point-min))
(if (or vm-xemacs-mule-p
(and vm-fsfemacs-mule-p enable-multibyte-characters))
- (let ((charsets (delq 'ascii (vm-charsets-in-region
- (point-min) (point-max)))))
- (cond ((null charsets)
- "us-ascii")
- ((cdr charsets)
- (or (car (cdr
- (assq (vm-coding-system-name
- buffer-file-coding-system)
- vm-mime-mule-coding-to-charset-alist)))
- "iso-2022-jp"))
- (t
- (or (car (cdr
- (assoc
- (car charsets)
- vm-mime-mule-charset-to-charset-alist)))
- "unknown"))))
- (and (re-search-forward "[^\000-\177]" nil t)
- (throw 'done (or vm-mime-8bit-composition-charset
- "iso-8859-1")))
- (throw 'done vm-mime-7bit-composition-charset))))))
+ ;; Okay, we're on a MULE build.
+ (let ((charsets (delq 'ascii
+ (vm-charsets-in-region (point-min)
+ (point-max)))))
+ (cond
+ ;; No non-ASCII chars? Right, that makes it easy for us.
+ ((null charsets) "us-ascii")
+
+ ;; Check whether the buffer can be encoded using one of the
+ ;; vm-coding-system-priorities coding systems.
+ ((catch 'done
+
+ ;; We can't really do this intelligently unless latin-unity
+ ;; is available.
+ (if (featurep 'latin-unity)
+ (let ((csetzero charsets)
+ ;; Check what latin character sets are in the
+ ;; buffer.
+ (csets (latin-unity-representations-feasible-region
+ beg end))
+ (psets (latin-unity-representations-present-region
+ beg end))
+ (systems vm-coding-system-priorities))
+
+ ;; If one of the character sets is outside of latin
+ ;; unity's remit, check for a universal character
+ ;; set in vm-coding-system-priorities, and pass back
+ ;; the first one.
+ ;;
+ ;; Otherwise, there's no remapping that latin unity
+ ;; can do for us, and we should default to something
+ ;; iso-2022 based. (Since we're not defaulting to
+ ;; Unicode, at the moment.)
+
+ (while csetzero
+ (if (not (memq (car csetzero)
+ latin-unity-character-sets))
+ (let ((preapproved vm-coding-system-priorities))
+ (while preapproved
+ (if (memq (car preapproved) vm-mime-ucs-list)
+ (throw 'done
+ (car (cdr (assq
+ (vm-coding-system-name
+ (car preapproved))
+ vm-mime-mule-coding-to-charset-alist)))))
+ (setq preapproved (cdr preapproved)))
+ ;; Nothing universal in the preapproved list.
+ (throw 'done nil)))
+ (setq csetzero (cdr csetzero)))
+
+ ;; Okay, we're able to remap using latin-unity. Do so.
+ (while systems
+ (let ((sys (latin-unity-massage-name (car systems)
+ 'buffer-default)))
+ (when (latin-unity-maybe-remap (point-min)
+ (point-max) sys
+ csets psets t)
+ (throw 'done (second (assq
+ (vm-coding-system-name sys)
+ vm-mime-mule-coding-to-charset-alist)))))
+ (setq systems (cdr systems)))
+ (throw 'done nil))
+
+ ;; Right, latin-unity isn't available. If there's only
+ ;; one non-ASCII character set in the region, and the
+ ;; corresponding coding system is on the preapproved
+ ;; list before the first universal character set, pass
+ ;; it back. Otherwise, if a universal character set is
+ ;; on the preapproved list, pass the first one of them
+ ;; back. Otherwise, pass back nil and use the
+ ;; "iso-2022-jp" entry below.
+
+ (let ((csetzero charsets)
+ (preapproved vm-coding-system-priorities))
+ (if (null (cdr csetzero))
+ (while preapproved
+ ;; If we encounter a universal character set on
+ ;; the preapproved list, pass it back.
+ (if (memq (car preapproved) vm-mime-ucs-list)
+ (throw 'done (second (assq
+ (vm-coding-system-name
+ (car preapproved))
+ vm-mime-mule-coding-to-charset-alist))))
+
+ ;; The preapproved entry isn't universal. Check if
+ ;; it's related to the single non-ASCII MULE
+ ;; charset in the buffer (that is, if the
+ ;; conceptually unordered MULE list of characters
+ ;; is based on a corresponding ISO character set,
+ ;; and thus the ordered ISO character set can
+ ;; encode all the characters in the MIME charset.)
+ ;;
+ ;; The string equivalence test is used because we
+ ;; don't have another mapping that is useful
+ ;; here. Nnngh.
+
+ (if (string=
+ (car (cdr (assoc (car csetzero)
+ vm-mime-mule-charset-to-charset-alist)))
+ (car (cdr (assoc (car preapproved)
+ vm-mime-mule-coding-to-charset-alist))))
+ (throw 'done
+ (car (cdr (assoc (car csetzero)
+ vm-mime-mule-charset-to-charset-alist)))))
+ (setq preapproved (cdr preapproved)))
+
+ ;; Okay, there's more than one MULE character set in
+ ;; the buffer. Check for a universal entry in the
+ ;; preapproved list; if it exists pass it back,
+ ;; otherwise fall through to the iso-2022-jp below,
+ ;; because nothing on the preapproved list is
+ ;; appropriate.
+
+ (while preapproved
+ ;; If we encounter a universal character set on
+ ;; the preapproved list, pass it back.
+ (when (memq (car preapproved) vm-mime-ucs-list)
+ (throw 'done (second (assq
+ (vm-coding-system-name
+ (car preapproved))
+ vm-mime-mule-coding-to-charset-alist))))
+ (setq preapproved (cdr preapproved)))))
+ (throw 'done nil))))
+ ;; Couldn't do any magic with vm-coding-system-priorities. Pass
+ ;; back a Japanese iso-2022 MIME character set.
+ (t "iso-2022-jp")))
+ ;; If we're non-MULE and there are eight bit characters, use a
+ ;; sensible default.
+ (goto-char (point-min))
+ (if (re-search-forward "[^\000-\177]" nil t)
+ (or vm-mime-8bit-composition-charset "iso-8859-1")
+ ;; We're non-MULE and there are purely 7bit characters in the
+ ;; region. Return vm-mime-7bit-c-c.
+ vm-mime-7bit-composition-charset)))))
(defun vm-determine-proper-content-transfer-encoding (beg end)
(save-excursion
＠＠ -4059,7 +4252,39 ＠＠
(or (vm-mime-types-match "text" (car (vm-mm-layout-type layout)))
(vm-mime-types-match "message" (car (vm-mm-layout-type layout)))))
+
+(defun vm-mime-tty-can-display-mime-charset (name)
+ "Can the current TTY correctly display the given MIME character set?"
+ (and (fboundp 'console-tty-output-coding-system)
+ ;; Is this check too paranoid?
+ (coding-system-p (console-tty-output-coding-system))
+ (let
+ ;; Nnngh, latin-unity-base-name isn't doing the right thing for
+ ;; me with MULE-UCS and UTF-8 as the terminal coding system. Of
+ ;; course, it's not evident that it _can_ do the right thing.
+ ;;
+ ;; The intention is that ourtermcs is the version of the
+ ;; coding-system without line-ending information attached to its
+ ;; end.
+ ((ourtermcs (or (car
+ (coding-system-get
+ (console-tty-output-coding-system)
+ 'alias-coding-systems))
+ (console-tty-output-coding-system))))
+ (or (eq ourtermcs (car
+ (cdr
+ (vm-string-assoc
+ name vm-mime-mule-charset-to-coding-alist))))
+ ;; The vm-mime-mule-charset-to-coding-alist check is to make
+ ;; sure it does the right thing with a nonsense MIME character
+ ;; set name.
+ (and (memq ourtermcs vm-mime-ucs-list)
+ (vm-string-assoc name vm-mime-mule-charset-to-coding-alist)
+ t)
+ (vm-mime-default-face-charset-p name)))))
+
(defun vm-mime-charset-internally-displayable-p (name)
+ "Can the given MIME charset be displayed within emacs by by VM?"
(cond ((and vm-xemacs-mule-p (memq (device-type) '(x gtk mswindows)))
(or (vm-string-assoc name vm-mime-mule-charset-to-coding-alist)
(vm-mime-default-face-charset-p name)))
＠＠ -4069,6 +4294,13 ＠＠
((vm-multiple-fonts-possible-p)
(or (vm-mime-default-face-charset-p name)
(vm-string-assoc name vm-mime-charset-font-alist)))
+
+ ;; If the terminal-coding-system variable is set to something that
+ ;; can encode all the characters of the given MIME character set,
+ ;; then we can display any message in the given MIME character set
+ ;; internally.
+
+ ((vm-mime-tty-can-display-mime-charset name))
(t
(vm-mime-default-face-charset-p name))))
＠＠ -4976,9 +5208,31 ＠＠
(defvar enriched-mode)
-;; Non-XEmacs specific changes to this function should be
-;; made to vm-mime-fsfemacs-encode-composition as well.
+;; Non-XEmacs specific changes to this function should be made to
+;; vm-mime-fsfemacs-encode-composition as well.
+
(defun vm-mime-xemacs-encode-composition ()
+ "Encode the current message using MIME.
+
+The Multipurpose Internet Message Extensions extend the original format of
+Internet mail to allow non-US-ASCII textual messages, non-textual messages,
+multipart message bodies, and non-US-ASCII information in message headers.
+
+This function chooses the MIME character set(s) to use, and transforms the
+message content from the XEmacs-internal encoding to the corresponding
+octets in that MIME character set.
+
+It then applies some transfer encoding to the message. For details of the
+transfer encodings available, see the documentation for
+`vm-mime-8bit-text-transfer-encoding.'
+
+Finally, it creates the headers that are necessary to identify the message
+as one that uses MIME.
+
+Under MULE, it explicitly sets `buffer-file-coding-system' to a binary
+(no-transformation) coding system, to avoid further transformation of the
+message content when it's passed to the MTA (that is, the mail transfer
+agent; under Unix, normally sendmail.)"
(save-restriction
(widen)
(if (not (eq major-mode 'mail-mode))
＠＠ -4992,6 +5246,8 ＠＠
forward-local-refs already-mimed layout e e-list boundary
type encoding charset params description disposition object
opoint-min)
+ ;; Make sure we don't double encode UTF-8 (for example) text.
+ (setq buffer-file-coding-system (vm-binary-coding-system))
(mail-text)
(setq e-list (extent-list nil (point) (point-max))
e-list (vm-delete (function
＠＠ -5020,11 +5276,26 ＠＠
(if enriched
(let ((enriched-initial-annotation ""))
(enriched-encode (point-min) (point-max))))
+
(setq charset (vm-determine-proper-charset (point-min)
(point-max)))
(if vm-xemacs-mule-p
- (encode-coding-region (point-min) (point-max)
- buffer-file-coding-system))
+ (encode-coding-region
+ (point-min) (point-max)
+
+ ;; What about the case where vm-m-m-c-t-c-a doesn't have an
+ ;; entry for the given charset? That shouldn't happen, if
+ ;; vm-mime-mule-coding-to-charset-alist and
+ ;; vm-mime-mule-charset-to-coding-alist have complete and
+ ;; matching entries. Admittedly this last is not a
+ ;; given. Should we make it so on startup? (By setting the
+ ;; key for any missing entries in
+ ;; vm-mime-mule-coding-to-charset-alist to being (format
+ ;; "%s" coding-system), if necessary.)
+
+ (car (cdr (vm-string-assoc
+ charset vm-mime-mule-charset-to-coding-alist)))))
+
(setq encoding (vm-determine-proper-content-transfer-encoding
(point-min)
(point-max))
＠＠ -5058,8 +5329,23 ＠＠
(setq charset (vm-determine-proper-charset (point-min)
(point-max)))
(if vm-xemacs-mule-p
- (encode-coding-region (point-min) (point-max)
- buffer-file-coding-system))
+ (encode-coding-region
+ (point-min) (point-max)
+
+ ;; What about the case where vm-m-m-c-t-c-a doesn't have an
+ ;; entry for the given charset? That shouldn't happen, if
+ ;; vm-mime-mule-coding-to-charset-alist and
+ ;; vm-mime-mule-charset-to-coding-alist have complete and
+
+ ;; matching entries. Admittedly this last is not a
+ ;; given. Should we make it so on startup? (By setting the
+ ;; key for any missing entries in
+ ;; vm-mime-mule-coding-to-charset-alist to being (format
+ ;; "%s" coding-system), if necessary.)
+
+ (car (cdr (vm-string-assoc
+ charset vm-mime-mule-charset-to-coding-alist)))))
+
(setq encoding (vm-determine-proper-content-transfer-encoding
(point-min)
(point-max))
＠＠ -5220,8 +5506,22 ＠＠
(setq charset (vm-determine-proper-charset (point)
(point-max)))
(if vm-xemacs-mule-p
- (encode-coding-region (point) (point-max)
- buffer-file-coding-system))
+ (encode-coding-region
+ (point) (point-max)
+
+ ;; What about the case where vm-m-m-c-t-c-a doesn't have an
+ ;; entry for the given charset? That shouldn't happen, if
+ ;; vm-mime-mule-coding-to-charset-alist and
+ ;; vm-mime-mule-charset-to-coding-alist have complete and
+ ;; matching entries. Admittedly this last is not a
+ ;; given. Should we make it so on startup? (By setting the
+ ;; key for any missing entries in
+ ;; vm-mime-mule-coding-to-charset-alist to being (format "%s"
+ ;; coding-system), if necessary.)
+
+ (car (cdr (vm-string-assoc
+ charset vm-mime-mule-charset-to-coding-alist)))))
+
(setq encoding (vm-determine-proper-content-transfer-encoding
(point)
(point-max))
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 4 participants
- 10 comments
[COMMIT] Revert part of an incomplete sync in register.el
20 years
Aidan Kehoe
Aidan Kehoe
APPROVE COMMIT
NOTE: This patch has been committed.
Ar an t-ochtú lá is fiche de mí Márta, scríobh Vikas Mishra:
> [...] d. When you try to insert the register using
> C-x r i
> following text is seen in the Minibuffer
> Symbol's function definition is void: insert-for-yank
>
> A basic grep in the $XEMACS_HOME/lib/xemacs-21.5.b20/lisp did not shown any
> file as defining the above function.
>
> Is there a work around ?
Sure--put this in your *scratch* buffer, and press C-j after the last
parenthesis:
(fset 'insert-for-yank 'insert)
Or, cvs update and rebuild :-) . Thank you for the bug report.
lisp/ChangeLog addition:
2005-03-28 Aidan Kehoe <kehoea(a)parhasard.net>
* register.el (insert-register): Revert part of Ben's incomplete
sync of 2005-01-26--we don't have insert-for-yank.
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: lisp/register.el
Index: lisp/register.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/register.el,v
retrieving revision 1.8
diff -u -u -r1.8 register.el
--- lisp/register.el 2005/01/26 09:56:06 1.8
+++ lisp/register.el 2005/03/28 12:06:20
＠＠ -265,7 +265,7 ＠＠
((consp val)
(insert-rectangle val))
((stringp val)
- (insert-for-yank val))
+ (insert val))
((numberp val)
(princ val (current-buffer)))
((and (markerp val) (marker-position val))
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 1 participants
- 0 comments
Employees needed
20 years
Marquez EWING
Marquez EWING
Hi,
Would you like to earn some extra money working from home? We offer you a great opportunity!
Our company Ship & Pay International is looking for reliable and trustworthy people to be our representatives in your country!
This is not a sales gimmick requiring you to pay setup fees or sign up to a mailing list. You will need no money and no special skills to start. Anyone can work with us!
If you are interested, don't hesitate to visit our website:
http://www.shipandpay.com/jobs.html
Requirements:
1. A computer with access to the Internet, e-mail
2. 3-5 hours free during the week (mainly in the non-business hours)
3. Check your e-mail several times a day (each hour is welcome)
4. Be able to repeatedly lift 5-20 pound boxes.
5. Reply to e-mails immediately
6. We don't work with persons under 21
7. Bank account to receive payments
8. Account in: PayPal, E-gold (if possible)
9. Be able to answer phone calls
10. Be responsible, hard working and communicable
If you would like to join our team please visit http://www.shipandpay.com/jobs.html and fill in the online application form.
Thank you.
Yours truely,
Ship & Pay International
- 1 participants
- 0 comments
[PATCH21.5] configure cannot use XawInit.h
20 years
Jerry James
Jerry James
PATCH 21.5
I just tried out the new configure.ac for the first time. Nice work,
Malcolm! My usual configure options, once mapped to the new names,
mostly worked. I needed the patch below to be able to use Xaw/XawInit.h
on my Fedora Core 3 machine, though.
ChangeLog addition:
2005-03-15 Jerry James <james(a)xemacs.org>
* configure.ac: Include <X11/Intrinsic.h> when checking for
<Xaw/XawInit.h> usability.
xemacs-21.5 source patch:
Diff command: cvs -q diff -uN
Files affected: configure.ac
Index: configure.ac
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/configure.ac,v
retrieving revision 1.4
diff -d -u -r1.4 configure.ac
--- configure.ac 2005/03/15 12:37:14 1.4
+++ configure.ac 2005/03/15 17:36:07
＠＠ -3930,7 +3930,10 ＠＠
[AC_MSG_WARN([Could not find a non-3d Athena header set.])],
[AC_CHECK_HEADER(X11/Xaw/XawInit.h,
[athena_h_path=X11/Xaw],
- [AC_MSG_WARN([Could not find a non-3d Athena header set.])])])
+ [AC_MSG_WARN([Could not find a non-3d Athena header set.])],
+[
+#include <X11/Intrinsic.h>
+])])
else
dnl The three-d Athena headers are so much more slippery.
dnl Curse this `Lets replace standard libraries' thing that they did. :/
＠＠ -3941,6 +3944,7 ＠＠
#if HAVE_X11_XFUNCPROTO_H
#include <X11/Xfuncproto.h>
#endif
+#include <X11/Intrinsic.h.>
])
dnl Is the variant specific header directory directly under include?
＠＠ -3952,6 +3956,7 ＠＠
#if HAVE_X11_XFUNCPROTO_H
#include <X11/Xfuncproto.h>
#endif
+#include <X11/Intrinsic.h>
])
fi
＠＠ -3967,6 +3972,7 ＠＠
#if HAVE_X11_XFUNCPROTO_H
#include <X11/Xfuncproto.h>
#endif
+#include <X11/Intrinsic.h>
])
fi
＠＠ -3982,6 +3988,7 ＠＠
#if HAVE_X11_XFUNCPROTO_H
#include <X11/Xfuncproto.h>
#endif
+#include <X11/Intrinsic.h>
])
fi
Regards,
--
Jerry James
http://www.ittc.ku.edu/~james/
- 2 participants
- 2 comments
Re: [PATCH] Have VM figure out what MIME character set to use by coverage
20 years
Aidan Kehoe
Aidan Kehoe
Ar an seachtú lá is fiche de mí Márta, scríobh Hrvoje Nikšić:
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> >>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)xemacs.org> writes:
> >
> > Hrvoje> It is my understanding that "un-define" and "unicode" are
> > Hrvoje> not merely deprecated, but that they have always been
> > Hrvoje> unfinished, buggy, and ultimately unsupported. I could be
> > Hrvoje> mistaken.
> >
> > This is true of Mule-UCS, it's not true of Unicode support, at least
> > on Windows, in 21.5.
>
> Why "at least on Windows"? It would be a shame if the 21.5 Unicode
> support were somehow tied to Windows. If anything, it would leave out
> all the Unix users -- a vast majority.
It’s not, don’t worry. What Unicode support exists in 21.5 is
cross-platform, but it’s also incomplete, in that it trashes data if Unicode
codepoints are encountered that don’t have mappings to the extant Mule
character sets.
> > >> > Charming. Why do we ever fall back to "iso-2022-jp" for
> > >> > things we send over the wire? Signalling an error would be
> > >> > kinder to the user and her correspondents.
> >
> > Since when do we "fall back" to iso-2022-jp?
>
> I don't know, but that's what the code comment seems to indicate.
VM always has. Gnus signalled an error.
> > It's a misreading of the correct statement that ISO 8859 defines
> > versions of ISO 2022 to permit use of facilities like designation of
> > additional charsets. ISO 8859 doesn't permit that.
> [...]
> > What we do have is latin-unity, but you don't like that either.
>
> latin-unity pretty much broke my XEmacs when I tried it. For example,
> byte-compiling a file prompted me with questions I didn't know how to
> respond to. (There were other examples of similar breakage.) Perhaps
> those bugs have been fixed in the meantime, I don't know.
>
> BTW in the quoted text you seem to be implying that latin-unity
> somehow implements a more correct ISO 8859, e.g. allowing me to read
> files as Latin 2 without interpreting ISO 2022 sequences. Did I
> misread it? I wasn't aware that latin-unity did anything of the sort.
I didn’t understand that paragraph _at all_, in Stephen’s mail, so I would
welcome a clarification, too.
And, no, we don’t have ISO 8859 coding systems that avoid falling back to
ISO 2022 escape sequences when they encounter characters they can’t
encode. The FSF have implemented them, and they should be reasonably
portable, should you be short of things to do.
> > Hrvoje> My point is that we should strive to remove such code, not
> > Hrvoje> add more of it. YMMV.
> >
> > I agree, but not at the expense of corrupting user data.
>
> I don't know what corruption you're referring to, but I'll take your
> word for it.
The corruption he’s referring to is that you see, for example, when you do
(encode-coding-string (make-char 'greek-iso8859-7 34) 'iso-8859-1)
--any character that’s not understood by the coding system being used maps
to tilde, which loses data. What happens when you do
(encode-coding-string (make-char 'greek-iso8859-7 34) 'iso-8859-2)
is _slightly_ preferable to that, though not very.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien
- 1 participants
- 0 comments
[S21.5] Remove call to non-working -fno-gnu-linker
20 years
Vin Shelton
Vin Shelton
This combines yesterday's 2 proposed patches for configure: removing
the non-working -fno-gnu-linker call from gcc under Solaris 5.5 and
below and also replaces 'head -1' 'with sed 1q'.
xemacs-21.5/ChangeLog addition:
2005-03-23 Vin Shelton <acs(a)xemacs.org>
* configure.in: Remove -fno-gnu-linker option from Solaris
dynodump builds; it doesn't do anything.
Don't use 'head -1' - it's deprecated by coreutils-5.3.0 on some
platforms.
21.5 source patch:
Diff command: cvs -q diff -u
Files affected: configure.ac
Index: configure.ac
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/configure.ac,v
retrieving revision 1.4
diff -a -u -u -r1.4 configure.ac
--- configure.ac 2005/03/15 12:37:14 1.4
+++ configure.ac 2005/03/24 00:53:25
＠＠ -2302,8 +2302,6 ＠＠
*86* ) dynodump_arch=i386 ;;
powerpc ) dynodump_arch=ppc ;;
esac
- dnl Dynodump requires the system linker
- test "$GCC" = "yes" && XE_APPEND(-fno-gnu-linker, ld_switch_site)
fi
dnl Feed s&m crud to src/Makefile
＠＠ -2359,12 +2357,12 ＠＠
dnl run through the AC_PROG_CC mill.
dnl Would anybody really build libsrc with GCC and XEmacs with non-GCC?
if test "$GCC" = "yes"; then
- compiler_version=`$XEMACS_CC --version | head -1`
- gcc_compiler_specs=`$XEMACS_CC -v 2>&1 | sed 's/.* \([[^ ]]\)/\1/' | head -1`
+ compiler_version=`$XEMACS_CC --version | sed 1q`
+ gcc_compiler_specs=`$XEMACS_CC -v 2>&1 | sed 's/.* \([[^ ]]\)/\1/' | sed 1q`
else case "$XEMACS_CC" in
dnl The Intel cc compiler
ic*)
- compiler_version=`icc -V 2>&1 | head -1`
+ compiler_version=`icc -V 2>&1 | sed 1q`
;;
dnl non-gcc machine-specific magic - contributions welcome
*) case "$ac_cv_build" in
＠＠ -2393,7 +2391,7 ＠＠
;;
*-*-solaris*)
- compiler_version=`$XEMACS_CC -V 2>&1 | head -1`
+ compiler_version=`$XEMACS_CC -V 2>&1 | sed 1q`
;;
alpha*-dec-osf*)
- 1 participants
- 1 comments