Recursive load of mule-util.elc

Recursive load of mule-util.elc

[Juanma Barranquero]

Uh, what could be causing this error I get now when starting Emacs?

> Loading mule-util... [4 times]
> Error during redisplay: (error Recursive load c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/tooltip.elc)
> Loading mule-util...done [4 times]


                                                           /L/e/k/t/u

Re: Recursive load of mule-util.elc

[Juanma Barranquero]

On Mon, 04 Nov 2002 08:26:47 +0100, Juanma Barranquero <lektu@terra.es> wrote:

> Uh, what could be causing this error I get now when starting Emacs?
> 
> > Loading mule-util... [4 times]
> > Error during redisplay: (error Recursive load c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/tooltip.elc)
> > Loading mule-util...done [4 times]

I've fixed it by moving `coding-system-eol-type-mnemonic' from
mule-util.el to mule.el, which seems like the simplest and more logical
way, as `coding-system-eol-type' is already there. Still, touching mule
stuff always makes me uneasy...


                                                           /L/e/k/t/u

Re: Recursive load of mule-util.elc

[Kenichi Handa]

In article <20021105114339.0CED.LEKTU@terra.es>, Juanma Barranquero <lektu@terra.es> writes:
> On Mon, 04 Nov 2002 08:26:47 +0100, Juanma Barranquero <lektu@terra.es> wrote:
>>  Uh, what could be causing this error I get now when starting Emacs?
>>  
>>  > Loading mule-util... [4 times]
>>  > Error during redisplay: (error Recursive load c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/international/mule-util.elc c:/bin/emacs/HEAD/lisp/tooltip.elc)
>>  > Loading mule-util...done [4 times]

> I've fixed it by moving `coding-system-eol-type-mnemonic' from
> mule-util.el to mule.el, which seems like the simplest and more logical
> way, as `coding-system-eol-type' is already there. Still, touching mule
> stuff always makes me uneasy...

Thank you for the fix.  I agree that having
coding-system-eol-type-mnemonic in mule.el is better because
the following change calls that function always.

2002-11-02  Stefan Monnier  <monnier@cs.yale.edu>

	* bindings.el (mode-line-change-eol)
	(mode-line-eol-desc-cache, mode-line-eol-desc): New.
	(mode-line-mule-info): Use them for the EOL part of the modeline.

But, I still don't know why the previous code signals
recursive loading error.  I can't reproduce the bug even if
I revert your change.  Is the bug specific to Windows?

---
Ken'ichi HANDA
handa@m17n.org

Re: Recursive load of mule-util.elc

[Juanma Barranquero]

On Wed, 6 Nov 2002 10:07:59 +0900 (JST), Kenichi Handa <handa@m17n.org> wrote:

> I can't reproduce the bug even if
> I revert your change.  Is the bug specific to Windows?

Perhaps. I'll try to test it on a RedHat.


                                                           /L/e/k/t/u

Re: Recursive load of mule-util.elc

[Juanma Barranquero]

On Wed, 6 Nov 2002 10:07:59 +0900 (JST), Kenichi Handa <handa@m17n.org> wrote:

> Is the bug specific to Windows?

Not.

Reverting my patch to mule.el/mule-util.el I've been able to reproduce
it on a RedHat 7.2.


                                                           /L/e/k/t/u

Re: Recursive load of mule-util.elc

[Kenichi Handa]

In article <20021106131931.66A2.LEKTU@terra.es>, Juanma Barranquero <lektu@terra.es> writes:
> On Wed, 6 Nov 2002 10:07:59 +0900 (JST), Kenichi Handa <handa@m17n.org> wrote:
>>  Is the bug specific to Windows?

> Not.

> Reverting my patch to mule.el/mule-util.el I've been able to reproduce
> it on a RedHat 7.2.

Hmmm, strange.  Then, perhaps, I did that reverting wrongly.
Can you find out why that recursive loading happens?

---
Ken'ichi HANDA
handa@m17n.org

Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Kenichi Handa]

In article <200211061302.WAA07800@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>>  Reverting my patch to mule.el/mule-util.el I've been able to reproduce
>>  it on a RedHat 7.2.

> Hmmm, strange.  Then, perhaps, I did that reverting wrongly.
> Can you find out why that recursive loading happens?

I tried the reverting again, and this time, I could
reproduce this recursive loading.  The reason is as below:

At first, tool-bar is being autoloaded.  Then, Fload is
called, and it calls message_with_string () to show "Loading
XXX.." before starting to load a file.  This leads to
calling display_mode_element in this sequence.

message_with_string -> message3 -> message3_nolog
  -> echo_area_display -> redisplay_mode_lines ->
  -> display_mode_lines -> display_mode_element

In display_mode_element, `(mode-line-eol-desc)' is evaled,
and mule-util is being autoloaded.  This triggers the same
calling sequence above recursively and infinitely.

When you moved coding-system-eol-type-mnemonic to mule.el,
autoloading of mule-util in display_mode_element is avoided,
thus the problem is fixed.

However, this means that the current Emacs has a potential
problem.  Anything being autoloaded in display_mode_element
cause the same error.  And currently, one can attach any
code that will lead to autoloading to mode-line-format.

