Re: bug in file-name-coding-system detection [was: font-lock-fontify-* ...]
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an deichiú lá de mí Eanair, scríobh Stephen J. Turnbull:
> > > Excuse me? "Sniffing the encoding of a file *name*"? Surely you
> > > mean your patch for "determining the system's
> > > file-name-coding-system"?
> >
> > Tomato, tomato :-) .
>
> Hey, I don't care; if you don't write clearly the first time, I'll
> just turn up the flame until I do understand. ;-)
Carefully using the XEmacs vocabulary and having non-XEmacs developers
understand what I mean can be conflicting goals. You understood what I
meant.
> > > And this is in the *locale* package? Aidan, that's wrong;
>
> Uh, what exactly is in the locale package? If anything that has to do
> with coding detection is in there,
It’s not.
(The reason things changed is that we take our language environment from
LC_CTYPE and interpretation of that variable got better--so
mule-packages/locale used the newly non-English locale. )
> it still needs to get moved out (preferably to the Attic, but I gather
> you're going to resist that :-).
>
> > echo '(define-coding-system-alias 'file-name 'utf-8) ' >> ~/.xemacs/init.el
>
> Excuse me? Then what do I do with my FAT USB key? NFS mounts on
> systems running who knows what?
I don’t know. It’s your system; I’ve no idea if it does the sensible thing
and presents a normalised UTF-8 api for those cases. I can’t implement this
for you and get it right, without lots of information from you, along the
lines of:
1. Is system-type always 'darwin on Mac OS X?
2. What does locale -a give you?
3. Are other file systems’ names re-interpreted as above?
4. For Win32 file systems accessed over Samba, are the file names normalised
or not?
and whatever else comes up. And you’ve sufficient experience with XEmacs
that it would be more efficient of everyone’s time were you to do it
yourself.
> > As I said, I don’t have access to an OS X machine. Having a
> > system-specific hard-coding of the file-name coding-system alias is
> > the right thing to do there, but if I implement it without being able
> > to test it, I’ll get it wrong.
>
> You'll still get it wrong, because not all OS X machines rely
> exclusively on HFS+ file systems.
As I ask above, does the API do the sensible thing and normalise?
> The whole problem with your patch is that you think in terms of *you*
> getting it right, but you can't (except on your own machine).
I can get it right for standard average Unixes, and Win32 at some point in
the future, which are the machines I have access to.
> > > The point is (as I've said before) that the POSIX locale is *not* a
> > > sufficiently reliable way to determine file-name-coding-system.
> >
> > And as I said in lisp/mule-cmds.el and in email,
> >
> > ;; On Unix--with the exception of Mac OS X--there is no way
> > ;; to know for certain what coding system to use for file
> > ;; names, and the environment is the best guess. If a
> > ;; particular user's preferences differ from this, then that
> > ;; particular user needs to edit ~/.xemacs/init.el. Aidan
> > ;; Kehoe, Sun Nov 26 18:11:31 CET 2006. OS X uses an
> > ;; almost-normal-form version of UTF-8.
>
> We now have *three* users on *three* different systems who were hosed
> by this patch.
Who? You, okay. But Volker Zell and Wulf Krüger? How is having a German
menubar in a German locale ‘hosed?’ My preliminary judgement on Mats’ Gnus
issue is that it’s a Gnus issue, but it’s something I need to look into
further.
> Your best guess is probably the best guess---and guess what? *It is not
> sufficiently reliable.* For now, let's not guess; *first* let's give the
> user a convenient intuitive way to do such configuration himself. Once
> we've got a way for the user to get himself out of a hole, *then* it's
> time for you to start digging them.
Bullshit. The intuitive thing is for XEmacs to pay attention to the locale
and use that information. If the user has a particularly riced-out
environment that doesn’t conform to expectations, then that user can modify
the file-name and native coding system aliases by hand. Treating them as
Latin-1 when the environment indicates ‘probably otherwise’ is wrong and
annoying. And you can’t start your XEmacs in "/tmp/за родину!" and open that
directory after startup.
> > Our language environment model is not as fine-grained as that of
> > POSIX. For working out which language to use on Unix, we pay
> > attention to LC_CTYPE and nothing else.
>
> Yet another bug. That may or may not be correct for file systems (it
> would be interesting to know what POSIX says about this, and yes,
> since you're the advocate of using POSIX locales in a multilingual
> application, I think you should investigate it).
POSIX says that’s wrong. Also, I didn’t implement the use-POSIX-locales
code; I’m fixing bugs in it.
> It's *definitely* wrong for UI language stuff (where LC_MESSAGES
> should rule, of course), and it should be considered at most a strong
> hint for coding autodetection.
On Standard Average Unix, it _is_ the file name encoding. I’m mystified as
to why you don’t like this.
> > If you can suggest a better approach to this, that is also
> > compatible with language environment treatment on Windows, where the
> > granularity is different, have at it.
>
> The setup that we had before is a better approach, simply because it's
> the one we had before. It may be stupid and insane, but it's
> backwardly compatible stupid insanity that few non-standards-geeks
> have actually complained about.
It wasn’t cross-platform, and didn’t make sense on native Windows. And note
I didn’t introduce the choice of LC_CTYPE--that was Ben, in 2002.
> Then the next step is to give users a reasonable way to set things up
> for themselves.
Users don’t care that much, in Europe. That we don’t respect the environment
just makes us look bad. People still get work done when they see their name
as Krüger or René, and the investment of time to get it working
right--when getting it working right is often not possible--is not economic.
But all other things being equal, they’ll prefer the app that gets it right.
> After that, autoconfiguration for systems that we know how to guess
> well.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 3 participants
- 3 comments
Re: [Bug: 21.5-b27] font-lock-fontify-* / infinite loop
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an dara lá déag de mí Eanair, scríobh Stephen J. Turnbull:
> > Because then the lambda would never get byte-compiled--the
> > non-byte-compilation of the lambda expression is the problem, not the
> > solution. As I understand it, which I may not.
>
> If that's so, then simply require'ing bytecomp at the top of
> `message-font-lock-make-header-matcher' in message.el should do the
> trick.
Except that the second last entry in message-font-lock-keywords will remain
uncompiled, since the the byte compiler won’t recognise it as a lambda
expression and compile it as such.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: [Bug: 21.5-b27] font-lock-fontify-* / infinite loop
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an dara lá déag de mí Eanair, scríobh Stephen J. Turnbull:
> Why not just change the `(featurep 'bytecomp)' form to
>
> (and (featurep 'bytecomp) gnus-use-byte-compile)
>
> ? Has that variable been deprecated or obsoleted?
Because then the lambda would never get byte-compiled--the
non-byte-compilation of the lambda expression is the problem, not the
solution. As I understand it, which I may not. Cf. Wulf’s second error
message:
(40) (general/warning) Error in unknown: Invalid function: (macro .
#<compiled-function (&rest cdr) “...(6)” [cdr function lambda] 3 737017>)
and the output of
(symbol-function 'lambda)
=> (macro . #<compiled-function (&rest cdr) "...(6)" [cdr function lambda] 3 674424>)
Whether this addresses his first error message is an open question.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
[Bug: 21.5-b27] font-lock-fontify-* / infinite loop
17 years, 11 months
Wulf C. Krueger
Wulf C. Krueger
================================================================
Dear Bug Team!
I've font-lock-mode turned on by default. Using Gnus (from CVS as
well; updated and installed shortly before this bug report) and
answering an email (yank (with Supercite as in the XEmacs repository)
and reply) font locking runs into an infinite loop while "Fontifying
*wide reply to <recipient>*... (regexps).." is shown in the status
bar.
The mouse cursor continuously changes from the busy cursor to the
normal cursor and back.
The backtrace below ("recent messages") is shown when I abort
fontifying (Meta-g; which I usually have to press *twice* before it
really aborts).
Consequently, in the buffer to be fontified usually exactly one line
is correctly fontified while the rest is unmodified.
Interestingly, if I turn *off* font-lock-mode and switch it back on
while inside that buffer, it's being fontified correctly instantly.
I *think* I've seen this problem years ago once already and someone on
this list told me about a switch for font-lock-mode that fixed the
infinite loop but unfortunately I can't find the message in the
archives.
Feel free to request any additional information.
Oh, btw, why is my XEmacs standard menu ("File", etc.) suddenly in
German?
LANG=en_US.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY=de_DE.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux janus 2.6.19-gentoo-r2 #7 SMP PREEMPT Sat Jan 6 19:11:18 CET 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
./configure '--prefix=/usr' '--with-widgets=motif' '--with-dialogs=motif' '--with-scrollbars=motif' '--with-menubars=lucid' '--with-x' '--with-msw=no' '--with-ncurses' '--with-xpm' '--with-athena=3d' '--with-gif' '--with-png' '--with-jpeg' '--with-tiff' '--with-xface' '--with-pop' '--with-sound=native' '--with-mule' '--with-error-checking=none' '--with-debug=no' '--with-gpm' '--with-pdump' '--with-kkcc' '--with-optimization' '--with-cflags=-mtune=athlon64 -march=athlon64 -O2 -pipe' '--with-dynamic' '--with-xft=emacs,tabs,gauges,menubars' '--with-dragndrop' '--with-zlib' '--with-ldap' '--with-modules' '--with-site-lisp=yes' '--with-site-modules=yes' 'CFLAGS=-mtune=athlon64 -march=athlon64 -O2 -pipe'
XEmacs 21.5-b27 "fiddleheads" (+CVS-20070106) configured for `x86_64-unknown-linux'.
Compilation Environment and Installation Defaults:
Source code location: /usr/src/emacsen-cvs/xemacs/xemacs
Installation prefix: /usr
Operating system description file: `s/linux.h'
Not using any machine description file
Compiler version: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)
- GCC specs file: specs.
- Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wunused-parameter -g -O3 -mtune=athlon64 -march=athlon64 -O2 -pipe
libc version: 2.5
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 fontconfig to manage fonts.
- Compiling in support for Xft antialiased fonts (EXPERIMENTAL).
Compiling in support for Motif.
*WARNING* Many versions of Motif are buggy, requiring workarounds.
You are likely to experience slow redisplay.
You may need to install vendor patches to Motif.
See PROBLEMS for more information.
Using Lucid menubars.
- Using Xft to render antialiased fonts in menubars.
WARNING: This feature will be replaced with a face.
Using Motif scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
- Using Xft to render antialiased fonts in tab controls.
WARNING: This feature will be replaced with a face.
- Using Xft to render antialiased fonts in progress bars.
WARNING: This feature will be replaced with a face.
WARNING: This feature not yet implemented; setting ignored.
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).
Compiling in support for ALSA (Advanced Linux Sound Architecture).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using Motif to provide XIM support.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "file" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new GC mark algorithms (KKCC).
WARNING: ---------------------------------------------------------
WARNING: The new algorithms are experimental. They are enabled by
WARNING: default for this release. Use `--disable-kkcc' to
WARNING: turn it off.
WARNING: ---------------------------------------------------------
Using the new portable dumper.
Dumping into executable.
Load-Path Lisp Shadows:
----------------------
(/usr/lib/xemacs/xemacs-packages/lisp/ecrypto/sha1
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sha1
/usr/lib/xemacs/xemacs-packages/lisp/ecrypto/password
/usr/lib/xemacs/xemacs-packages/lisp/gnus/password
/usr/lib/xemacs/xemacs-packages/lisp/ecrypto/md4
/usr/lib/xemacs/xemacs-packages/lisp/gnus/md4
/usr/lib/xemacs/xemacs-packages/lisp/ecrypto/hex-util
/usr/lib/xemacs/xemacs-packages/lisp/gnus/hex-util
/usr/lib/xemacs/xemacs-packages/lisp/ecrypto/encrypt
/usr/lib/xemacs/xemacs-packages/lisp/gnus/encrypt
/usr/lib/xemacs/xemacs-packages/lisp/gnus/tls
/usr/lib/xemacs/xemacs-packages/lisp/mail-lib/tls
/usr/lib/xemacs/xemacs-packages/lisp/gnus/netrc
/usr/lib/xemacs/xemacs-packages/lisp/mail-lib/netrc
/usr/lib/xemacs/xemacs-packages/lisp/gnus/starttls
/usr/lib/xemacs/xemacs-packages/lisp/mail-lib/starttls
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pop3
/usr/lib/xemacs/xemacs-packages/lisp/mail-lib/pop3
/usr/lib/xemacs/xemacs-packages/lisp/gnus/rfc2104
/usr/lib/xemacs/xemacs-packages/lisp/mail-lib/rfc2104
/usr/lib/xemacs/xemacs-packages/lisp/gnus/dns-mode
/usr/lib/xemacs/xemacs-packages/lisp/net-utils/dns-mode
/usr/lib/xemacs/xemacs-packages/lisp/gnus/dns
/usr/lib/xemacs/xemacs-packages/lisp/net-utils/dns
/usr/lib/xemacs/xemacs-packages/lisp/gnus/dig
/usr/lib/xemacs/xemacs-packages/lisp/net-utils/dig
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg-pgp5
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg-pgp5
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg-pgp
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg-pgp
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg-gpg
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg-gpg
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg-parse
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg-parse
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg-def
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg-def
/usr/lib/xemacs/xemacs-packages/lisp/gnus/pgg
/usr/lib/xemacs/xemacs-packages/lisp/pgg/pgg
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sasl-ntlm
/usr/lib/xemacs/xemacs-packages/lisp/sasl/sasl-ntlm
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sasl-digest
/usr/lib/xemacs/xemacs-packages/lisp/sasl/sasl-digest
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sasl-cram
/usr/lib/xemacs/xemacs-packages/lisp/sasl/sasl-cram
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sasl
/usr/lib/xemacs/xemacs-packages/lisp/sasl/sasl
/usr/lib/xemacs/xemacs-packages/lisp/gnus/ntlm
/usr/lib/xemacs/xemacs-packages/lisp/sasl/ntlm
/usr/lib/xemacs/xemacs-packages/lisp/gnus/hmac-md5
/usr/lib/xemacs/xemacs-packages/lisp/sasl/hmac-md5
/usr/lib/xemacs/xemacs-packages/lisp/gnus/hmac-def
/usr/lib/xemacs/xemacs-packages/lisp/sasl/hmac-def
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sieve-manage
/usr/lib/xemacs/xemacs-packages/lisp/sieve/sieve-manage
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sieve-mode
/usr/lib/xemacs/xemacs-packages/lisp/sieve/sieve-mode
/usr/lib/xemacs/xemacs-packages/lisp/gnus/sieve
/usr/lib/xemacs/xemacs-packages/lisp/sieve/sieve
/usr/lib/xemacs/mule-packages/lisp/mule-base/korea-util
/usr/lib/xemacs-21.5-b27/lisp/mule/korea-util
/usr/lib/xemacs/mule-packages/lisp/mule-base/cyril-util
/usr/lib/xemacs-21.5-b27/lisp/mule/cyril-util
/usr/lib/xemacs/mule-packages/lisp/mule-base/ethio-util
/usr/lib/xemacs-21.5-b27/lisp/mule/ethio-util
/usr/lib/xemacs/mule-packages/lisp/mule-base/china-util
/usr/lib/xemacs-21.5-b27/lisp/mule/china-util
/usr/lib/xemacs/mule-packages/lisp/mule-base/japan-util
/usr/lib/xemacs-21.5-b27/lisp/mule/japan-util
/usr/lib/xemacs/mule-packages/lisp/mule-base/viet-util
/usr/lib/xemacs-21.5-b27/lisp/mule/viet-util
/usr/lib/xemacs/xemacs-packages/lisp/xemacs-base/regexp-opt
/usr/lib/xemacs-21.5-b27/lisp/regexp-opt
/usr/lib/xemacs/mule-packages/lisp/mule-ucs/unicode
/usr/lib/xemacs-21.5-b27/lisp/unicode
/usr/lib/xemacs/xemacs-packages/lisp/xemacs-base/easy-mmode
/usr/lib/xemacs-21.5-b27/lisp/easy-mmode
/usr/lib/xemacs/xemacs-packages/lisp/build/build-report
/usr/lib/xemacs-21.5-b27/lisp/build-report)
Installed XEmacs Packages:
-------------------------
(zenirc ver: 1.16 upstream: 2.112)
(xwem ver: 1.22 upstream: lg(a)xwem.org--2005/xwem--main--2.1--versionfix-1)
(xslt-process ver: 1.12 upstream: 1.2.1)
(xslide ver: 1.09 upstream: 0.2.2)
(xlib ver: 1.14 upstream: lg(a)xwem.org--2005/xlib--main--2.1--version-0)
(xetla ver: 1.01 upstream: steve(a)eicq.org--2005/xetla--main--1.1--version-0)
(xemacs-devel ver: 1.75 upstream: No-Upstream-Ver)
(xemacs-base ver: 2.08 upstream: No-Upstream-Ver)
(x-symbol ver: 1.1 upstream: 4.5.1)
(w3 ver: 1.33 upstream: 4.0pre47)
(vm ver: 7.22 upstream: 7.17)
(viper ver: 1.54 upstream: 3.09)
(view-process ver: 1.13 upstream: 2.4)
(vhdl ver: 1.22 upstream: 3.33.12)
(vc ver: 1.41 upstream: No-Upstream-Ver)
(tpu ver: 1.14 upstream: 4.2X)
(tm ver: 1.38 upstream: No-Upstream-Ver)
(time ver: 1.14 upstream: 1.17)
(textools ver: 1.15 upstream: No-Upstream-Ver)
(text-modes ver: 1.92 upstream: No-Upstream-Ver)
(texinfo ver: 1.3 upstream: No-Upstream-Ver)
(supercite ver: 1.21 upstream: 3.55x3)
(strokes ver: 1.1 upstream: No-Upstream-Ver)
(speedbar ver: 1.28 upstream: 0.14beta4)
(slider ver: 1.15 upstream: 0.3x1)
(sieve ver: 1.18 upstream: No-Upstream-Ver)
(sh-script ver: 1.21 upstream: 2.0f)
(sgml ver: 1.11 upstream: No-Upstream-Ver)
(semantic ver: 1.2 upstream: 1.4.4)
(scheme ver: 1.14 upstream: No-Upstream-Ver)
(ruby-modes ver: 1.02 upstream: 1.6.8)
(rmail ver: 1.14 upstream: No-Upstream-Ver)
(riece ver: 1.22 upstream: 2.0.2)
(reftex ver: 1.34 upstream: 4.21)
(re-builder ver: 1.05 upstream: 1.20)
(python-modes ver: 1.08 upstream: No-Upstream-Ver)
(psgml ver: 1.44 upstream: 1.3.1)
(ps-print ver: 1.11 upstream: 6.5.6)
(prog-modes ver: 2.09 upstream: No-Upstream-Ver)
(pgg ver: 1.06 upstream: 0.1)
(perl-modes ver: 1.09 upstream: No-Upstream-Ver)
(pcomplete ver: 1.04 upstream: 1.1.6)
(pcl-cvs ver: 1.67 upstream: R-2_9_9)
(pc ver: 1.28 upstream: No-Upstream-Ver)
(os-utils ver: 1.39 upstream: No-Upstream-Ver)
(oo-browser ver: 1.04 upstream: 4.08)
(ocaml ver: 0.06 upstream: 3.06)
(net-utils ver: 1.5 upstream: N/A)
(misc-games ver: 1.19 upstream: No-Upstream-Ver)
(mine ver: 1.16 upstream: 1.9)
(mh-e ver: 1.29 upstream: 7.4.2)
(mew ver: 1.19 upstream: 1.94.2)
(mailcrypt ver: 2.14 upstream: 3.5.8)
(mail-lib ver: 1.78 upstream: No-Upstream-Ver)
(jde ver: 1.51 upstream: 2.3.3)
(ispell ver: 1.32 upstream: 3.6)
(ilisp ver: 1.34 upstream: 5.12.0)
(igrep ver: 1.14 upstream: 2.111)
(idlwave ver: 1.32 upstream: 5.1)
(ibuffer ver: 1.09 upstream: No-Upstream-Ver)
(hyperbole ver: 1.16 upstream: 4.18)
(hm--html-menus ver: 1.23 upstream: 5.9)
(haskell-mode ver: 1.1 upstream: 2.1)
(gnats ver: 1.17 upstream: 3.101)
(games ver: 1.17 upstream: 1.04)
(fsf-compat ver: 1.15 upstream: No-Upstream-Ver)
(fortran-modes ver: 1.05 upstream: No-Upstream-Ver)
(forms ver: 1.15 upstream: 2.37)
(footnote ver: 1.16 upstream: 0.18x)
(eudc ver: 1.39 upstream: 1.32)
(eterm ver: 1.17 upstream: No-Upstream-Ver)
(eshell ver: 1.1 upstream: 2.4.1)
(escreen ver: 1.01 upstream: 1.16)
(emerge ver: 1.11 upstream: No-Upstream-Ver)
(eieio ver: 1.05 upstream: 0.17)
(efs ver: 1.33 upstream: 1.23)
(edt ver: 1.13 upstream: No-Upstream-Ver)
(edit-utils ver: 2.37 upstream: No-Upstream-Ver)
(ediff ver: 1.67 upstream: 2.75)
(edebug ver: 1.22 upstream: No-Upstream-Ver)
(ecrypto ver: 0.2 upstream: 2.0)
(ecb ver: 1.22 upstream: 2.31)
(docbookide ver: 0.07000000000000001 upstream: 0.1)
(dired ver: 1.17 upstream: 7.13)
(dictionary ver: 1.16 upstream: 1.8)
(debug ver: 1.18 upstream: No-Upstream-Ver)
(cookie ver: 1.15 upstream: No-Upstream-Ver)
(clearcase ver: 1.1 upstream: /main/laptop/165)
(cc-mode ver: 1.45 upstream: 5.30.10)
(calendar ver: 1.3 upstream: No-Upstream-Ver)
(calc ver: 1.26 upstream: 2.02fX3)
(c-support ver: 1.22 upstream: No-Upstream-Ver)
(build ver: 1.14 upstream: 2.02)
(bbdb ver: 1.29 upstream: 2.34)
(auctex ver: 1.46 upstream: 11.55)
(apel ver: 1.32 upstream: 10.6)
(ada ver: 1.14 upstream: 2.27)
(skk ver: 1.23 upstream: 10.62a)
(mule-ucs ver: 1.14 upstream: 0.84)
(mule-base ver: 1.49 upstream: No-Upstream-Ver)
(lookup ver: 1.15 upstream: 1.0)
(leim ver: 1.24 upstream: No-Upstream-Ver)
(latin-unity ver: 1.19 upstream: 1.19)
(egg-its ver: 1.27 upstream: No-Upstream-Ver)
(edict ver: 1.16 upstream: 0.9.9)
Installed Modules:
-----------------
Features:
--------
(xemacsbug shadow bbdb-sc bbdb supercite regi annotations browse-url
w3m-hist w3m-xmas path-util w3m-ccl pccl pccl-20 w3m-favicon w3m-image
w3m-proc w3m-util poem poem-xm pces pces-xfc pces-20 broken pces-xm
poe-xemacs overlay poe pym static apel-ver product smtpmail
latin-unity-tables latin-euro-standards latin-euro-latin10
latin-euro-latin9 latin-euro-latin8 latin-euro-latin7 latin-unity-vars
latin-unity message-utils pp gnus-cite ansi-color gnus-bcklg
gnus-async sort gnus-ml gnus-topic parse-time timezone nnfolder
byte-optimize bytecomp byte-compile nnml utf7 nnimap imap efs-cu
encrypt edmacro mail-extr gnus-junk boxquote rect ispell uudecode
deuglify smiley gnus-delay gnus-draft gnus-agent gnus-srvr nnvirtual
nntp gnus-cache gnus-msg gnus-art regexp-opt mm-uu mml2015 pgg
pgg-parse pgg-def mm-view nndraft nnmh gnus-score score-mode gnus-sum
nnoo gnus-group gnus-undo nnmail mail-source format-spec mailcrypt
comint gnus-start gnus-spec gnus-int gnus-range message ecomplete mml
mml-sec mml-smime smime password smime-ldap ldap dig mm-decode
mm-bodies mm-encode mailcap lpr mail-parse rfc2045 rfc2231 rfc2047 qp
ietf-drums mail-abbrevs sendmail rfc822 gmm-utils mailheader canlock
sha1 hex-util hashcash executable gnus-win gnus gnus-ems gnus-xmas
messagexmas nnheader nnheaderxm gnus-util netrc time-date mail-utils
mm-util timer-funcs mail-prsvr wid-edit gnuserv semantic-ia
semantic-analyze semantic-load semanticdb eieio-base eieio senator
ring semantic-imenu advice advice-preload imenu semantic-ctxt
semantic-util-modes timer semantic-util semantic assoc working mwheel
font-lock recent-files x-font-menu font-menu font disp-table cus-face
zenirc-autoloads xwem-autoloads xslt-process-autoloads
xslide-autoloads xlib-autoloads xetla-autoloads xemacs-devel-autoloads
xemacs-base-autoloads x-symbol-autoloads w3-autoloads vm-autoloads
viper-autoloads view-process-autoloads vhdl-autoloads vc-autoloads
tpu-autoloads tm-autoloads time-autoloads textools-autoloads
text-modes-autoloads texinfo-autoloads supercite-autoloads
strokes-autoloads speedbar-autoloads slider-autoloads sieve-autoloads
sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads
ruby-modes-autoloads rmail-autoloads riece-autoloads reftex-autoloads
re-builder-autoloads python-modes-autoloads psgml-autoloads
ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads oo-browser-autoloads ocaml-autoloads
net-utils-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads
mew-autoloads mailcrypt-autoloads mail-lib-autoloads jde-autoloads
ispell-autoloads ilisp-autoloads igrep-autoloads idlwave-autoloads
ibuffer-autoloads hyperbole-autoloads hm--html-menus-autoloads
haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads
fsf-compat-autoloads fortran-modes-autoloads forms-autoloads
footnote-autoloads eudc-autoloads eterm-autoloads eshell-autoloads
escreen-autoloads erc-autoloads emerge-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 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 leim-autoloads
latin-unity-autoloads egg-its-autoloads edict-autoloads
modules-autoloads mule-autoloads auto-autoloads rsz-minibuf auto-show
fontl-hooks canna-leim tibetan slovenian czech romanian lao devanagari
indian ccl code-cmds gutter-items menubar-items x-menubar mode-motion
mouse behavior itimer auto-save lisp-mode easymenu easy-mmode
iso8859-1 page buff-menu lib-complete loadhist cus-file derived
newcomment env text-props fontconfig frame obsolete cus-start custom
widget cl-extra cl cl-19 packages backquote unicode font-mgr
motif-scrollbars cut-buffer xft-fonts lucid-menubars motif-dialogs x
c-balloon-help tty-frames tty toolbar native-sound alsa-sound
scrollbar unix-processes multicast network-streams subprocesses
modules menu-accelerator-support menubar berkeley-db md5 xemacs xim
mule gutter tiff png gif jpeg xface xpm xbm lisp-float-type
file-coding linux dialog devices window-system base64)
Recent keystrokes:
-----------------
down down down down down down up down down down up
up up up RET down down RET RET C-end up RET up up up
RET W v W v F RET button1 button1up down down down
down down down down down down down down down down down
down down down down down down down down down down down
down down down down down down down down down down down
down down down down down down down down down down down
C-home M-x r p e BS BS e o BS p o TAB r TAB x e TAB
RET
Recent messages (most recent first):
-----------------------------------
Warning:
Defaulting to the GNU Emacs-derived `sendmail.el' mail client. This facility,
while part of base XEmacs, is heinously underfeatured, and not going to get
better in the medium term. We include it so that bug reports work without
packages; we suggest that you choose and/or install one of the other mail
clients from packages if you're doing something other than M-x
report-xemacs-bug , or even if you are reporting bugs regularly.
To choose a package from those installed, click on "Options" ->
"Internet" -> "Compose Mail With ..." and decide on one from the
list. Gnus and VM are full-featured and have active user communities.
To disable this warning and stick with the old behavior, you can explicitly
initialize `mail-user-agent' to 'sendmail-user-agent .
Loading xemacsbug...done
Loading xemacsbug...
Making completion list...
Warning: Error in unknown: Quit
Backtrace follows:
# (unwind-protect ...)
# bind (val next prev start end prop value object newface override end start match highlight end highlights matcher keyword nkeywords iter old-progress progress bufname keywords case-fold-search loudly loudvar end start)
font-lock-fontify-keywords-region(754 1400 nil)
# (unwind-protect ...)
# bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg)
font-lock-default-fontify-region(754 1400 nil)
# bind (loudly end beg)
font-lock-fontify-region(754 1400)
# bind (val end beg)
#<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>(754 1400 t)
map-range-table(#<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3> #<range-table [754 1400) t [1401 1483) t [1484 1629) t [1630 2314) t [2315 2596) t [2597 3083) t [3084 3544) t [3545 3750) t [3752 3926) t 0x59b3b>)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# bind (dummy buffer)
#<compiled-function (buffer dummy) "...(47)" [font-lock-pending-buffer-table font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function (ex dummy-maparg) "...(32)" [font-lock-range-table ex end beg extent-start-position extent-end-position 0 1 put-range-table t] 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>] 9>(#<buffer "*wide reply to Stephen J. Turnbull*"> t)
# (unwind-protect ...)
maphash(#<compiled-function (buffer dummy) "...(47)" [font-lock-pending-buffer-table font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function (ex dummy-maparg) "...(32)" [font-lock-range-table ex end beg extent-start-position extent-end-position 0 1 put-range-table t] 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>] 9> #<hash-table size 0/29 weakness key 0x59b36>)
# (unwind-protect ...)
# bind (match-data)
font-lock-fontify-pending-extents()
#<compiled-function nil "...(10)" [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2>()
# (unwind-protect ...)
call-with-condition-handler(#<compiled-function (__call_trapping_errors_arg__) "...(17)" [__call_trapping_errors_arg__ errstr error-message-string lwarn general warning "Error in %s: %s\n\nBacktrace follows:\n\n%s" "unknown" backtrace-in-condition-handler-eliminating-handler] 8> #<compiled-function nil "...(10)" [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2>)
# (condition-case ... . ((error)))
font-lock-pre-idle-hook()
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0xab0f28> ...)
# (unwind-protect ...)
# (unwind-protect ...)
# bind (inhibit-quit)
# (unwind-protect ...)
# (unwind-protect ...)
# bind (inhibit-quit)
# (condition-case ... . error)
# (catch top-level ...)
Fontifying *wide reply to Stephen J. Turnbull*... aborted.aborted.
("" . ">"), ">>", " >> "
Fontifying *wide reply to Stephen J. Turnbull*... (regexps)..
Fontifying *wide reply to Stephen J. Turnbull*...
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
("" . ">"), ">>", " >> "
Loading bbdb-sc...done
Fontifying *wide reply to Stephen J. Turnbull*... done.
--
Grüße, Wulf
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 3 participants
- 5 comments
[Bug: 21.4.20] directory completion in shell not working
17 years, 11 months
Stephen J. Turnbull
Stephen J. Turnbull
Aaron Stambler writes:
> Directory completion in a shell is not working correctly. This
> problem is new with my installation of 21.4.20. This problem did not
> exist in 21.4.19.
Sorry for the long delay. Have you gotten any response on this? Do
you have any further information?
I do have one question: what shell are you using?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
cperl xemacs bug
17 years, 11 months
Peter Gordon
Peter Gordon
Hi.
I have found a bug in cperl mode.
If I write code
s/\s+//g ;
it confuses cperl no end and tit hinks that a lot of code after this
statement is now comment.
If I change it to
s!\s+!!g
it works.
Regards,
Peter
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: bug in file-name-coding-system detection
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an t-aonú lá déag de mí Eanair, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > Carefully using the XEmacs vocabulary and having non-XEmacs developers
> > understand what I mean can be conflicting goals. You understood what I
> > meant.
>
> Yes ... after about 15 minutes, having read your whole post and
> getting halfway through drafting a reply. Wasting my time is not a
> good thing.
>
> In this case it was completely pointless. I can imagine situations
> where precision and layman understanding would be conflicting goals,
> but not here. `file-name-coding-system' is rather clearly named, and
> a useful gloss is available via C-h v.
‘Coding system’ is not a clear term to those unfamiliar with ISO 2022.
> > I don’t know. It’s your system; I’ve no idea if it does the
> > sensible thing and presents a normalised UTF-8 api for those cases.
>
> *sigh* It doesn't matter. When you have access to about 1% of the
> variant systems that run your code,
Like everyone. Do you remember how many systems XEmacs runs on? Are you
suggesting we abandon any development, since we can’t test our changes on
platforms we don’t have access to? Wasn’t a distributed form of such testing
part of the point of a beta status?
> the file name coding system should be a *variable* that can be easily
> bound or buffer-local for quick fixes and special uses, not an alias for
> a constant coding system.
You’re arguing with me about a design decision I didn’t make. If there’s a
design decision in XEmacs that you don’t like and you have a better approach
that solves the same problems, implement it. Don’t give other people hassle
for acknowledging that those decisions were made.
> There is such a variable, but at the very least the existence of an
> aliasable coding system confuses things, and maybe reduces
> reliability. Please fix that, and give us a UI, before you go
> hardwiring things.
>
> > > We now have *three* users on *three* different systems who were hosed
> > > by this patch.
> >
> > Who? You, okay. But Volker Zell and Wulf Krüger? How is having a German
> > menubar in a German locale ‘hosed?’ M
>
> Both were surprised, and insisted on learning how to get rid of it.
> "Hosed" is an exaggeration, but the direction is right.
>
> Furthermore, Wulf's menubar is *not* in a German locale;
> LC_MESSAGES=en. "Forgetting" that fact is exactly the kind of
> carelessness that causes me to oppose your patches.
You’re arguing with me about a design decision I didn’t make.
> > Bullshit. The intuitive thing is for XEmacs to pay attention to the
> > locale
>
> First get XEmacs to pay *proper* attention to the locale. It
> currently does so in a very buggy way, as you point out yourself.
I don’t have strong feelings about it either way; I can see the logic behind
it, and it is clear that it contradicts POSIX. Either way, it’s a design
decision I didn’t make.
> > and use that information. If the user has a particularly riced-out
> > environment that doesn’t conform to expectations, then that user
> > can modify the file-name and native coding system aliases by hand.
>
> Sure, they can. But the problem is not that the environments are
> riced-out; it's that you limit your expectations to what you deal
> with. You put a different spin on it, but that's the excuse you use
> regularly for committing buggy patches. "I don't have that system, so
> I couldn't test it."
Are you suggesting we abandon any development, since we can’t test our
changes on platforms we don’t have access to? Wasn’t a distributed form of
such testing part of the point of a beta status?
> > On Standard Average Unix, it _is_ the file name encoding. I’m
> > mystified as to why you don’t like this.
>
> Because your obeisance to this fictitious Standard Average Unix cost
> me hours. I'm mystified as to why you think I should like that.
I’ve had epic flame wars with Peter T. Daniels in sci.lang for using UTF-8
in my posts. In sci.lang. Where the necessity of using the IPA and non-Roman
scripts is daily. Now, there are workarounds to the absence of phonetic
symbols in ASCII, but by far the best solution is to use UTF-8 there. He’s
shut up about it since he abandoned Netscape 3 for Google Groups and no
longer sees the problem.
Peter’s an expert on writing systems and a Semiticist, and wilfully
non-technical. You’re not wilfully non-technical, I didn’t anticipate that
the idea that the better way to do things in general may cause you in
particular some pain, would be new to you.
> > Users don’t care that much, in Europe. That we don’t respect the
> > environment just makes us look bad. People still get work done when
> > they see their name as Krüger or René, and the investment of time
> > to get it working right--when getting it working right is often not
> > possible--is not economic.
>
> In other words, providing them a simple flexible way to customize it
> would give them 90% of what they want, at no risk to existing
> satisfied customers.
No. The problem is not simple enough that we can provide people with an
interface much simpler than what we already have and have it solve most
people’s problems.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Attachments getting wrong encoding when saved to disk
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an deichiú lá de mí Eanair, scríobh Mats Lidell:
> Aidan> Could you try it again with the checked-out isearch-mode.el,
> Aidan> and give me details of where you get fuzz? No need to re-dump,
> Aidan> a byte-compile and load before the first call to
> Aidan> isearch-forward should do.
>
> It simply doesn't work for me and, worse!?, I get different behavior
> depending on whether it is dumped or not. In both variants searches in
> gnus still complain about "aring not defined." When it is dumped dired
> also gets weired and does not accept any searches.
Mysterious.
What does
(values
(hash-table-key-list isearch-known-printable)
(let (res)
(map-keymap (lambda (key binding) (when (eq 'isearch-printing-char
binding)
(push key res)))
isearch-mode-map)
res))
give you? I’m interested in its return value both before and after you first
call isearch.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Attachments getting wrong encoding when saved to disk
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an deichiú lá de mí Eanair, scríobh Mats Lidell:
> I don't know why patch says it is fuzzy. Comparing the output from
> "cvs diff" with your patch seems almost identical. But the almost
> might be the fuzz ;-)
Right:-) . I’ve put the whole file as I have it up at
http://www.parhasard.net/xemacs/isearch-mode.el.bz2 , in case the fuzz is
the problem.
> I'll try the pathed version again later.
Thanks!
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Attachments getting wrong encoding when saved to disk
17 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an deichiú lá de mí Eanair, scríobh Mats Lidell:
> Aidan> It’s just for 21.5, and shouldn’t have needed any fuzz. Also,
> Aidan> note that isearch is dumped, so you’ll need to byte compile and
> Aidan> load the whole file on startup.
>
> I know so I rebuilt from scratch. "make distclean" etc in order to get
> it into the dump.
>
> Aidan> I prefer to think that ‘better’ since it means the same problem
> Aidan> should get fixed faster :-) .
>
> Well I'm afraid I must confess I reverted back to the old behavior ;-)
Bugger. Could you try it again with the checked-out isearch-mode.el, and
give me details of where you get fuzz? No need to re-dump, a byte-compile
and load before the first call to isearch-forward should do.
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments