From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Sat, 11 Sep 2004 16:51:27 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200409112151.i8BLpRB13427@raven.dms.auburn.edu> References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <200409060059.i860xdo20431@raven.dms.auburn.edu> <200409110214.i8B2EaZ12276@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1094939552 7249 80.91.229.6 (11 Sep 2004 21:52:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 11 Sep 2004 21:52:32 +0000 (UTC) Cc: boris@gnu.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 11 23:52:20 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C6Fn9-0004gZ-00 for ; Sat, 11 Sep 2004 23:52:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C6Fsa-0008Ms-Uj for ged-emacs-devel@m.gmane.org; Sat, 11 Sep 2004 17:57:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C6FsS-0008Mi-3v for emacs-devel@gnu.org; Sat, 11 Sep 2004 17:57:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C6FsR-0008MV-0c for emacs-devel@gnu.org; Sat, 11 Sep 2004 17:57:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C6FsQ-0008MR-Uk for emacs-devel@gnu.org; Sat, 11 Sep 2004 17:57:46 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C6Fmg-0005C3-RS; Sat, 11 Sep 2004 17:51:51 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i8BLpnuE005134; Sat, 11 Sep 2004 16:51:50 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i8BLpRB13427; Sat, 11 Sep 2004 16:51:27 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan on Sat, 11 Sep 2004 12:56:15 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27029 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27029 Stefan Monnier wrote: > ! (let ((inhibit-quit t)) Please don't mess with inhibit-quit unless it's *really* *really* necessary. I'd recommend you just stop worrying about `quit' here or else use `unwind-protect' if there are cleanup operations that need to be done. There is nothing time consuming done inside that `inhibit-quit'. Actually, after this some code in post-command-hook will run (which automatically prevents quitting) but nothing time consuming is done there either. 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. Auto Revert mode runs tons of relatively more time consuming stuff inside an implicit inhibit-quit, and before I started using Tramp, as well as after we disabled auto-reverting for remote files, this has never caused me any problems, nor did I see anybody else complain about such problems. (Again, except for the Tramp stuff.) 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. Sincerely, Luc.