Re: Feature request : Tab-completion for 'shell-comand'

[TSUCHIYA Masatoshi]

Dear Emacs developers,

>> On Sun, 09 Mar 2008 19:48:46 +0200
>> address@hidden (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