* Recursive load of mule-util.elc
@ 2002-11-04 7:26 Juanma Barranquero
2002-11-05 10:47 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2002-11-04 7:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recursive load of mule-util.elc 2002-11-04 7:26 Recursive load of mule-util.elc Juanma Barranquero @ 2002-11-05 10:47 ` Juanma Barranquero 2002-11-06 1:07 ` Kenichi Handa 0 siblings, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2002-11-05 10:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recursive load of mule-util.elc 2002-11-05 10:47 ` Juanma Barranquero @ 2002-11-06 1:07 ` Kenichi Handa 2002-11-06 7:44 ` Juanma Barranquero 2002-11-06 12:20 ` Juanma Barranquero 0 siblings, 2 replies; 13+ messages in thread From: Kenichi Handa @ 2002-11-06 1:07 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recursive load of mule-util.elc 2002-11-06 1:07 ` Kenichi Handa @ 2002-11-06 7:44 ` Juanma Barranquero 2002-11-06 12:20 ` Juanma Barranquero 1 sibling, 0 replies; 13+ messages in thread From: Juanma Barranquero @ 2002-11-06 7:44 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recursive load of mule-util.elc 2002-11-06 1:07 ` Kenichi Handa 2002-11-06 7:44 ` Juanma Barranquero @ 2002-11-06 12:20 ` Juanma Barranquero 2002-11-06 13:02 ` Kenichi Handa 1 sibling, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2002-11-06 12:20 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recursive load of mule-util.elc 2002-11-06 12:20 ` Juanma Barranquero @ 2002-11-06 13:02 ` Kenichi Handa 2002-11-07 1:46 ` Potential redisplay problem [Re: Recursive load of mule-util.elc] Kenichi Handa 0 siblings, 1 reply; 13+ messages in thread From: Kenichi Handa @ 2002-11-06 13:02 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-06 13:02 ` Kenichi Handa @ 2002-11-07 1:46 ` Kenichi Handa 2002-11-08 12:07 ` Richard Stallman 0 siblings, 1 reply; 13+ messages in thread From: Kenichi Handa @ 2002-11-07 1:46 UTC (permalink / raw) Cc: lektu 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-07 1:46 ` Potential redisplay problem [Re: Recursive load of mule-util.elc] Kenichi Handa @ 2002-11-08 12:07 ` Richard Stallman 2002-11-13 7:36 ` Kenichi Handa 0 siblings, 1 reply; 13+ messages in thread From: Richard Stallman @ 2002-11-08 12:07 UTC (permalink / raw) Cc: emacs-devel, lektu 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-08 12:07 ` Richard Stallman @ 2002-11-13 7:36 ` Kenichi Handa 2002-11-14 12:16 ` Richard Stallman 2002-11-14 12:16 ` Richard Stallman 0 siblings, 2 replies; 13+ messages in thread From: Kenichi Handa @ 2002-11-13 7:36 UTC (permalink / raw) Cc: emacs-devel, lektu 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-13 7:36 ` Kenichi Handa @ 2002-11-14 12:16 ` Richard Stallman 2002-11-14 12:16 ` Richard Stallman 1 sibling, 0 replies; 13+ messages in thread From: Richard Stallman @ 2002-11-14 12:16 UTC (permalink / raw) Cc: emacs-devel, lektu 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-13 7:36 ` Kenichi Handa 2002-11-14 12:16 ` Richard Stallman @ 2002-11-14 12:16 ` Richard Stallman 2002-11-14 12:59 ` Kenichi Handa 1 sibling, 1 reply; 13+ messages in thread From: Richard Stallman @ 2002-11-14 12:16 UTC (permalink / raw) Cc: emacs-devel, lektu 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-14 12:16 ` Richard Stallman @ 2002-11-14 12:59 ` Kenichi Handa 2002-11-16 1:34 ` Richard Stallman 0 siblings, 1 reply; 13+ messages in thread From: Kenichi Handa @ 2002-11-14 12:59 UTC (permalink / raw) Cc: emacs-devel, lektu 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Potential redisplay problem [Re: Recursive load of mule-util.elc] 2002-11-14 12:59 ` Kenichi Handa @ 2002-11-16 1:34 ` Richard Stallman 0 siblings, 0 replies; 13+ messages in thread From: Richard Stallman @ 2002-11-16 1:34 UTC (permalink / raw) Cc: emacs-devel, lektu 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-11-16 1:34 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-04 7:26 Recursive load of mule-util.elc Juanma Barranquero 2002-11-05 10:47 ` Juanma Barranquero 2002-11-06 1:07 ` Kenichi Handa 2002-11-06 7:44 ` Juanma Barranquero 2002-11-06 12:20 ` Juanma Barranquero 2002-11-06 13:02 ` Kenichi Handa 2002-11-07 1:46 ` Potential redisplay problem [Re: Recursive load of mule-util.elc] Kenichi Handa 2002-11-08 12:07 ` Richard Stallman 2002-11-13 7:36 ` Kenichi Handa 2002-11-14 12:16 ` Richard Stallman 2002-11-14 12:16 ` Richard Stallman 2002-11-14 12:59 ` Kenichi Handa 2002-11-16 1:34 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).