From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: buffer-offer-save, gnus and mh-e Date: Sun, 17 Apr 2005 13:47:50 -0500 (CDT) Message-ID: <200504171847.j3HIloe22669@raven.dms.auburn.edu> References: <200504171500.j3HF0Ha22225@raven.dms.auburn.edu> <21194.1113759889@olgas.newt.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1113764346 2269 80.91.229.2 (17 Apr 2005 18:59:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 17 Apr 2005 18:59:06 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 17 20:59:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DNEyk-0000AL-HG for ged-emacs-devel@m.gmane.org; Sun, 17 Apr 2005 20:58:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNF2h-0004KA-Vh for ged-emacs-devel@m.gmane.org; Sun, 17 Apr 2005 15:02:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DNEzm-0003Fv-NA for emacs-devel@gnu.org; Sun, 17 Apr 2005 14:59:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DNEza-00039D-II for emacs-devel@gnu.org; Sun, 17 Apr 2005 14:59:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNEzX-00032g-C2 for emacs-devel@gnu.org; Sun, 17 Apr 2005 14:59:35 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DNErG-0000p7-QM for emacs-devel@gnu.org; Sun, 17 Apr 2005 14:51:02 -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 j3HInd9N007774; Sun, 17 Apr 2005 13:49:39 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j3HIloe22669; Sun, 17 Apr 2005 13:47:50 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: wohler@newt.com In-reply-to: <21194.1113759889@olgas.newt.com> (message from Bill Wohler on Sun, 17 Apr 2005 10:44:49 -0700) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:36057 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36057 Bill Wohler wrote: I'm a little confused by this since mh-folder-mode extends fundamental-mode. I believe that I indeed got confused. I am not very familiar with mh-e. I use mail-mode myself. The normal mode for mail buffers in mh-e appears to be mh-letter-mode. That one does not appear to set buffer-offer-save, unlike mail-mode and message-mode. After my proposed change it would, when invoked via compose-mail. I could avoid that by checking mail-user-agent in compose-mail. But should mail buffers not set buffer-offer-save to t, because otherwise the user might loose work if inadvertently exiting Emacs? `mh-compose-and-send-mail' could do it right after calling mh-letter-mode. (I now saw that mh-e can be invoked in a way that bypasses compose-mail). I now believe that mh-make-folder should set buffer-offer-save to t right after calling mh-folder-mode. Just to be sure I'm understanding correctly, you'd like to see the following code in mh-e.el:(mh-folder-mode), right? (if (or mh-xemacs-flag (< emacs-major-version 22)) (setq buffer-offer-save t)) Unfortunately, to play it completely save, that might still be necessary (even if mh-make-folder already would set buffer-offer-save to t) because if the user switches modes in the buffer, then in prior Emacs versions and XEmacs, the local variable buffer-offer-save will be killed. Also, is the setting of buffer-offer-save to nil in mh-utils.el:(mh-find-path) still appropriate? Yes. mh-find-path is not a major mode (or so I believe). I believe all that one does is avoid asking the user to save a temporary buffer (mh-temp-buffer) created by mh-find-path. Correct? Sincerely, Luc.