From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Feature request : Tab-completion for 'shell-comand' Date: Sun, 09 Mar 2008 12:39:53 -0400 Message-ID: References: <874pbmjgsy.fsf@gmx.de> <874pbknt3j.fsf@tsuchiya.vaj.namazu.org> <87mypccg6r.fsf@jurta.org> <87abl8svpl.fsf@jurta.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1205080958 26447 80.91.229.12 (9 Mar 2008 16:42:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Mar 2008 16:42:38 +0000 (UTC) Cc: emacs-devel@gnu.org, michael.albinus@gmx.de, monnier@iro.umontreal.ca, tsuchiya@namazu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 09 17:43:04 2008 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 1JYOc2-00027m-Ay for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 17:43:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYObU-0003cY-A8 for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 12:42:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYOZ9-0002Rr-E0 for emacs-devel@gnu.org; Sun, 09 Mar 2008 12:40:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYOZ2-0002Ks-M6 for emacs-devel@gnu.org; Sun, 09 Mar 2008 12:39:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYOZ1-0002JN-MI for emacs-devel@gnu.org; Sun, 09 Mar 2008 12:39:56 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JYOZ1-0003YC-2Q for emacs-devel@gnu.org; Sun, 09 Mar 2008 12:39:55 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1JYOYz-0006oY-Qd; Sun, 09 Mar 2008 12:39:53 -0400 In-reply-to: <87abl8svpl.fsf@jurta.org> (message from Juri Linkov on Sun, 09 Mar 2008 00:21:42 +0200) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:91885 Archived-At: > I have doubts that this is uniformly the best thing to do. > I think that the best thing to do depends on the message: > some messages are good to display at the end of the minibuffer, > as in `minibuffer-message', and some are better just omitted > while in the minibuffer. Currently messages displayed when the minibuffer is active don't get omitted. They just obscure the minibuffer content from the user. The message I replied to showed an example of code that omits the message when the minibuffer is active. With the patch I sent (that changes `message' to call `minibuffer-message' in the active minibuffer), Isearch in the minibuffer works mostly without changes, I am surprised. How does it do that? If `message' calls `minibuffer-message', how come that doesn't cause all the isearch messages to appear after the minibuffer text? but there is a difference on failed Isearch: without this patch the Isearch error message overwrites the minibuffer content, but with this patch it appends the error message to the end of the minibuffer, e.g. I-search backward: foo [Failing I-search backward: bar] I am not sure how to interpret that, because I do not know what foo and bar stand for. But it cannot be right to have two isearch messages at once. Whether the search succeeds or fails, its message should be displayed in the same place, in the same way. Otherwise, we could just fix this particular case not to use `minibuffer-message'. If `message' automatically calls `minibuffer-message' when the minibuffer is active, how is it possible to fix one case not to do that?