From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.devel Subject: Re: messages override minibuffer input Date: Mon, 24 Sep 2007 01:33:02 +0200 Message-ID: <18166.63406.655047.618376@tfkp07.physik.uni-erlangen.de> References: <18146.9183.561171.347511@tfkp07.physik.uni-erlangen.de> <18156.41397.801020.981025@tfkp07.physik.uni-erlangen.de> <18158.37860.82364.792281@tfkp07.physik.uni-erlangen.de> <18165.12883.174199.925266@tfkp07.physik.uni-erlangen.de> <18166.33116.790735.879497@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 1190590404 8737 80.91.229.12 (23 Sep 2007 23:33:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 Sep 2007 23:33:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 24 01:33:18 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 1IZawv-0002OS-E7 for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 01:33:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZaws-0000kw-Oh for ged-emacs-devel@m.gmane.org; Sun, 23 Sep 2007 19:33:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZawp-0000je-UH for emacs-devel@gnu.org; Sun, 23 Sep 2007 19:33:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZawn-0000hF-34 for emacs-devel@gnu.org; Sun, 23 Sep 2007 19:33:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZawn-0000h6-0V for emacs-devel@gnu.org; Sun, 23 Sep 2007 19:33:09 -0400 Original-Received: from tfkpsv.physik.uni-erlangen.de ([131.188.164.197]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IZawl-0001iu-31; Sun, 23 Sep 2007 19:33:07 -0400 Original-Received: from tfkp07.physik.uni-erlangen.de (tfkp07.physik.uni-erlangen.de [131.188.164.207]) by tfkpsv.physik.uni-erlangen.de (Postfix) with ESMTP id C7EC22124C; Mon, 24 Sep 2007 01:33:04 +0200 (CEST) In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.1.1 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:79629 Archived-At: On Sun Sep 23 2007 Richard Stallman wrote: > Yet quite generally, it confuses me when I type something and > suddenly the text I have typed disappears. Even when the message > disappears again when I continue typing, a smooth work flow requires > that I know the last character I typed before the message appeared > so that I know where to continue typing while something else is > displayed. > > 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? It appears more natural to me to put the message at the end than above the minibuffer contents. In a case like the message "Mismatched parentheses" point will usually be at the end of the minibuffer so that the relation between minibuffer input and the issued message is most obvious. (Conversely, one might argue that a message issued by a timer function is not related to the current minibuffer input. So if such a message was put above the minibuffer contents, that would make it more clear to the user that the message is asynchronous, not related to current minibuffer input. But such a "deluxe" solution might be difficult to implement. Also, it is in a way more confusing because a temporary message will make minibuffer input move by a line when the message disappears again.) Whether the message should go at the end of the current line or in a new line might depend on the window width. Generally, readability is best if there are no linebreaks within a message. For a narrow window it appears thus better to me if the message is displayed in a new line. If the window width is large it might be more convenient to append the message at the end of the current line. Even if the minibuffer grows by a line (thus shifting point upwards by one line), in my opinion this is by far less a nuisance because I know immediately what I typed last before the message popped up and where / how I want to continue typing. Currently, if (due to whatever reason) the minibuffer grows by a line while it is active, it will keep this maximum size till minibuffer input has been completed. I believe it would make sense to implement a similar policy for "minibuffer + (temporary) messages". Roland