Marko Koci=C4=87 writes:
>> Not necessarily; if the lisp file is accessed through a logical
>> pathname, for instance, the compiled file name will use the
>> platform-preferred case, which has arbitrarily been defined as upper
>> case for Windows. Does the change in case actually cause a problem
>> for you?
> I'm not sure "platform preferred case" for Windows should be all
> uppercase. It might be true back in the old DOS days, but windows
> supports mixed case for at least 10 years. Is it "platform prefered
> case" defined somewhere? It should be "keep existing case" as default.
The host structures in, among other places, src/code/target-pathname.lisp=
have a "customary-case" field. The actual default values are specified in=
src/code/target-pathname.lisp, and apparently are either :upper or :lower=
This field is SETFable, so (setf (sb-impl::host-customary-case
sb-impl::*win32-host*) :lower) works at runtime, and is as close to "fixi=
this problem as you're likely to see just yet.
> I can't se why it would be a problem right now, but it's just plain ugl=
It's just plain ugly, yes, but your failure mode is when using (at least
cygwin) emacs. If you find a file with C-x C-f, you'll find it with a
lower-case buffer name. If you then use slime's M-. to find something in
that file, it will occasionally (particularly with system sources) use an=
upper-case filename... And emacs uses case-sensetive filename matching. T=
results in somewhat counterintuitive behavior. At least there's a