From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: TSUCHIYA Masatoshi Newsgroups: gmane.emacs.devel Subject: Re: Feature request : Tab-completion for 'shell-comand' Date: Mon, 10 Mar 2008 09:08:45 +0900 Message-ID: <87lk4rmodu.fsf@tsuchiya.vaj.namazu.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205107741 2270 80.91.229.12 (10 Mar 2008 00:09:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 00:09:01 +0000 (UTC) To: Juri Linkov , Michael Albinus , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 01:09:28 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 1JYVa2-0005wE-J8 for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 01:09:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYVZU-0001dC-6U for ged-emacs-devel@m.gmane.org; Sun, 09 Mar 2008 20:08:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYVZP-0001bw-BV for emacs-devel@gnu.org; Sun, 09 Mar 2008 20:08:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYVZN-0001av-P3 for emacs-devel@gnu.org; Sun, 09 Mar 2008 20:08:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYVZN-0001as-L1 for emacs-devel@gnu.org; Sun, 09 Mar 2008 20:08:45 -0400 Original-Received: from vaj.namazu.org ([202.221.179.42]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JYVZM-0006cc-ST for emacs-devel@gnu.org; Sun, 09 Mar 2008 20:08:45 -0400 Original-Received: from vaj.namazu.org (vaj.namazu.org [202.221.179.42]) by vaj.namazu.org (Postfix) with ESMTP id 503A4202C0; Mon, 10 Mar 2008 09:08:41 +0900 (JST) X-cite: xcite 1.56 X-Cite-Me: =?iso-2022-jp?B?GyRCRVobKEI=?= In-Reply-To: <87ejajajbt.fsf@jurta.org> (Juri Linkov's message of "Sun, 09 Mar 2008 19:48:46 +0200") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:91963 Archived-At: Dear Emacs developers, >> On Sun, 09 Mar 2008 19:48:46 +0200 >> juri@jurta.org (Juri Linkov) said as follows: >> 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. I see. 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. >> 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. Wow, such general resolution will be very nice. I, however, worry that is is very difficult to find it because there are too many contexts when a minibuffer is used and the best way to combinate prompts and temoporal status messages depend on their contexts. >>>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 see. Regards, -- TSUCHIYA Masatoshi