9:05 a.m.
================================================================
Dear Bug Team!
In "xemacs-21.4.10 -vanilla", with the sumo package of 2003-02-05
installed, hexl-find-file produces the following error message:
Symbol's function definition is void: get-coding-system
Here's a stack trace:
# bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error
debug-on-error)
get-coding-system(binary)
# bind (codesys filename)
find-file("/tmp/foo.dvi" binary)
# bind (filename)
hexl-find-file("/tmp/foo.dvi")
# bind (command-debug-status)
call-interactively(hexl-find-file)
command-execute(hexl-find-file t)
# bind (_execute_command_keys_ _execute_command_name_ prefix-arg)
execute-extended-command(nil)
# bind (command-debug-status)
call-interactively(execute-extended-command)
# (condition-case ... . error)
# (catch top-level ...)
Jouni K Seppänen
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux itl-pc9.hut.fi 2.4.18-4 #1 Tue May 14 15:10:08 EEST 2002 i686 unknown
./configure '--prefix=/r' '--pdump'
XEmacs 21.4.10 "Military Intelligence" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /share/r_src/xemacs/xemacs-21.4.10-linux
Installation prefix: /r
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O -mcpu=pentium -march=pentium
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Load-Path Lisp Shadows:
----------------------
(/r/lib/xemacs/xemacs-packages/lisp/build/build-report
/r/stow/xemacs-21.4.10/lib/xemacs-21.4.10/lisp/build-report)
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.11 :type regular)
(xslide :version 1.04 :type regular)
(xemacs-devel :version 1.5 :type single-file)
(xemacs-base :version 1.75 :type regular)
(w3 :version 1.28 :type regular)
(vm :version 7.07 :type regular)
(viper :version 1.35 :type regular)
(view-process :version 1.12 :type regular)
(vhdl :version 1.16 :type regular)
(vc-cc :version 1.21 :type regular)
(vc :version 1.35 :type regular)
(tramp :version 1.11 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.35 :type regular)
(time :version 1.12 :type regular)
(textools :version 1.14 :type regular)
(text-modes :version 1.58 :type single-file)
(texinfo :version 1.23 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.26 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(sml-mode :version 0.07000000000000001 :type regular)
(slider :version 1.13 :type regular)
(sieve :version 1.11 :type regular)
(sh-script :version 1.17 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.17 :type regular)
(scheme :version 1.13 :type regular)
(sasl :version 1.12 :type regular)
(ruby-modes :version 1.01 :type regular)
(rmail :version 1.13 :type regular)
(reftex :version 1.28 :type regular)
(python-modes :version 1.02 :type single-file)
(psgml-dtds :version 1.02 :type regular)
(psgml :version 1.38 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.72
:type
single-file)
(pgg :version 1.02 :type regular)
(perl-modes :version 1.04 :type single-file)
(pcomplete :version 1.02 :type regular)
(pcl-cvs :version 1.64 :type regular)
(pc :version 1.25 :type single-file)
(os-utils :version 1.3 :type single-file)
(ocaml :version 0.04 :type regular)
(net-utils :version 1.31 :type single-file)
(mmm-mode :version 1.0 :type regular)
(misc-games :version 1.16 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.17 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.12 :type regular)
(mail-lib :version 1.56 :type regular)
(liece :version 1.1 :type regular)
(jde :version 1.43 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.29 :type regular)
(igrep :version 1.1 :type regular)
(idlwave :version 1.28 :type regular)
(ibuffer :version 1.08 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.05 :type regular)
(gnus :version 1.65 :type regular)
(gnats :version 1.15 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.12 :type single-file)
(frame-icon :version 1.09 :type regular)
(fortran-modes :version 1.02 :type single-file)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.37 :type regular)
(eterm :version 1.13 :type regular)
(ess :version 1.03 :type regular)
(eshell :version 1.04 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.04 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.98 :type single-file)
(ediff :version 1.46 :type regular)
(edebug :version 1.15 :type regular)
(ecrypto :version 0.12 :type regular)
(ecb :version 1.01 :type regular)
(docbookide :version 0.06 :type regular)
(dired :version 1.13 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.16 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.04 :type regular)
(cc-mode :version 1.32 :type regular)
(calendar :version 1.19 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.1 :type regular)
(bbdb :version 1.21 :type regular)
(auctex :version 1.33 :type regular)
(apel :version 1.26 :type regular)
(ada :version 1.13 :type regular))
Installed Modules:
-----------------
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 hexl zenirc-autoloads
xslt-process-autoloads xslide-autoloads xemacs-devel-autoloads
xemacs-base-autoloads w3-autoloads vm-autoloads viper-autoloads
view-process-autoloads vhdl-autoloads vc-cc-autoloads vc-autoloads
tramp-autoloads tpu-autoloads tooltalk-autoloads tm-autoloads
time-autoloads textools-autoloads text-modes-autoloads
texinfo-autoloads supercite-autoloads strokes-autoloads
speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads
sml-mode-autoloads slider-autoloads sieve-autoloads
sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads
sasl-autoloads ruby-modes-autoloads rmail-autoloads reftex-autoloads
python-modes-autoloads psgml-dtds-autoloads psgml-autoloads
ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads ocaml-autoloads net-utils-autoloads
mmm-mode-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads
mew-autoloads mailcrypt-autoloads mail-lib-autoloads liece-autoloads
jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads
idlwave-autoloads ibuffer-autoloads hm--html-menus-autoloads
haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads
fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
ess-autoloads eshell-autoloads emerge-autoloads elib-autoloads
eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads
ediff-autoloads edebug-autoloads ecrypto-autoloads ecb-autoloads
docbookide-autoloads dired-autoloads dictionary-autoloads
debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads
cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
apel-autoloads ada-autoloads lisp-autoloads loadhist auto-show
fontl-hooks x-iso8859-1 gutter-items menubar-items x-menubar
mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page
buff-menu lib-complete help-nomule cus-file derived frame text-props
obsolete cus-start custom widget cl-extra mini-cl cl cl-19 packages
backquote very-early-lisp lucid-scrollbars cut-buffer lucid-menubars
motif-dialogs x c-balloon-help tty-frames tty toolbar native-sound
scrollbar unix-processes multicast network-streams subprocesses
modules menu-accelerator-support menubar berkeley-db md5 xemacs gutter
tiff png gif jpeg xface xpm xbm lisp-float-type linux dialog devices
window-system base64)
Recent keystrokes:
-----------------
M-x h e x l - f i n d - f i l e RET / t m p / f o o
. d v i RET misc-user
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Symbol's function definition is void: get-coding-system
Loading xemacsbug...
Loading hexl...done
Loading hexl...
1:24 p.m.
On Thu, 2003-02-06 at 11:05, Jouni Seppanen wrote:
In "xemacs-21.4.10 -vanilla", with the sumo package of
2003-02-05
installed, hexl-find-file produces the following error message:
Symbol's function definition is void: get-coding-system
Eek. get-coding-system is defined only in Mule XEmacsen, and invoking
`find-file' with the optional CODESYS argument uses it, no matter
whether running on Mule or not.
I'm not sure how this should be fixed, but the patch below could qualify
as a workaround for this particular case (feedback most welcome). Maybe
find-file-* in files.el should check for availablility of
get-coding-system before using it. hexl.el from GNU Emacs 21.2.93 uses
`find-file-literally' here, which we don't have.
By the way Jouni, do you happen to have any idea why the hut.fi Linux
boxes have a non-Mule XEmacs? Maybe a note to the ATK-keskus people
would be a good idea :)
Index: hexl.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/text-modes/hexl.el,v
retrieving revision 1.5
diff -a -u -r1.5 hexl.el
--- hexl.el 20 Jul 2001 14:09:16 -0000 1.5
+++ hexl.el 9 Feb 2003 13:20:30 -0000
＠＠ -293,7 +293,9 ＠＠
"Edit file FILENAME in hexl-mode.
Switch to a buffer visiting file FILENAME, creating one if none exists."
(interactive "fFilename: ")
- (find-file filename 'binary)
+ (if (featurep 'mule)
+ (find-file filename 'binary)
+ (find-file filename))
(if (not (eq major-mode 'hexl-mode))
(hexl-mode)))
--
\/ille Skyttä
scop at xemacs.org
1:37 p.m.
Ville Skyttä wrote:
> In "xemacs-21.4.10 -vanilla", with the sumo package of
2003-02-05
> installed, hexl-find-file produces the following error message:
>
> Symbol's function definition is void: get-coding-system
Eek. get-coding-system is defined only in Mule XEmacsen, and invoking
`find-file' with the optional CODESYS argument uses it, no matter
whether running on Mule or not.
It isn't MULE-specific; it's present if either --with-file-coding or
--with-mule are used (--with-file-coding is enabled by default on
Windows).
+ (if (featurep 'mule)
(if (featurep 'file-coding)
--
Glynn Clements <glynn.clements(a)virgin.net>
1:44 p.m.
On Sun, 2003-02-09 at 15:37, Glynn Clements wrote:
It isn't MULE-specific; it's present if either
--with-file-coding or
--with-mule are used (--with-file-coding is enabled by default on
Windows).
> + (if (featurep 'mule)
(if (featurep 'file-coding)
Oops! Thanks, Glynn.
--
\/ille Skyttä
scop at xemacs.org
3:14 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Sun, 2003-02-09 at 15:37, Glynn Clements wrote:
> It isn't MULE-specific; it's present if either
> --with-file-coding or --with-mule are used (--with-file-coding
> is enabled by default on Windows).
Not only that, I think this problem was fixed about a year ago. Steve
Y, ring any bells?
I smell a possible reversion :-(
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:38 p.m.
Ville Skyttä <scop(a)xemacs.org> writes:
I'm not sure how this should be fixed, but the patch below could
qualify
as a workaround for this particular case (feedback most welcome).
Thanks!
By the way Jouni, do you happen to have any idea why the hut.fi
Linux
boxes have a non-Mule XEmacs? Maybe a note to the ATK-keskus people
would be a good idea :)
No idea; but since I'm responsible for compiling XEmacs on our lab
computers (not operated by the ATK-keskus), perhaps you are interested
in why I didn't enable Mule:
* The XEmacs Installation HOWTO on the web pages describe how to build
a non-Mule XEmacs.
* According to the INSTALL file, "The Mule support is not yet as
stable or efficient as the `Latin1' support."
* My experiences with GNU Emacs 20.* have made me associate Mule
with unpredictable breakage even when only using Latin-1.
Has Mule become stable enough that even we Latin-1-speaking people
should enable it? If so, shouldn't it be recommended in the
documentation? (etc/InstallGuide does mention a goat, but I suppose
that's a different animal.)
--
Jouni K Seppänen
3:30 a.m.
>>>> "Jouni" == Jouni K Seppanen <Jouni>
writes:
Jouni> * According to the INSTALL file, "The Mule support is not
Jouni> yet as stable or efficient as the `Latin1' support."
This is still pedantically true, but should not stop anyone with a
modern machine (Pentium 200MHz or better) from building with Mule,
except in a few special cases. Thanks for reporting, I'll fix that.
Jouni> * My experiences with GNU Emacs 20.* have made me associate
Jouni> Mule with unpredictable breakage even when only using
Jouni> Latin-1. Has Mule become stable enough that even we
Jouni> Latin-1-speaking people should enable it?
Red Hat et al seem to think so; they do not provide non-mule packages
anymore.
We never had the kind of breakage that GNU Emacs had with internal
encodings (the infamous \201 characters) leaking into files. However,
there are two kinds of breakage that you might encounter in XEmacs
with Mule:
1) Mistaken recognition of encodings in binary files, leading to
data lossage. That is, binary files will often randomly
contain sequences that look like ISO 2022 escapes, this will
trigger decoding of the file, which is sometimes irreversible;
if that buffer is saved, you get file corruption.
This can be almost completely avoided by properly use of
`set-coding-priority-list'. However the default assumes that
you are reading text files and relatively aggressive decoding
is enabled.
2) With European integration, the traditional Mule treatment of
the ISO-8859 family as disjoint character sets has become
untenable. Both GNU Emacs and XEmacs provide facilities to
deal with identification of characters that are common to
different Latin sets, but both are as yet pretty raw. I have
personally experienced breakage from this; I _think_ it is
specific to my very unusual set up, but it's possible that
people could induce the same bug by configuring the
`latin-unity' package.
3) People have experienced problems with process buffers that may
be Mule-related.
I think that for sites which use Latin-1, but would like to have
access to the Euro character (Latin-9) and may receive mails written
in other Latin character sets the advantages of Mule now far outweigh
the disadvantages.
Jouni> If so, shouldn't it be recommended in the documentation?
It's really very site-specific, but probably in Europe it should be
recommended. In the U.S. it's not necessary for many, perhaps most
users. In Asia, Emacs is unusable without Mule, of course.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:42 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
[corruption of files that accidentally look like ISO 2022]
This can be almost completely avoided by properly use of
`set-coding-priority-list'. However the default assumes that
you are reading text files and relatively aggressive decoding
is enabled.
Solving this should then be just a matter of site-wide configuration.
2) With European integration, the traditional Mule treatment of
the ISO-8859 family as disjoint character sets has become
untenable.
So *that's* the reason behind the multipart emails that alternate
between Latin-1 and Latin-9 even though all of the text could have
been represented in either character set. It appears that your
latin-unity package is meant to solve this problem; would calling
latin-unity-install in the site-wide configuration file be a
reasonable thing to do? On a quick scan, it doesn't hook into Gnus, so
that would also have to be done in the site configuration.
I think that for sites which use Latin-1, but would like to have
access to the Euro character (Latin-9) and may receive mails written
in other Latin character sets the advantages of Mule now far outweigh
the disadvantages.
In fact, the euro sign is not the only reason that moving to Latin-9
would be desirable for us. The official Finnish orthography requires
the use of s-caron and z-caron in some rare words, so theoretically
you cannot write Finnish correctly in Latin-1. Adoption of Latin-9 has
been slow, however, so we need to maintain backward compatibility by,
e.g., sending Latin-1 whenever the message can be represented in it.
Now latin-unity definitely seems to be worth trying.
--
Jouni K Seppänen
7956
days inactive
7960
days old
7 comments
4 participants
participants (4)
-
Glynn Clements -
Jouni K Seppanen -
Stephen J. Turnbull -
Ville Skyttä