Status of shell-pcomplete integration?

Status of shell-pcomplete integration?

[Romain FRANCOISE]

Hi,

is someone currently working on integrating pcomplete in Shell-mode?
From the list archives, I see that support for pcomplete has been added
in Feb. 2002 then removed in March, because it wasn't ready and didn't
work right.

If no progress has been made towards this goal since then (and a quick
look through shell.el didn't seem to indicate there has), I think the
entry in etc/NEWS that says that Shell-mode now supports programmable
completion should be removed; it is misleading.

        Romain.

-- 
Romain FRANCOISE <romain@orebokech.com> | Every sky is blue, but not
it's a miracle -- http://orebokech.com/ | for me and you.

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

Romain FRANCOISE <romain@orebokech.com> writes:

> is someone currently working on integrating pcomplete in Shell-mode?
> From the list archives, I see that support for pcomplete has been added
> in Feb. 2002 then removed in March, because it wasn't ready and didn't
> work right.
>
> If no progress has been made towards this goal since then (and a quick
> look through shell.el didn't seem to indicate there has), I think the
> entry in etc/NEWS that says that Shell-mode now supports programmable
> completion should be removed; it is misleading.

I would like to see pcomplete completion in shell mode.  IIRC, the
complaints were ones that could have been solved by frobbing the
pcomplete options appropriately.

It would be a pity to omit this feature because of such easily solved
problems.

Caveat: I don't _know_ what exactly were the problems.  I only
_believe_ it would have been easy to solve them.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[John Wiegley]

>>>>> On Sun Dec  1, Kai writes:

> It would be a pity to omit this feature because of such easily
> solved problems.

I agree.  Let's make a list, and then tackle them.

John

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

>>>>>> On Sun Dec  1, Kai writes:
>
>> It would be a pity to omit this feature because of such easily
>> solved problems.
>
> I agree.  Let's make a list, and then tackle them.

Okay.  There was a thread on this some months ago...  I wonder if
more items will crop up.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

> I agree.  Let's make a list, and then tackle them.

Is just binding TAB to pcomplete the right way to integrate it into
shell-mode?  I tried the following:

emacs -q -no-site-file
(require 'shell) C-j
(define-key shell-mode-map (kbd "TAB") 'pcomplete) C-j
M-x shell RET
ls /us<TAB>             this completes /usr correctly
ls /us<TAB>             BAM!  no completion anymore

Reported by Felix Klee on gnu.emacs.help.

But maybe it's my fault for suggesting the wrong pcomplete integration.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[Romain FRANCOISE]

Kai Großjohann writes:

> Is just binding TAB to pcomplete the right way to integrate it into
> shell-mode?  I tried the following:

[...]

FWIW, the previous integration (the one that was removed from the
repository in March) did something more: apparently the buffer had to
be "setup" for pcomplete.  You can get a more or less usable diff using

cvs diff -r1.109 -r1.108 shell.el

        Romain.

-- 
Romain FRANCOISE <romain@orebokech.com> | They're nothing but cold
it's a miracle -- http://orebokech.com/ | little demons.

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

Romain FRANCOISE <romain@orebokech.com> writes:

> FWIW, the previous integration (the one that was removed from the
> repository in March) did something more: apparently the buffer had to
> be "setup" for pcomplete.  You can get a more or less usable diff using
>
> cvs diff -r1.109 -r1.108 shell.el

Good.  So let's change pcomplete-cycle-completions to nil at the same
time, to see whether people complain.

I think that would solve Noah's complaint, voiced in
http://mail.gnu.org/pipermail/emacs-devel/2002-March/006508.html , at
least.

Hmmm...

What's the problem with the following?

(require 'shell)
(define-key shell-mode-map (kbd "TAB") 'pcomplete)
(add-hook 'shell-mode-hook 'pcomplete-shell-setup)

It seems to work.  It does not defer loading of pcomplete until
completion is actually used, but oh, well.

Maybe pcomplete-shell-setup should set pcomplete-cycle-completions to
nil?  But that would make it difficult to override.  Hm.

John, how about setting pcomplete-cycle-completions to nil globally?
That would make it more consistent.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[John Wiegley]

>>>>> On Tue Dec  3, Kai writes:

> Good.  So let's change pcomplete-cycle-completions to nil at the
> same time, to see whether people complain.

I thought it was suggested that rather than disabling completion
cycling altogether, we should prompt in the minibuffer while cycling
is being done, notifying of how many alternatives are left to
display...?

John

> John, how about setting pcomplete-cycle-completions to nil
> globally?  That would make it more consistent.

But cycling is a GOOD thing, and if you turn it off globally, 90% of
Emacs users won't know that it's there to turn on.

John

Re: Status of shell-pcomplete integration?

[Romain FRANCOISE]

John Wiegley writes:

> But cycling is a GOOD thing, and if you turn it off globally, 90% of
> Emacs users won't know that it's there to turn on.

It's a nice feature, but it's not consistent with the rest of Emacs, and
it's not the default completion type of Bash, so I think it will confuse
people.  IMHO, in Shell-mode you should have the same interface as in a
regular terminal.

And there are tons of features in Emacs that you discover by reading
the docs, not because they are activated by default.

        Romain.

-- 
Romain FRANCOISE <romain@orebokech.com> | Every sky is blue, but not
it's a miracle -- http://orebokech.com/ | for me and you.

Re: Status of shell-pcomplete integration?

[Stefan Monnier]

> > Good.  So let's change pcomplete-cycle-completions to nil at the
> > same time, to see whether people complain.
> 
> I thought it was suggested that rather than disabling completion
> cycling altogether, we should prompt in the minibuffer while cycling
> is being done, notifying of how many alternatives are left to
> display...?

I think the priority is to switch over to pcomplete.
To maximize the chances of such a switch being accepted, we should
strive to preserve the current behavior as much as possible.
The behavior can later on be changed, but at first we should just
concentrate on getting pcomplete to behave "like the current code".


	Stefan

Re: Status of shell-pcomplete integration?

[John Wiegley]

>>>>> On Tue Dec  3, Stefan writes:

> I think the priority is to switch over to pcomplete.  To maximize
> the chances of such a switch being accepted, we should strive to
> preserve the current behavior as much as possible.  The behavior
> can later on be changed, but at first we should just concentrate on
> getting pcomplete to behave "like the current code".

As long as it gets changed before 21.3 goes out?  I tell you, no one
will know its there, and nobody will get the benefit of using it.

John

Re: Status of shell-pcomplete integration?

[Miles Bader]

John Wiegley <johnw@gnu.org> writes:
> > The behavior can later on be changed, but at first we should just
> > concentrate on getting pcomplete to behave "like the current code".
> 
> As long as it gets changed before 21.3 goes out?  I tell you, no one
> will know its there, and nobody will get the benefit of using it.

Maybe so, but you can argue that later.  It's a minor issue.

[BTW, I tried pcomplete-cycle-completions for a while, and hated it.
 It makes much less sense in emacs, which can show a list of
 completions and then restore the screen, than it does in a shell,
 which can't.]

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I think the priority is to switch over to pcomplete.
> To maximize the chances of such a switch being accepted, we should
> strive to preserve the current behavior as much as possible.

Yes.  It's not really that the functionality is gone, people can
activate it with a single user option.  Later on, we can discuss to
change the default for that option.

But getting people to accept pcomplete everywhere is the difficult
part.  It promises tremendous benefit.

(The echo area message about remaining number of completions would be
cool nonetheless.  It might make me turn completion cycling back on :-)

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[Romain FRANCOISE]

Kai Großjohann writes:

> What's the problem with the following?

> (require 'shell)
> (define-key shell-mode-map (kbd "TAB") 'pcomplete)
> (add-hook 'shell-mode-hook 'pcomplete-shell-setup)

> It seems to work.  It does not defer loading of pcomplete until
> completion is actually used, but oh, well.

Provided you set pcomplete-cycle-completions to nil, it indeed seems to
work fine, with a few quirks:

- it doesn't complete filenames or directories containing spaces, even
  if you escape them with backslashes.  (With the completion cycling
  turned on, it works)

- it doesn't complete environment variables, e.g. 
  
        $ cd $HOME/foo<TAB>

  will not complete to

        $ cd $HOME/foobar

  but I think this is supposed to work with pcomplete, maybe John will
  know how to fix it.


        Romain.

-- 
Romain FRANCOISE <romain@orebokech.com> | They're nothing but scared
it's a miracle -- http://orebokech.com/ | little mice.

Re: Status of shell-pcomplete integration?

[John Wiegley]

>>>>> On Tue Dec  3, Romain writes:

> - it doesn't complete environment variables, e.g.

>         $ cd $HOME/foo<TAB>

>   will not complete to

>         $ cd $HOME/foobar

Huh?  This should work just fine.

John

Re: Status of shell-pcomplete integration?

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

>>>>>> On Tue Dec  3, Romain writes:
>
>> - it doesn't complete environment variables, e.g.
>
>>         $ cd $HOME/foo<TAB>
>
>>   will not complete to
>
>>         $ cd $HOME/foobar
>
> Huh?  This should work just fine.

I can't reproduce that bug, either.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Status of shell-pcomplete integration?

[Mario Lang]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Romain FRANCOISE <romain@orebokech.com> writes:
>
>> is someone currently working on integrating pcomplete in Shell-mode?
>> From the list archives, I see that support for pcomplete has been added
>> in Feb. 2002 then removed in March, because it wasn't ready and didn't
>> work right.
>>
>> If no progress has been made towards this goal since then (and a quick
>> look through shell.el didn't seem to indicate there has), I think the
>> entry in etc/NEWS that says that Shell-mode now supports programmable
>> completion should be removed; it is misleading.
>
> I would like to see pcomplete completion in shell mode.

Same here.

I'd also like pcompete completion in M-! and M-| and alike.

-- 
CYa,
  Mario

Re: Status of shell-pcomplete integration?

[Richard Stallman]

I will delete that NEWS item.  If someone gets this working
we can add it back.