[9fans] file name completion

[9fans] file name completion

[Rob 'Commander' Pike]

[-- Attachment #1: Type: text/plain, Size: 3023 bytes --]

living with a foot in two worlds, i finally broke down and implemented
file name completion for rio and acme.  the sources are attached as a
gzipped bundle.  acme/look.c is just a bug fix that's already on sources.
i started on doing sam too and i mean to finish it but it will take a while
and may involve bumping the protocol version number, which is annoying.

i've been using it for about a week and am starting to like it, but i'm far
from convinced my solutions are the right ones, especially with regard to
user interface.  also, i think the rules about how to complete should be
decided by the plumber, but i don't have that figured out, either. since it's
done in a library, however, if i do figure it out it will be very easy to
slide in: just update the library.

it's done in the window system, which makes for some nice properties
such as uniformity and some less nice ones such as failure when the
namespaces differ.  but plumbing and other things break down in that
case, anyway, and if file name completion doesn't work you can always
just type the file name, so this doesn't bother me much. yet.

here's how it works: type control-F or the Insert key (Ins on some keyboards)
and the window manager will push the file name you're typing as far as
it unambiguously can.  if it can't do anything unambiguously, it will
present a list of options, either just before the host point (in rio) or in the
default Errors window (in acme).  keep that acme window up so it doesn't
pop up and steal the mouse; if you're like me, you'll get use to this fast.
but maybe there's a better way.  (the rio trick doesn't work because there's
no host point in acme.)

in the bundle i've included updated and new man pages, a new library
(libcomplete) and header file (complete.h) and small updates to acme and
rio.  if you're up to date with respect to sources, they should plug in and
compile.

i'm not sure this is worthwhile for plan 9 alone, but boy does it make life
easier across that 9fs boundary.

one known issue is that nothing is done for blanks in file names.  when
i see one i care about, i'll address the issue.  it's trivial - just quote the
blank in libcomplete.

one more thing, only partially related: this package also makes left and
right arrow keys move the selection left and right, makes Page Up and
Page Down keys work like up and down arrow, and Home and End keys
move to the beginning or end of the window, without changing the
selection.   End won't work for you because you'll need a fix to the
keyboard driver to map that key to the value in the current keyboard.h
rather than to carriage return.  i debated changing up and down arrows
to move the selection up or down a line, but as they are they behave
somewhat like most web browsers and many other applications, so i
left them as is. i'm debating making them scroll less and making Page
Up and Page Down scroll more, but not in this bundle.

enjoy if you want, ignore if you prefer.

-rob

[-- Attachment #2: complete.bun.gz --]
[-- Type: application/octet-stream, Size: 28753 bytes --]

Re: [9fans] file name completion

[mirtchov]

The plumber, it seems, is emerging as Plan 9's secret weapon. One
that may make the system compelling to others again...

A nice exercise in its usefulness is the breaking down of a huge,
monolithic program such as Links into smaller parts tied together by
plumbing -- from an all-encompassing piece of code that knows how
to handle everything from rendering html tables to handling ftp and
samba protocols, into a simple html renderer that works with the
plumber to give out work to whichever external program is best suited
for the job (and not having to know anything about them)...

I have found that for day-to-day stuff, the plumber is one of the
most-often used Plan 9 "features" that do not exist anywhere else,
save Inferno.  Second only to private namespaces.

andrey

ps: this email prompted by the "how appropriate to put filename
completion outside the shell, wouldn't have thought of it in a
lifetime" foundation :)

Re: [9fans] file name completion

[ron minnich]

On Sun, 21 Dec 2003 mirtchov@cpsc.ucalgary.ca wrote:

> ps: this email prompted by the "how appropriate to put filename
> completion outside the shell, wouldn't have thought of it in a
> lifetime" foundation :)

The amiga did a trial run outside the shell too.

ron

RE: [9fans] file name completion

[boyd, rounin]

i'm not real convinced about this but I could be interesting.

--
MGRS 56H LJ 78915 53260

RE: [9fans] file name completion

[boyd, rounin]

be buggered, this jet-lag, XP and bronchitis are not helping:

   i'm not real convinced about this but it could be interesting.

--
MGRS 56H LJ 78915 53260

RE: [9fans] file name completion

[okamoto]

> be buggered, this jet-lag, XP and bronchitis are not helping:
> 
>    i'm not real convinced about this but it could be interesting.

It seems to show a little shift from fundametalist Rob Pike 
to someone else.☺
However, I appreciate and thank this change, because I don't need
to switch mouse/keyboard so often now.   However, Plan 9 still be
fundametalist as possible.

Kenji

Re: [9fans] file name completion

[Steve Kilbane]

> i'm not real convinced about this but I could be interesting.

Oh, but that's going into my fortune file...

steve

Re: [9fans] file name completion

[Jack Johnson]

On Monday, December 22, 2003, at 05:17 PM, boyd, rounin wrote:

> i'm not real convinced about this but I could be interesting.

I'm not convinced, but I'm not interesting, either.  :)

