Re: address@hidden: strange Emacs 22.1 failure due to utf-8-compose-scripts when --no-window-system used]

[Joe Wells]

Kenichi Handa <address@hidden> writes:

> In article <address@hidden>, Joe Wells <address@hidden> writes:
>
>> I have reverified the bug.  I tested in a dummy account to make sure
>> none of my account settings affected things.  I have also verified
>> that I get the bug when using the console (no X windows).
>
>> Here are some more details on my configuration.  I am using
>> Ubuntu 6.06 LTS (“Dapper Drake”) with all packages fully updated.
>> Everything I am using is standard Ubuntu except for my kernel and
>> Emacs.  I am using a custom Linux kernel version 2.6.17 (this version
>> was fairly current a year ago) with a few extra patches applied by my
>> hardware middleman.  As I reported in my original report, I built
>> Emacs with these options:
>
>>   export CFLAGS='-O0 -g3 -ggdb'
>>   ./configure --prefix=$HOME/local2 --enable-debug --disable-nls 
>> --with-x-toolkit=gtk
>
>> I suppose that the “--disable-nls” or “--with-x-toolkit=gtk” options
>> might contribute to the bug.
>
> I configured Emacs 21.1 with the same options, but still
> can't reproduce the bug (my distribution is Debian).  After
> starting Emacs, the *Messsage* buffer contains this:
>
> ("/home/handa/local2/bin/emacs" "--quick" "--eval" "(setq 
> utf-8-compose-scripts\ t)" "--load" "lao-util")
> Loading encoded-kb...done
> For information about the GNU Project and its goals, type C-h C-p.
> Loading regexp-opt...done
> Loading thai-util...
> Loading mule-util...done
> Loading thai-util...done
> Loading devan-util...
> Loading ind-util...done
> Loading devan-util...done
> Loading mlm-util...done
> Loading tml-util...done

Here is the *Messages* buffer for me which shows the error:

----------------------------------------------------------------------
("/home/jbw/local2/bin/emacs" "--quick" "--eval" "(setq utf-8-compose-scripts 
t)" "--load" "lao-util")
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
Loading thai-util... [2 times]
Loading mule-util...
Loading lao-util... [2 times]
Loading regexp-opt...
Loading lao-util... [2 times]
Loading regexp-opt...
Loading lao-util... [2 times]
Loading regexp-opt...
Loading lao-util...
utf-8-post-read-conversion: Recursive load: 
"/home/jbw/local2/share/emacs/22.1/lisp/language/lao-util.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/language/lao-util.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/emacs-lisp/regexp-opt.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/language/lao-util.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/language/lao-util.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/emacs-lisp/regexp-opt.elc", 
"/home/jbw/local2/share/emacs/22.1/lisp/language/lao-util.elc"
----------------------------------------------------------------------

There are several differences.  Your *Messages* buffer shows
regexp-opt being loaded just once and before the other files.  Mine
shows regexp-opt not being loaded until after several other files, and
it is loaded repeatedly as part of the recursive load loop.

Mine shows thai-util being loaded _twice_, with the second time
apparently happening during the first time.

Yours _never_ loads lao-util.

> If you don't supply "--load lao-util", does your emacs work
> well?

No, sooner or later something else causes it to be loaded.  It seems
that any time an attempt is made to load “mule-util”, “lao-util”, or
“regexp-opt”, a recursive loading loop results.  A quick check reveals
I get the same error with both of these command lines:

  emacs --no-window-system --quick --eval '(setq utf-8-compose-scripts t)' 
--load "mule-util"

  emacs --no-window-system --quick --eval '(setq utf-8-compose-scripts t)' 
--load "regexp-opt"

> How about "--load lao-util.el" instead?

I get the same problem if I load “lao-util.el” instead of “lao-util”.

-- 
Joe

P.S.  Unfortunately, doing (setq debug-on-error t) before (load
"lao-util") does not trigger the debugger, which makes it harder to
figure out just what is happening.