wily in cygwin

[Don McLane]

I just started using Wily and had some questions/comments. I'm running
it in cygwin (which is probably the source of my problems).

Is it supposed to display "$PWD" in the tag? Seems like that's an
expression that should be evaluated somehow.

If you have a file named "new" (lowercase n) and you middle-click "New"
then it opens the file "new". What are the odds that a new user, trying
wily for the first time, had a file named "new"? Well it happened! It
makes for a very confused newbie.

Shouldn't I be able to right-click on "../" and open a window in the
parent directory?

Anyway, thanks to the developers. Wily promises to be a really
productive environment.

Don

[Tommy Pettersson]

Post by Don McLane
Is it supposed to display "$PWD" in the tag? Seems like that's an
expression that should be evaluated somehow.

It's the other way around actually. Paths can be long and easily
fill up the tag, so wily tries to shorten them. If some prefix
of the path is the value of any environment variable, such a
prefix is replaced with $<VARIABLENAME> in the tag, in the
shortest possible way.

I start wily from a wrapper script that, among other things,
sets some short variable names for my usual working dirs, _and_
unsets PWD, but the latter is much a matter of taste.

Post by Don McLane
If you have a file named "new" (lowercase n) and you middle-click "New"
then it opens the file "new". What are the odds that a new user, trying
wily for the first time, had a file named "new"? Well it happened! It
makes for a very confused newbie.

I think the type of file system is involved in this. It's case
insensitive in some backward compatible way with 8.3 names,
isn't it?

Anyway, the reason for opening an existing 'New' is that New
creates a buffer with that file name, and if you later Put it
you would (perhaps accidently) overwrite the existing file
'New'. The same thing will of course happen if you change the
name and Put, an existing file with that name is overwritten,
but then it's "your own fault".

I use a patch that makes wily perform safe Puts: if the file has
been (externally) modified since the last Put, or was never read
by wily, or disappeared, wily complains instead of saving the
file, unless you do a "force Put" (click in the file label and
B2B1 on Put). With this arrangement New could always open new
buffers since you would get a warning and be able to rename the
file before you Put it.

Post by Don McLane
Shouldn't I be able to right-click on "../" and open a window in the
parent directory?

Just clicked it and got a window with the parent directory. :-)
I have no idea what's failing here.

Post by Don McLane
Anyway, thanks to the developers. Wily promises to be a really
productive environment.

A minute to learn, a lifetime to master... :-)

[Ian Broster]

Post by Tommy Pettersson

Post by Don McLane
Shouldn't I be able to right-click on "../" and open a window in the
parent directory?

Just clicked it and got a window with the parent directory. :-)
I have no idea what's failing here.

This fails if the directory is an environment variable, $PWD for example.

ian

[Don McLane]

Post by Don McLane
I just started using Wily and had some questions/comments. I'm running
it in cygwin (which is probably the source of my problems).
Is it supposed to display "$PWD" in the tag? Seems like that's an
expression that should be evaluated somehow.

you need to kill the PWD environment variable; e.g.
bash$ PWD= wily
although i noticed that wily is fooled by variables with values like ".".

Yes, I can get rid of the "$PWD" in the tag if I start wily like that
... but, opps, now I have to change $HOME too. And who knows what else.
Is this really a feature?

[snip]

Post by Don McLane
Shouldn't I be able to right-click on "../" and open a window in the
parent directory?

you should.

I seem to have a talent for being in the wrong place, at the wrong time,
with the wrong assumptions. It's a cygwin thing. I happened to be in
the cygwin root, "/", but knew that I was really in "C:/cygwin" and
expected that right clicking would jump up to "C:". Well it doesn't do
that in the cygwin shell either (you have to go to "/cygdrive/c" to get
to the "C:/" directory).

[snip]

Yes I actually starting looking at acme with the plan9port on linux.
Wily was attractive because it would run both on linux and windows (via
cygwin). It's not that I like windows, it's just that I'm stuck with it
for some things. I also looked at the Inferno/SAC port on windows,
however they only run plan9 commands, not native commands.

Comparing wily with acme; there are some nits: I like wily because the
up/down arrow controls cursor movement. Although I like acme because
the scroll wheel works.

Wily seems better behaved, for instance try right clicking on "Program
Files/" in acme (Inferno/SAC). Too bad! But wily doesn't complain.
(No, I don't like spaces in directory names, but they're there and I
have to deal with it).

The big feature that acme seems to have is the "win" command. There are
a lot of important programs that are textually interactive. Consider
gpg, mutt, or configuring the linux kernel before compilation. In acme,
I wonder why "Win" isn't in the top tag, it seems a natural for the
center-left cord.

Why not use "Copy" instead of "Snarf"? Familiar names ease the transition.

Cheers,
Don

[Davor Cubranic]

Post by Don McLane
Yes, I can get rid of the "$PWD" in the tag if I start wily like that
... but, opps, now I have to change $HOME too. And who knows what else.
Is this really a feature?

Why waste the space in the tag for "/home/cubranic/foo" when "$HOME/foo"
is shorter and more informative? ("~/foo" would be even nicer.)

Post by Don McLane
Comparing wily with acme; there are some nits: I like wily because the
up/down arrow controls cursor movement. Although I like acme because
the scroll wheel works.

There have been at least a couple of patches for using scroll wheel in
Wily posted here a couple of years ago, if you can track them down in the
archive.