Re: [9fans] bug in libcomplete?

[Rob Pike <rob@mightycheese.com>]

> Next question (please bear with me): Has anyone thought of making
> libcomplete suggest binaries when there's a match? It's more trivial
> to look
> in /bin then to parse $PATH the way bash is doing. On the other hand
> the
> semantics need to be thought of right -- does it show executable files
> when
> none of the local files match? does it put preference on executables
> than
> files in the current dir (when no partial match exists) and so on?
>
> Maybe it isn't worth it and just typing /bin before hitting Ins is the
> way
> to go?

sure.

> Lastly: what would it take to make libcomplete work in directories
> served by
> things like ftpfs, dossrv (9fat:) or 9fs (9fs sources)?

i put in file name completion because the file names i see have grown
long
and because working with people who have file name completion kinda
forces you into it because they name things given that ability.

however, i still hate it.  like history in the shell that doesn't work
in other
commands, completion becomes this thing that only works some times in
some contexts.  for instance, it doesn't work on the rhs of a cp command
and it certainly doesn't work in scp.  it doesn't work in the address
bar of
the browser.  and so on and so on.  at least here it's in the window
system,
which makes it a little more general than it is in other systems, but
it's
fundamentally not a universally available thing, nor can it be.

so i vote strongly against hacks to make it work more broadly.  that way
lie layers of hideous goo that i don't need to name explicitly because
we've all seen linux's readline.  if it's not universal by design,
don't make
it semi-universal by hackery.

-rob