[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 0.9.9.5; 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.
Joost
On Sat, Sep 21 2013, aidalgol@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@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