From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Sat, 11 Sep 2004 18:55:49 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <200409060059.i860xdo20431@raven.dms.auburn.edu> <200409110214.i8B2EaZ12276@raven.dms.auburn.edu> <200409112151.i8BLpRB13427@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1094943410 915 80.91.229.6 (11 Sep 2004 22:56:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 11 Sep 2004 22:56:50 +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 Sun Sep 12 00:56:37 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 1C6GnM-0006ux-00 for ; Sun, 12 Sep 2004 00:56:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C6Gsn-0005ui-R8 for ged-emacs-devel@m.gmane.org; Sat, 11 Sep 2004 19:02:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C6GsZ-0005tr-9w for emacs-devel@gnu.org; Sat, 11 Sep 2004 19:01:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C6GsW-0005sb-G7 for emacs-devel@gnu.org; Sat, 11 Sep 2004 19:01:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C6GsW-0005s2-6a for emacs-devel@gnu.org; Sat, 11 Sep 2004 19:01:56 -0400 Original-Received: from [206.47.199.141] (helo=simmts12-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C6Gmd-0006rY-Ft; Sat, 11 Sep 2004 18:55:51 -0400 Original-Received: from empanada.home ([67.71.119.105]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040911225447.YYVG1580.simmts12-srv.bellnexxia.net@empanada.home>; Sat, 11 Sep 2004 18:54:47 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id 18A582E38D1; Sat, 11 Sep 2004 18:55:50 -0400 (EDT) Original-To: Luc Teirlinck In-Reply-To: <200409112151.i8BLpRB13427@raven.dms.auburn.edu> (Luc Teirlinck's message of "Sat, 11 Sep 2004 16:51:27 -0500 (CDT)") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (darwin) 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:27030 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27030 > 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