9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "andrey mirtchovski" <mirtchovski@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] control-F completion question
Date: Fri,  3 Oct 2008 10:52:59 -0600	[thread overview]
Message-ID: <14ec7b180810030952x232d9cd3p1d5d1e969ab28a8a@mail.gmail.com> (raw)
In-Reply-To: <a560a5d00810030939i7f337a84t5763d3f039ec07b5@mail.gmail.com>

i sometimes wonder whether the ^F completion stuff wasn't left this
way on purpose, as if to illustrate the futility of (essentially) a
single-node solution in the presence of distributed environments.

to solve what you perceive to be a problem you must ask yourself: what
is the one thing that is fully aware of the current namespace? it's
obviously not rio: it simply juggles windows with shells in them. is
it the shell? putting the completion in the shell itself would work
for plain terminals, but wouldn't work for rio. is it the kernel?
would you bother adding to the kernel something as silly as command
completion? how about completing across a network?

all difficult questions for a silly problem ;)

On Fri, Oct 3, 2008 at 10:39 AM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> Hello everybody!
>
> If I understand it right ^f (or an 'ins' key) are taken care of by rio and
> thus the success of completion is essentially dependent on the namespace rio
> is using. This namespace is created when rio is started, usually right after
> a computer start. When the namespaces of individual windows are changed, e.
> g. by binding some remote filesystems, ^f can't handle those new files
> (since the rio namespace stays intact). Even though I may understand the
> reason (i.e. what I have just said) I find it rather irritating, having
> maybe the whole space I work with out of reach of ^f. Is there any help with
> that? Couldn't it be somehow achieved that ^f worked 'better'? (Not saying
> rc should take care of it, it probably should not; but what about if it were
> somehow connected with the individual windows? -- I don't know, it may not
> be possible, just asking. Having to always write 'lc' is somewhat ...).
> Starting a bunch of several rios can help it. But is that a right way to
> go?
>
> Thanks for answers.
> Ruda
>



  reply	other threads:[~2008-10-03 16:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 16:39 Rudolf Sykora
2008-10-03 16:52 ` andrey mirtchovski [this message]
2008-10-03 17:11   ` Rudolf Sykora
2008-10-03 17:34     ` Federico G. Benavento
2008-10-03 17:34     ` erik quanstrom
2008-10-03 16:53 ` Nathaniel W Filardo
2008-10-03 17:32 ` erik quanstrom
2008-10-03 18:42 ` Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14ec7b180810030952x232d9cd3p1d5d1e969ab28a8a@mail.gmail.com \
    --to=mirtchovski@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).