On Jan 23, 2012, at 3:58 , smiley@icebubble.org wrote:

> 	* Finally! A sane solution to the problem of hard-coded paths
> 	in the plan9port tree: Most of them have been removed, in
> 	favor of a "#!/usr/bin/env 9rc" approach (which execs "9 rc").
> 	The "9" script has been updated with "intelligence" to detect
> 	and set $PLAN9 from miscellaneous clues in its environment.
> 	(Exec is used throughout, so no memory penalty is incurred.)
> 	Just a few hard-coded paths remain. One of them is in the "9"
> 	script, itself. The others (5, at last count) can be found in
> 	lib/moveplan9.files. OS X users should develop a habit (like
> 	Linux users) of setting their $PATH variables to include
> 	$PLAN9/bin, so some of the remaining hard-coded paths can be
> 	eliminated.





> 	* To facilitate the "9rc" mechanism, a few additional scripts
> 	have been added. "9awk" execs "9 awk", "9sed" execs "9 sed",
> 	etc. There's even a 9bash to make it easy to run bash scripts
> 	with $PLAN9 set to an appropriate value. There's also a "9fmt"
> 	to make it easier to run "|fmt" (which would otherwise have to
> 	be run as "|9 fmt") in Acme on plan9port.

Early versions of 9p9 had a bunch of 9foo commands, before the addition of
the "9" command. Your change here seems like a step backwards to me, as
it'd require much more editing of various scripts. Set the default $PATH the
way you like it, and if you have something which depends on the differences,
use ". 9" or ". u" to override it.


> 	* vac and vacfs now support symbolic links, block and
> 	character devices, named pipes, Unix domain sockets, and inode
> 	change times (ctime), as well as set-user-id, set-group-id,
> 	and sticky bits. In theory, they also support append-only
> 	(DMAPPEND), exclusive-use (DMEXCL), and temporary (DMTMP)
> 	bits. However, due to lack of a native Plan 9 system, support
> 	for DMAPPEND, DMEXCL, and DMTMP has not been tested.
> 	Preliminary support in unvac for these file types and mode
> 	bits exists, but is still incomplete. 9pfuse has been updated
> 	to support those of the above attributes which can be exposed
> 	by 9P2000. So now you can have, for example, block devices and
> 	Unix domain sockets appear in your 9pfuse file systems.

This could be very interesting. My main reason for running venti instead of,
say, cwfs is to dump bits from Unix hosts, so doing this better could be a
significant win.

> Notes on the changes to lib9:



I don't think I really like what you've done with symlinks, but I agree there
isn't really a "right" answer in the face of differing expectations between
the Unix and Plan 9 worlds. It'll be an interesting experiment, at the least.

I'm not sure I see what you mean by suggesting the existing symlink
behavior aims at imitating namespaces.

> Notes on developing in Acme:
> 
> 	This is the first project I've done in Acme. Some of my
> 	impressions of the experience follow.
> 
> 	* Click-to-focus is just as annoying today as it was in 1995.
> 	Point-to-focus is cumbersome when used by small windows, such
> 	as Acme window tag lines. For tag lines, "sloppy" focus might
> 	be better, although it's unclear how sloppy focus and
> 	point-to-focus could be made to co-exist peacefully.

I've sometimes thought I'd like the tag lines and window body to have
different default fonts, to make tag lines easier to hit. Mostly, though, this
comes up when using Acme with something other than a good mouse, and
I've "solved" the problem by only using acme with a good mouse handy.

> 	* Having to switch a hand back and forth between the keyboard
> 	and mouse (or typing with one hand, while mousing with the
> 	other) is an annoyance. I suspect you really need three arms
> 	to use Acme efficiently. (For the record, I'm a touch-typist.)

This comes up all the time. You can scan the mailing list archive for
references and discussion if you like, but suffice it to say that this doesn't
impact your actual time spent doing given tasks the way you think it
does, and is largely psychological.

That said, particular things can make it more or less productive. You really
want a good (accurate and responsive) mouse. I liked trackpoints before
I started using Acme regularly, but they're very irritating there. Trackpads
seem okay. I also found Acme a lot more compelling when I started using
keyboards that don't have the extraneous stuff to the right of enter.

> 	* Recalling/editing previous commands in "win" windows is
> 	tedious.

I don't agree, but if you find it such you might enjoy Russ's " and "" scripts
(/n/sources/contrib/rsc/scripts) or Erik's rc tweak, which includes some
form of history (/n/sources/contrib/quanstro/src/futharc).

> 	* It's difficult to find the header/source file in which a
> 	particular function, variable, or macro is defined. Why can't
> 	Acme cross-reference such things, like other IDEs do?

The short answer is that this isn't Acme's job. There are a number of
solutions to this problem using 3rd party tools, though. I ported
Exuberant Ctags to Plan 9 and added acme-style tag output to make
plumbing things easier; I expect the changes would be easily
backportable to Unix, although I've never tried. Other people have done
other things with code tagging databases.

See my ctags note here: http://9fans.net/archive/2008/02/504

> 	* Where did all my keyboard accelerators go?  Acme could use
> 	Put, Undo, and Paste accelerators, at a minimum.  Keystrokes
> 	for forward/backward word would be great, and a keystroke to
> 	warp the pointer to the end of the tag line would be really
> 	nice, too.

For the most part, these are absent as a conscious choice. Some folks
disagree, of course. It hasn't been updated in a while, but Ron has an
acme fork ("smacme"; /n/sources/contrib/rminnich/smacme) which
implements some emacs-style navigation. I'm not sure if it got into
higher-level things like Put, but it generated some discussion at the
time. The archives might be informative, or at least suggest who to ask.

anth