But, I don't know how to suppress calling
redisplay_mode_lines in this special case.

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Richard Stallman]

    At first, tool-bar is being autoloaded.  Then, Fload is
    called, and it calls message_with_string () to show "Loading
    XXX.." before starting to load a file.  This leads to
    calling display_mode_element in this sequence.

    message_with_string -> message3 -> message3_nolog
      -> echo_area_display -> redisplay_mode_lines ->
      -> display_mode_lines -> display_mode_element

    In display_mode_element, `(mode-line-eol-desc)' is evaled,

You need to make it safe to call mode-line-eol-desc.  It
should never try to autoload anything.

    When you moved coding-system-eol-type-mnemonic to mule.el,
    autoloading of mule-util in display_mode_element is avoided,
    thus the problem is fixed.

Yes, exactly.

    However, this means that the current Emacs has a potential
    problem.  Anything being autoloaded in display_mode_element
    cause the same error.

We could put in code that gets an error if anything autoloaded
is called from within display_mode_element.

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Kenichi Handa]

In article <E18A7vG-0007ov-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>     At first, tool-bar is being autoloaded.  Then, Fload is
>     called, and it calls message_with_string () to show "Loading
>     XXX.." before starting to load a file.  This leads to
>     calling display_mode_element in this sequence.

>     message_with_string -> message3 -> message3_nolog
>	->  echo_area_display -> redisplay_mode_lines ->
>	->  display_mode_lines -> display_mode_element
>     In display_mode_element, `(mode-line-eol-desc)' is evaled,

> You need to make it safe to call mode-line-eol-desc.  It
> should never try to autoload anything.

Then, how about this kind of change in the docstring of
mode-line-format?

*** buffer.c.~1.403.~	Fri Nov  8 08:42:22 2002
--- buffer.c	Wed Nov 13 16:26:46 2002
***************
*** 5260,5266 ****
   A string appearing directly as the value of a symbol is processed verbatim
   in that the %-constructs below are not recognized.
  For a list of the form `(:eval FORM)', FORM is evaluated and the result
!  is used as a mode line element.
  For a list whose car is a symbol, the symbol's value is taken,
   and if that is non-nil, the cadr of the list is processed recursively.
   Otherwise, the caddr of the list (if there is one) is processed.
--- 5260,5267 ----
   A string appearing directly as the value of a symbol is processed verbatim
   in that the %-constructs below are not recognized.
  For a list of the form `(:eval FORM)', FORM is evaluated and the result
!  is used as a mode line element.  FORM should not leads to loading of
!  Emacs Lisp file even if it is by autoloading.
  For a list whose car is a symbol, the symbol's value is taken,
   and if that is non-nil, the cadr of the list is processed recursively.
   Otherwise, the caddr of the list (if there is one) is processed.


By the way, is autloading the only way to cause of the above
recursive call?

>     When you moved coding-system-eol-type-mnemonic to mule.el,
>     autoloading of mule-util in display_mode_element is avoided,
>     thus the problem is fixed.

> Yes, exactly.

>     However, this means that the current Emacs has a potential
>     problem.  Anything being autoloaded in display_mode_element
>     cause the same error.

> We could put in code that gets an error if anything autoloaded
> is called from within display_mode_element.

If that is possible, why don't just add a code to suppress
the call of message_with_string when something is being
autoloaded?

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Richard Stallman]

    Then, how about this kind of change in the docstring of
    mode-line-format?

That is a good idea.  I willimprove the wording a little.

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Richard Stallman]

    By the way, is autloading the only way to cause of the above
    recursive call?

I am not certain.  I haven't studied the code.

    If that is possible, why don't just add a code to suppress
    the call of message_with_string when something is being
    autoloaded?

We don't want to do this in general.  The user should be informed
about loading due to autoloads.

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Kenichi Handa]

In article <E18CIvK-0004Yf-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     By the way, is autloading the only way to cause of the above
>     recursive call?

> I am not certain.  I haven't studied the code.

>     If that is possible, why don't just add a code to suppress
>     the call of message_with_string when something is being
>     autoloaded?

> We don't want to do this in general.  The user should be informed
> about loading due to autoloads.

I don't mean to do that in general, but to add such a
suppressing code somewhere in this calling sequence:
>     message_with_string -> message3 -> message3_nolog
>	->  echo_area_display -> redisplay_mode_lines ->
>	->  display_mode_lines -> display_mode_element

For instance, introducing a global variable
`inhibit_loading_message', toggle it on and off around the
code of evaluating a form in display_mode_element, and
modify Fload to pay attention to it.

This is just a quick thought.  For the correct fix, we have
to study the code more.   For instance, I don't know why
echo_area_display must lead to redisplay_mode_lines.

But, for the moment, I don't have a time to study this issue
in detail and write an actual code.

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential redisplay problem [Re: Recursive load of mule-util.elc]

[Richard Stallman]

    I don't mean to do that in general, but to add such a
    suppressing code somewhere in this calling sequence:
    >     message_with_string -> message3 -> message3_nolog
    >	->  echo_area_display -> redisplay_mode_lines ->
    >	->  display_mode_lines -> display_mode_element

I think it would work to make this code

	  /* If the display update has been interrupted by pending
	     input, update mode lines in the frame.  Due to the
	     pending input, it might have been that redisplay hasn't
	     been called, so that mode lines above the echo area are
	     garbaged.  This looks odd, so we prevent it here.  */
	  if (!display_completed)
	    n = redisplay_mode_lines (FRAME_ROOT_WINDOW (f), 0);

bind redisplaying_p in the same way redisplay_internal does.