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: Mon, 10 Mar 2008 03:29:02 +0200 Organization: JURTA Message-ID: <87lk4r74gt.fsf@jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205114122 16636 80.91.229.12 (10 Mar 2008 01:55:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 01:55:22 +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 Mon Mar 10 02:55:49 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 1JYXEz-0003LS-0K for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 02:55:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYXER-000757-0f for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 21:55:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYXE9-0006zK-6R for emacs-devel@gnu.org; Sun, 09 Mar 2008 21:54:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYXE7-0006yV-Np for emacs-devel@gnu.org; Sun, 09 Mar 2008 21:54:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYXE7-0006yP-HL for emacs-devel@gnu.org; Sun, 09 Mar 2008 21:54:55 -0400 Original-Received: from relay03.kiev.sovam.com ([62.64.120.201]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JYXE7-0001vb-22 for emacs-devel@gnu.org; Sun, 09 Mar 2008 21:54:55 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JYXDv-000NRk-Sc; Mon, 10 Mar 2008 03:54:52 +0200 In-Reply-To: <87lk4rmodu.fsf@tsuchiya.vaj.namazu.org> (TSUCHIYA Masatoshi's message of "Mon, 10 Mar 2008 09:08:45 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: a96565856d7d777f03ae631b61e05b17 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-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 [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:91977 Archived-At: > But I still think my idea to use a minibuffer as two areas is effective. > Could you evaluate the following code after loading shell-command.el and > try `shell-command' again? > > (defun shell-command-read-minibuffer > (format-string current-directory &optional initial-contents > user-keymap read hist) > "Read a command string in the minibuffer, with completion." > (let ((keymap (make-sparse-keymap)) > (prompt (shell-command-make-prompt-string > format-string current-directory))) > (set-keymap-parent keymap (or user-keymap minibuffer-local-map)) > (define-key keymap "\t" > (lambda () > (interactive) > (let ((orig-function (symbol-function 'message))) > (unwind-protect > (progn > (defun message (string &rest arguments) > (let* ((s1 (concat prompt > (buffer-substring > (shell-command/minibuffer-prompt-end) > (point-max)))) > (s2 (apply (function format) string arguments)) > (w (- (window-width) > (string-width s1) > (string-width s2) > 3))) > (funcall orig-function > (if (>= w 0) > (concat s1 " [" s2 "]") > s2)) > (if (sit-for 2) (funcall orig-function s1)) > s2)) > (require 'shell) > (require 'comint) > (run-hook-with-args-until-success > 'shell-command-complete-functions)) > (fset 'message orig-function))))) > (read-from-minibuffer prompt initial-contents keymap read hist))) > > I think that the above code still have a problem: the above code moves a > cursor to the end of line temporarily. I think that such temoporal > movement will confuse users. Yes, it would be too bad to move the cursor to the end of the line. But `minibuffer-message' doesn't do this: it leaves the cursor before the additional message appended to 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. -- Juri Linkov http://www.jurta.org/emacs/