GNU bug report logs - #15385
[Eshell] Directory completion overwrites preceding characters

Previous Next

Full log

View this message in rfc822 format

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: Aidan Gauland <aidalgol <at> no8wireless.co.nz>
Cc: 15385 <at> debbugs.gnu.org
Subject: bug#15385: [Eshell] Directory completion overwrites preceding characters
Date: Sat, 21 Sep 2013 16:42:46 +0200

But that still does not explain why the problem only occurs with the
second argument on the command line. The first argument is completed
without any problem, and *without* expanding ~ to /home/joost.

Joost


On Sat, Sep 21 2013, aidalgol <at> no8wireless.co.nz wrote:
> 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 <at> 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


-- 
Joost Kremers
Life has its moments

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.