2006-05-16 shell.el hosed

Combination of `shell' and `comint' after your commit of 2006/05/25 02:49:48 +0 (marked 2006-05-16 in `ChangeLog') is hosed both in 21.4 and 21.5. In 21.4 after executing `shell' command can not run any command using minibuffer, including `M-x', `C-x b', `C-x C-f', `f1 k', `f1 l'. Message is output in echo area: Symbol's function definition is void: font-lock-unfontify-buffer (File name) completion in shell buffer also does not work as it previously would. Observed that on 21.4 In 21.5 it is broken in another way. Otherwise xemacs works normally, including minibuffer input. The message Symbol's function definition is void: font-lock-unfontify-buffer is output only once after `shell' command is executed. In shell mode buffer shell prompt never appears, if input command that must output something, like `echo', no output is seen. Please fix. About adding (add-hook 'change-major-mode-hook 'font-lock-unfontify-buffer nil t) without (make-local-hook 'change-major-mode-hook) in `comint-mode'. The function is intended to change settings in current buffer, and thus it changes global ones, which itself is improper, unless there are some special reasons. Adding `font-lock-unfontify-buffer' is particularly harmful because it *may* be defined by `font-lock', but not autoloaded in its package; autoloading the function or loading the file before `comint' may be done in settings of particular user, but not in every `comint' installation. In some build configurations it even may be highly undesirable, because they would dump `comint', but not `font-lock'. It may be undesirable to even load `font-lock', since it (unconditionally) enables itself on load (by changing `find-file-hooks'). (It is generally <against XEmacs policy>, but has remained so for years.)