Reinsertion of file prefix for accepted completion?

Reinsertion of file prefix for accepted completion?

[James Devenish]

Hi,

Is there some way (that isn't too outrageous, but perhaps involves the
calling of a 'fixup' function) to reinsert a compadd -W file prefix when
the completion is accepted? For example, pretend that arguments for 'echo'
are paths, being matched using -W "( . /not/current/directory )":

% ls /not/current/directory<Enter>
a1 a2 b1 c1
% ls<Enter>
d1 d2 e1
% echo a<Tab>
a1 a2
% echo a1<Tab><Enter>
/not/current/directory/a1
% echo b<Tab><Enter>
/not/current/directory/b1
% echo e<Tab><Enter>
e1

Or at worst:

% echo e<Tab><Enter>
./e1

(The above notation is probably a bit ambiguous, but hopefully my first
paragraph helps explain what I mean.)

Re: Reinsertion of file prefix for accepted completion?

[Bart Schaefer]

On Jan 3, 12:33pm, James Devenish wrote:
} 
} Is there some way (that isn't too outrageous, but perhaps involves the
} calling of a 'fixup' function) to reinsert a compadd -W file prefix when
} the completion is accepted?

Not really, no.

It's a completion system, not an abbreviation system.  The focus is on
producing on the command line an argument in the form that is expected
by the command.  If the command expects a full path, then the completer
should insert the full path.

In other words, instead of

    _path_files -W "( . /not/current/directory )" -g '*(.)'

you should be using something like

    _alternative \
	"local-files:: _path_files -g '*(.)'" \
	"other-files:: _path_files -g '/not/current/directory/*(.)'"

If you have a particular command for which you'd like to be able to use
abbreviated file names as arguments, then write a wrapper function for
that command; e.g. (crudely, for a command named "foo"):

    foo () {
	setopt localoptions noksharrays noshwordsplit
	integer i=$ARGC
	while ((--i))
	do
	    if [[ -f ./$argv[i] ]]; then
		continue
	    elif [[ -f /not/current/directory/$argv[i] ]]; then
		argv[i]=/not/current/directory/$argv[i]
	    fi
	done
	command foo $*
    }

However, you don't both get to use the abbreviations *and* see the full
paths in the command history.

If you *really* wanted to work for it, you could write a new ZLE widget
to replace accept-line, which would walk through the command buffer
every time you press enter to do this same sort of rewriting before
finally calling `zle .accept-line'.  I'm not going to attempt to show
an example of that, because it's fraught with potential problems, but
it could be done.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Reinsertion of file prefix for accepted completion?

[James Devenish]

In message <1030103055654.ZM28760@candle.brasslantern.com>
on Fri, Jan 03, 2003 at 05:56:53AM +0000, Bart Schaefer wrote:
> On Jan 3, 12:33pm, James Devenish wrote:
> } Is there some way...to reinsert a compadd -W file prefix when
> } the completion is accepted?
> Not really, no. // It's a completion system, not an abbreviation
> system.  The focus is on producing on the command line an argument
> in the form that is expected by the command.

At least are such special cases as $cdpath (thankfully)!

> If you have a particular command for which you'd like to be able to use
> abbreviated file names as arguments, then write a wrapper function
[...]
> However, you don't both get to use the abbreviations *and* see the full
> paths in the command history.
[...]
> If you *really* wanted to work for it, you could write a new ZLE widget
> to replace accept-line,

I am tempted to look into the latter, but the number of users who could
benefit from it (as opposed to having no use for it or being harmed by
it) is so small, the wrapper sounds fine. It is specifically to do with
the BSD ports management commands, so there are a few restrictions that
it (the thing I wanted to achieve) both pertinent and relatively risk
free. I will be asking for comments presently, so I guess I'll get some
reactions then. I have a compromise in mind.

PS. I am really impressed with the quality of the answers I've received
from people on the zsh mailing lists (including off-list). Thank you.