2006-05-16 shell.el hosed

[Ilya N. Golubev]

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.)