-Jack

Re: [9fans] file name completion

[Scott Schwartz]

I haven't tried it yet, but I'm convinced and interested.  Something like
"rk", a markov chain based input predictor would be great too.  Most of
what we type is highly predictable, and having a key to accept the next
offered word or line can really accelerate things.

Re: [9fans] file name completion

[boyd, rounin]

T9 input on GSM mobiles is kinda neat for sending SMS's.

Re: [9fans] file name completion

[rob pike, esq.]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

sigh.  this update fixes a stupid bug with ← and → and also
makes the arrow keys go 1/3 page and page up/down go 2/3 page.
if you're going to overload the functionality, do something
distinguishable...

i hope this is it for a while.

-rob


643c643,644
< 		if(t->q0 > 0)
---
> 		if(t->q0 > 0){
> 			textcommit(t, TRUE);
644a646
> 		}
647c649,650
< 		if(t->q1 < t->file->nc)
---
> 		if(t->q1 < t->file->nc){
> 			textcommit(t, TRUE);
648a652
> 		}
650a655,656
> 		n = t->maxlines/3;
> 		goto case_Down;
652c658,659
< 		n = t->maxlines/2;
---
> 		n = 2*t->maxlines/3;
> 	case_Down:
656a664,665
> 		n = t->maxlines/3;
> 		goto case_Up;
658c667,668
< 		n = t->maxlines/2;
---
> 		n = 2*t->maxlines/3;
> 	case_Up:

[-- Attachment #2: text.c.gz --]
[-- Type: application/octet-stream, Size: 8623 bytes --]

Re: [9fans] file name completion

[rog]

> ps: this email prompted by the "how appropriate to put filename
> completion outside the shell, wouldn't have thought of it in a
> lifetime" foundation :)

danny byrne added a similar feature to his version of the
inferno shell window a good while ago; not integrated into
the main version yet (i didn't like the way it subverted the tab
key), but standardising on "Ins" seems like a good thing.

Re: [9fans] file name completion

[rob pike, esq.]

> but standardising on "Ins" seems like a good thing.

since doing this, using ^F and "Ins" both to try them out and
discovering that i prefer ^F because i can always find it, i've
learned that some shells have already chosen ^F for the purpose,
so i think that's the way to go.

-rob

Re: [9fans] file name completion

[Russ Cox]

> > ps: this email prompted by the "how appropriate to put filename
> > completion outside the shell, wouldn't have thought of it in a
> > lifetime" foundation :)
>
> danny byrne added a similar feature to his version of the
> inferno shell window a good while ago; not integrated into
> the main version yet (i didn't like the way it subverted the tab
> key), but standardising on "Ins" seems like a good thing.

if you're going to standardize, include ctl-f too.  that's much
easier to type anyway.

[9fans] Newbie: rio help

[Chris Lamrock]

Hi,

I installed plan 9 a few days ago.   The install came up & recognized my S3
card & did the graphical install fine.

I only had 2 problems.

1. I had had lilo on the drive and I had to mbr the system to get it to boot
plan 9.

2. (Here is my unresolved problem) Plan 9 hasn't started rio since the
install.  I get a "No frame buffers" error.  Something must be different on
the boot floppy & CD than is on my installed system - but I don't know what?

I went through the installation troubleshooting some last night but it
didn't get me too far - most likely due to my lack of knowlege ;-)

Any ideas on why rio would run durring install but not again?  Any help on
this would be appreciated!

Thanks!

-Chris

Re: [9fans] Newbie: rio help

[mirtchov]

the installation and default Plan 9 kernels seem to differ in their
support for specific versions of some video cards, most notably Nvidia
TNT (did 0x20, I believe).

Search back the 9fans archives to see if anyone has had the same
problem with your particular video card version, if you don't find
anything run the 'pci' command and send it to the list -- you'll
probably have to edit /sys/src/9/pc/vgaxxxxxxx.c or vgadb using 'ed'
and add the device id for your card there:)

