[Bug: 21.5-b27] font-lock-fontify-* / infinite loop

[Wulf C. Krueger]

Hallo Stephen!

"SJT" == Stephen J Turnbull <stephen at xemacs.org> writes:

 >> font locking runs into an infinite loop while "Fontifying *wide
 >> reply to <recipient>*... (regexps).." is shown in the status bar.
 SJT> Does this happen with all replies, or just for a particular
 SJT> message?

It always happens. I just found out it doesn't even happen with replies
only but even for new messages. The following backtrace is being
generated (this time *without* the inf. loop and without aborting):

(40) (general/warning) Error in unknown: Invalid function: (macro . #<compiled-function (&rest cdr) "...(6)" [cdr function lambda] 3 737017>)

Backtrace follows:

  lambda(284)
  # bind (highlights matcher keyword nkeywords iter old-progress progress bufname keywords case-fold-search loudly loudvar end start)
  font-lock-fontify-keywords-region(1 284 nil)
  # (unwind-protect ...)
  # bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg)
  font-lock-default-fontify-region(1 284 nil)
  # bind (loudly end beg)
  font-lock-fontify-region(1 284)
  # bind (val end beg)
  #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>(1 284 t)
  map-range-table(#<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3> #<range-table [1 284) t 0x59b3b>)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (dummy buffer)
  #<compiled-function (buffer dummy) "...(47)" [font-lock-pending-buffer-table font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function (ex dummy-maparg) "...(32)" [font-lock-range-table ex end beg extent-start-position extent-end-position 0 1 put-range-table t] 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>] 9>(#<buffer "*mail*<2>"> t)
  # (unwind-protect ...)
  maphash(#<compiled-function (buffer dummy) "...(47)" [font-lock-pending-buffer-table font-lock-range-table buffer remhash buffer-live-p clear-range-table map-extents #<compiled-function (ex dummy-maparg) "...(32)" [font-lock-range-table ex end beg extent-start-position extent-end-position 0 1 put-range-table t] 5> nil font-lock-pending t put-text-property map-range-table #<compiled-function (beg end val) "...(5)" [end beg font-lock-fontify-region] 3>] 9> #<hash-table size 0/29 weakness key 0x59b36>)
  # (unwind-protect ...)
  # bind (match-data)
  font-lock-fontify-pending-extents()
  #<compiled-function nil "...(10)" [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2>()
  # (unwind-protect ...)
  call-with-condition-handler(#<compiled-function (__call_trapping_errors_arg__) "...(17)" [__call_trapping_errors_arg__ errstr error-message-string lwarn general warning "Error in %s: %s\n\nBacktrace follows:\n\n%s" "unknown" backtrace-in-condition-handler-eliminating-handler] 8> #<compiled-function nil "...(10)" [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2>)
  # (condition-case ... . ((error)))
  font-lock-pre-idle-hook()
  # (unwind-protect ...)
  # (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0xab0f28> ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (inhibit-quit)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (inhibit-quit)
  # (condition-case ... . error)
  # (catch top-level ...)

 >> Oh, btw, why is my XEmacs standard menu ("File", etc.) suddenly in
 >> German?
 >> LC_CTYPE=de_DE.utf8 LC_MESSAGES=en_US.utf8
 SJT> Probably XEmacs just looks at the LC_CTYPE [...]
 SJT> I would guess this should follow LC_MESSAGES rather than LC_CTYPE,

That would indeed be the correct way to determine the language
environment if LANG is not set or usable, I think.

 SJT> Do you consider this a bug or a feature?  (Well, "feature" is a
 SJT> little strong, maybe "hint at better things are possible". :-)

Usually, I'd call it a "feature" (MS-style feature ;) ) but in this case
it's worse because I now have an English/German mixture (i. e. "Neuer
Schirm" (en: "new frame") but "Close Frame") both inside the menus and
even among the menu titles ("Datei" (en: "File) but "View") which is
fairly disturbing.

And even though German is my native language I would never have guessed
that "Schirm" (colloquial for "monitor" and "umbrella" in German) is
supposed to refer to a frame. :)

Anyway, I'll proceed with removing the package for now but I'd really be
grateful if this could be corrected.

-- 
Grüße, Wulf