From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: wrapper fn for message and minibuffer-message? Date: Fri, 7 Oct 2005 15:29:54 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1128724290 22136 80.91.229.2 (7 Oct 2005 22:31:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Oct 2005 22:31:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 08 00:31:29 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EO0jl-0002iR-PP for ged-emacs-devel@m.gmane.org; Sat, 08 Oct 2005 00:30:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EO0jl-0002hG-3O for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2005 18:30:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EO0jN-0002gH-1d for emacs-devel@gnu.org; Fri, 07 Oct 2005 18:30:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EO0jK-0002fg-Sg for emacs-devel@gnu.org; Fri, 07 Oct 2005 18:30:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EO0jK-0002fd-O6 for emacs-devel@gnu.org; Fri, 07 Oct 2005 18:30:18 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EO0jK-0006ku-On for emacs-devel@gnu.org; Fri, 07 Oct 2005 18:30:18 -0400 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j97MYOmn015696 for ; Fri, 7 Oct 2005 17:34:39 -0500 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j97MU0OB011836 for ; Fri, 7 Oct 2005 16:30:01 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j97MU0is011829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Oct 2005 16:30:00 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:43663 Archived-At: differences between `message' and `minibuffer-message': - `message' exits the minibuffer (and recursive edit); No it doesn't. My bad. - `minibuffer-message' wraps the message in " [...]"; `message' does not That's just a matter of how to make it stand out at the end of the minibuffer. Yes, of course. I should also have mentioned this difference: - `message' temporarily erases the minibuffer before displaying the message; `minibuffer-message appends the message to the minibuffer contents, so both are visible together I guess that's part of what you're referring to with your variable `minibuffer-message-at-end': if non-nil, the message would be appended, without first erasing the minibuffer. I still have the same question: Would the variable also be set to non-nil implicitly, whenever `minibufferp'? (That was the behavior I originally suggested: use `minibuffer-message' when the minibuffer is active.) If no, then what is now a simple call to `minibuffer-message' would require something like (let ((minibuffer-message-at-end t)) (message ...)). If yes, then a simple call to `message' could require (let ((minibuffer-message-at-end nil)) (message ...)). IIUC, I don't see the advantage of the variable. But I'm probably missing something. It could use the same mechanism as now; or, maybe it would be cleaner to change the lower levels of redisplay to display the message at the end of the minibuffer when it is selected. Sorry, I don't understand you, here. Could you elaborate a bit? {}? Do you mean that low-level redisplay would, in effect, use `minibuffer-message' when the minibuffer is active and `message' otherwise? If so, that's the behavior of the function I suggested. However, if that is the behavior for `message', then my comment above applies: you would need to do (let ((minibuffer-message-at-end nil)) (message ...)) to get the current effect of `message' (erase content first) when the minibuffer is active. Sometimes you want to erase the minibuffer first, even if the minibuffer is active. Most of the time you don't. Why is your solution "cleaner" than just having `message' (erase first), `minibuffer-message' (append without erasing), and a wrapper function that DTRT most of the time (based on `minibufferp')?