andrey

Re: [9fans] Newbie: rio help

[Chris Lamrock]

Thanks for the help.  I know my card is an older S3 - it took a few cards
before I found one that rio came up on.

I'll look into it tonight & see what I can come up with.

Thanks again!

-Chris
----- Original Message -----
From: <mirtchov@cpsc.ucalgary.ca>
To: <9fans@cse.psu.edu>
Sent: Wednesday, January 07, 2004 9:52 AM
Subject: Re: [9fans] Newbie: rio help


> the installation and default Plan 9 kernels seem to differ in their
> support for specific versions of some video cards, most notably Nvidia
> TNT (did 0x20, I believe).
>
> Search back the 9fans archives to see if anyone has had the same
> problem with your particular video card version, if you don't find
> anything run the 'pci' command and send it to the list -- you'll
> probably have to edit /sys/src/9/pc/vgaxxxxxxx.c or vgadb using 'ed'
> and add the device id for your card there:)
>
> andrey
>

Re: [9fans] file name completion

[Sape Mullender]

> ===> 2/ (application/octet-stream) [file]
> 	cp /mail/fs/mbox/27/2/body /usr/sape/complete.bun.gz

Before you run complete.bun, mkdir sys/src/libcomplete

RE: [9fans] file name completion

[cej]

>  A nice exercise in its usefulness is the breaking down of a huge, monolithic program such
>  as Links into smaller parts tied together by plumbing -- from an all-encompassing piece of
>  code that knows how to handle everything from rendering html tables to handling ftp and
>  samba protocols, into a simple html renderer that works with the plumber to give out work
>  to whichever external program is best suited for the job (and not having to know anything
>  about them)...

>  I have found that for day-to-day stuff, the plumber is one of the most-often used Plan 9
>   "features" that do not exist anywhere else, save Inferno.  Second only to private namespaces.

That's it!
++pac.

RE: [9fans] file name completion

[Charles Forsyth]

>  A nice exercise in its usefulness is the breaking down of a huge, monolithic program such
>  as Links into smaller parts tied together by plumbing -- from an all-encompassing piece of
>  code that knows how to handle everything from rendering html tables to handling ftp and
>  samba protocols, into a simple html renderer that works with the plumber to give out work
>  to whichever external program is best suited for the job (and not having to know anything
>  about them)...

it would be nice if that were possible but it's the interaction between
javascript and html rendering, at many and seemingly arbitrary points,
that complicates browsers, even as regards interaction with the transport protocols
(fortunately less so, so that those can indeed be handled in a more modular way).
for instance, javascript has an interface to the state of the renderer.
conversely, and perhaps even worse, the renderer implementation needs to provide the
sort of state that the javascript interface expects, which further limits
design and implementation freedom.  actually, there are several interfaces
because different browsers historically gave javascript access to state that their implementations
happened to provide, which changed from browser to browser.

Re: [9fans] file name completion

[Rob 'Commander' Pike]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

evidence is that this didn't get out before, so here it is again.
there's a stupid mistake in the implementation of left and right
arrows.  the other change here is that i tweaked the parameters
so the up and down arrows go 1/3 page and page up and page
down arrows go 2/3 page.

i hope this is it for a while.

-rob

643c643,644
< 		if(t->q0 > 0)
---
> 		if(t->q0 > 0){
> 			textcommit(t, TRUE);
644a646
> 		}
647c649,650
< 		if(t->q1 < t->file->nc)
---
> 		if(t->q1 < t->file->nc){
> 			textcommit(t, TRUE);
648a652
> 		}
650a655,656
> 		n = t->maxlines/3;
> 		goto case_Down;
652c658,659
< 		n = t->maxlines/2;
---
> 		n = 2*t->maxlines/3;
> 	case_Down:
656a664,665
> 		n = t->maxlines/3;
> 		goto case_Up;
658c667,668
< 		n = t->maxlines/2;
---
> 		n = 2*t->maxlines/3;
> 	case_Up:

[-- Attachment #2: text.c.gz --]
[-- Type: application/octet-stream, Size: 8623 bytes --]