10:44 p.m.
Hi, XEmacs.
When I try to build the packages, the build errors out in auctex with
these messages:
#########################################################################
Generating autoloads for auctex/tex-jp.el...
# bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
# (unwind-protect ...)
scan-sexps(10341 1)
# bind (count)
forward-sexp(1)
# (unwind-protect ...)
# (unwind-protect ...)
# bind (autoloads-done)
byte-code("..." [noninteractive load-name outbuf trim-name
generate-autoload-cookie autoloads-done nil search-forward t message "No autoloads
found in %s" #:generate-lisp-file-autoloads-1 "Generating autoloads for
%s..." " \n
" looking-at regexp-quote
process-one-lisp-autoload ";" 1 forward-sexp "Generating autoloads for
%s...done"] 4)
# (catch #:generate-lisp-file-autoloads-1 ...)
# bind (trim-name load-name outbuf)
generate-lisp-file-autoloads-1(#<buffer "auto-autoloads.el">
"tex-jp" "auctex/tex-jp.el")
# (unwind-protect ...)
# (unwind-protect ...)
# bind (outbuf trim-name autoloads-done print-length print-readably float-output-format
visited suppress-form output-end)
byte-code("..." [trim-name autoloads-done _pkg outbuf suppress-form file
autoload-trim-file-name nil t get-file-buffer expand-file-name file-name-directory
"_pkg.el" file-readable-p ((byte-code �� ��� !��" [pkg-vis pkg-buf
kill-buffer] 2)) find-file-noselect set-syntax-table #:nil (byte-code
"����#����!��p!� k����p!!���)�_�" [suppress-form load-name supfile
search-forward "(package-suppress" nil t forward-sexp 1 read eval #:nil] 5)
((byte-code "\n���p!� q�� Ç" [output-end outbuf visited kill-buffer
point-marker] 2)) #:generate-autoload-type-section prin1 autoloads terpri "\n;;;
Suppress form from _pkg.el\n" "(unless " prin1-to-string "\n\n"
"\n) ;; unless (suppressed)\n" output-end visited dir pkg-vis
emacs-lisp-mode-syntax-table load-name float-output-format print-readably print-length
pkg-buf enable-local-variables find-file-hooks literal fun-to-call
generate-autoload-section-header generate-a!
utoload-section-trailer] 9)
# (catch #:generate-autoload-type-section ...)
# bind (fun-to-call literal load-name file)
generate-autoload-type-section("/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/auctex/tex-jp.el"
"tex-jp" nil generate-lisp-file-autoloads-1)
# bind (file)
generate-file-autoloads("/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/auctex/tex-jp.el")
# (unwind-protect ...)
# bind (load-name trim-name section-begin form file)
update-file-autoloads("/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/auctex/tex-jp.el")
# bind (#:G49943 arg defdir autoload-feature-name enable-local-eval
autoload-feature-prefix generated-autoload-file force into-file feature-prefix
files-or-dirs)
update-autoload-files(("bib-cite.el" "font-latex.el"
"latex.el" "toolbar-x.el" "tex-bar.el"
"multi-prompt.el" "tex-buf.el" "tex-info.el"
"tex-mik.el" "tex.el" "texmathp.el" "context.el"
"context-en.el" "context-nl.el" "tex-fold.el"
"tex-jp.el" "_pkg.el") "auctex"
"./auto-autoloads.el" t)
batch-update-autoloads()
# bind (arg)
command-line-do-funcall("-f")
# bind (dir file-count line end-of-options file-p arg tem)
command-line-1()
# bind (command-line-args-left)
command-line()
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
xemacs exiting.
Scan error: Unbalanced parentheses, 10341, 29792make[2]: *** [auto-autoloads.el] Error
255
make[2]: Leaving directory
`/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/auctex'
make[1]: *** [auctex/autoloads.target] Error 2
make[1]: Leaving directory
`/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages'
make: *** [xemacs-packages/autoloads.target] Error 2
#########################################################################
If this is indeed an error in auctex, would its maintainer please fix it
soon. Otherwise, could somebody please give me a hint as to what's going
wrong in my build.
Other than that, is there a nice easy recipe to build the packages whilst
omitting the erroneous ones, so as to get a working, up to date XEmacs?
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:33 p.m.
>>>> Alan Mackenzie <acm(a)muc.de> writes:
When I try to build the packages, the build errors out in auctex
with
these messages:
Strange. Need to get some version info I think. What version of XEmacs
and what version of the packages are you using?
The tip version of the packages are in a good state right now I
think. The smoketest is all green and has been that for a while
"http://www.contactor.se/~matsl/smoketest/"
[...]
Other than that, is there a nice easy recipe to build the packages
whilst omitting the erroneous ones, so as to get a working, up to
date XEmacs?
I normally use the -k flag to make to just let it continue when
stumbling on an error. That can sometimes get you going.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:55 p.m.
Hi, Mats.
On Fri, Mar 15, 2013 at 12:33:59AM +0100, Mats Lidell wrote:
>>>>> Alan Mackenzie <acm(a)muc.de> writes:
> When I try to build the packages, the build errors out in auctex
with
> these messages:
Further: I can load tex-jp.el without problem into GNU Emacs. In my
(semi-working) XEmacs, it seems to be ignoring the character encoding,
treating each 8-bit byte as a character. There are what look like
parentheses throwing off the paren matching.
Strange. Need to get some version info I think. What version of
XEmacs
and what version of the packages are you using?
I'm using the hg tip version of XEmacs and I've just updated (and failed
to build) the tip version of the packages. I have just two lines in my
Local.rules changed from Local.rules.template, namely:
XEMACS_BINARY = ~/emacs/xemacs.hg/xemacs/src/xemacs
XEMACS_INSTALLED_PACKAGES_ROOT = /home/acm/emacs/xemacs.hg/xemacs-packages.elc
.
The tip version of the packages are in a good state right now I
think. The smoketest is all green and has been that for a while
I can't agree with this. I first did make clean. Using your -k
suggestion (thanks!), xemacs-packages mostly builds, mule-packages fails
almost totally, producing an obscure dump for many (almost all?)
files.el. A typical output in mule-packages looks like this:
#########################################################################
Cannot open load file:
"/home/acm/emacs/xemacs.hg/xemacs-packages/mule-packages/mule-base/auto-autoloads"make[2]:
*** [auto-autoloads.elc] Error 255
~/emacs/xemacs.hg/xemacs/src/xemacs -no-autoloads -vanilla -batch -eval '(setq
stack-trace-on-error t load-always-display-messages t load-ignore-out-of-date-elc-files t
load-show-full-path-in-messages t)' -eval '(setq load-path (list (expand-file-name
"mule" lisp-directory) lisp-directory))' -l
/home/acm/emacs/xemacs.hg/xemacs-packages/package-compile.el -- leim mule-base fsf-compat
xemacs-base latin-euro-standards -- -f batch-byte-compile custom-load.el
Loading /home/acm/emacs/xemacs.hg/xemacs-packages/package-compile.el...
Loading /home/acm/emacs/xemacs.hg/xemacs/lisp/auto-autoloads.elc...
Requiring /home/acm/emacs/xemacs.hg/xemacs/lisp/bytecomp.elc...
Loading /home/acm/emacs/xemacs.hg/xemacs/lisp/cl-macs.elc...
Requiring /home/acm/emacs/xemacs.hg/xemacs/lisp/byte-optimize.elc...
Loading
/home/acm/emacs/xemacs.hg/xemacs-packages/mule-packages/latin-euro-standards/auto-autoloads.el...
Loading
/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/xemacs-base/auto-autoloads.elc...
Loading
/home/acm/emacs/xemacs.hg/xemacs-packages/xemacs-packages/fsf-compat/auto-autoloads.elc...
# bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
# (unwind-protect ...)
signal(file-error ("Cannot open load file"
"/home/acm/emacs/xemacs.hg/xemacs-packages/mule-packages/mule-base/auto-autoloads"))
# bind (handler path nosuffix nomessage noerror filename)
load("/home/acm/emacs/xemacs.hg/xemacs-packages/mule-packages/mule-base/auto-autoloads")
# bind (etc-dir dir)
(let* ((dir (car dirs)) (etc-dir (expand-file-name "etc" dir))) (while dirs
(push (car dirs) load-path) (setq dirs (cdr dirs))) (if (file-directory-p
(expand-file-name (car depends) etc-dir)) (push (file-name-as-directory etc-dir)
data-directory-list)) (load (expand-file-name "auto-autoloads" dir)) (pop
depends))
# bind (dirs)
(let ((dirs (package-name-to-directories (car depends)))) (when (null dirs) (error
"%s is not in `package-directory-map'. See: package-compile.el" (car
depends))) (let* ((dir (car dirs)) (etc-dir (expand-file-name "etc" dir)))
(while dirs (push (car dirs) load-path) (setq dirs (cdr dirs))) (if (file-directory-p
(expand-file-name (car depends) etc-dir)) (push (file-name-as-directory etc-dir)
data-directory-list)) (load (expand-file-name "auto-autoloads" dir)) (pop
depends)))
(while depends (let ((dirs (package-name-to-directories (car depends)))) (when (null
dirs) (error "%s is not in `package-directory-map'. See:
package-compile.el" (car depends))) (let* ((dir (car dirs)) (etc-dir
(expand-file-name "etc" dir))) (while dirs (push (car dirs) load-path) (setq
dirs (cdr dirs))) (if (file-directory-p (expand-file-name (car depends) etc-dir)) (push
(file-name-as-directory etc-dir) data-directory-list)) (load (expand-file-name
"auto-autoloads" dir)) (pop depends))))
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
(load-internal "[internal]")
load-internal("/home/acm/emacs/xemacs.hg/xemacs-packages/package-compile.el"
nil t nil binary)
# bind (handler path nosuffix nomessage noerror filename)
load("/home/acm/emacs/xemacs.hg/xemacs-packages/package-compile.el" nil t)
# bind (file arg)
command-line-do-load("-l")
# bind (dir file-count line end-of-options file-p arg tem)
command-line-1()
# bind (command-line-args-left)
command-line()
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
xemacs exiting.
#########################################################################
Is this dump meant to be a stack trace? How come there are 8 consecutive
lines of "# (unwind-protect ...)"?
Further help would be greatly appreciated.
"http://www.contactor.se/~matsl/smoketest/"
Yours
--
%% Mats
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:06 p.m.
> "Alan" == Alan Mackenzie <acm(a)muc.de> writes:
Hi, Mats.
On Fri, Mar 15, 2013 at 12:33:59AM +0100, Mats Lidell wrote:
> >>>>> Alan Mackenzie <acm(a)muc.de> writes:
> > When I try to build the packages, the build errors out in
auctex with
> > these messages:
Further: I can load tex-jp.el without problem into GNU Emacs. In my
(semi-working) XEmacs, it seems to be ignoring the character encoding,
treating each 8-bit byte as a character. There are what look like
parentheses throwing off the paren matching.
Hm which version of xemacs are you using, more importantly: are you using
Mule? I remember that tex-jp.el was a sort of problem but I don't recall
right now the details.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:40 p.m.
Hello, Uwe.
On Fri, Mar 15, 2013 at 04:06:18PM +0100, Uwe Brauer wrote:
>> "Alan" == Alan Mackenzie <acm(a)muc.de>
writes:
> Hi, Mats.
> On Fri, Mar 15, 2013 at 12:33:59AM +0100, Mats Lidell wrote:
>> >>>>> Alan Mackenzie <acm(a)muc.de> writes:
>> > When I try to build the packages, the build errors
out in auctex with
>> > these messages:
> Further: I can load tex-jp.el without problem into GNU Emacs.
In my
> (semi-working) XEmacs, it seems to be ignoring the character encoding,
> treating each 8-bit byte as a character. There are what look like
> parentheses throwing off the paren matching.
Hm which version of xemacs are you using, more importantly: are you
using
Mule? I remember that tex-jp.el was a sort of problem but I don't recall
right now the details.
I'm trying to use the repository tip. I'm not sure if I'm using Mule;
the manual doesn't say how you tell. Except, I configured XEmacs
without "--with-mule", so probably not.
Surely one can build XEmacs without Mule, otherwise there wouldn't be an
option at configuration. Also tex-jp.el _must_ be usable without Mule,
since whilst it is being compiled by the Make process, Mule doesn't yet
exist.
Uwe Brauer
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:47 p.m.
> "Alan" == Alan Mackenzie <acm(a)muc.de> writes:
> Hello, Uwe.
> On Fri, Mar 15, 2013 at 04:06:18PM +0100, Uwe Brauer wrote:
>> > "Alan" == Alan Mackenzie
<acm(a)muc.de> writes:
> > Hi, Mats.
> > On Fri, Mar 15, 2013 at 12:33:59AM +0100, Mats Lidell wrote:
> >> >>>>> Alan Mackenzie <acm(a)muc.de> writes:
> >> > When I try to build the packages, the build errors
out in auctex with
> >> > these messages:
> > Further: I can load tex-jp.el without problem into GNU
Emacs. In my
> > (semi-working) XEmacs, it seems to be ignoring the character encoding,
> > treating each 8-bit byte as a character. There are what look like
> > parentheses throwing off the paren matching.
> Hm which version of xemacs are you using, more importantly: are
you using
> Mule? I remember that tex-jp.el was a sort of problem but I don't recall
> right now the details.
I'm trying to use the repository tip. I'm not sure if
I'm using Mule;
the manual doesn't say how you tell. Except, I configured XEmacs
without "--with-mule", so probably not.
I always forget what is the standard. Can you try
to evaluate
(featurep 'mule)
Surely one can build XEmacs without Mule, otherwise there
wouldn't be an
option at configuration. Also tex-jp.el _must_ be usable without Mule,
since whilst it is being compiled by the Make process, Mule doesn't yet
exist.
That is true for Xemacs but not for GNU Emacs. (GNU Emacs is not Mule
free since 15 years or even more.) Don't forget that auctex was almost
entirely developed by GNU Emacs users, and so it seems likely that you
need a Mule version to compile tex-jp.el
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:41 a.m.
Hi, Uwe.
On Fri, Mar 15, 2013 at 06:47:38PM +0100, Uwe Brauer wrote:
>> "Alan" == Alan Mackenzie <acm(a)muc.de>
writes:
> > Hello, Uwe.
> > On Fri, Mar 15, 2013 at 04:06:18PM +0100, Uwe Brauer wrote:
> > >> "Alan" == Alan
Mackenzie <acm(a)muc.de> writes:
>> > Hi, Mats.
>> > On Fri, Mar 15, 2013 at 12:33:59AM +0100, Mats Lidell wrote:
>> >> >>>>> Alan Mackenzie <acm(a)muc.de> writes:
>> >> > When I try to build the packages, the build
errors out in auctex with
>> >> > these messages:
>> > Further: I can load tex-jp.el without problem into
GNU Emacs. In my
>> > (semi-working) XEmacs, it seems to be ignoring the character encoding,
>> > treating each 8-bit byte as a character. There are what look like
>> > parentheses throwing off the paren matching.
>> Hm which version of xemacs are you using, more
importantly: are you using
>> Mule? I remember that tex-jp.el was a sort of problem but I don't recall
>> right now the details.
> I'm trying to use the repository tip. I'm not sure
if I'm using Mule;
> the manual doesn't say how you tell. Except, I configured XEmacs
> without "--with-mule", so probably not.
I always forget what is the standard. Can you try
to evaluate
(featurep 'mule)
Sorry, too late! I'd already reconfigured my XEmacs with --with-mule and
rebuilt it before I saw your email. With that change, I can now load
tex-jp.el into XEmacs successfully, and indeed it builds properly whilst
making the packages.
> Surely one can build XEmacs without Mule, otherwise there
wouldn't be an
> option at configuration. Also tex-jp.el _must_ be usable without Mule,
> since whilst it is being compiled by the Make process, Mule doesn't yet
> exist.
That is true for Xemacs but not for GNU Emacs. (GNU Emacs is not Mule
free since 15 years or even more.) Don't forget that auctex was almost
entirely developed by GNU Emacs users, and so it seems likely that you
need a Mule version to compile tex-jp.el
Yes. To build the packages' sources, one must configure --with-mule.
Anyhow, I've now got my XEmacs more or less working again (after several
days pure pain) - recent XEmacs cores don't work at all well with older
(November 2011) packages. ;-)
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:07 p.m.
Alan Mackenzie writes:
Anyhow, I've now got my XEmacs more or less working again (after
several
days pure pain) - recent XEmacs cores don't work at all well with older
(November 2011) packages. ;-)
Please report these, even in the form "!?#$%!! foo package won't
build". (If it's too embarrassing to post that to -beta, feel free to
write me personally. ;-) We can't afford to have package maintainers
in pain.) Unfortunately at the moment I can't personally guarantee
speedy work on the problems -- you know how it is -- but at least give
me a reason to feel *guilty* about dallying!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:51 p.m.
Alan Mackenzie writes:
I'm trying to use the repository tip. I'm not sure if
I'm using Mule;
the manual doesn't say how you tell. Except, I configured XEmacs
without "--with-mule", so probably not.
You need to configure --with-mule to get multilingual functionality.
Surely one can build XEmacs without Mule, otherwise there
wouldn't
be an option at configuration.
You can, but it will ignore the core lisp/mule directory. It can't
handle those files. Unfortunately the package Makefile (actually a
mess of a dozen or so Makefiles and includes) isn't so smart. You
could reconfigure and rebuild to get a Mule XEmacs, or you can use
your existing non-Mule build, if first you tell the packages to build
without Mule with
BUILD_WITHOUT_MULE = t
in the Local.rules file in the toplevel package directory (the one
which contains the xemacs-packages and mule-packages hierarchies).
Also tex-jp.el _must_ be usable without Mule,
It's not. Cf this stanza in the AUCTeX Makefile:
ifeq ($(BUILD_WITHOUT_MULE),)
ELCS += tex-jp.elc
endif
since whilst it is being compiled by the Make process, Mule
doesn't
yet exist.
In fact, it does. When present, Mule functionality infests Emacs at
the lowest possible level since it redefines the concept of buffer
text, changing the bit-level semantics of Finsert etc.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:48 a.m.
Hi, Stephen.
On Sat, Mar 16, 2013 at 06:51:08AM +0900, Stephen J. Turnbull wrote:
Alan Mackenzie writes:
> I'm trying to use the repository tip. I'm not sure if
I'm using Mule;
> the manual doesn't say how you tell. Except, I configured XEmacs
> without "--with-mule", so probably not.
You need to configure --with-mule to get multilingual functionality.
Thanks, I understand that now. Maybe --with-mule should be made the
default.
> Surely one can build XEmacs without Mule, otherwise there
wouldn't
> be an option at configuration.
You can, but it will ignore the core lisp/mule directory. It
can't
handle those files. Unfortunately the package Makefile (actually a
mess of a dozen or so Makefiles and includes) isn't so smart. You
could reconfigure and rebuild to get a Mule XEmacs, or you can use
your existing non-Mule build, if first you tell the packages to build
without Mule with
BUILD_WITHOUT_MULE = t
in the Local.rules file in the toplevel package directory (the one
which contains the xemacs-packages and mule-packages hierarchies).
> Also tex-jp.el _must_ be usable without Mule,
It's not. Cf this stanza in the AUCTeX Makefile:
ifeq ($(BUILD_WITHOUT_MULE),)
ELCS += tex-jp.elc
endif
OK.
> since whilst it is being compiled by the Make process, Mule
doesn't
> yet exist.
In fact, it does. When present, Mule functionality infests Emacs at
the lowest possible level since it redefines the concept of buffer
text, changing the bit-level semantics of Finsert etc.
Ah. I would presume there's not a lot of call for a non-Mule XEmacs any
more.
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:23 p.m.
New subject: RFC: -- default configure to --with-mule
Anybody with feelings about this, please let us know!
Alan Mackenzie writes:
Thanks, I understand that now. Maybe --with-mule should be made the
default.
Yes, I think you're right. People who need the speed will know it and
usually are the kind of folks who build their own and mess with CFLAGS
on the configure command-line. :-)
Ah. I would presume there's not a lot of call for a non-Mule
XEmacs any
more.
I wouldn't go so far as to say that. People can and do process
gigabyte log files with XEmacs, for example. If 99.44% of it is
ASCII, the few non-ASCII characters rarely matter and if necessary you
can iconv them in a Unicode terminal. But what the 0.56% do to
char-byte position translation speed is a vicious hate crime.
Nevertheless, I think the "if you need it, you have the option"
argument is pretty strong.
The other thing is that with Xft builds, it probably should be
relatively easy to make no-mule XEmacs Unicode *display-capable*
without making it Unicode edit-capable. (The complex parts of Mule at
the C level are buffer position translations and coding systems.) The
theory is that Xft already knows how to interpret UTF-8, I think (if
not, the translation to UTF-16 is trivial and code probably already in
all 21.5 builds). So there would be a special UTF-8 buffer display
mode, which would provide overlays to hide the UTF-8 representation
and display the Unicode glyphs, and a simple function to pipe to iconv
(or other character code translation program such as GNU recode).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:52 p.m.
New subject: RFC: -- default configure to --with-mule
On Sat, Mar 16, 2013 at 8:23 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Yes, I think you're right. People who need the speed will know
it and
usually are the kind of folks who build their own and mess with CFLAGS
on the configure command-line. :-)
I agree. Let's make --with-mule the default.
The other thing is that with Xft builds, it probably should be
relatively easy to make no-mule XEmacs Unicode *display-capable*
without making it Unicode edit-capable. (The complex parts of Mule at
the C level are buffer position translations and coding systems.) The
theory is that Xft already knows how to interpret UTF-8, I think (if
not, the translation to UTF-16 is trivial and code probably already in
all 21.5 builds). So there would be a special UTF-8 buffer display
mode, which would provide overlays to hide the UTF-8 representation
and display the Unicode glyphs, and a simple function to pipe to iconv
(or other character code translation program such as GNU recode).
AIUI, Xft can work with UTF-8, UTF-16, and UTF-32 strings: hence,
XftDrawString8, XftDrawString16, XftDrawString32, etc.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:36 p.m.
New subject: RFC: -- default configure to --with-mule
>>>> Jerry James <james(a)xemacs.org> writes:
I agree. Let's make --with-mule the default.
+1
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:09 a.m.
New subject: RFC: -- default configure to --with-mule
Mats Lidell wrote:
>>>>> Jerry James <james(a)xemacs.org> writes:
> I agree. Let's make --with-mule the default.
+1
FWIW, +1 from me, too. I find UTF-8 text appearing more often, and it
provides better Emacs compatibility as Alan discovered.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:43 a.m.
New subject: RFC: -- default configure to --with-mule
On Sat, 16 Mar 2013 23:23:50 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Anybody with feelings about this, please let us know!
If with-mule becomes the default, will the xemacs-mule-sumo be rolled
into the xemacs-sumo? It seems to me that if with-mule is the default,
the "default" sumo should just work.
Not sure how that would affect us without-mule users.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:36 p.m.
New subject: RFC: -- default configure to --with-mule
Sean MacLennan writes:
On Sat, 16 Mar 2013 23:23:50 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
> Anybody with feelings about this, please let us know!
If with-mule becomes the default, will the xemacs-mule-sumo be rolled
into the xemacs-sumo? It seems to me that if with-mule is the default,
the "default" sumo should just work.
I'll have to think about it. For the packages the main issue is that
it's just deadweight, I think, although there *may* be some packages
that conditionally require Mule packages if they're available (rather
than when (featurep 'mule)). That would be *bad* as Alan discovered.
Not sure how that would affect us without-mule users.
Shouldn't affect you at all. You'll just have some deadweight files
under mule-packages.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:29 a.m.
New subject: RFC: -- default configure to --with-mule
On Wed, 20 Mar 2013 08:36:39 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Sean MacLennan writes:
> On Sat, 16 Mar 2013 23:23:50 +0900
> "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>
> > Anybody with feelings about this, please let us know!
>
> If with-mule becomes the default, will the xemacs-mule-sumo be
> rolled into the xemacs-sumo? It seems to me that if with-mule is
> the default, the "default" sumo should just work.
I'll have to think about it. For the packages the main issue is that
it's just deadweight, I think, although there *may* be some packages
that conditionally require Mule packages if they're available (rather
than when (featurep 'mule)). That would be *bad* as Alan discovered.
> Not sure how that would affect us without-mule users.
Shouldn't affect you at all. You'll just have some deadweight files
under mule-packages.
Cool. I if I get some time.... I may just try installing the mule sumo
just for giggles.
I take it then there are no byte compile issues with mule versus
non-mule?
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:06 a.m.
New subject: RFC: -- default configure to --with-mule
+1
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:26 p.m.
>>>> Alan Mackenzie <acm(a)muc.de> writes:
> The tip version of the packages are in a good state right now
[...]
I can't agree with this. [...]
It could be the MULE configuration that Stephen talks about. The
smoketest uses this configuration parameter depending on whether it is
a mule or non mule build.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4265
days inactive
4271
days old
18 comments
8 participants
participants (8)
-
Alan Mackenzie -
Jerry James -
Michael Sperber -
Mike Kupfer -
Sean MacLennan -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer