[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joost Kremers
Subject: bug#15385: [Eshell] Directory completion overwrites preceding characters
Date: Sat, 21 Sep 2013 16:42:46 +0200
User-agent: mu4e; emacs 24.3.1

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.


On Sat, Sep 21 2013, address@hidden 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 <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]