9:08 a.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
I've noticed this with the last few builds. It may be older than a
week or so, but that's all the longer I've been aware of the
problem. What happens is, when I open dired I don't see the file name
highlighted under the mouse cursor. When I move point over the file
name and hit enter, I get an error saying "no file on this line"
STH
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux ljosalfr 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
configure '--with-clash-detection' '--with-mule' '--with-xfs'
'--pdump' '--with-pop' '--with-dialogs=athena'
'--with-widgets=athena' '--prefix=/home/hattons/opt'
'--site-libraries=/usr/X11/lib/Xaw3d'
XEmacs 21.5-b9 "brussels sprouts" (+CVS-20021020) configured for
`i686-pc-linux'.
Compilation / Installation:
Source code location: /download/org/xemacs/xemacs-HEAD
Installation prefix: /home/hattons/opt
Additional libraries: /usr/X11/lib/Xaw3d
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -Wshadow
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/X11/include
- X Windows libraries location: /usr/X11/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena 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.
Sound:
Compiling in support for sound (native).
Compiling in support for ESD (Enlightened Sound Daemon).
Databases:
Compiling in support for Berkeley database.
Compiling in support for GNU DBM.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Mail:
Compiling in support for POP mail retrieval.
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.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
Load-Path Lisp Shadows:
----------------------
(/home/hattons/opt/lib/xemacs/xemacs-packages/lisp/ecrypto/md5
/home/hattons/opt/lib/xemacs/xemacs-packages/lisp/gnus/md5
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/ethio-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/ethio-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/china-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/china-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/japan-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/japan-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/korea-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/korea-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/cyril-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/cyril-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-base/viet-util
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/mule/viet-util
/home/hattons/opt/lib/xemacs/mule-packages/lisp/mule-ucs/unicode
/home/hattons/opt/lib/xemacs-21.5-b9/lisp/unicode)
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.1 :type regular)
(xslide :version 1.03 :type regular)
(xemacs-devel :version 1.48 :type single-file)
(xemacs-base :version 1.68 :type regular)
(w3 :version 1.25 :type regular)
(vm :version 7.07 :type regular)
(viper :version 1.34 :type regular)
(view-process :version 1.12 :type regular)
(vhdl :version 1.15 :type regular)
(vc-cc :version 1.21 :type regular)
(vc :version 1.33 :type regular)
(tramp :version 1.08 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.34 :type regular)
(time :version 1.12 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.52 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.24 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(sml-mode :version 0.03 :type regular)
(slider :version 1.13 :type regular)
(sieve :version 1.09 :type regular)
(sh-script :version 1.15 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.14 :type regular)
(scheme :version 1.11 :type regular)
(sasl :version 1.12 :type regular)
(rmail :version 1.13 :type regular)
(reftex :version 1.28 :type regular)
(psgml-dtds :version 1.02 :type regular)
(psgml :version 1.33 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.65
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.64 :type regular)
(pc :version 1.25 :type single-file)
(os-utils :version 1.28 :type single-file)
(ocaml :version 0.03 :type regular)
(net-utils :version 1.28 :type single-file)
(mmm-mode :version 1.0 :type regular)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.15 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.11 :type regular)
(mail-lib :version 1.49 :type regular)
(liece :version 1.07 :type regular)
(jde :version 1.35 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.28 :type regular)
(igrep :version 1.09 :type regular)
(idlwave :version 1.25 :type regular)
(ibuffer :version 1.08 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.03 :type regular)
(gnus :version 1.62 :type regular)
(gnats :version 1.15 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(frame-icon :version 1.09 :type regular)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.36 :type regular)
(eterm :version 1.13 :type regular)
(ess :version 1.02 :type regular)
(eshell :version 1.03 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.03 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.93 :type single-file)
(ediff :version 1.41 :type regular)
(edebug :version 1.14 :type regular)
(ecrypto :version 0.11 :type regular)
(docbookide :version 0.05 :type regular)
(dired :version 1.12 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.15 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.04 :type regular)
(cc-mode :version 1.3 :type regular)
(calendar :version 1.18 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.07 :type regular)
(bbdb :version 1.21 :type regular)
(auctex :version 1.32 :type regular)
(apel :version 1.25 :type regular)
(ada :version 1.1 :type regular)
(skk :version 1.22 :type regular)
(mule-ucs :version 1.04 :type regular)
(mule-base :version 1.42 :type regular)
(lookup :version 1.12 :type regular)
(locale :version 1.18 :type regular)
(leim :version 1.19 :type regular)
(latin-unity :version 1.05 :type regular)
(egg-its :version 1.26 :type regular)
(edict :version 1.13 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow dired-faces dired-xemacs dired sendmail
rfc822 tempo psgml-html efs-cu backup-dir blink-cursor font-lock paren
blink-paren pending-del cus-edit cus-load wid-edit cus-face mwheel mma
func-menu psgml-xemacs sgml-mode psgml session un-define mule-uni
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 rmail-autoloads reftex-autoloads psgml-dtds-autoloads
psgml-autoloads ps-print-autoloads prog-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 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 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 skk-autoloads
mule-ucs-autoloads mule-base-autoloads lookup-autoloads
locale-autoloads leim-autoloads latin-unity-autoloads
egg-its-autoloads edict-autoloads xemacs-HEAD-autoloads src-autoloads
loadhist rsz-minibuf auto-show fontl-hooks x-iso8859-1 tibetan lao
devanagari indian slovenian czech romanian ccl code-cmds gutter-items
menubar-items x-menubar mode-motion mouse behavior itimer auto-save
lisp-mode easymenu iso8859-1 page buff-menu lib-complete cus-file
derived env text-props frame obsolete cus-start custom widget cl-extra
mini-cl cl cl-19 packages backquote very-early-lisp unicode
lucid-scrollbars cut-buffer lucid-menubars athena-dialogs x
c-balloon-help tty-frames tty toolbar esd-sound native-sound scrollbar
unix-processes multicast network-streams subprocesses modules
menu-accelerator-support menubar berkeley-db dbm md5 xemacs xim mule
gutter tiff png gif jpeg xpm xbm lisp-float-type file-coding linux
dialog devices window-system base64)
Recent keystrokes:
-----------------
up up up up RET C-x k RET C-x d BS BS BS BS BS BS BS
BS BS BS BS BS BS BS BS BS RET button1 button1up button2
button2up button1 button1up button1 button1up button1
button1up button2 button2up button1 button1up button1
button1up down down down right right right right right
right right right right right right right right right
right right right RET button1 button1up misc-user C-g
misc-user g l o b a l s y m m e t r y . c o m RET M-x
r e p TAB o TAB r TAB x TAB RET
Recent messages (most recent first):
-----------------------------------
Auto save file for draft message exists; consider M-x mail-recover
Loading xemacsbug...done
Loading xemacsbug...
Making completion list...
Making completion list...
Quit
No file on this line
Buffer is read-only: #<buffer "projects">
Buffer is read-only: #<buffer "projects">
Reading directory /home/hattons/public_html/projects/...done
Reading directory /home/hattons/public_html/projects/...
Reading directory
/home/hattons/public_html/projects/mathbook/mb-001/notebooks/mml-out...done
Reading directory /home/hattons/public_html/projects/mathbook/mb-001/notebooks/mml-out...
Loading dired...done
Loading dired-mule...done
Loading dired-mule...
Loading dired...
Loading sendmail...done
Loading sendmail...
Loading efs-cu...done
10:13 a.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> This bug report will be sent to the XEmacs Development Team,
Steven> not to your local site managers!!
Steven> Please write in English, because the XEmacs maintainers do not have
Steven> translators to read other languages for them.
Steven> Please describe as succinctly as possible:
Steven> - What happened.
Steven> - What you thought should have happened.
Steven> - Precisely what you were doing at the time.
Steven> Please also include any C or lisp back-traces that you may have.
Steven> ================================================================
Steven> Dear Bug Team!
Steven> I've noticed this with the last few builds. It may be older than a
Steven> week or so, but that's all the longer I've been aware of the
Steven> problem. What happens is, when I open dired I don't see the file name
Steven> highlighted under the mouse cursor. When I move point over the file
Steven> name and hit enter, I get an error saying "no file on this line"
This is almost certainly a locale issue. You need to do a M-x
dired-report-bug RET (in the buffer a problem has occurred) to give us
more information (and to direct it to the right place.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:36 a.m.
On Monday 21 October 2002 05:13 am, Michael Sperber [Mr. Preprocessor] wrote:
>>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> This bug report will be sent to the XEmacs Development Team,
Steven> not to your local site managers!!
Steven> Please write in English, because the XEmacs maintainers do not have
Steven> translators to read other languages for them.
Steven> Please describe as succinctly as possible:
Steven> - What happened.
Steven> - What you thought should have happened.
Steven> - Precisely what you were doing at the time.
Steven> Please also include any C or lisp back-traces that you may have.
Steven> ================================================================
Steven> Dear Bug Team!
Steven> I've noticed this with the last few builds. It may be older than a
Steven> week or so, but that's all the longer I've been aware of the
Steven> problem. What happens is, when I open dired I don't see the file
name Steven> highlighted under the mouse cursor. When I move point over the
file Steven> name and hit enter, I get an error saying "no file on this
line"
This is almost certainly a locale issue. You need to do a M-x
dired-report-bug RET (in the buffer a problem has occurred) to give us
more information (and to direct it to the right place.)
As you may already know, I sent a bug report to the dired developers. Just
for the sake of informing other on the list what I've learned, this part of
that report may be of interest:
Dired works for root:
ljosalfr:~ # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
ljosalfr:~ #
But not for me:
hattons＠ljosalfr:/download/org/xemacs/
Mon Oct 21 05:58:11:> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=POSIX
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
hattons＠ljosalfr:/download/org/xemacs/
Mon Oct 21 05:58:17:>
This is a SuSE 8.1 box, and I really don't know what the locale setting does.
I just use it because someone told me it would make all my stuff UTF-8
compliant.... sort of. Linux MUST move to UTF-8, and if this is part of the
pain in doing so, so be it.
--
Hatton's Law: There is only One inviolable Law
1:24 p.m.
"Steven T. Hatton" <hattons(a)speakeasy.net> writes:
On Monday 21 October 2002 05:13 am, Michael Sperber [Mr.
Preprocessor] wrote:
> >>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
>
> Steven> This bug report will be sent to the XEmacs Development Team,
> Steven> not to your local site managers!!
> Steven> Please write in English, because the XEmacs maintainers do not have
> Steven> translators to read other languages for them.
>
>
> Steven> Please describe as succinctly as possible:
> Steven> - What happened.
> Steven> - What you thought should have happened.
> Steven> - Precisely what you were doing at the time.
>
> Steven> Please also include any C or lisp back-traces that you may have.
> Steven> ================================================================
> Steven> Dear Bug Team!
>
> Steven> I've noticed this with the last few builds. It may be older than a
> Steven> week or so, but that's all the longer I've been aware of the
> Steven> problem. What happens is, when I open dired I don't see the file
> name Steven> highlighted under the mouse cursor. When I move point over the
> file Steven> name and hit enter, I get an error saying "no file on this
> line"
>
> This is almost certainly a locale issue. You need to do a M-x
> dired-report-bug RET (in the buffer a problem has occurred) to give us
> more information (and to direct it to the right place.)
As you may already know, I sent a bug report to the dired developers. Just
for the sake of informing other on the list what I've learned, this part of
that report may be of interest:
Dired works for root:
ljosalfr:~ # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
ljosalfr:~ #
But not for me:
hattons＠ljosalfr:/download/org/xemacs/
Mon Oct 21 05:58:11:> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=POSIX
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
hattons＠ljosalfr:/download/org/xemacs/
Mon Oct 21 05:58:17:>
This is a SuSE 8.1 box, and I really don't know what the locale setting does.
I just use it because someone told me it would make all my stuff UTF-8
compliant.... sort of. Linux MUST move to UTF-8, and if this is part of the
pain in doing so, so be it.
--
Hatton's Law: There is only One inviolable Law
I had this same problem after I installed Mandrake 9.0. For me,
unset LANG
unset LC_TIME
before starting XEmacs made dired work again.
HTH,
Vin
2:16 p.m.
On Monday 21 October 2002 08:24 am, Vin Shelton wrote:
"Steven T. Hatton" <hattons(a)speakeasy.net> writes:
>
> Dired works for root:
>
> ljosalfr:~ # locale
> LANG=POSIX
> LC_CTYPE=en_US.UTF-8
> LC_NUMERIC="POSIX"
> LC_TIME="POSIX"
> LC_COLLATE="POSIX"
> LC_MONETARY="POSIX"
>
> But not for me:
> hattons＠ljosalfr:/download/org/xemacs/
> Mon Oct 21 05:58:11:> locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
I had this same problem after I installed Mandrake 9.0. For me,
unset LANG
unset LC_TIME
before starting XEmacs made dired work again.
HTH,
Vin
This seems to work. Thanks!
What's that say about how XEmacs will handle files?
I am all over the place with character encodings and font issues, and that's
just to learn to use the tools I'm using to learn to use the tools I want to
be using. Trust me, this is not the only bug report I've filed in the past
72 hours. This UTF-8 transsition is essential. I've seen the problems
resulting from conflicting character encodings, and they are deadly.
STH
--
Hatton's Law: There is only One inviolable Law
3:17 a.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> What's that say about how
XEmacs will handle files?
Nothing. This is a dired parsing bug.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:55 a.m.
On Monday 21 October 2002 10:17 pm, Stephen J. Turnbull wrote:
>>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> What's that say about how XEmacs will handle files?
Nothing. This is a dired parsing bug.
I meant: what, if any, affect will changing
from UTF-8 to POSIX in the
environment have on XEmacs? IOW, does XEmacs sniff that variable?
It was rather fortunate I ran into this, and posted it. I've been
bad-mouthing Mathematica for having a screwed up display, and discovered that
it too has a problem with the UTF-8 settings.
Do you happen to know what determines how these locale settings affect the
behavior of the OS, and programs? That is, what files and components are
involved in defining the encodings? What actually changes when the values of
the variables are modified? These are the variables in question:
Tue Oct 22 03:42:12:> locale
LANG=POSIX
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
I've learned more about fonts, encodings, font formats, font servers, and
related issues in the past month than I ever wanted to know. The most
disturbing thing I learned is that there's a whole lot more to this than I
ever imagined. Don't get me wrong, I find the characters used to encode
human languages in written form to be truly beautiful. I also find the
technology involved in reproducing on a computer screen, what is done fairly
naturally with pen and ink, quite impressive. It's just that sometimes, I
just want to _use_ my computer, not study it. :-)
I haven't found time to research this, but I find it tantalizing:
http://www.umass.edu/wsp/connections/sources/spp.html
STH
--
Hatton's Law: There is only One inviolable Law
11:45 a.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> On Monday 21 October 2002 10:17 pm, Stephen J. Turnbull
Steven> wrote:
> >>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net>
> writes:
Steven> What's that say about how XEmacs will handle files?
> Nothing. This is a dired parsing bug.
Steven> I meant: what, if any, affect will changing from UTF-8 to
Steven> POSIX in the environment have on XEmacs? IOW, does XEmacs
Steven> sniff that variable?
LANG? Yes, if XEmacs is Mule-enabled. It uses it to determine the
language environment, and the X Input Method. The XIM IM is possibly
a problem, but at least for the IMs I use (kinput2) the native
interface is much better (Canna) for XEmacs because the IM just drops
characters with bucky-bits set on the floor. The XIM setting requires
that XEmacs do a setlocale(), which can affect libraries it calls, but
we actually use it in such a way as to avoid setting some of the
common locale members (LC_TIME and LC_NUMERIC, I think).
However, I've been running in an en_US.utf8 environment for about a
year now with no noticable ill effects. I just don't think there's
much in XEmacs proper affected by locale. The real issue is going to
be the many Lisp libraries that call external programs whose behavior
depends on the locale.
Steven> Do you happen to know what determines how these locale
Steven> settings affect the behavior of the OS, and programs?
The effects are quite pervasive, though sparse. The C library is
affected in many places. Gconv, collation, time, and numbers are the
primary ones. X needs to know about encodings and input methods,
which come from LC_CTYPE. Many programs pay attention to this stuff.
Steven> That is, what files and components are involved in
Steven> defining the encodings?
gconv in glibc, the junk in XFree86 that handles Cmapping, and the
Mule subsystem in XEmacs for starters.
Steven> What actually changes when the values of the variables are
Steven> modified?
Pretty much anything can change.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
12:36 p.m.
Steven T. Hatton wrote:
Do you happen to know what determines how these locale settings
affect the
behavior of the OS, and programs? That is, what files and components are
involved in defining the encodings? What actually changes when the values of
the variables are modified? These are the variables in question:
Tue Oct 22 03:42:12:> locale
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_ALL=
The above are all specified by ANSI C.
LC_MESSAGES="POSIX"
LANG=POSIX
These aren't specified by ANSI C, but are part of POSIX or similar
Unix standards.
Apart from LC_MESSAGES, these variables affect a number of ANSI C
functions. The following is from a draft of the C9X standard (although
it's basically unchanged since C89).
[#2] The setlocale function selects the appropriate portion
of the program's locale as specified by the category and
locale arguments. The setlocale function may be used to
change or query the program's entire current locale or
portions thereof. The value LC_ALL for category names the
program's entire locale; the other values for category name
only a portion of the program's locale. LC_COLLATE affects
the behavior of the strcoll and strxfrm functions. LC_CTYPE
affects the behavior of the character handling functions174)
and the multibyte and wide-character functions. LC_MONETARY
affects the monetary formatting information returned by the
localeconv function. LC_NUMERIC affects the decimal-point
character for the formatted input/output functions and the
string conversion functions, as well as the nonmonetary
formatting information returned by the localeconv function.
LC_TIME affects the behavior of the strftime and strfxtime
functions.
LC_MESSAGES is used by gettext() etc to select a message catalogue.
However, note that libc uses gettext() internally (e.g. for error
messages), so it may affect programs which don't explicitly use
gettext().
However:
1. Most of these variables only have an effect if the program calls
setlocale() with an empty string as the second argument; otherwise,
the program behaves as if the "C" (or "POSIX") locale was selected.
Also, a program may use some variables while ignoring others; E.g.
using LC_NUMERIC complicates matters if the program needs to write
floating-point numbers to network streams or files which will be read
by programs which assume that the decimal separator is a dot (aka
period, full-stop).
2. If LC_ALL is set, it overrides the settings of all of the other
LC_* variables. OTOH, the value of LANG is used as a default for any
categories for which the appropriate LC_* variable is unset.
More details may be available from the manual pages for the relevant
functions, the "libc" Info file, and various standards documents.
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
I have never heard of these.
--
Glynn Clements <glynn.clements(a)virgin.net>
4:02 p.m.
>>>> "Glynn" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
Glynn> Steven T. Hatton wrote:
Do you happen to know what determines how these locale settings
affect the
behavior of the OS, and programs? That is, what files and components are
involved in defining the encodings? What actually changes when the values of
the variables are modified? These are the variables in question:
Tue Oct 22 03:42:12:> locale
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE=POSIX
LC_MONETARY="POSIX"
LC_ALL=
Glynn> The above are all specified by ANSI C.
Strictly speaking, ISTR that only the macros are specified by the C
standard; the environment variables (ie, the behavior in the default
case) are not. Those are part of the environment, and are specified
by POSIX. (IIRC)
LC_MESSAGES="POSIX"
LANG=POSIX
Glynn> These aren't specified by ANSI C, but are part of POSIX or
Glynn> similar Unix standards.
Glynn> Apart from LC_MESSAGES, these variables affect a number of
Glynn> ANSI C functions. The following is from a draft of the C9X
Glynn> standard (although it's basically unchanged since C89).
"info libc locales" will give a bit more information.
Despite my kvetching below, "info libc" is a fount of knowledge.
Almost as good as source, and far more readable. :-)
Glynn> 1. Most of these variables only have an effect if the
Glynn> program calls setlocale() with an empty string as the
Glynn> second argument; otherwise, the program behaves as if the
Glynn> "C" (or "POSIX") locale was selected.
This is false. It depends on the implementation, but I have verified
that with glibc 2.1.something all of the variables above except
LC_COLLATE are affected as a Japanese would expect when the second
argument is "ja_JP". (At that time the Japanese locale was
incomplete, and collation was not implemented -- it's possible that
either localedef or libc6 itself was buggy.)
Glynn> Also, a program may use some variables while ignoring
Glynn> others; E.g. using LC_NUMERIC complicates matters if the
Glynn> program needs to write
src/input-method-xlib.c has an example, along with more kvetching from
Didier.
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
Glynn> I have never heard of these.
These are standard, I bet it's ISO 14652 (cf the Debian manpage for
localedef(1).)
I wish Uli would get around to documenting locale(1) and localedef(1).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:34 p.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
> This is almost certainly a locale issue. You need to do a M-x
> dired-report-bug RET (in the buffer a problem has occurred) to give us
> more information (and to direct it to the right place.)
Steven> As you may already know, I sent a bug report to the dired developers. [...]
Yes, but I asked you to do a M-x dired-report-bug RET which will
provide more information for me to go on.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
3:52 p.m.
On Monday 21 October 2002 10:34 am, Michael Sperber [Mr. Preprocessor] wrote:
>>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
>>
>> This is almost certainly a locale issue. You need to do a M-x
>> dired-report-bug RET (in the buffer a problem has occurred) to give us
>> more information (and to direct it to the right place.)
Steven> As you may already know, I sent a bug report to the dired
developers. [...]
Yes, but I asked you to do a M-x dired-report-bug RET which will
provide more information for me to go on.
OK, I'm confused. I thought I already did that. Twice. What do you mean by
"M-x dired-report-bug RET"? I typed "Alt+x",
"dired-report-bug", filled out
the bug report, and hit "Ctrl+c", Ctrl+c". The message appeared on the
XEmacs Beta list. The first time, my packages were out of date, and I didn't
launche the dired-report-bug while in the dired buffer. The second report
was generated after a package update, and while in the dired buffer.
What have I done wrong?
STH
--
Hatton's Law: There is only One inviolable Law
8:20 a.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> On Monday 21 October 2002 10:34 am, Michael Sperber [Mr. Preprocessor] wrote:
>> >>>> "Steven" ==
Steven T Hatton <hattons(a)speakeasy.net> writes:
>> >>
>> >> This is almost certainly a locale issue. You need to do a M-x
>> >> dired-report-bug RET (in the buffer a problem has occurred) to give us
>> >> more information (and to direct it to the right place.)
Steven> >
Steven> As you may already know, I sent a bug report to the dired
> developers. [...]
Steven> >
> Yes, but I asked you to do a M-x dired-report-bug RET which will
> provide more information for me to go on.
Steven> OK, I'm confused. I thought I already did that. Twice. What do you mean
by
Steven> "M-x dired-report-bug RET"? I typed "Alt+x",
"dired-report-bug", filled out
Steven> the bug report, and hit "Ctrl+c", Ctrl+c". The message appeared
on the
Steven> XEmacs Beta list. The first time, my packages were out of date, and I
didn't
Steven> launche the dired-report-bug while in the dired buffer. The second report
Steven> was generated after a package update, and while in the dired buffer.
Steven> What have I done wrong?
I wish I could tell you. But in a standard installation of XEmacs and
Dired (and every standard installation of XEmacs and Dired in the
past), M-x dired-report-bug RET
a) provides a different kind of report than the one you posted
b) sends that bug report to efs-bugs, not xemacs-beta
What you posted looks like the output of M-x report-xemacs-bug RET.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
10:13 a.m.
>>>> "Steven" == Steven T Hatton
<hattons(a)speakeasy.net> writes:
Steven> I've noticed this with the last few builds. It may be
Steven> older than a week or so, but that's all the longer I've
Steven> been aware of the problem. What happens is, when I open
Steven> dired I don't see the file name highlighted under the
Steven> mouse cursor. When I move point over the file name and hit
Steven> enter, I get an error saying "no file on this line"
There are a bunch of dired bugs that have to do with locale lossage.
This sounds like one of them. Dired can handle non-ASCII filename,
but any change in the output of ls -l drives it nuts.
M-x dired-report-bug is the best way to get the maintainer's
attention.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8067
days inactive
8068
days old
13 comments
5 participants
participants (5)
-
Glynn Clements -
Michael Sperber -
Stephen J. Turnbull -
Steven T. Hatton -
Vin Shelton