Re: enriched-mode and switching major modes.

[Stefan]

> There are several problems.  I could take care of the very bad problem
> of `enriched-change-major-mode-flag' not being reset to nil with no
> code _explicitly_ inside inhibit-quit and even less time consuming
> code in post-command-hook.  But doing this could leave Enriched mode
> disabled in buffers in which it should be enabled and these buffers
> may not even be current when the user returns.  The disabling was done
> behind the user's back, without even notifying the user.  C-x s will
> save the buffer in the wrong format.  My code completely avoids this
> risk.

It seems you don't realize that a lot of elisp code suffers from such
"not 100% correct state if C-g is hit at the wrong moment".  It's not such
a big deal.

And even if you want to solve such problems, inhibit-quit is usually not the
best way to solve them.  Making sure that the state is consistent at all
times is a better one (when available).
E.g. instead of

!     (let ((inhibit-quit t))
!       (enriched-mode 0)
!       (setq enriched-change-major-mode-flag t)
!       (add-to-list 'enriched-marked-buffers (current-buffer)))))

you can do

!       (add-to-list 'enriched-marked-buffers (current-buffer))))
!       (setq enriched-change-major-mode-flag t)
!       (enriched-mode 0)

Oh, and please don't go through details like mentioning with-local-quit
when it's just one of many possible cases (and especially since the cause
of the "problem" is not with-local-quit, but just the `quit' itself).

> Of course, if somebody accidentally introduces an infinite loop in
> `enriched-mode', my inhibit-quit (as well as the use of
> post-command-hook) will make a bad problem even worse.  But the same
> holds for any function run from a timer, pre- or post-command-hook.

Of course, if inhibit-quit poses problem, it's a bug, and bugs are "rare"
(thanks to our debugging efforts), so inhibit-quit rarely poses problems.
But when it does it's a real pain.

BTW, looking at the enriched-mode code, I'm wondering whether all this
fiddling is necessary.  After all the variables it sets are:
- buffer-file-format: already permanent-local.
- use-hard-newlines: we agreed this should also be permanent-local.
- indent-line-function: I'd argue that enriched-mode should *not* change
  this variable.  After all, enriched-mode is supposed to be a minor mode
  that can be used with various major modes and the indentation behavior
  should be determined by the major mode.
- default-text-properties: the changes applied to this var seem to be
  unrelated to enriched-mode and is just always useful/necessary.  They should
  be moved out of enriched-mode.
- buffer-display-table: OK, this one is trickier.  It's used to turn ^L
  (i.e. form feed) chars into a line of dashes.  We could get rid of the
  feature or replace it with a display property, or keep it as is
  (i.e. works only as long as the major mode is not changed).

Alternatively, we can go through the trouble that Luc proposes, but then we
should make it generic, so that enriched-mode can just be added to a list of
"permanent-local minor modes that need to be turned back on after a major
mode change".



        Stefan