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

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

[paul r]

M-x shell-command, as well as its relatives (shell-command-on-region,
grep, grep-find, compile and maybe more), do not provide any kind of
completion in the minibuffer. This is a surprising behaviour, because
almost any other interactive function prompting for something that can
be tab-completed do provide tab-completion.
TSUCHIYA Masatoshi wrote an enhancement for it, that can be found
http://namazu.org/~tsuchiya/elisp/shell-command.el . This code works
against current head.
What do you think about adding the author to this thread ( if the
mailing-list rules allow it ) and discussing a possible inclusion ?

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

[Michael Albinus]

"paul r" <paul.r.ml@gmail.com> writes:

> M-x shell-command, as well as its relatives (shell-command-on-region,
> grep, grep-find, compile and maybe more), do not provide any kind of
> completion in the minibuffer. This is a surprising behaviour, because
> almost any other interactive function prompting for something that can
> be tab-completed do provide tab-completion.
> TSUCHIYA Masatoshi wrote an enhancement for it, that can be found
> http://namazu.org/~tsuchiya/elisp/shell-command.el . This code works
> against current head.

It's a neat package. However, its implementation is based mainly on
defadvices of shell-command, shell-command-on-region, grep, grep-find
and compile. I don't believe that it shall be integrated into the Emacs
core lisp *this* way. This could be a conflict, because the author seems
to be interested in offering this package for different Emacs version,
where this approach looks necessary.

Some minor concerns are the used GPLv2 (shall be GPLv3), and that it
doesn't support Tramp. But this could be solved easily.

Best regards, Michael.

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

[Juri Linkov]

>> M-x shell-command, as well as its relatives (shell-command-on-region,
>> grep, grep-find, compile and maybe more), do not provide any kind of
>> completion in the minibuffer. This is a surprising behaviour, because
>> almost any other interactive function prompting for something that can
>> be tab-completed do provide tab-completion.
>> TSUCHIYA Masatoshi wrote an enhancement for it, that can be found
>> http://namazu.org/~tsuchiya/elisp/shell-command.el . This code works
>> against current head.
>
> It's a neat package. However, its implementation is based mainly on
> defadvices of shell-command, shell-command-on-region, grep, grep-find
> and compile. I don't believe that it shall be integrated into the Emacs
> core lisp *this* way. This could be a conflict, because the author seems
> to be interested in offering this package for different Emacs version,
> where this approach looks necessary.

This is a useful feature to add to Emacs, and it is a pity it uses defadvices.
Perhaps defadvices could be replaced by a new shell-command specific
minibuffer keymap that just redefines TAB to perform completion on commands
and file names.  What I mean basically is:

