bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 21.1 on HP-UX 10.20 behaves oddly


From: Eli Zaretskii
Subject: Re: Emacs 21.1 on HP-UX 10.20 behaves oddly
Date: Wed, 23 Jan 2002 19:03:57 +0200

> Date: Wed, 23 Jan 2002 15:02:19 +0200 (EET)
> From: Esa A E Peuha <esa.peuha@helsinki.fi>
> 
> > If this is indeed so, the next step is to see what kind of object is
> > in idx inside Faref.  (I suspect some snafu with signed/unsigned, so
> > please see whether the result of MAKE_CHAR above gets munged on its
> > way through make_number and into Faref.)
> >
> > Also, I'm not sure that charset being -1 is okay, so please see what
> > does MAKE_CHAR does in that case.
> 
> MAKE_CHAR (-1, 40, 3) evaluates as -14424, which is what Faref gets as
> idx.  It certainly is not okay of charset to be -1; I think it should
> be between 0 and MAX_CHARSET, but MAKE_CHAR doesn't check this.

charset being -1 seems to be the problem, but I wonder how did that
happen.

> > Finally, I wonder where does the string "\e(B2002-01-18", the one
> > Emacs tries to decode, comes from?  It looks like it's 2002-01-18
> > with an ISO-2022 leading escape sequence, but why would Emacs try to
> > do something with that string during startup?  Could you try to find
> > that out?
> 
> The "\e(B" part of the string is inserted by code_convert_string_norecord
> when Fformat_time_string calls it to encode its format string; it then
> formats the string (which doesn't change the escape sequence) and calls
> code_convert_string_norecord again to decode the string, which fails.

Yes, but do you understand why was Fformat_time_string called during
startup?  (I'm trying to figure out what is special about your system
that causes the problem.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]