From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Feature request : Tab-completion for 'shell-comand' Date: Fri, 07 Mar 2008 01:47:00 +0200 Organization: JURTA Message-ID: <8763vz2z2r.fsf@jurta.org> References: <874pbmjgsy.fsf@gmx.de> <874pbknt3j.fsf@tsuchiya.vaj.namazu.org> <87mypccg6r.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204848231 26096 80.91.229.12 (7 Mar 2008 00:03:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2008 00:03:51 +0000 (UTC) Cc: Michael Albinus , TSUCHIYA Masatoshi , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 07 01:04:17 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 1JXQ4P-0004Bq-13 for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 01:04:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXQ3r-0003CG-I6 for ged-emacs-devel@m.gmane.org; Thu, 06 Mar 2008 19:03:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXQ2H-0002Oo-UM for emacs-devel@gnu.org; Thu, 06 Mar 2008 19:02:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXQ2G-0002OK-L7 for emacs-devel@gnu.org; Thu, 06 Mar 2008 19:02:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXQ2G-0002O1-Ai for emacs-devel@gnu.org; Thu, 06 Mar 2008 19:02:04 -0500 Original-Received: from relay01.kiev.sovam.com ([62.64.120.200]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JXQ2F-0004Zd-Nc for emacs-devel@gnu.org; Thu, 06 Mar 2008 19:02:04 -0500 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JXQ25-000CIt-Ru; Fri, 07 Mar 2008 02:02:02 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 06 Mar 2008 11:04:07 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: b3971b7ac160fe45482707327a257f38 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2366 [Mar 6 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 11 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) 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:91568 Archived-At: >> Yes, these messages overwrite the minibuffer, but instead of temporarily >> redefining the function `message' as in shell-command.el, it would be >> better to fix comint.el and shell.el to not display completion messages >> when the minibuffer is active. These files already contain places where >> this check is done this way: > >> (unless (window-minibuffer-p (selected-window)) >> (message "Completing file name...")) > > I think that when the minibuffer is active, we should still output > a message, only differently (as does minibuffer-message). Maybe just > using minibuffer-message (and changing it so it uses plain "message" > when the minibuffer is not active) would do the trick. It turns out that `minibuffer-message' doesn't help in this particular case: after typing TAB on the command name in the minibuffer it displays Shell command: ema [Completing command name...] then waits 2 sec and displays another message Shell command: emacs [Type space to flush; repeat completion command to scroll] then again waits 2 sec and displays Shell command: emacs [Partially completed] After typing more and typing TAB Shell command: emacs22 [Completing command name...] waits 2 sec and displays Shell command: emacs22 [Type space to flush; repeat completion command to scroll] again waits 2 sec and displays Shell command: emacs22 [Completed] This delay for 2 sec is unbearable. I think comint.el messages were not designed to be helpful in the minibuffer. So we should decide which comint.el messages are necessary in the minibuffer and which are not, and change unnecessary ones to display conditionally depending on whether the minibuffer is active or not. -- Juri Linkov http://www.jurta.org/emacs/