From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Feature request : Tab-completion for 'shell-comand' Date: Tue, 11 Mar 2008 22:12:01 -0400 Message-ID: References: <874pbmjgsy.fsf@gmx.de> <874pbknt3j.fsf@tsuchiya.vaj.namazu.org> <87mypccg6r.fsf@jurta.org> <87r6ekm1wr.fsf@tsuchiya.vaj.namazu.org> <87ejajajbt.fsf@jurta.org> <87lk4rmodu.fsf@tsuchiya.vaj.namazu.org> <87lk4r74gt.fsf@jurta.org> <87skywrame.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 1205287944 9001 80.91.229.12 (12 Mar 2008 02:12:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2008 02:12:24 +0000 (UTC) Cc: Juri Linkov , Michael Albinus , emacs-devel@gnu.org To: TSUCHIYA Masatoshi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 12 03:12:51 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 1JZGST-0000vk-R5 for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 03:12:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZGRv-0004yK-FH for ged-emacs-devel@m.gmane.org; Tue, 11 Mar 2008 22:12:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZGRp-0004xW-Th for emacs-devel@gnu.org; Tue, 11 Mar 2008 22:12:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZGRn-0004x8-VD for emacs-devel@gnu.org; Tue, 11 Mar 2008 22:12:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZGRn-0004wx-Gc for emacs-devel@gnu.org; Tue, 11 Mar 2008 22:12:03 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JZGRm-0005oG-WA for emacs-devel@gnu.org; Tue, 11 Mar 2008 22:12:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAM7Y1kfO+JwVUGdsb2JhbACQZgEBJxKBGpY5gQc X-IronPort-AV: E=Sophos;i="4.25,483,1199682000"; d="scan'208";a="15891667" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 11 Mar 2008 22:12:02 -0400 Original-Received: from pastel.home ([206.248.156.21]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id SFY19702; Tue, 11 Mar 2008 22:12:02 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B43CF7F05; Tue, 11 Mar 2008 22:12:01 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:92240 Archived-At: > I have just prepared the minimized patch to support tab-completion > features for `shell-command' etc. It is attached at the end of this > message. Because several users do not want to see the current > directory, the default values of prompt options do not contain > %-sequences. Could you provide a new version of your patch without the make-shell-prompt-string? I'm not sure whether make-shell-prompt-string is a good idea or not, but in any case I'd rather keep it as a separate question (same thing with the introduction of all those *-prompt defcustoms). Also I note that it's used in *every* call to read-shell-commmand, so it would be better to place just a single call to it directly inside read-shell-commmand. Also, please remove the `keymap' argument to read-shell-commmand since it's not used anywhere. In turn this will allow you to move the construction of the keymap out of the function into a variable read-shell-command-map where users will then be able to customize it to use pcomplete, for example. Try to avoid interactive anonymous functions, so just give it a name like minibuffer-complete-shell-command. Finally, using `defun' within another function is a bug in 99.99% of the cases. This case is not an exception. Such tricks, similarly to using defadvice, are fine for external Emacs packages who want/need to work with existing Emacs releases, but we're lucky enough to be in a position to change the rest of Emacs, so we don't need such things: just change the comint completion code so that it works well when used in the minibuffer. >> However, I still don't see a solution for the problem how to display >> the message (such as "[Completing command name...]") without a delay, >> and leave it visible to the user persistently without interfering with >> the user input. Why would you want to? This message is not particularly important, as far as I can tell. All it says, basically is "yeah I did get your key press and it was bound to the command you thought". I suggest to only display it if the minibuffer is not active (I'd even happily remove it altogether, but at least when the minibuffer is inactive the message is pretty harmless, so I don't mind keeping it). Stefan