bug#15385: [Eshell] Directory completion overwrites preceding characters

[Aidan Gauland]

The bug seems to be in pcomplete, line 1140 of pcomplete.el, to be
exact:

  (delete-char (- (length (comint-quote-filename stub))))

`comint-quote-filename' is given a relative path, "~/Dro", and returning
an absolute path, "/home/joost/Dropbox/".  The length of this is then
passed to `delete-char' to clear the argument being completed, but the
length is wrong when it's a relative path, because
`comint-quote-filename' seems to always return an absolute path.

I'm not sure how to fix this without breaking something else or leaving
out other special cases, such as ${FOO}tm[TAB], because I still don't
really understand how pcomplete works.  I still want to sit down with
pcomplete for a while and document it (it was left undocumented along
with Eshell, of which it was originally a component), so unless someone
else can come up with a good fix, this bug will have to remain
outstanding for a while, unfortunately.

--Aidan

Joost Kremers <joostkremers@fastmail.fm> writes:

> Starting from `emacs -Q', if I do
>
>    (setq eshell-cmpl-ignore-case t)
>
> and then start up a shell, TAB completion behaves incorrectly under some
> conditions.
>
> Specifically, I type a command such as:
>
>     $ cp ~/Dropbox/Work/Reading/Wilbur_Martinez2002.pdf ~/Dro
>
> At this point, I hit TAB to complete `~/Dro' and get:
>
>     $ cp ~/Dropbox/Work/Reading/Wilbur_Martine/home/joost/Dropbox/
>
> Note that the problem does *not* occur with the first file path. If I
> hit TAB to complete
>
>     $ cp ~/Dro
>
> then completion produces the correct result:
>
>     $ cp ~/Dropbox/
>
> It seems the problem occurs when the file path is the second argument on
> the command line, because if I type:
>
>     $ ls ~/Dropbox/Work/Literature/k/kim2002.pdf ~/dro
>
> and hit TAB to complete, the result is also:
>
>     $ ls ~/Dropbox/Work/Literature/k/ki/home/joost/Dropbox/
>
> It does not occur when there is a switch preceding the file path:
>
>     $ ls -l ~/dro
>
> completes fine.
>
> Thanks,
>
> Joost Kremers