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: messages override minibuffer input Date: Sun, 23 Sep 2007 19:02:45 -0700 Message-ID: References: <18167.4792.543242.737218@tfkp07.physik.uni-erlangen.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190599397 28183 80.91.229.12 (24 Sep 2007 02:03:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2007 02:03:17 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Roland Winkler" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 24 04:03:13 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IZdHu-0003XR-Mj for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 04:03:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZdHs-0007DZ-93 for ged-emacs-devel@m.gmane.org; Sun, 23 Sep 2007 22:03:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZdHM-0006zQ-KY for emacs-devel@gnu.org; Sun, 23 Sep 2007 22:02:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZdHL-0006z2-44 for emacs-devel@gnu.org; Sun, 23 Sep 2007 22:02:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZdHL-0006yz-13 for emacs-devel@gnu.org; Sun, 23 Sep 2007 22:02:31 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IZdHJ-0000sX-So; Sun, 23 Sep 2007 22:02:30 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8O22R95029399; Sun, 23 Sep 2007 21:02:27 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l8O20OIF016795; Sun, 23 Sep 2007 20:02:26 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-220.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3238462091190599340; Sun, 23 Sep 2007 19:02:20 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <18167.4792.543242.737218@tfkp07.physik.uni-erlangen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 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:79658 Archived-At: > > > If we put such messages at the end, that may cause the minibuffer > > > to grow by a line. Would you find that disturbing? > > > > > > If not, perhaps the thing to do is to put the message below the > > > current input, always growing the minibuffer. Or put the message > > > above the minibuffer contents. What would you think of that? > > > > Please don't do that. In general, let's try to keep echo-area > > messages to one line. If they happen to be so long that they > > wrap, so be it. So I'd request that we append without a newline. > > Maybe I misunderstand something here. I thought that the question > was about messages placed at the end of a minibuffer line. So if the > minibuffer takes already 70 display columns and the message requires > another 70 columns I don't know how the message could fit into a > standard window with 80 display columns unless the message is > wrapped. In such a (standard?) case it would seem more natural to me > to put the message completely into a new line. It will wrap anyway if it is too long for the window size. That is, the window width will automatically determine whether and where to visually add a new line. Different users have different width minibuffer windows. I, for instance, use a standalone minibuffer frame that stretches all the way across my display. On the display I'm using right now, it has room for 160 characters. When I'm use other displays, it is narrower or wider; it always fills the display width. It is not a good idea to start inserting newlines in message text based on assumptions of a standard (or any other) minibuffer width or height. Just treat the echo area as a single long line, and let it wrap as needed. That doesn't mean there could never be newlines in the echo area under any circumstances. I'm just saying that there is no good reason to add them for no good reason, and based on a window-size assumption.