Proposal for shell completion in M-x shell RET

Proposal for shell completion in M-x shell RET

[David Kastrup]

Hi,

it turns out that when using bash's programmable completion, the
results are typically much better than Emacs' completion.  Since it is
unfeasible to mimic or interpret the wealth of shell-completion
scripts in Emacs, I would propose making it configurable to use the
shell completion instead.

The way this would work would be when TAB is pressed to send the
partial line up to the cursor as input to the shell, followed by TAB,
then capture the output from bash and interpret it (either inserting
completed output, or offering a completion menu).  When committing a
line (or pressing TAB), when the partial line already submitted does
not correspond with the one in the shell command line, the line is
erased and committed fresh, otherwise only the rest of the line is
submitted.

This approach would have the advantage of leaving no trace of the
completion in the shell history unless a command is actually sent to
the shell.

It should also work with other shells.

-- 
David Kastrup

Re: Proposal for shell completion in M-x shell RET

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> The way this would work would be when TAB is pressed to send the
> partial line up to the cursor as input to the shell, followed by TAB,
> then capture the output from bash and interpret it (either inserting
> completed output, or offering a completion menu).

Command line editing is disabled in the inferior shell.  If you want to
enable it you'll have to make sure all literal control characters are
preceded by the quote character before sending the line to the shell.
You'll also have to enable echoing to be able to capture anything.

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: Proposal for shell completion in M-x shell RET

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The way this would work would be when TAB is pressed to send the
>> partial line up to the cursor as input to the shell, followed by TAB,
>> then capture the output from bash and interpret it (either inserting
>> completed output, or offering a completion menu).
>
> Command line editing is disabled in the inferior shell.  If you want to
> enable it you'll have to make sure all literal control characters are
> preceded by the quote character before sending the line to the
> shell.

Should be doable.  Command line editing is necessary for completion?

> You'll also have to enable echoing to be able to capture anything.

Hm.  Completion is not really echoing.  Worth an experiment, but
probably one could expect this to work on more shells if one did not
rely on a nice combination of non-echo/complete.

-- 
David Kastrup

Re: Proposal for shell completion in M-x shell RET

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Should be doable.  Command line editing is necessary for completion?

TAB completion is part of line editing.

>> You'll also have to enable echoing to be able to capture anything.
>
> Hm.  Completion is not really echoing.

If the terminal is on -echo state then readline does not echo anything
besides the initial prompt.

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: Proposal for shell completion in M-x shell RET

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Should be doable.  Command line editing is necessary for completion?
>
> TAB completion is part of line editing.
>
>>> You'll also have to enable echoing to be able to capture anything.
>>
>> Hm.  Completion is not really echoing.
>
> If the terminal is on -echo state then readline does not echo anything
> besides the initial prompt.

Checked it.  If there is no unique completion, the completion list
appears, but if a unique completion is performed, no echoing happens.

At least with the version of bash I am using.  So you are right: one
would have to turn on echoing on the tty at least while one is fishing
for completions.

-- 
David Kastrup

Re: Proposal for shell completion in M-x shell RET

[Stefan Monnier]

> The way this would work would be when TAB is pressed to send the
> partial line up to the cursor as input to the shell, followed by TAB,

It would most likely have to be another key, because shell.el cannot know if
the command is sent to bash or to some other application, so it could only
be the user's choice to either get local completion or to send "prefix string
plus TAB" to the application.


        Stefan

Re: Proposal for shell completion in M-x shell RET

[Stefan Monnier]

>> The way this would work would be when TAB is pressed to send the
>> partial line up to the cursor as input to the shell, followed by TAB,

> It would most likely have to be another key, because shell.el cannot know if
> the command is sent to bash or to some other application, so it could only
> be the user's choice to either get local completion or to send "prefix string
> plus TAB" to the application.

BTW, maybe we can do it the way `gdb' does it: instead of sending TAB, we
send a "list_all_completions" command, presuming that bash offers such
a function.


        Stefan

Re: Proposal for shell completion in M-x shell RET

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The way this would work would be when TAB is pressed to send the
>>> partial line up to the cursor as input to the shell, followed by TAB,
>
>> It would most likely have to be another key, because shell.el cannot know if
>> the command is sent to bash or to some other application, so it could only
>> be the user's choice to either get local completion or to send "prefix string
>> plus TAB" to the application.
>
> BTW, maybe we can do it the way `gdb' does it: instead of sending TAB, we
> send a "list_all_completions" command, presuming that bash offers such
> a function.

programmable completion is extensively context-sensitive (which is
pretty much its whole point: it does not just complete file names, but
also CVS revisions, options and other stuff).

And sending such a command would clobber the command history, too.

-- 
David Kastrup

Re: Proposal for shell completion in M-x shell RET

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> programmable completion is extensively context-sensitive (which is
> pretty much its whole point: it does not just complete file names, but
> also CVS revisions, options and other stuff).

The gdb completions are context sentive as well.  The implementation
uses the complete command that gets the current command line as argument
and lists all completions thereof.  That does not handle all cases
though, there is no trailing context.

> And sending such a command would clobber the command history, too.

In gdb this is solved by defining a special prefix that suppresses
putting the command in the history.  Of course, this is much easier
implemented in gdb since there is a fixed set of commands.

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: Proposal for shell completion in M-x shell RET

[Richard Stallman]

    Maybe this can help on some platforms?

    process-running-child-p is a built-in function in `C source code'.
    (process-running-child-p &optional PROCESS)

I think it is not reliable to use this, because input is ansynchronous.

Re: Proposal for shell completion in M-x shell RET

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The way this would work would be when TAB is pressed to send the
>> partial line up to the cursor as input to the shell, followed by TAB,
>
> It would most likely have to be another key, because shell.el cannot know if
> the command is sent to bash or to some other application, so it could only
> be the user's choice to either get local completion or to send "prefix string
> plus TAB" to the application.

Maybe this can help on some platforms?

process-running-child-p is a built-in function in `C source code'.
(process-running-child-p &optional PROCESS)

Return t if PROCESS has given the terminal to a child.
If the operating system does not make it possible to find out,
return t unconditionally.

[back]

Anyway, one could just send the partial line plus TAB to the other
application, anyway.  If it just echoes it, no harm is done.  The
behavior should work for most applications that use either a normal
stty setting or readline.

-- 
David Kastrup