(define-key shell-command-minibuffer-local-map "\t"
  (lambda ()
    (interactive)
    (require 'shell)
    (let ((comint-dynamic-complete-functions
           shell-dynamic-complete-functions))
      (comint-dynamic-complete))))

and use this map for reading commands in shell-command,
shell-command-on-region, grep, grep-find and compile.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

> This is a useful feature to add to Emacs, and it is a pity it uses defadvices.
> Perhaps defadvices could be replaced by a new shell-command specific
> minibuffer keymap that just redefines TAB to perform completion on commands
> and file names.  What I mean basically is:

> (define-key shell-command-minibuffer-local-map "\t"
>   (lambda ()
>     (interactive)
>     (require 'shell)
>     (let ((comint-dynamic-complete-functions
>            shell-dynamic-complete-functions))
>       (comint-dynamic-complete))))

> and use this map for reading commands in shell-command,
> shell-command-on-region, grep, grep-find and compile.

Yes, that's indeed a desirable change.  Better yet would be if someone
could fix/improve the pcomplete code so that it can be used for that
as well.


        Stefan

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

[TSUCHIYA Masatoshi]

Dear Emacs core developers,

>> On Tue, 04 Mar 2008 22:54:53 +0100
>> michael.albinus@gmx.de (Michael Albinus) said as follows:

>Some minor concerns are the used GPLv2 (shall be GPLv3), and that it
>doesn't support Tramp. But this could be solved easily.

First of all, I will be willing to contribute the code of
shell-command.el into Emacs core under GPL3.

>> On Wed, 05 Mar 2008 01:17:22 +0200
>> juri@jurta.org (Juri Linkov) said as follows:

>This is a useful feature to add to Emacs, and it is a pity it uses defadvices.
>Perhaps defadvices could be replaced by a new shell-command specific
>minibuffer keymap that just redefines TAB to perform completion on commands
>and file names.  What I mean basically is:

>(define-key shell-command-minibuffer-local-map "\t"
> (lambda ()
>   (interactive)
>   (require 'shell)
>   (let ((comint-dynamic-complete-functions
>          shell-dynamic-complete-functions))
>     (comint-dynamic-complete))))

This code is insufficient, because the output of `message' function
which is called from tab-completion functions will bury the current
completing status in minibuffer.

And more, the customize hook like `shell-command-complete-functions'
will be necessary, in order to enable users to customize tab-completion
functions.

Regards,

-- 
TSUCHIYA Masatoshi

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

[Juri Linkov]

>>This is a useful feature to add to Emacs, and it is a pity it uses defadvices.
>>Perhaps defadvices could be replaced by a new shell-command specific
>>minibuffer keymap that just redefines TAB to perform completion on commands
>>and file names.  What I mean basically is:
>
>>(define-key shell-command-minibuffer-local-map "\t"
>> (lambda ()
>>   (interactive)
>>   (require 'shell)
>>   (let ((comint-dynamic-complete-functions
>>          shell-dynamic-complete-functions))
>>     (comint-dynamic-complete))))
>
> This code is insufficient, because the output of `message' function
> which is called from tab-completion functions will bury the current
> completing status in minibuffer.

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 we should add the same to more places with the following patch:

Index: lisp/comint.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/comint.el,v
retrieving revision 1.373
diff -u -r1.373 comint.el
--- lisp/comint.el	22 Jan 2008 23:53:43 -0000	1.373
+++ lisp/comint.el	6 Mar 2008 10:01:27 -0000
@@ -3014,7 +3014,8 @@
 	    (current-window-configuration))
       (with-output-to-temp-buffer "*Completions*"
 	(display-completion-list completions))
-      (message "Type space to flush; repeat completion command to scroll"))
+      (unless (window-minibuffer-p (selected-window))
+	(message "Type space to flush; repeat completion command to scroll")))
 
     ;; Read the next key, to process SPC.
     (let (key first)

Index: lisp/shell.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/shell.el,v
retrieving revision 1.158
diff -u -r1.158 shell.el
--- lisp/shell.el	8 Jan 2008 20:44:52 -0000	1.158
+++ lisp/shell.el	6 Mar 2008 10:02:11 -0000
@@ -965,7 +965,8 @@
 	     (save-match-data (not (string-match "[~/]" filename)))
 	     (eq (match-beginning 0)
 		 (save-excursion (shell-backward-command 1) (point))))
-	(prog2 (message "Completing command name...")
+	(prog2 (unless (window-minibuffer-p (selected-window))
+		 (message "Completing command name..."))
 	    (shell-dynamic-complete-as-command)))))

> And more, the customize hook like `shell-command-complete-functions'
> will be necessary, in order to enable users to customize tab-completion
> functions.

I agree that this user option `shell-command-complete-functions' is
necessary for users to customize, and I think its default value should
be the same as the default value of `shell-dynamic-complete-functions'.

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.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

> 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 when the minibuffer is active, we should still output
a message, only differently (as does minibuffer-message).  Maybe just
using minibuffer-message (and changing it so it uses plain "message"
when the minibuffer is not active) would do the trick.


        Stefan

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

[Drew Adams]

> I think that when the minibuffer is active, we should still output
> a message, only differently (as does minibuffer-message).  Maybe just
> using minibuffer-message (and changing it so it uses plain "message"
> when the minibuffer is not active) would do the trick.

Haven't followed this thread, but FWIW, I use this a lot:

(defun icicle-msg-maybe-in-minibuffer (format-string &rest args)
  "Display FORMAT-STRING as a message.
If called with the minibuffer inactive, this is done using `message'.
Otherwise, it is done using `minibuffer-message'."
  (if (active-minibuffer-window)
      (save-selected-window
        (select-window (minibuffer-window))
        (minibuffer-message
          (apply #'format (concat "  [" format-string "]") args)))
    (apply #'message format-string args)))

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

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I think that when the minibuffer is active, we should still output
> a message, only differently (as does minibuffer-message).  Maybe just
> using minibuffer-message (and changing it so it uses plain "message"
> when the minibuffer is not active) would do the trick.

I wish _all_ messages would display ala minibuffer-message when the
user's editing in the minibuffer -- the current behavior (temporarily
ovewriting the minibuffer to show messages) is stupid and annoying,
especially given that many errors one gets are fairly trivial or
transient.

I made a patch to do this sometime before Emacs 21 was released, and
recall various issues popping up though... I think mainly it was the
somewhat more exotic users of message, like quail completion info etc.

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

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

[Drew Adams]

> > I think that when the minibuffer is active, we should still output
> > a message, only differently (as does minibuffer-message).  
> > Maybe just using minibuffer-message (and changing it so it uses
> > plain "message" when the minibuffer is not active) would do the trick.
> 
> I wish _all_ messages would display ala minibuffer-message when the
> user's editing in the minibuffer -- the current behavior (temporarily
> ovewriting the minibuffer to show messages) is stupid and annoying,
> especially given that many errors one gets are fairly trivial or
> transient.
> 
> I made a patch to do this sometime before Emacs 21 was released, and
> recall various issues popping up though... I think mainly it was the
> somewhat more exotic users of message, like quail completion info etc.

I find that it depends, though I can't give you a good fer-instance right
now. I'm not sure that a blanket change would be appropriate.

One disadvantage to `minibuffer-message' in some contexts is its
`minibuffer-message-timeout' delay. That can be inappropriate or annoying in
some contexts. And the message appears for only a limited time, even if
there is no input event. That's usually TRT, but not always, in my
experience.

Possibly a single DTRT messaging interface can be devised, but I suspect
that some code will continue to need to explicitly DTRT on a case-by-case
basis.

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

[Stefan Monnier]

>> I think that when the minibuffer is active, we should still output
>> a message, only differently (as does minibuffer-message).  Maybe just
>> using minibuffer-message (and changing it so it uses plain "message"
>> when the minibuffer is not active) would do the trick.

> I wish _all_ messages would display ala minibuffer-message when the
> user's editing in the minibuffer -- the current behavior (temporarily
> ovewriting the minibuffer to show messages) is stupid and annoying,
> especially given that many errors one gets are fairly trivial or
> transient.

> I made a patch to do this sometime before Emacs 21 was released, and
> recall various issues popping up though... I think mainly it was the
> somewhat more exotic users of message, like quail completion info etc.

Since minibuffer-message doesn't do anything useful currently when the
minibuffer is not active, we can change it to call `message' in
that case.

Then we can replace calls to `message' with calls to minibuffer-message on
a case-by-case basis.


        Stefan

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

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I wish _all_ messages would display ala minibuffer-message when the
>> user's editing in the minibuffer -- the current behavior (temporarily
>> ovewriting the minibuffer to show messages) is stupid and annoying,
>> especially given that many errors one gets are fairly trivial or
>> transient.
>
> Since minibuffer-message doesn't do anything useful currently when the
> minibuffer is not active, we can change it to call `message' in
> that case.
>
> Then we can replace calls to `message' with calls to minibuffer-message on
> a case-by-case basis.

I don't think that's a good idea -- really you would want to replace
_all_ (except a vanishingly small minority) of calls to message with
minibuffer-message, then.  The name "minibuffer-message" is uglier --
it's annoyingly long and awkward for such an extremely common call --
and really it's a huge amount of silly source-code churn for a
relatively minor change.

I think it would be better just to make "message" do the right thing,
and fix those places that don't work with the new way (in my testing,
that was very very few of them).

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

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

[Juri Linkov]

>> I think that when the minibuffer is active, we should still output
>> a message, only differently (as does minibuffer-message).  Maybe just
>> using minibuffer-message (and changing it so it uses plain "message"
>> when the minibuffer is not active) would do the trick.
>
> I wish _all_ messages would display ala minibuffer-message when the
> user's editing in the minibuffer -- the current behavior (temporarily
> ovewriting the minibuffer to show messages) is stupid and annoying,
> especially given that many errors one gets are fairly trivial or
> transient.
>
> I made a patch to do this sometime before Emacs 21 was released, and
> recall various issues popping up though... I think mainly it was the
> somewhat more exotic users of message, like quail completion info etc.

I see that quail completion currently doesn't work correctly in the
minibuffer: it doesn't display completions in the minibuffer for
multi-key input methods.  So this needs fixing anyway.

BTW, I see there are several duplicate implementations of
`minibuffer-message' in Emacs.  Maybe they all can be replaced
with a simple call to `minibuffer-message'?

(defun quail-minibuffer-message (string)
  (message nil)
  (let ((point-max (point-max))
	(inhibit-quit t))
    (save-excursion
      (goto-char point-max)
      (insert string))
    (sit-for 1000000)
    (delete-region point-max (point-max))
    (when quit-flag
      (setq quit-flag nil
	    unread-command-events '(7)))))

(defun file-cache-temp-minibuffer-message (msg)
  "A Lisp version of `temp_minibuffer_message' from minibuf.c."
  (let ((savemax (point-max)))
    (save-excursion
      (goto-char (point-max))
      (insert msg))
    (let ((inhibit-quit t))
      (sit-for 2)
      (delete-region savemax (point-max))
      (if quit-flag
	  (setq quit-flag nil
		unread-command-events (list 7))))))

(defun calc-temp-minibuffer-message (m)
  (let ((savemax (point-max)))
    (save-excursion
      (goto-char (point-max))
      (insert m))
    (let ((okay nil))
      (unwind-protect
	  (progn
	    (sit-for 2)
	    (identity 1)   ; this forces a call to QUIT; in bytecode.c.
	    (setq okay t))
	(progn
	  (delete-region savemax (point-max))
	  (or okay (abort-recursive-edit)))))))

(defun PC-temp-minibuffer-message (message)
  "A Lisp version of `temp_minibuffer_message' from minibuf.c."
  (cond (PC-not-minibuffer
	 (message "%s" message)
	 (sit-for 2)
	 (message ""))
	((fboundp 'temp-minibuffer-message)
	 (temp-minibuffer-message message))
	(t
	 (let ((point-max (point-max)))
	   (save-excursion
	     (goto-char point-max)
	     (insert message))
	   (let ((inhibit-quit t))
	     (sit-for 2)
	     (delete-region point-max (point-max))
	     (when quit-flag
	       (setq quit-flag nil
		     unread-command-events '(7))))))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

>> 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 when the minibuffer is active, we should still output
> a message, only differently (as does minibuffer-message).  Maybe just
> using minibuffer-message (and changing it so it uses plain "message"
> when the minibuffer is not active) would do the trick.

This will require changes in a lot of places to replace `message' with
`minibuffer-message'.

But maybe `message' should take care of the active minibuffer and
display the message at the end of the minibiffer when it is active
using `minibuffer-message'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

>> I think that when the minibuffer is active, we should still output
>> a message, only differently (as does minibuffer-message).  Maybe just
>> using minibuffer-message (and changing it so it uses plain "message"
>> when the minibuffer is not active) would do the trick.
>
> This will require changes in a lot of places to replace `message' with
> `minibuffer-message'.
>
> But maybe `message' should take care of the active minibuffer and
> display the message at the end of the minibiffer when it is active
> using `minibuffer-message'?

I tried to run Emacs with a small patch below that modifies `message' to
call `minibuffer-message' when the minibuffer is active, and so far I see
no problems.

When I run a timer (run-at-time t 3 'message "Hello") that displays
the message every 3 sec, and activate the minibuffer, then it correctly
displays its message in the minibuffer as:

Find file: ~/ [Hello]

It also plays nicely with the completion messages by appending the
message like (after typing TAB):

Find file: ~/.emacs [Complete, but not unique] [Hello]

Here is the patch if someone wants to try:

Index: src/editfns.c
===================================================================
RCS file: /sources/emacs/emacs/src/editfns.c,v
retrieving revision 1.456
diff -u -r1.456 editfns.c
--- src/editfns.c	26 Feb 2008 16:36:52 -0000	1.456
+++ src/editfns.c	6 Mar 2008 23:45:35 -0000
@@ -3365,8 +3365,21 @@
       message (0);
       return args[0];
     }
-  else
+  else if (WINDOWP (selected_window)
+	   && MINI_WINDOW_P (XWINDOW (selected_window)))
     {
+      register Lisp_Object val1, val2;
+      Lisp_Object args2[2];
+
+      val1 = Fformat (nargs, args);
+      args2[0] = build_string (" [%s]");
+      args2[1] = val1;
+      val2 = Fformat (2, args2);
+
+      temp_echo_area_glyphs (val2);
+      return val1;
+    }
+  else     {
       register Lisp_Object val;
       val = Fformat (nargs, args);
       message3 (val, SBYTES (val), STRING_MULTIBYTE (val));

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

>> 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 when the minibuffer is active, we should still output
> a message, only differently (as does minibuffer-message).  Maybe just
> using minibuffer-message (and changing it so it uses plain "message"
> when the minibuffer is not active) would do the trick.

It turns out that `minibuffer-message' doesn't help in this particular case:
after typing TAB on the command name in the minibuffer it displays

Shell command: ema [Completing command name...]

then waits 2 sec and displays another message

Shell command: emacs [Type space to flush; repeat completion command to scroll]

then again waits 2 sec and displays

Shell command: emacs [Partially completed]

After typing more and typing TAB

Shell command: emacs22 [Completing command name...]

waits 2 sec and displays

Shell command: emacs22 [Type space to flush; repeat completion command to scroll]

again waits 2 sec and displays

Shell command: emacs22 [Completed]

This delay for 2 sec is unbearable.  I think comint.el messages were not
designed to be helpful in the minibuffer.  So we should decide which
comint.el messages are necessary in the minibuffer and which are not,
and change unnecessary ones to display conditionally depending on
whether the minibuffer is active or not.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

    I think that when the minibuffer is active, we should still output
    a message, only differently (as does minibuffer-message).

I have doubts that this is uniformly the best thing to do.
I think that the best thing to do depends on the message:
some messages are good to display at the end of the minibuffer,
as in `minibuffer-message', and some are better just omitted
while in the minibuffer.

There are some messages that probably should be displayed as now,
replacing the minibuffer.  For instance, the messages displayed by
Isearch.  I think that is the best way to display them; I think that
displaying them at the end, as in `minibuffer-message', would look
strange.

It is possible that if we try displaying Isearch messages at the end,
we will like it.  But it seems unlikely.

My advice is that we should not rush to adopt a simple uniform policy
about this.

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

[Juri Linkov]

>     I think that when the minibuffer is active, we should still output
>     a message, only differently (as does minibuffer-message).
>
> I have doubts that this is uniformly the best thing to do.
> I think that the best thing to do depends on the message:
> some messages are good to display at the end of the minibuffer,
> as in `minibuffer-message', and some are better just omitted
> while in the minibuffer.

Currently messages displayed when the minibuffer is active don't get
omitted.  They just obscure the minibuffer content from the user.

> There are some messages that probably should be displayed as now,
> replacing the minibuffer.  For instance, the messages displayed by
> Isearch.  I think that is the best way to display them; I think that
> displaying them at the end, as in `minibuffer-message', would look
> strange.
>
> It is possible that if we try displaying Isearch messages at the end,
> we will like it.  But it seems unlikely.

With the patch I sent (that changes `message' to call `minibuffer-message'
in the active minibuffer), Isearch in the minibuffer works mostly without
changes, but there is a difference on failed Isearch: without this patch
the Isearch error message overwrites the minibuffer content, but with this
patch it appends the error message to the end of the minibuffer, e.g.

I-search backward: foo [Failing I-search backward: bar]

I'm not sure this is a bad thing since it keeps displaying the original
content of the minibuffer.

Otherwise, we could just fix this particular case not to use
`minibuffer-message'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Lennart Borgman (gmail)]

Juri Linkov wrote:
> the Isearch error message overwrites the minibuffer content, but with this
> patch it appends the error message to the end of the minibuffer, e.g.
> 
> I-search backward: foo [Failing I-search backward: bar]

Maybe it would be good to show the message before the prompt and on its 
own line? That way it could perhaps easily be made read-only etc.

It also seems to be a rather natural place to show it - at least if you 
are used to command line tools.

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

[Juri Linkov]

>> the Isearch error message overwrites the minibuffer content, but with this
>> patch it appends the error message to the end of the minibuffer, e.g.
>>
>> I-search backward: foo [Failing I-search backward: bar]
>
> Maybe it would be good to show the message before the prompt and on its
> own line? That way it could perhaps easily be made read-only etc.
>
> It also seems to be a rather natural place to show it - at least if you
> are used to command line tools.

I don't understand what do you propose.  Currently the error message
is already before the prompt and looks like:

Failing I-search backward: bar

but overwrites the minibuffer content.  With `minibuffer-message'
it looks like:

I-search backward: foo [Failing I-search backward: bar]

If necessary, we can make the error message shorter like:

I-search backward: foo [Failing: bar]

Anyway, to show the failed search string is more important than
the minibuffer content.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>>> the Isearch error message overwrites the minibuffer content, but with this
>>> patch it appends the error message to the end of the minibuffer, e.g.
>>>
>>> I-search backward: foo [Failing I-search backward: bar]
>> Maybe it would be good to show the message before the prompt and on its
>> own line? That way it could perhaps easily be made read-only etc.
>>
>> It also seems to be a rather natural place to show it - at least if you
>> are used to command line tools.
> 
> I don't understand what do you propose.  Currently the error message
> is already before the prompt and looks like:

It was me that did not understand, sorry. I suggested adding the 
messages to the prompt, but as Stefan pointed out this does not work if 
the minibuffer only has a single line available.

Reading the thread more carefully I see that you have found that the 2 
seconds delay when using minibuffer-message can be very disturbing. How 
about redesigning that part, something like this:

- If there is an old minibuffer-message "active" then immediately remove 
this and put a copy in the *Message* buffer.
- Then display the new minibuffer-message.

> Failing I-search backward: bar
> 
> but overwrites the minibuffer content.  With `minibuffer-message'
> it looks like:
> 
> I-search backward: foo [Failing I-search backward: bar]
> 
> If necessary, we can make the error message shorter like:
> 
> I-search backward: foo [Failing: bar]

Looks good to me.

> Anyway, to show the failed search string is more important than
> the minibuffer content.

And the suggestion to make minibuffer-message fallback to just message 
if the minibuffer is not active seems useful.

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

[Stefan Monnier]

> Maybe it would be good to show the message before the prompt and on its own
> line? That way it could perhaps easily be made read-only etc.

Some people's minibuffer only has a single line available.  E.g. mine.
So it's fine to make up solutions using multi-line minibuffers (and
echo areas), but the behavior should be acceptable also for
single-line minibuffers.


        Stefan

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

[Richard Stallman]

    > I have doubts that this is uniformly the best thing to do.
    > I think that the best thing to do depends on the message:
    > some messages are good to display at the end of the minibuffer,
    > as in `minibuffer-message', and some are better just omitted
    > while in the minibuffer.

    Currently messages displayed when the minibuffer is active don't get
    omitted.  They just obscure the minibuffer content from the user.

The message I replied to showed an example of code that omits
the message when the minibuffer is active.

    With the patch I sent (that changes `message' to call `minibuffer-message'
    in the active minibuffer), Isearch in the minibuffer works mostly without
    changes,

I am surprised.  How does it do that?  If `message' calls
`minibuffer-message', how come that doesn't cause all the isearch
messages to appear after the minibuffer text?

	     but there is a difference on failed Isearch: without this patch
    the Isearch error message overwrites the minibuffer content, but with this
    patch it appends the error message to the end of the minibuffer, e.g.

    I-search backward: foo [Failing I-search backward: bar]

I am not sure how to interpret that, because I do not know what foo
and bar stand for.  But it cannot be right to have two isearch
messages at once.  Whether the search succeeds or fails, its message
should be displayed in the same place, in the same way.

    Otherwise, we could just fix this particular case not to use
    `minibuffer-message'.

If `message' automatically calls `minibuffer-message' when the minibuffer
is active, how is it possible to fix one case not to do that?

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

[Juri Linkov]

>     > I have doubts that this is uniformly the best thing to do.
>     > I think that the best thing to do depends on the message:
>     > some messages are good to display at the end of the minibuffer,
>     > as in `minibuffer-message', and some are better just omitted
>     > while in the minibuffer.
>
>     Currently messages displayed when the minibuffer is active don't get
>     omitted.  They just obscure the minibuffer content from the user.
>
> The message I replied to showed an example of code that omits
> the message when the minibuffer is active.

Then I agree that if some messages are not important they should be
omitted while in the minibuffer (by using a condition that check if the
minibuffer is active before calling `minibuffer-message', or in `message'
if it will call `minibuffer-message').  Otherwise, a message should be
appended to the end of the minibuffer.  But I think messages should never
overwrite the content of the active minibuffer.

>     With the patch I sent (that changes `message' to call `minibuffer-message'
>     in the active minibuffer), Isearch in the minibuffer works mostly without
>     changes,
>
> I am surprised.  How does it do that?  If `message' calls
> `minibuffer-message', how come that doesn't cause all the isearch
> messages to appear after the minibuffer text?

This is due to the special function `minibuffer-history-isearch-message'
that doesn't call `isearch-message' if isearch is not failed.

If we will change `message' to call `minibuffer-message' in the active
minibuffer, then something like this could be implemented in a few
special cases where using `minibuffer-message' will be not desirable.

> 	     but there is a difference on failed Isearch: without this patch
>     the Isearch error message overwrites the minibuffer content, but with this
>     patch it appends the error message to the end of the minibuffer, e.g.
>
>     I-search backward: foo [Failing I-search backward: bar]
>
> I am not sure how to interpret that, because I do not know what foo
> and bar stand for.

The former is is the minibuffer content and the latter is the search string.
The complete workflow looks like:

1. Activate the minibuffer and type some text like "text":

Prompt: text

2. Type C-r and type a character "t":

I-search backward: text

The successful isearch highlights the found character "t".

3. Type a search string like "search string".
When isearch fails, it will display using `minibuffer-message':

I-search backward: text [Failing I-search backward: search string]

5. But currently it displays:

Failing I-search backward: search string

> But it cannot be right to have two isearch messages at once.
> Whether the search succeeds or fails, its message should be displayed
> in the same place, in the same way.

So it seems it would be better to leave its current behavior.

>     Otherwise, we could just fix this particular case not to use
>     `minibuffer-message'.
>
> If `message' automatically calls `minibuffer-message' when the minibuffer
> is active, how is it possible to fix one case not to do that?

We could add a condition to `message' to check for the value of
a variable like `minibuffer-message-timeout', and if it is nil
then don't call `minibuffer-message'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

    This is due to the special function `minibuffer-history-isearch-message'
    that doesn't call `isearch-message' if isearch is not failed.

Is that in the trunk only?  I cannot build the trunk; it has failed
ever since the unicode merge.  I am using Emacs 22, so I saw different
behavior.

    3. Type a search string like "search string".
    When isearch fails, it will display using `minibuffer-message':

    I-search backward: text [Failing I-search backward: search string]

I don't think that is desirable output.

    5. But currently it displays:

    Failing I-search backward: search string

Perhaps failing searches should continue displaying that.
I am not sure what is best for them  to display, but we should
not let that decision be forced by limited behavior of `message'.
We should choose the output we want, and make sure we have primitives
that can display it.

Perhaps we should change `message' should be changed to act like
`minibuffer-message', but then add a new function which continues to
do what `message' does now.  Then isearch could use that.

Cannot build the trunk since unicode (was: Feature request : Tab-completion for 'shell-comand')

[Stefan Monnier]

> Is that in the trunk only?  I cannot build the trunk; it has failed
> ever since the unicode merge.  I am using Emacs 22, so I saw different
> behavior.

Is that because of the failure to dump you've talked about?
This is really strange.  You're using some kind of GNU/Linux
distribution, right?  I haven't heard of any such problem on GNU/Linux.
What's so different about your system?


        Stefan

Re: Cannot build the trunk since unicode (was: Feature request : Tab-completion for 'shell-comand')

[Richard Stallman]

    Is that because of the failure to dump you've talked about?

Yes.  I tracked it down to clobberage inside `write' which is called from
`unexec'.  I hope that Glibc developers will help me track it down.

    This is really strange.  You're using some kind of GNU/Linux
    distribution, right?  I haven't heard of any such problem on GNU/Linux.
    What's so different about your system?

I don't know.  The failure started at the time of the Unicode merge.

Re: Cannot build the trunk since unicode (was: Feature request : Tab-completion for 'shell-comand')

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Yes.  I tracked it down to clobberage inside `write' which is called from
> `unexec'.  I hope that Glibc developers will help me track it down.

If write clobbers your data then you need to look at the kernel.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Juri Linkov]

>     This is due to the special function `minibuffer-history-isearch-message'
>     that doesn't call `isearch-message' if isearch is not failed.
>
> Is that in the trunk only?

Yes, this is in the trunk only.

>     3. Type a search string like "search string".
>     When isearch fails, it will display using `minibuffer-message':
>
>     I-search backward: text [Failing I-search backward: search string]
>
> I don't think that is desirable output.
>
>     5. But currently it displays:
>
>     Failing I-search backward: search string
>
> Perhaps failing searches should continue displaying that.
> I am not sure what is best for them  to display, but we should
> not let that decision be forced by limited behavior of `message'.
> We should choose the output we want, and make sure we have primitives
> that can display it.
>
> Perhaps we should change `message' should be changed to act like
> `minibuffer-message', but then add a new function which continues to
> do what `message' does now.  Then isearch could use that.

A new function would be good if `minibuffer-message' worked well.
But unfortunately `minibuffer-message' is still unsatisfactory.
The main problem of `minibuffer-message' is that requires a delay 2 sec.
So for instance, when you call `dabbrev-expand' M-/ in the minibuffer,
it displays an unimportant message [Scanning for dabbrevs...] and then
waits.  When you do the same in a normal buffer, `message' doesn't wait.

One solution for `minibuffer-message' is to put an overlay at the end
of the minibuffer with the message and don't wait.  Any new call to
`minibuffer-message' could replace the message on this overlay shared
between several calls to `minibuffer-message'.  Any cursor movement
will remove it like cursor movements remove the message displayed
by `message'.  Would this work?

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

    One solution for `minibuffer-message' is to put an overlay at the end
    of the minibuffer with the message and don't wait.  Any new call to
    `minibuffer-message' could replace the message on this overlay shared
    between several calls to `minibuffer-message'.  Any cursor movement
    will remove it like cursor movements remove the message displayed
    by `message'.  Would this work?

What user-visible behavior are you proposing?
(I am not sure from those words.)

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

[Juri Linkov]

>     One solution for `minibuffer-message' is to put an overlay at the end
>     of the minibuffer with the message and don't wait.  Any new call to
>     `minibuffer-message' could replace the message on this overlay shared
>     between several calls to `minibuffer-message'.  Any cursor movement
>     will remove it like cursor movements remove the message displayed
>     by `message'.  Would this work?
>
> What user-visible behavior are you proposing?
> (I am not sure from those words.)

I thought about something like a new function `message-minibuffer' to be
called in the minibuffer instead of the current `minibuffer-message', e.g.:

(defvar message-minibuffer-overlay)

(defun message-minibuffer (message)
  (setq message-minibuffer-overlay
        (make-overlay (1- (point-max)) (point-max)))
  (overlay-put message-minibuffer-overlay 'evaporate t)
  (overlay-put message-minibuffer-overlay 'after-string
                                          (format " [%s]" message)))

But it seems impossible to add an overlay *after* the cursor
at the end of the minibuffer, like `minibuffer-message' already does
inserting the message after the cursor at the end of the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> But it seems impossible to add an overlay *after* the cursor at the
> end of the minibuffer, like `minibuffer-message' already does
> inserting the message after the cursor at the end of the minibuffer.

Try

    (setq ov (make-overlay (point-max) (point-max)))
    (overlay-put ov 'insert-in-front-hooks
                 (list (lambda (o &rest ignore)
                         (move-overlay o (point-max) (point-max)))))
    (overlay-put ov 'after-string (concat (propertize " " 'cursor t)
                                           "[No match]"))

-- 
Johan Bockgård

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

[David Kastrup]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Juri Linkov <juri@jurta.org> writes:
>
>> But it seems impossible to add an overlay *after* the cursor at the
>> end of the minibuffer, like `minibuffer-message' already does
>> inserting the message after the cursor at the end of the minibuffer.
>
> Try
>
>     (setq ov (make-overlay (point-max) (point-max)))
>     (overlay-put ov 'insert-in-front-hooks
>                  (list (lambda (o &rest ignore)
>                          (move-overlay o (point-max) (point-max)))))

Huh?  Why don't you do (make-overlay (point-max) (point-max) nil t t)
instead of using that hook?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Johan Bockgård]

David Kastrup <dak@gnu.org> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
>>     (setq ov (make-overlay (point-max) (point-max)))
>>     (overlay-put ov 'insert-in-front-hooks
>>                  (list (lambda (o &rest ignore)
>>                          (move-overlay o (point-max) (point-max)))))
>
> Huh?  Why don't you do (make-overlay (point-max) (point-max) nil t t)
> instead of using that hook?

Because I thought I had already tried that and found that it didn't
work. (Setting either FRONT-ADVANCE or REAR-ADVANCE didn't do what I
want.)

Apparently not.

-- 
Johan Bockgård

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

[Juri Linkov]

>> But it seems impossible to add an overlay *after* the cursor at the
>> end of the minibuffer, like `minibuffer-message' already does
>> inserting the message after the cursor at the end of the minibuffer.
>
> Try
>
>     (setq ov (make-overlay (point-max) (point-max)))
>     (overlay-put ov 'insert-in-front-hooks
>                  (list (lambda (o &rest ignore)
>                          (move-overlay o (point-max) (point-max)))))
>     (overlay-put ov 'after-string (concat (propertize " " 'cursor t)
>                                            "[No match]"))

Yes, this would work.  But it seems putting overlays at
(point-max) might have some negative consequences,
e.g. `(remove-overlays)' won't remove it because it can't
find this overlay in (overlays-in (point-min) (point-max)).
But (mapcar 'delete-overlay (overlays-in (point-min) (1+ (point-max))))
will do.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> `(remove-overlays)' won't remove it because it can't find this overlay
> in (overlays-in (point-min) (point-max)).

That seems like a problem in itself.

-- 
Johan Bockgård

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

[Stefan Monnier]

>> `(remove-overlays)' won't remove it because it can't find this overlay
>> in (overlays-in (point-min) (point-max)).

> That seems like a problem in itself.

Indeed.  If (1+ (point-max)) works, then a solution is to let
`remove-overlays' default to (1+ (point-max)) rather than just
(point-max).


        Stefan

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

[martin rudalics]

 >>>`(remove-overlays)' won't remove it because it can't find this overlay
 >>>in (overlays-in (point-min) (point-max)).
 >
 >
 >>That seems like a problem in itself.
 >
 >
 > Indeed.  If (1+ (point-max)) works, then a solution is to let
 > `remove-overlays' default to (1+ (point-max)) rather than just
 > (point-max).

I suppose this would make

(progn
   (make-overlay 5 6)
   (narrow-to-region 2 5)
   (remove-overlays)
   (widen))

fail.  The correct approach is to call `remove-overlays' twice as

(remove-overlays)
(remove-overlays (point-max) (point-max))

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

[Richard Stallman]

    I suppose this would make

    (progn
       (make-overlay 5 6)
       (narrow-to-region 2 5)
       (remove-overlays)
       (widen))

    fail.  The correct approach is to call `remove-overlays' twice as

If it does, that suggests there may be a different bug
that needs a different fix.

The doc string of `remove-overlays' doesn't make it precisely clear
what the criterion is for removing an overlay.  Perhaps that criterion
needs to be changed.  It is worth some thought.

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

 > The doc string of `remove-overlays' doesn't make it precisely clear
 > what the criterion is for removing an overlay.  Perhaps that criterion
 > needs to be changed.  It is worth some thought.

The doc-string of `remove-overlays' is not useful in this regard - its
first sentence is silly.  But `remove-overlays' relies on `overlays-in'
and the latter's doc-string is precise.  A zero-length overlay located
at the (implicit) END arg of `remove-overlays' should _not_ get deleted
unless it's located at the (implicit) BEG too.

`remove-overlays' is more often used for the wrong purpose - to delete
all overlays (with a given property) in a buffer.  As I suggested
earlier some form of `delete-all-overlays' would serve that purpose much
better - in particular it wouldn't have to build and subsequently gc the
intermediate list returned by `overlays-in'.  Moreover it wouldn't have
to recenter overlays and could be easily instructed to delete overlays
with given properties only.

OTOH `overlays-in' disregards overlay properties.  This contrasts with
its actual use in Emacs: The vast majority of `overlays-in' calls is
followed by code checking whether the returned overlays match some
specific property.  This approach is highly inefficient when a buffer
contains few overlays with property foo, many with property bar, and a
client is looking for all overlays with property foo.  `overlays-in'
must investigate all overlays (find their start and end points, compare
whether they fit into the region, maybe allocate an additional vector)
and put them together in a list.  The client has to filter the list
returned and the collector has to recycle it.

I attached an older patch I found useful in this context.  `overlays-in'
would get an additional optional parameter PROP and include an overlay
iff either PROP is nil or its property list has an entry for PROP.
`overlays-with-prop-eq-value' would get two additional parameters PROP
and VALUE and include an overlay only if its PROP property eqs VALUE.

People then could start to get rid of monstrosities like

	    (let ((pos (point-min)))
	      (while (< (setq pos (next-overlay-change pos)) (point-max))
		(dolist (ol (overlays-at pos))
		  (if (overlay-get ol 'sgml-tag)
		      (delete-overlay ol)))))

in sgml-mode.


[-- Attachment #2: buffer.patch --]
[-- Type: text/plain, Size: 6549 bytes --]

*** buffer.c.~1.541.~	Wed Nov 28 05:46:22 2007
--- buffer.c	Mon Jan 14 19:58:34 2008
***************
*** 2679,2691 ****
     If EXTEND is non-zero, we make the vector bigger if necessary.
     If EXTEND is zero, we never extend the vector,
     and we store only as many overlays as will fit.
!    But we still return the total number of overlays.  */
  
  static int
! overlays_in (beg, end, extend, vec_ptr, len_ptr, next_ptr, prev_ptr)
       int beg, end;
       int extend;
       Lisp_Object **vec_ptr;
       int *len_ptr;
       int *next_ptr;
       int *prev_ptr;
--- 2679,2700 ----
     If EXTEND is non-zero, we make the vector bigger if necessary.
     If EXTEND is zero, we never extend the vector,
     and we store only as many overlays as will fit.
!    But we still return the total number of overlays.
! 
!    CHECK should be 0, 1 or 2.  CHECK == 0 means do not check overlay
!    properties.  CHECK == 1 means include an overlay only if PROP is an
!    element of the overlay's property list.  CHECK == 2 means include an
!    overlay only if PROP is an element of the overlay's property list and
!    its value equals VAL  .x
! */
  
  static int
! overlays_in (beg, end, extend, vec_ptr, len_ptr, next_ptr, prev_ptr, check, prop, value)
       int beg, end;
       int extend;
+      int check;
       Lisp_Object **vec_ptr;
+      Lisp_Object prop, value;
       int *len_ptr;
       int *next_ptr;
       int *prev_ptr;
***************
*** 2705,2710 ****
--- 2714,2725 ----
  
        XSETMISC (overlay, tail);
  
+       if ((check != 0)
+ 	  && ((NILP (Fplist_member ((XOVERLAY (overlay)->plist), prop)))
+ 	      || ((check == 2)
+ 		  && (!EQ ((Foverlay_get (overlay, prop)), value)))))
+ 	continue;
+ 
        ostart = OVERLAY_START (overlay);
        oend = OVERLAY_END (overlay);
        endpos = OVERLAY_POSITION (oend);
***************
*** 2753,2758 ****
--- 2768,2779 ----
  
        XSETMISC (overlay, tail);
  
+       if ((check != 0)
+ 	  && ((NILP (Fplist_member ((XOVERLAY (overlay)->plist), prop)))
+ 	      || ((check == 2)
+ 		  && (!EQ ((Foverlay_get (overlay, prop)), value)))))
+ 	continue;
+ 
        ostart = OVERLAY_START (overlay);
        oend = OVERLAY_END (overlay);
        startpos = OVERLAY_POSITION (ostart);
***************
*** 2814,2824 ****
  
    size = 10;
    v = (Lisp_Object *) alloca (size * sizeof *v);
!   n = overlays_in (start, end, 0, &v, &size, NULL, NULL);
    if (n > size)
      {
        v = (Lisp_Object *) alloca (n * sizeof *v);
!       overlays_in (start, end, 0, &v, &n, NULL, NULL);
      }
  
    for (i = 0; i < n; ++i)
--- 2835,2845 ----
  
    size = 10;
    v = (Lisp_Object *) alloca (size * sizeof *v);
!   n = overlays_in (start, end, 0, &v, &size, NULL, NULL, 0, Qnil, Qnil);
    if (n > size)
      {
        v = (Lisp_Object *) alloca (n * sizeof *v);
!       overlays_in (start, end, 0, &v, &n, NULL, NULL, 0, Qnil, Qnil);
      }
  
    for (i = 0; i < n; ++i)
***************
*** 3958,3971 ****
    return result;
  }
  
! DEFUN ("overlays-in", Foverlays_in, Soverlays_in, 2, 2, 0,
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
  Empty overlays are included in the result if they are located at BEG
! or between BEG and END.  */)
!      (beg, end)
!      Lisp_Object beg, end;
  {
    int noverlays;
    Lisp_Object *overlay_vec;
--- 3979,4032 ----
    return result;
  }
  
! DEFUN ("overlays-in", Foverlays_in, Soverlays_in, 2, 3, 0,
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
  Empty overlays are included in the result if they are located at BEG
! or between BEG and END.
! Optional argument PROP non-nil means return only overlays with property PROP.  */)
!      (beg, end, prop)
!      Lisp_Object beg, end, prop;
! {
!   int noverlays;
!   Lisp_Object *overlay_vec;
!   int len;
!   Lisp_Object result;
! 
!   CHECK_NUMBER_COERCE_MARKER (beg);
!   CHECK_NUMBER_COERCE_MARKER (end);
! 
!   len = 10;
!   overlay_vec = (Lisp_Object *) xmalloc (len * sizeof (Lisp_Object));
! 
!   /* Put all the overlays we want in a vector in overlay_vec.
!      Store the length in len.  */
!   if (NILP (prop))
!     noverlays = overlays_in (XINT (beg), XINT (end), 1, &overlay_vec, &len,
! 			     (int *) 0, (int *) 0, 0, Qnil, Qnil);
!   else noverlays = overlays_in (XINT (beg), XINT (end), 1, &overlay_vec, &len,
! 				(int *) 0, (int *) 0, 1, prop, Qnil);
! 
!   /* Make a list of them all.  */
!   result = Flist (noverlays, overlay_vec);
! 
!   xfree (overlay_vec);
!   return result;
! }
! 
! DEFUN ("overlays-with-prop-eq-value",
!        Foverlays_with_prop_eq_value, Soverlays_with_prop_eq_value, 3, 4, 0,
!        doc: /* Return a list of overlays in BEG...END whose property PROP equals VALUE.
! An overlay is in BEG...END when at least one character within that
! region is contained within the overlay.  Empty overlays are included in
! the result if they are located at BEG or between BEG and END.
! An overlay is returned if and only if PROP is a member of the overlay's
! property list and the value of PROP is `eq' to VALUE.  If the optional
! argument VALUE is omitted return only overlays whose PROP has the value
! nil.  */)
!      (beg, end, prop, value)
!      Lisp_Object beg, end, prop, value;
  {
    int noverlays;
    Lisp_Object *overlay_vec;
***************
*** 3981,3987 ****
    /* Put all the overlays we want in a vector in overlay_vec.
       Store the length in len.  */
    noverlays = overlays_in (XINT (beg), XINT (end), 1, &overlay_vec, &len,
! 			   (int *) 0, (int *) 0);
  
    /* Make a list of them all.  */
    result = Flist (noverlays, overlay_vec);
--- 4042,4048 ----
    /* Put all the overlays we want in a vector in overlay_vec.
       Store the length in len.  */
    noverlays = overlays_in (XINT (beg), XINT (end), 1, &overlay_vec, &len,
! 			   (int *) 0, (int *) 0, 2, prop, value);
  
    /* Make a list of them all.  */
    result = Flist (noverlays, overlay_vec);
***************
*** 6142,6147 ****
--- 6203,6209 ----
    defsubr (&Soverlay_properties);
    defsubr (&Soverlays_at);
    defsubr (&Soverlays_in);
+   defsubr (&Soverlays_with_prop_eq_value);
    defsubr (&Snext_overlay_change);
    defsubr (&Sprevious_overlay_change);
    defsubr (&Soverlay_recenter);

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

[Stefan Monnier]

> People then could start to get rid of monstrosities like

> 	    (let ((pos (point-min)))
> 	      (while (< (setq pos (next-overlay-change pos)) (point-max))
> 		(dolist (ol (overlays-at pos))
> 		  (if (overlay-get ol 'sgml-tag)
> 		      (delete-overlay ol)))))

The first step is for this code to use remove-overlays.


        Stefan

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

[Richard Stallman]

overlays-with-prop-eq-value seems like a good idea,
but we should pick a shorter name, like overlay-search.

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

[Richard Stallman]

    The doc-string of `remove-overlays' is not useful in this regard - its
    first sentence is silly.  But `remove-overlays' relies on `overlays-in'
    and the latter's doc-string is precise.  A zero-length overlay located
    at the (implicit) END arg of `remove-overlays' should _not_ get deleted
    unless it's located at the (implicit) BEG too.

Perhaps remove-overlays should have an argument controlling
how to interpret END.  I think often people will want to delete
zero-lenth overlays at END, and often they won't.

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

[Stefan Monnier]

>>>> `(remove-overlays)' won't remove it because it can't find this overlay
>>>> in (overlays-in (point-min) (point-max)).
>> 
>> 
>>> That seems like a problem in itself.
>> 
>> 
>> Indeed.  If (1+ (point-max)) works, then a solution is to let
>> `remove-overlays' default to (1+ (point-max)) rather than just
>> (point-max).

> I suppose this would make

> (progn
>   (make-overlay 5 6)
>   (narrow-to-region 2 5)
>   (remove-overlays)
>   (widen))

Good point.  I guess the (1+ (point-max)) should only be used when
(point-max) is the really the end of the buffer, since otherwise it's
not clear whether the overlays at (point-max) are inside or outside the
narrowing (and since it's not clear, it's better not to remove them).


        Stefan

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

[martin rudalics]

 > I guess the (1+ (point-max)) should only be used when
 > (point-max) is the really the end of the buffer, since otherwise it's
 > not clear whether the overlays at (point-max) are inside or outside the
 > narrowing (and since it's not clear, it's better not to remove them).

It would still be an ugly hack.  Future implementations of `overlays-in'
should be allowed to check whether its arguments constitute valid buffer
positions.

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

[Stefan Monnier]

>> I guess the (1+ (point-max)) should only be used when
>> (point-max) is the really the end of the buffer, since otherwise it's
>> not clear whether the overlays at (point-max) are inside or outside the
>> narrowing (and since it's not clear, it's better not to remove them).

> It would still be an ugly hack.  Future implementations of `overlays-in'
> should be allowed to check whether its arguments constitute valid buffer
> positions.

Yes.  (overlays-in (point-min) (point-max)) SHOULD
return all overlays if the buffer is widened.

Can someone try to fix it?


        Stefan

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

 > Yes.  (overlays-in (point-min) (point-max)) SHOULD
 > return all overlays if the buffer is widened.

I attached a patch.  If you want to apply it, the manual should be
modified accordingly.  Anyway, most calls of `remove-overlays' are a
pain.

[-- Attachment #2: buffer.patch --]
[-- Type: text/plain, Size: 3855 bytes --]

*** buffer.c.~1.551.~	Mon Feb 11 18:56:14 2008
--- buffer.c	Fri Mar 14 19:23:10 2008
***************
*** 1634,1640 ****
    Vbuffer_alist = link;
  
    /* Effectively do a delq on buried_buffer_list.  */
!   
    prev = Qnil;
    for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
         link = XCDR (link))
--- 1634,1640 ----
    Vbuffer_alist = link;
  
    /* Effectively do a delq on buried_buffer_list.  */
! 
    prev = Qnil;
    for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
         link = XCDR (link))
***************
*** 2715,2722 ****
    return idx;
  }
  \f
! /* Find all the overlays in the current buffer that overlap the range BEG-END
!    or are empty at BEG.
  
     Return the number found, and store them in a vector in *VEC_PTR.
     Store in *LEN_PTR the size allocated for the vector.
--- 2715,2723 ----
    return idx;
  }
  \f
! /* Find all the overlays in the current buffer that overlap the range
!    BEG-END, or are empty at BEG, or are empty at END and the buffer is
!    widened.
  
     Return the number found, and store them in a vector in *VEC_PTR.
     Store in *LEN_PTR the size allocated for the vector.
***************
*** 2751,2756 ****
--- 2752,2758 ----
    int next = ZV;
    int prev = BEGV;
    int inhibit_storing = 0;
+   int widened = ! NARROWED;
  
    for (tail = current_buffer->overlays_before; tail; tail = tail->next)
      {
***************
*** 2768,2777 ****
  	  break;
  	}
        startpos = OVERLAY_POSITION (ostart);
!       /* Count an interval if it either overlaps the range
! 	 or is empty at the start of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos && beg == endpos))
  	{
  	  if (idx == len)
  	    {
--- 2770,2781 ----
  	  break;
  	}
        startpos = OVERLAY_POSITION (ostart);
!       /* Count an interval if it overlaps the range, is empty at the
! 	 start of the range, or the buffer is widened and the overlay is
! 	 empty at the end of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos
! 	      && (beg == endpos || (widened && endpos == end))))
  	{
  	  if (idx == len)
  	    {
***************
*** 2816,2825 ****
  	  break;
  	}
        endpos = OVERLAY_POSITION (oend);
!       /* Count an interval if it either overlaps the range
! 	 or is empty at the start of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos && beg == endpos))
  	{
  	  if (idx == len)
  	    {
--- 2820,2831 ----
  	  break;
  	}
        endpos = OVERLAY_POSITION (oend);
!       /* Count an interval if it overlaps the range, is empty at the
! 	 start of the range, or the buffer is widened and the overlay is
! 	 empty at the end of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos
! 	      && (beg == endpos || (widened && endpos == end))))
  	{
  	  if (idx == len)
  	    {
***************
*** 4015,4022 ****
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
! Empty overlays are included in the result if they are located at BEG
! or between BEG and END.  */)
       (beg, end)
       Lisp_Object beg, end;
  {
--- 4021,4028 ----
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
! Empty overlays are included in the result if they are located at BEG,
! between BEG and END, or at END and the buffer is widened.  */)
       (beg, end)
       Lisp_Object beg, end;
  {

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

[Stefan Monnier]

>> Yes.  (overlays-in (point-min) (point-max)) SHOULD
>> return all overlays if the buffer is widened.

> I attached a patch.  If you want to apply it, the manual should be
> modified accordingly.

Looks good, except that it checks NARROWED, which depends on the
position of point-min whereas point-min should have no effect on the
behavior at `end'.  I.e. it should just check ZV == Z.
Please install it and adjust the manual.

> Anyway, most calls of `remove-overlays' are a pain.

I have no idea what that is supposed to mean.


        Stefan

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

 > Looks good, except that it checks NARROWED, which depends on the
 > position of point-min whereas point-min should have no effect on the
 > behavior at `end'.  I.e. it should just check ZV == Z.

I'm afraid there was a double misunderstanding.  Isn't what we really
want check "end == Z"?

[-- Attachment #2: buffer.patch --]
[-- Type: text/plain, Size: 3909 bytes --]

*** buffer.c.~1.551.~	Mon Feb 11 18:56:14 2008
--- buffer.c	Fri Mar 14 23:21:30 2008
***************
*** 1634,1640 ****
    Vbuffer_alist = link;
  
    /* Effectively do a delq on buried_buffer_list.  */
!   
    prev = Qnil;
    for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
         link = XCDR (link))
--- 1634,1640 ----
    Vbuffer_alist = link;
  
    /* Effectively do a delq on buried_buffer_list.  */
! 
    prev = Qnil;
    for (link = XFRAME (frame)->buried_buffer_list; CONSP (link);
         link = XCDR (link))
***************
*** 2715,2722 ****
    return idx;
  }
  \f
! /* Find all the overlays in the current buffer that overlap the range BEG-END
!    or are empty at BEG.
  
     Return the number found, and store them in a vector in *VEC_PTR.
     Store in *LEN_PTR the size allocated for the vector.
--- 2715,2723 ----
    return idx;
  }
  \f
! /* Find all the overlays in the current buffer that overlap the range
!    BEG-END, or are empty at BEG, or are empty at END provided END
!    denotes the position at the end of the current buffer.
  
     Return the number found, and store them in a vector in *VEC_PTR.
     Store in *LEN_PTR the size allocated for the vector.
***************
*** 2751,2756 ****
--- 2752,2758 ----
    int next = ZV;
    int prev = BEGV;
    int inhibit_storing = 0;
+   int end_is_Z = end == Z;
  
    for (tail = current_buffer->overlays_before; tail; tail = tail->next)
      {
***************
*** 2768,2777 ****
  	  break;
  	}
        startpos = OVERLAY_POSITION (ostart);
!       /* Count an interval if it either overlaps the range
! 	 or is empty at the start of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos && beg == endpos))
  	{
  	  if (idx == len)
  	    {
--- 2770,2781 ----
  	  break;
  	}
        startpos = OVERLAY_POSITION (ostart);
!       /* Count an interval if it overlaps the range, is empty at the
! 	 start of the range, or is empty at END provided END denotes the
! 	 end of the buffer.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos
! 	      && (beg == endpos || (end_is_Z && endpos == end))))
  	{
  	  if (idx == len)
  	    {
***************
*** 2816,2825 ****
  	  break;
  	}
        endpos = OVERLAY_POSITION (oend);
!       /* Count an interval if it either overlaps the range
! 	 or is empty at the start of the range.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos && beg == endpos))
  	{
  	  if (idx == len)
  	    {
--- 2820,2831 ----
  	  break;
  	}
        endpos = OVERLAY_POSITION (oend);
!       /* Count an interval if it overlaps the range, is empty at the
! 	 start of the range, or is empty at END provided END denotes the
! 	 end of the buffer.  */
        if ((beg < endpos && startpos < end)
! 	  || (startpos == endpos
! 	      && (beg == endpos || (end_is_Z && endpos == end))))
  	{
  	  if (idx == len)
  	    {
***************
*** 4015,4022 ****
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
! Empty overlays are included in the result if they are located at BEG
! or between BEG and END.  */)
       (beg, end)
       Lisp_Object beg, end;
  {
--- 4021,4029 ----
         doc: /* Return a list of the overlays that overlap the region BEG ... END.
  Overlap means that at least one character is contained within the overlay
  and also contained within the specified region.
! Empty overlays are included in the result if they are located at BEG,
! between BEG and END, or at END provided END denotes the position at the
! end of the buffer.  */)
       (beg, end)
       Lisp_Object beg, end;
  {

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

[Stefan Monnier]

>> Looks good, except that it checks NARROWED, which depends on the
>> position of point-min whereas point-min should have no effect on the
>> behavior at `end'.  I.e. it should just check ZV == Z.

> I'm afraid there was a double misunderstanding.  Isn't what we really
> want check "end == Z"?

Yes.


        Stefan

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

[martin rudalics]

 >>Anyway, most calls of `remove-overlays' are a pain.
 >
 > I have no idea what that is supposed to mean.

They're a pain because `remove-overlays' does (1) recenter all overlays,
(2) construct a list of all overlays in the region, (3) select the
overlays needed, and (4) delete them.  All this for the single purpose
that overlays overlapping BEG or END get split appropriately.

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

[Stefan Monnier]

>>> Anyway, most calls of `remove-overlays' are a pain.
>> I have no idea what that is supposed to mean.
> They're a pain because `remove-overlays' does (1) recenter all overlays,
> (2) construct a list of all overlays in the region, (3) select the
> overlays needed, and (4) delete them.  All this for the single purpose
> that overlays overlapping BEG or END get split appropriately.

You mean it's not as efficient as it could be?  Agreed.
It hasn't bit me yet, tho.  Do you have a use case where the speed is
a problem?


        Stefan

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

[martin rudalics]

 >>They're a pain because `remove-overlays' does (1) recenter all overlays,
 >>(2) construct a list of all overlays in the region, (3) select the
 >>overlays needed, and (4) delete them.  All this for the single purpose
 >>that overlays overlapping BEG or END get split appropriately.
 >
 >
 > You mean it's not as efficient as it could be?  Agreed.
 > It hasn't bit me yet, tho.  Do you have a use case where the speed is
 > a problem?

Removing the old whitespace overlays was devastatingly slow.  Richard
fixed it by putting an (overlay-recenter (point-max)) somewhere in the
code of whitespace.el before the call of `remove-overlays'.  But I still
don't understand why that fixed the problem and, for example, why the
argument `point-max' is any better than say `point-min'.  And the nxml
author wants to

** Explore whether overlay-recenter can cure overlays performance
problems.

Is there really anyone using `remove-overlays' who also wants its
feature that "Overlays might be moved and/or split."

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

[Stefan Monnier]

> Is there really anyone using `remove-overlays' who also wants its
> feature that "Overlays might be moved and/or split."

It's used by outline.el (it's where it comes from, as a matter of fact)
and IIRC I've changed a few other similar packages to use it rather than
roll their own.

Fundamentally, these packages don't care about overlays, they just want
to place properties, so they use overlays but would rather use
text-properties (except they need/want to know which properties are
theirs so they can safely remove them).


        Stefan

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

[Juri Linkov]

>> But it seems impossible to add an overlay *after* the cursor at the
>> end of the minibuffer, like `minibuffer-message' already does
>> inserting the message after the cursor at the end of the minibuffer.
>
> Try
>
>     (setq ov (make-overlay (point-max) (point-max)))
>     (overlay-put ov 'insert-in-front-hooks
>                  (list (lambda (o &rest ignore)
>                          (move-overlay o (point-max) (point-max)))))
>     (overlay-put ov 'after-string (concat (propertize " " 'cursor t)
>                                            "[No match]"))

This makes possible to create a function like below:

(defvar message-minibuffer-overlay)
(make-variable-buffer-local 'message-minibuffer-overlay)
(defun message-minibuffer (message)
  (when (overlayp message-minibuffer-overlay)
    (delete-overlay message-minibuffer-overlay))
  (setq message-minibuffer-overlay
        (make-overlay (point-max) (point-max) nil t t))
  (overlay-put message-minibuffer-overlay
               'after-string
               (concat (propertize " " 'cursor t)
                       (format "[%s]" message))))

But I observed that a static message at the end of the minibuffer
causes a false impression that the command that put this message is
not yet completed, thus inviting to wait until it goes out.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[TSUCHIYA Masatoshi]

Dear Emacs core developers,

>> On Thu, 06 Mar 2008 12:04:36 +0200
>> juri@jurta.org (Juri Linkov) said as follows:

>> This code is insufficient, because the output of `message' function
>> which is called from tab-completion functions will bury the current
>> completing status in minibuffer.

>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.

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.  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.

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.

(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)
			       1)))
		    (funcall orig-function
			     (if (>= w 0)
				 (concat s1 (make-string w ?\ ) s2)
			       s2))
		    (if (sit-for 0.3) (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 hope that you will try http://namazu.org/~tsuchiya/elisp/shell-command.el
before further discussion.

>> And more, the customize hook like `shell-command-complete-functions'
>> will be necessary, in order to enable users to customize tab-completion
>> functions.

>I agree that this user option `shell-command-complete-functions' is
>necessary for users to customize, and I think its default value should
>be the same as the default value of `shell-dynamic-complete-functions'.

>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.

I already signed a disclaimer for Gnus.  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?

Regards,

-- 
TSUCHIYA Masatoshi

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

[Juri Linkov]

>>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/

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

[TSUCHIYA Masatoshi]

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

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

[Drew Adams]

> But I still think my idea to use a minibuffer as two areas is 
> effective.

Forgive me for not having followed this thread and perhaps misunderstanding.

Dividing the minibuffer into sections would be, I think, a bad idea. The
minibuffer is used for so many different types of input. It can involve
multi-line input expressions that are quite long, in some cases. I cannot
imagine a useful partitioning of the space.

Similarly, I think that if we are looking for different output areas for
messages, status indicators, and such, it is better, instead of dividing the
echo area, to use other parts of the screen: mode line, "header" lines near
the echo area, temporary displays, pop-ups, tooltips, and so on.

In sum, I'd say let's leave the minibuffer and the echo area alone - they're
doing enough work already. ;-)

Wrt shell-command.el's insertion of the current directory into the prompt: I
can imagine that some users might like a reminder of the current directory
in the prompt, but many would not. Unless this displayed directory can
sometimes be different from `default-directory' for some reason. Is that the
case, or is it always just a reminder of `default-directory' (output of
`pwd')?

If it is just `default-directory', then this boils down to the preferences
that users have wrt their shell prompts. Some like to see the directory in
the prompt; others prefer to hit `pwd' when they want a reminder. I'm in the
latter camp (but I alias `.' to `pwd', so it's just one key to hit).

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

[Juri Linkov]

> 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/

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

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> 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.

Use the display margin :)

-- 
Johan Bockgård

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

[Lennart Borgman (gmail)]

Johan Bockgård wrote:
> Juri Linkov <juri@jurta.org> writes:
> 
>> 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.
> 
> Use the display margin :)

Or, if that is too small, use the prompt. A single persistent message 
could be added before the prompt (but technically be a part of the 
prompt during the display).

When discarding the message it could be added to the message buffer.

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

[Juri Linkov]

>>> 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.
>>
>> Use the display margin :)
>
> Or, if that is too small, use the prompt. A single persistent message
> could be added before the prompt (but technically be a part of the prompt
> during the display).
>
> When discarding the message it could be added to the message buffer.

This is like currently isearch in the minibuffer puts an overlay over
the prompt.  Maybe this could be used generally for other messages
in the minibuffer too.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[TSUCHIYA Masatoshi]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Dear Emacs developers,

>> On Mon, 10 Mar 2008 03:29:02 +0200
>> juri@jurta.org (Juri Linkov) said as follows:

>> 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.

Thanks.  This is my first time to notice `minibuffer-message' because
the first version of shell-command.el was created when I used Mule-2.3
based on Emacs-19.34.

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.

>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.

Persistently?  It may be quite difficult to realize, because
a completion function must know when it will disappear its temporal
message based on only user actions.

Regards,

-- 
TSUCHIYA Masatoshi

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: shell-command.diff --]
[-- Type: text/x-diff, Size: 10804 bytes --]

diff -ur emacs-22.1.orig/lisp/progmodes/compile.el emacs-22.1/lisp/progmodes/compile.el
--- emacs-22.1.orig/lisp/progmodes/compile.el	2007-05-25 21:43:33.000000000 +0900
+++ emacs-22.1/lisp/progmodes/compile.el	2008-03-12 10:18:31.641415258 +0900
@@ -490,6 +490,14 @@
 ;;;###autoload(put 'compile-command 'safe-local-variable 'stringp)
 
 ;;;###autoload
+(defcustom compile-prompt "Compile command: "
+  "*Prompt string of `compile' when tab-completion is enabled.
+Some %-sequences are available to customize this variable.  For more
+detail, see the document of `make-shell-prompt-string'."
+  :type 'string
+  :group 'compilation)
+
+;;;###autoload
 (defcustom compilation-disable-input nil
   "*If non-nil, send end-of-file as compilation process input.
 This only affects platforms that support asynchronous processes (see
@@ -901,11 +909,11 @@
    (list
     (let ((command (eval compile-command)))
       (if (or compilation-read-command current-prefix-arg)
-	  (read-from-minibuffer "Compile command: "
-				command nil nil
-				(if (equal (car compile-history) command)
-				    '(compile-history . 1)
-				  'compile-history))
+	  (read-shell-commmand (make-shell-prompt-string compile-prompt)
+			       command nil nil
+			       (if (equal (car compile-history) command)
+				   '(compile-history . 1)
+				 'compile-history))
 	command))
     (consp current-prefix-arg)))
   (unless (equal command (eval compile-command))
diff -ur emacs-22.1.orig/lisp/progmodes/grep.el emacs-22.1/lisp/progmodes/grep.el
--- emacs-22.1.orig/lisp/progmodes/grep.el	2007-04-08 11:08:48.000000000 +0900
+++ emacs-22.1/lisp/progmodes/grep.el	2008-03-12 10:16:13.785931321 +0900
@@ -91,6 +91,14 @@
 		 (const :tag "Not Set" nil))
   :group 'grep)
 
+;;;###autoload
+(defcustom grep-prompt "Run grep (like this): "
+  "*Prompt string of `grep' when tab-completion is enabled.
+Some %-sequences are available to customize this variable.  For more
+detail, see the document of `make-shell-prompt-string'."
+  :type 'string
+  :group 'grep)
+
 (defcustom grep-template nil
   "The default command to run for \\[lgrep].
 The default value of this variable is set up by `grep-compute-defaults';
@@ -127,6 +135,14 @@
 		 (const :tag "Not Set" nil))
   :group 'grep)
 
+;;;###autoload
+(defcustom grep-find-prompt "Run find (like this): "
+  "*Prompt string of `grep-find' when tab-completion is enabled.
+Some %-sequences are available to customize this variable.  For more
+detail, see the document of `make-shell-prompt-string'."
+  :type 'string
+  :group 'grep)
+
 (defcustom grep-find-template nil
   "The default command to run for \\[rgrep].
 The default value of this variable is set up by `grep-compute-defaults';
@@ -538,11 +554,11 @@
    (progn
      (grep-compute-defaults)
      (let ((default (grep-default-command)))
-       (list (read-from-minibuffer "Run grep (like this): "
-				   (if current-prefix-arg
-				       default grep-command)
-				   nil nil 'grep-history
-				   (if current-prefix-arg nil default))))))
+       (list (read-shell-commmand (make-shell-prompt-string grep-prompt)
+				  (if current-prefix-arg
+				      default grep-command)
+				  nil nil 'grep-history
+				  (if current-prefix-arg nil default))))))
 
   ;; Setting process-setup-function makes exit-message-function work
   ;; even when async processes aren't supported.
@@ -565,9 +581,9 @@
    (progn
      (grep-compute-defaults)
      (if grep-find-command
-	 (list (read-from-minibuffer "Run find (like this): "
-				     grep-find-command nil nil
-                                     'grep-find-history))
+	 (list (read-shell-commmand (make-shell-prompt-string grep-find-prompt)
+				    grep-find-command nil nil
+				    'grep-find-history))
        ;; No default was set
        (read-string
         "compile.el: No `grep-find-command' command available. Press RET.")
diff -ur emacs-22.1.orig/lisp/simple.el emacs-22.1/lisp/simple.el
--- emacs-22.1.orig/lisp/simple.el	2007-05-27 23:35:51.000000000 +0900
+++ emacs-22.1/lisp/simple.el	2008-03-12 10:22:27.999957912 +0900
@@ -1758,6 +1758,48 @@
 is run interactively.  A value of nil means that output to stderr and
 stdout will be intermixed in the output stream.")
 
+(defcustom shell-command-complete-functions
+  '(shell-dynamic-complete-environment-variable
+    shell-dynamic-complete-command
+    shell-replace-by-expanded-directory
+    comint-dynamic-complete-filename)
+  "*Function list to complete shell commands."
+  :type 'hook
+  :group 'shell)
+
+(defun read-shell-commmand (prompt &optional initial-contents keymap read
+				   hist default-value inherit-input-method)
+  "Read a command string in the minibuffer, with completion
+specified by `shell-command-complete-functions'."
+  (let ((new-keymap (make-sparse-keymap)))
+    (set-keymap-parent new-keymap (or keymap minibuffer-local-map))
+    (define-key new-keymap "\t"
+      (lambda ()
+	(interactive)
+	(let ((orig-function (symbol-function 'message)))
+	  (unwind-protect
+	      (progn
+		(defun message (string &rest arguments)
+		  (let ((minibuffer-message-timeout 2)
+			(s (apply (function format) string arguments)))
+		    (minibuffer-message (concat " [" s "]"))
+		    s))
+		(require 'shell)
+		(require 'comint)
+		(run-hook-with-args-until-success
+		 'shell-command-complete-functions))
+	    (fset 'message orig-function)))))
+    (read-from-minibuffer prompt initial-contents new-keymap read
+			  hist default-value inherit-input-method)))
+
+(defcustom shell-command-prompt
+  "Shell command: "
+  "*The prompt string for `shell-command' when tab-completion is enabled.
+Some %-sequences are available to customize this variable.  For more
+detail, see the document of `make-shell-prompt-string'."
+  :type 'string
+  :group 'shell)
+
 (defun shell-command (command &optional output-buffer error-buffer)
   "Execute string COMMAND in inferior shell; display output, if any.
 With prefix argument, insert the COMMAND's output at point.
@@ -1808,10 +1850,12 @@
 In an interactive call, the variable `shell-command-default-error-buffer'
 specifies the value of ERROR-BUFFER."
 
-  (interactive (list (read-from-minibuffer "Shell command: "
-					   nil nil nil 'shell-command-history)
-		     current-prefix-arg
-		     shell-command-default-error-buffer))
+  (interactive
+   (list (read-shell-commmand (make-shell-prompt-string shell-command-prompt
+							current-directory)
+			      nil nil nil 'shell-command-history)
+	 current-prefix-arg
+	 shell-command-default-error-buffer))
   ;; Look for a handler in case default-directory is a remote file name.
   (let ((handler
 	 (find-file-name-handler (directory-file-name default-directory)
@@ -1892,6 +1936,80 @@
 	    (shell-command-on-region (point) (point) command
 				     output-buffer nil error-buffer)))))))
 
+(defun make-shell-prompt-string (format-string &optional current-directory)
+  "Function to generate prompt string like shell
+
+Use FORMAT-STRING to generate prompt string at the directory
+CURRENT-DIRECTORY.  The following `%' escapes are available for use in
+FORMAT-STRING:
+
+%d     the date in \"Weekday Month Date\" format \(e.g., \"Tue May 26\"\)
+%h     the hostname up to the first `.'
+%H     the hostname
+%t     the current time in 24-hour HH:MM:SS format
+%T     the current time in 12-hour HH:MM:SS format
+%@     the current time in 12-hour am/pm format
+%u     the username of the current user
+%w     the current working directory
+%W     the basename of the current working directory
+%$     if the effective UID is 0, a #, otherwise a $
+%%     Insert a literal `%'.
+"
+  (unless current-directory
+    (setq current-directory default-directory))
+  (let ((case-fold-search nil)
+	start buf
+	(list (list format-string))
+	(alist (let ((system-name (system-name))
+		     host-name
+		     fqdn-name
+		     (time (current-time))
+		     (dir (directory-file-name
+			   (abbreviate-file-name current-directory))))
+		 (if (string-match "^\\([^.]+\\)\\.[^.]" system-name)
+		     (setq fqdn-name system-name
+			   host-name (match-string 1 system-name))
+		   (setq host-name system-name
+			 fqdn-name
+			 (cond
+			  ((and (boundp 'mail-host-address)
+				(stringp mail-host-address)
+				(string-match "\\." mail-host-address))
+			   mail-host-address)
+			  ((and user-mail-address
+				(string-match "\\." user-mail-address)
+				(string-match "@\\(.*\\)\\'"
+					      user-mail-address))
+			   (match-string 1 user-mail-address))
+			  (t system-name))))
+		 `(("%%" . "%")
+		   ("%d" . ,(format-time-string "%a %b %e" time))
+		   ("%h" . ,host-name)
+		   ("%H" . ,fqdn-name)
+		   ("%t" . ,(format-time-string "%H:%M:%S" time))
+		   ("%T" . ,(format-time-string "%I:%M:%S" time))
+		   ("%@" . ,(format-time-string "%I:%M%p" time))
+		   ("%u" . ,(user-login-name))
+		   ("%w" . ,dir)
+		   ("%W" . ,(file-name-nondirectory
+			     (directory-file-name current-directory)))
+		   ("%\\$" . ,(if (= (user-uid) 0) "#" "$"))))))
+    (while alist
+      (setq buf nil)
+      (while list
+	(setq start 0)
+	(while (string-match (car (car alist)) (car list) start)
+	  (setq buf (cons (cdr (car alist))
+			  (cons (substring (car list) start
+					   (match-beginning 0))
+				buf))
+		start (match-end 0)))
+	(setq buf (cons (substring (car list) start) buf)
+	      list (cdr list)))
+      (setq list (nreverse buf)
+	    alist (cdr alist)))
+    (apply 'concat list)))
+
 (defun display-message-or-buffer (message
 				  &optional buffer-name not-this-window frame)
   "Display MESSAGE in the echo area if possible, otherwise in a pop-up buffer.
@@ -1969,6 +2087,14 @@
 	       (car (cdr (cdr (process-command process))))
 	       (substring signal 0 -1))))
 
+(defcustom shell-command-on-region-prompt
+  "Shell command on region: "
+  "*Prompt string of `shell-command-on-region' when tab-completion is enabled.
+Some %-sequences are available to customize this variable.  For more
+detail, see the document of `make-shell-prompt-string'."
+  :type 'string
+  :group 'shell)
+
 (defun shell-command-on-region (start end command
 				      &optional output-buffer replace
 				      error-buffer display-error-buffer)
@@ -2027,9 +2153,11 @@
 		 ;; Do this before calling region-beginning
 		 ;; and region-end, in case subprocess output
 		 ;; relocates them while we are in the minibuffer.
-		 (setq string (read-from-minibuffer "Shell command on region: "
-						    nil nil nil
-						    'shell-command-history))
+		 (setq string
+		       (read-shell-commmand (make-shell-prompt-string
+					     shell-command-on-region-prompt)
+					    nil nil nil
+					    'shell-command-history))
 		 ;; call-interactively recognizes region-beginning and
 		 ;; region-end specially, leaving them in the history.
 		 (list (region-beginning) (region-end)

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

[Stefan Monnier]

> 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

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

[Juri Linkov]

>>> 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).

Yes, this message is not important, and currently when command's
completion is called not in the minibuffer, the user can't see it anyway,
because it is momentarily displayed and immediately becomes overwritten
by another message "Type space to flush; repeat completion command to
scroll".  So we can remove it from displaying in the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[TSUCHIYA Masatoshi]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Dear Emacs developers,

>> On Tue, 11 Mar 2008 22:12:01 -0400
>> monnier@iro.umontreal.ca (Stefan Monnier) said as follows:

>> I have just prepared the minimized patch to support tab-completion
>> features for `shell-command' etc.

>Could you provide a new version of your patch without the
>make-shell-prompt-string?

Thanks for your comments.  I have just prepared the re-minimized version
and attach it at the end of this message.  I believe that this patch
meets all of your comments.

Regards,

-- 
TSUCHIYA Masatoshi

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: completion.diff --]
[-- Type: text/x-diff, Size: 4267 bytes --]

diff -ur emacs-22.1.orig/lisp/progmodes/compile.el emacs-22.1/lisp/progmodes/compile.el
--- emacs-22.1.orig/lisp/progmodes/compile.el	2007-05-25 21:43:33.000000000 +0900
+++ emacs-22.1/lisp/progmodes/compile.el	2008-03-15 17:18:37.000000000 +0900
@@ -902,7 +902,9 @@
     (let ((command (eval compile-command)))
       (if (or compilation-read-command current-prefix-arg)
 	  (read-from-minibuffer "Compile command: "
-				command nil nil
+				command
+				minibuffer-complete-shell-command-map
+				nil
 				(if (equal (car compile-history) command)
 				    '(compile-history . 1)
 				  'compile-history))
diff -ur emacs-22.1.orig/lisp/progmodes/grep.el emacs-22.1/lisp/progmodes/grep.el
--- emacs-22.1.orig/lisp/progmodes/grep.el	2007-04-08 11:08:48.000000000 +0900
+++ emacs-22.1/lisp/progmodes/grep.el	2008-03-15 17:19:44.000000000 +0900
@@ -541,7 +541,8 @@
        (list (read-from-minibuffer "Run grep (like this): "
 				   (if current-prefix-arg
 				       default grep-command)
-				   nil nil 'grep-history
+				   minibuffer-complete-shell-command-map
+				   nil 'grep-history
 				   (if current-prefix-arg nil default))))))
 
   ;; Setting process-setup-function makes exit-message-function work
@@ -566,7 +567,9 @@
      (grep-compute-defaults)
      (if grep-find-command
 	 (list (read-from-minibuffer "Run find (like this): "
-				     grep-find-command nil nil
+				     grep-find-command
+				     minibuffer-complete-shell-command-map
+				     nil
                                      'grep-find-history))
        ;; No default was set
        (read-string
diff -ur emacs-22.1.orig/lisp/simple.el emacs-22.1/lisp/simple.el
--- emacs-22.1.orig/lisp/simple.el	2007-05-27 23:35:51.000000000 +0900
+++ emacs-22.1/lisp/simple.el	2008-03-15 17:25:40.000000000 +0900
@@ -1367,6 +1367,42 @@
   ;; Return the width of everything before the field at the end of
   ;; the buffer; this should be 0 for normal buffers.
   (1- (minibuffer-prompt-end)))
+
+(defcustom minibuffer-complete-shell-command-functions
+  '(shell-dynamic-complete-environment-variable
+    shell-dynamic-complete-command
+    shell-replace-by-expanded-directory
+    comint-dynamic-complete-filename)
+  "*Function list to complete shell commands."
+  :type 'hook
+  :group 'shell)
+
+(defun minibuffer-completing-message (string &rest arguments)
+  "Alternative function of `message' when completing shell command."
+  (let ((s (apply (function format) string arguments)))
+    (minibuffer-message (concat " [" s "]"))
+    s))
+
+(defun minibuffer-complete-shell-command ()
+  "Dynamically complete shell command at point with functions
+specified in `minibuffer-complete-shell-command-functions'."
+  (interactive)
+  (let ((orig-function (symbol-function 'message)))
+    (unwind-protect
+	(progn
+	  (fset 'message 'minibuffer-completing-message)
+	  (require 'shell)
+	  (require 'comint)
+	  (run-hook-with-args-until-success
+	   'minibuffer-complete-shell-command-functions))
+      (fset 'message orig-function))))
+
+(defvar minibuffer-complete-shell-command-map
+  (let ((map (make-sparse-keymap)))
+    (set-keymap-parent map minibuffer-local-map)
+    (define-key map "\t" 'minibuffer-complete-shell-command)
+    map)
+  "Keymap used for completiing shell commands in minibufffer.")
 \f
 ;Put this on C-x u, so we can force that rather than C-_ into startup msg
 (defalias 'advertised-undo 'undo)
@@ -1809,7 +1845,10 @@
 specifies the value of ERROR-BUFFER."
 
   (interactive (list (read-from-minibuffer "Shell command: "
-					   nil nil nil 'shell-command-history)
+					   nil
+					   minibuffer-complete-shell-command-map
+					   nil
+					   'shell-command-history)
 		     current-prefix-arg
 		     shell-command-default-error-buffer))
   ;; Look for a handler in case default-directory is a remote file name.
@@ -2028,7 +2067,9 @@
 		 ;; and region-end, in case subprocess output
 		 ;; relocates them while we are in the minibuffer.
 		 (setq string (read-from-minibuffer "Shell command on region: "
-						    nil nil nil
+						    nil
+						    minibuffer-complete-shell-command-map
+						    nil
 						    'shell-command-history))
 		 ;; call-interactively recognizes region-beginning and
 		 ;; region-end specially, leaving them in the history.

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

[paul r]

> Thanks for your comments.  I have just prepared the re-minimized version
>  and attach it at the end of this message.  I believe that this patch
>  meets all of your comments.

Thank you for your effort Masatoshi

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

[Juri Linkov]

>>> I have just prepared the minimized patch to support tab-completion
>>> features for `shell-command' etc.
>
>>Could you provide a new version of your patch without the
>>make-shell-prompt-string?
>
> Thanks for your comments.  I have just prepared the re-minimized version
> and attach it at the end of this message.  I believe that this patch
> meets all of your comments.

Thanks for your patch.  It seems everything is correct in your patch,
except the unresolved general problem of displaying completion messages
in the minibuffer.  Currently typing TAB displays the message
"[Completing command name...]" and waits 2 sec before displaying the
*Completions* buffer.  Until this problem is solved, minibuffer messages
cause delays that make this feature almost unusable.

But I noticed that this problem is already solved in comint.el for file
name completions.  In `comint-dynamic-complete-as-filename', completion
messages are displayed only when not in the minibuffer, except the error
message "No completions" that is important to display in the minibuffer.
Also it displays "Completing file name..." conditionally outside of
the minibuffer.

I assure this really works well because these messages are not very
important to display in the minibuffer, and the status of completion is
evident from the completions list and the content of the minibuffer
(e.g. partial completion doesn't insert a space after completion,
but complete completion inserts it, etc.)

So until a general way to display messages without a delay in the
minibuffer is found, I propose to use exactly the same solution already
implemented in `comint-dynamic-complete-as-filename' to display messages
conditionally in `comint-dynamic-simple-complete' too (plus one message
in shell.el).

Also using `minibuffer-message' to display two remaining messages
("No completions of ..." and "Type space to flush ...") makes
unneccessary a trick in your patch that redefines the `message' function.

I suggest to install the following patch, and after that to install
your patch with removing now unneccessary `minibuffer-completing-message'
and removing `fset' code in `minibuffer-complete-shell-command'.

Index: lisp/comint.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/comint.el,v
retrieving revision 1.375
diff -c -r1.375 comint.el
*** lisp/comint.el	12 Mar 2008 17:56:57 -0000	1.375
--- lisp/comint.el	15 Mar 2008 21:35:00 -0000
***************
*** 2871,2877 ****
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completion (file-name-completion filenondir directory)))
      (cond ((null completion)
! 	   (message "No completions of %s" filename)
  	   (setq success nil))
  	  ((eq completion t)            ; Means already completed "file".
  	   (insert filesuffix)
--- 2871,2879 ----
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completion (file-name-completion filenondir directory)))
      (cond ((null completion)
! 	   (if minibuffer-p
! 	       (minibuffer-message (format " [No completions of %s]" filename))
! 	     (message "No completions of %s" filename))
  	   (setq success nil))
  	  ((eq completion t)            ; Means already completed "file".
  	   (insert filesuffix)
***************
*** 2935,2953 ****
  
  See also `comint-dynamic-complete-filename'."
    (let* ((completion-ignore-case (memq system-type '(ms-dos windows-nt cygwin)))
  	 (suffix (cond ((not comint-completion-addsuffix) "")
  		       ((not (consp comint-completion-addsuffix)) " ")
  		       (t (cdr comint-completion-addsuffix))))
  	 (completions (all-completions stub candidates)))
      (cond ((null completions)
! 	   (message "No completions of %s" stub)
  	   nil)
  	  ((= 1 (length completions))	; Gotcha!
  	   (let ((completion (car completions)))
  	     (if (string-equal completion stub)
! 		 (message "Sole completion")
  	       (insert (substring completion (length stub)))
! 	       (message "Completed"))
  	     (insert suffix)
  	     'sole))
  	  (t				; There's no unique completion.
--- 2937,2960 ----
  
  See also `comint-dynamic-complete-filename'."
    (let* ((completion-ignore-case (memq system-type '(ms-dos windows-nt cygwin)))
+ 	 (minibuffer-p (window-minibuffer-p (selected-window)))
  	 (suffix (cond ((not comint-completion-addsuffix) "")
  		       ((not (consp comint-completion-addsuffix)) " ")
  		       (t (cdr comint-completion-addsuffix))))
  	 (completions (all-completions stub candidates)))
      (cond ((null completions)
! 	   (if minibuffer-p
! 	       (minibuffer-message (format " [No completions of %s]" stub))
! 	     (message "No completions of %s" stub))
  	   nil)
  	  ((= 1 (length completions))	; Gotcha!
  	   (let ((completion (car completions)))
  	     (if (string-equal completion stub)
! 		 (unless minibuffer-p
! 		   (message "Sole completion"))
  	       (insert (substring completion (length stub)))
! 	       (unless minibuffer-p
! 		 (message "Completed")))
  	     (insert suffix)
  	     'sole))
  	  (t				; There's no unique completion.
***************
*** 2959,2965 ****
  			 (member completion completions))
  		    ;; It's not unique, but user wants shortest match.
  		    (insert suffix)
! 		    (message "Completed shortest")
  		    'shortest)
  		   ((or comint-completion-autolist
  			(string-equal stub completion))
--- 2966,2973 ----
  			 (member completion completions))
  		    ;; It's not unique, but user wants shortest match.
  		    (insert suffix)
! 		    (unless minibuffer-p
! 		      (message "Completed shortest"))
  		    'shortest)
  		   ((or comint-completion-autolist
  			(string-equal stub completion))
***************
*** 2967,2973 ****
  		    (comint-dynamic-list-completions completions)
  		    'listed)
  		   (t
! 		    (message "Partially completed")
  		    'partial)))))))
  
  
--- 2975,2982 ----
  		    (comint-dynamic-list-completions completions)
  		    'listed)
  		   (t
! 		    (unless minibuffer-p
! 		      (message "Partially completed"))
  		    'partial)))))))
  
  
***************
*** 2985,2991 ****
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completions (file-name-all-completions filenondir directory)))
      (if (not completions)
! 	(message "No completions of %s" filename)
        (comint-dynamic-list-completions
         (mapcar 'comint-quote-filename completions)))))
  
--- 2994,3002 ----
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completions (file-name-all-completions filenondir directory)))
      (if (not completions)
! 	(if (window-minibuffer-p (selected-window))
! 	    (minibuffer-message (format " [No completions of %s]" filename))
! 	  (message "No completions of %s" filename))
        (comint-dynamic-list-completions
         (mapcar 'comint-quote-filename completions)))))
  
***************
*** 3031,3037 ****
  	    (current-window-configuration))
        (with-output-to-temp-buffer "*Completions*"
  	(display-completion-list completions))
!       (message "Type space to flush; repeat completion command to scroll"))
  
      ;; Read the next key, to process SPC.
      (let (key first)
--- 3042,3050 ----
  	    (current-window-configuration))
        (with-output-to-temp-buffer "*Completions*"
  	(display-completion-list completions))
!       (if (window-minibuffer-p (selected-window))
! 	  (minibuffer-message " [Type space to flush; repeat completion command to scroll]")
! 	(message "Type space to flush; repeat completion command to scroll")))
  
      ;; Read the next key, to process SPC.
      (let (key first)

Index: lisp/shell.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/shell.el,v
retrieving revision 1.158
diff -c -r1.158 shell.el
*** lisp/shell.el	8 Jan 2008 20:44:52 -0000	1.158
--- lisp/shell.el	15 Mar 2008 21:34:35 -0000
***************
*** 965,971 ****
  	     (save-match-data (not (string-match "[~/]" filename)))
  	     (eq (match-beginning 0)
  		 (save-excursion (shell-backward-command 1) (point))))
! 	(prog2 (message "Completing command name...")
  	    (shell-dynamic-complete-as-command)))))
  
  
--- 965,972 ----
  	     (save-match-data (not (string-match "[~/]" filename)))
  	     (eq (match-beginning 0)
  		 (save-excursion (shell-backward-command 1) (point))))
! 	(prog2 (unless (window-minibuffer-p (selected-window))
! 		 (message "Completing command name..."))
  	    (shell-dynamic-complete-as-command)))))
  
  
***************
*** 1040,1046 ****
    (interactive)
    (let ((variable (shell-match-partial-variable)))
      (if (and variable (string-match "^\\$" variable))
! 	(prog2 (message "Completing variable name...")
  	    (shell-dynamic-complete-as-environment-variable)))))
  
  
--- 1041,1048 ----
    (interactive)
    (let ((variable (shell-match-partial-variable)))
      (if (and variable (string-match "^\\$" variable))
! 	(prog2 (unless (window-minibuffer-p (selected-window))
! 		 (message "Completing variable name..."))
  	    (shell-dynamic-complete-as-environment-variable)))))
  
  

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

> Thanks for your comments.  I have just prepared the re-minimized version
> and attach it at the end of this message.  I believe that this patch
> meets all of your comments.

Thanks.  I've installed a slightly different version.
Now we need to fix the minibuffer messages (and use read-shell-command
wherever it can be used).


        Stefan

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

[Juri Linkov]

>> Thanks for your comments.  I have just prepared the re-minimized version
>> and attach it at the end of this message.  I believe that this patch
>> meets all of your comments.
>
> Thanks.  I've installed a slightly different version.
> Now we need to fix the minibuffer messages (and use read-shell-command
> wherever it can be used).

The following patch fixes the minibuffer messages.  I tried it for a week,
and it works really well.  There is no need to display most of the
completion messages (except "No completions") in the minibuffer
because it is self-evident what completion does from its result
(this is like completion in shells that doesn't display special
messages but it is clear what it does without messages).

This patch also fixes incorrect highlighting of the common completion
substring by adding a new optional argument `common-substring' to
`comint-dynamic-list-completions':

Index: lisp/comint.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/comint.el,v
retrieving revision 1.375
diff -c -r1.375 comint.el
*** lisp/comint.el	12 Mar 2008 17:56:57 -0000	1.375
--- lisp/comint.el	20 Mar 2008 20:52:54 -0000
***************
*** 2871,2877 ****
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completion (file-name-completion filenondir directory)))
      (cond ((null completion)
! 	   (message "No completions of %s" filename)
  	   (setq success nil))
  	  ((eq completion t)            ; Means already completed "file".
  	   (insert filesuffix)
--- 2871,2879 ----
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completion (file-name-completion filenondir directory)))
      (cond ((null completion)
! 	   (if minibuffer-p
! 	       (minibuffer-message (format " [No completions of %s]" filename))
! 	     (message "No completions of %s" filename))
  	   (setq success nil))
  	  ((eq completion t)            ; Means already completed "file".
  	   (insert filesuffix)
***************
*** 2935,2953 ****
  
  See also `comint-dynamic-complete-filename'."
    (let* ((completion-ignore-case (memq system-type '(ms-dos windows-nt cygwin)))
  	 (suffix (cond ((not comint-completion-addsuffix) "")
  		       ((not (consp comint-completion-addsuffix)) " ")
  		       (t (cdr comint-completion-addsuffix))))
  	 (completions (all-completions stub candidates)))
      (cond ((null completions)
! 	   (message "No completions of %s" stub)
  	   nil)
  	  ((= 1 (length completions))	; Gotcha!
  	   (let ((completion (car completions)))
  	     (if (string-equal completion stub)
! 		 (message "Sole completion")
  	       (insert (substring completion (length stub)))
! 	       (message "Completed"))
  	     (insert suffix)
  	     'sole))
  	  (t				; There's no unique completion.
--- 2937,2960 ----
  
  See also `comint-dynamic-complete-filename'."
    (let* ((completion-ignore-case (memq system-type '(ms-dos windows-nt cygwin)))
+ 	 (minibuffer-p (window-minibuffer-p (selected-window)))
  	 (suffix (cond ((not comint-completion-addsuffix) "")
  		       ((not (consp comint-completion-addsuffix)) " ")
  		       (t (cdr comint-completion-addsuffix))))
  	 (completions (all-completions stub candidates)))
      (cond ((null completions)
! 	   (if minibuffer-p
! 	       (minibuffer-message (format " [No completions of %s]" stub))
! 	     (message "No completions of %s" stub))
  	   nil)
  	  ((= 1 (length completions))	; Gotcha!
  	   (let ((completion (car completions)))
  	     (if (string-equal completion stub)
! 		 (unless minibuffer-p
! 		   (message "Sole completion"))
  	       (insert (substring completion (length stub)))
! 	       (unless minibuffer-p
! 		 (message "Completed")))
  	     (insert suffix)
  	     'sole))
  	  (t				; There's no unique completion.
***************
*** 2959,2973 ****
  			 (member completion completions))
  		    ;; It's not unique, but user wants shortest match.
  		    (insert suffix)
! 		    (message "Completed shortest")
  		    'shortest)
  		   ((or comint-completion-autolist
  			(string-equal stub completion))
  		    ;; It's not unique, list possible completions.
! 		    (comint-dynamic-list-completions completions)
  		    'listed)
  		   (t
! 		    (message "Partially completed")
  		    'partial)))))))
  
  
--- 2966,2982 ----
  			 (member completion completions))
  		    ;; It's not unique, but user wants shortest match.
  		    (insert suffix)
! 		    (unless minibuffer-p
! 		      (message "Completed shortest"))
  		    'shortest)
  		   ((or comint-completion-autolist
  			(string-equal stub completion))
  		    ;; It's not unique, list possible completions.
! 		    (comint-dynamic-list-completions completions stub)
  		    'listed)
  		   (t
! 		    (unless minibuffer-p
! 		      (message "Partially completed"))
  		    'partial)))))))
  
  
***************
*** 2985,2993 ****
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completions (file-name-all-completions filenondir directory)))
      (if (not completions)
! 	(message "No completions of %s" filename)
        (comint-dynamic-list-completions
!        (mapcar 'comint-quote-filename completions)))))
  
  
  ;; This is bound locally in a *Completions* buffer to the list of
--- 2994,3005 ----
  	 (directory (if filedir (comint-directory filedir) default-directory))
  	 (completions (file-name-all-completions filenondir directory)))
      (if (not completions)
! 	(if (window-minibuffer-p (selected-window))
! 	    (minibuffer-message (format " [No completions of %s]" filename))
! 	  (message "No completions of %s" filename))
        (comint-dynamic-list-completions
!        (mapcar 'comint-quote-filename completions)
!        filenondir))))
  
  
  ;; This is bound locally in a *Completions* buffer to the list of
***************
*** 2997,3003 ****
  
  (defvar comint-dynamic-list-completions-config nil)
  
! (defun comint-dynamic-list-completions (completions)
    "List in help buffer sorted COMPLETIONS.
  Typing SPC flushes the help buffer."
    (let ((window (get-buffer-window "*Completions*" 0)))
--- 3009,3015 ----
  
  (defvar comint-dynamic-list-completions-config nil)
  
! (defun comint-dynamic-list-completions (completions &optional common-substring)
    "List in help buffer sorted COMPLETIONS.
  Typing SPC flushes the help buffer."
    (let ((window (get-buffer-window "*Completions*" 0)))
***************
*** 3030,3037 ****
        (setq comint-dynamic-list-completions-config
  	    (current-window-configuration))
        (with-output-to-temp-buffer "*Completions*"
! 	(display-completion-list completions))
!       (message "Type space to flush; repeat completion command to scroll"))
  
      ;; Read the next key, to process SPC.
      (let (key first)
--- 3042,3051 ----
        (setq comint-dynamic-list-completions-config
  	    (current-window-configuration))
        (with-output-to-temp-buffer "*Completions*"
! 	(display-completion-list completions common-substring))
!       (if (window-minibuffer-p (selected-window))
! 	  (minibuffer-message " [Type space to flush; repeat completion command to scroll]")
! 	(message "Type space to flush; repeat completion command to scroll")))
  
      ;; Read the next key, to process SPC.
      (let (key first)

Index: lisp/shell.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/shell.el,v
retrieving revision 1.158
diff -c -r1.158 shell.el
*** lisp/shell.el	8 Jan 2008 20:44:52 -0000	1.158
--- lisp/shell.el	20 Mar 2008 20:54:09 -0000
***************
*** 965,971 ****
  	     (save-match-data (not (string-match "[~/]" filename)))
  	     (eq (match-beginning 0)
  		 (save-excursion (shell-backward-command 1) (point))))
! 	(prog2 (message "Completing command name...")
  	    (shell-dynamic-complete-as-command)))))
  
  
--- 965,972 ----
  	     (save-match-data (not (string-match "[~/]" filename)))
  	     (eq (match-beginning 0)
  		 (save-excursion (shell-backward-command 1) (point))))
! 	(prog2 (unless (window-minibuffer-p (selected-window))
! 		 (message "Completing command name..."))
  	    (shell-dynamic-complete-as-command)))))
  
  
***************
*** 1040,1046 ****
    (interactive)
    (let ((variable (shell-match-partial-variable)))
      (if (and variable (string-match "^\\$" variable))
! 	(prog2 (message "Completing variable name...")
  	    (shell-dynamic-complete-as-environment-variable)))))
  
  
--- 1041,1048 ----
    (interactive)
    (let ((variable (shell-match-partial-variable)))
      (if (and variable (string-match "^\\$" variable))
! 	(prog2 (unless (window-minibuffer-p (selected-window))
! 		 (message "Completing variable name..."))
  	    (shell-dynamic-complete-as-environment-variable)))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

> The following patch fixes the minibuffer messages.  I tried it for a week,
> and it works really well.  There is no need to display most of the
> completion messages (except "No completions") in the minibuffer
> because it is self-evident what completion does from its result
> (this is like completion in shells that doesn't display special
> messages but it is clear what it does without messages).

Feel free to install it.


        Stefan