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: Sun, 09 Mar 2008 19:48:46 +0200 Organization: JURTA Message-ID: <87ejajajbt.fsf@jurta.org> References: <874pbmjgsy.fsf@gmx.de> <874pbknt3j.fsf@tsuchiya.vaj.namazu.org> <87mypccg6r.fsf@jurta.org> <87r6ekm1wr.fsf@tsuchiya.vaj.namazu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205086213 28969 80.91.229.12 (9 Mar 2008 18:10:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Mar 2008 18:10:13 +0000 (UTC) Cc: Michael Albinus , Stefan Monnier , emacs-devel@gnu.org To: TSUCHIYA Masatoshi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 09 19:10:39 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 1JYPyn-0006bn-PI for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 19:10:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYPyF-00064p-LJ for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 14:10:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYPxS-0005jg-W4 for emacs-devel@gnu.org; Sun, 09 Mar 2008 14:09:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYPxS-0005jQ-Ej for emacs-devel@gnu.org; Sun, 09 Mar 2008 14:09:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYPxS-0005jK-7M for emacs-devel@gnu.org; Sun, 09 Mar 2008 14:09:14 -0400 Original-Received: from relay02.kiev.sovam.com ([62.64.120.197]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JYPxR-00021U-O8 for emacs-devel@gnu.org; Sun, 09 Mar 2008 14:09:13 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JYPxH-000Lf0-Fp; Sun, 09 Mar 2008 20:09:11 +0200 In-Reply-To: <87r6ekm1wr.fsf@tsuchiya.vaj.namazu.org> (TSUCHIYA Masatoshi's message of "Sun, 09 Mar 2008 23:01:56 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: 021e97fb5facab6d3ae496d7b6c27559 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 2374 [Mar 9 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Info: {TO: local part of email appears in body} X-SpamTest-Method: none X-SpamTest-Rate: 20 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) 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:91902 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 such change will not work well based on two reasons. > The first reason is that we will have to install the above change into > all completion functions including functions added by users if you hope > that this change works consistently. Such great change must be very > very difficult. The second reason is that several completion functions > will require a minibuffer to display their completing status. That is why we should try to find a general solution. > My solution employed in shell-command.el resolves these two problems. > The first problem is resolved by re-defining `message' function. > Re-definition of `message' function enables all tab-completion functions > to call `message' function without ill effects. As I see, your solution is just using a shorter delay for displaying the message: 0.3 sec instead of 2 sec. I think 0.3 sec is too short delay to be able to read the displayed message. > And more, the second problem is also resolved by this re-defined > `message' function which uses a single minibuffer as two separated > areas. The re-defined `message' function uses the left half of > minibuffer to display a regular prompt and uses the right half to > display a completing status. Displaying the message aligned to the right has the problem that it is hard to notice when you look at the default left part of the minibuffer. I use a wide frame and tried your command several times before I noticed that something blinks for the short period (0.3 sec) on its right part. > This trick is realized by the following code. You can see that the > re-defined `message' function concatenates a regular prompt and a > completing status, and displays both of them. Such workarounds like redefining the `message' function are not necessary when installing code to the Emacs core, because we can change Emacs internals in a general way to avoid similar problems in other places. > I hope that you will try http://namazu.org/~tsuchiya/elisp/shell-command.el > before further discussion. Yes, I already tried it, thanks. >>Also I see that shell-command.el changes the shell-command prompt. >>I think this is a separate feature that is better to implement as >>a minor mode that uses `minibuffer-setup-hook' to add shell-command >>specific information to the created prompt. Please see a mode like >>minibuffer-electric-default-mode or file-name-shadow-mode for the ideas >>how this could be implemented. > > I think that it is not a good idea to separate the tab-completion > feature and the feature to display a current directory in a prompt. > Users must know where they call commands with tab-completion, because > almost all actions of tab-completion functions depend on the current > directory. Under a separate feature I meant that it should possible to turn it on/off, and an ability to easily enable it also in other functions that use the minibuffer to read commands. I also appreciate that you implemented the same prompt format specifiers as are used for shell prompts. > I already signed a disclaimer for Gnus. I hope our maintainers will answer your questions about papers. > So, the simplest way is to merge necessary code of shell-command.el > into simple.el and grep.el after I will sign a disclaimer for Emacs > itself, isn't it? I think merging necessary code into simple.el and grep.el would be the best thing to do. -- Juri Linkov http://www.jurta.org/emacs/