headers
Mike Haertel | 1 Jun 2002 01:36

problem with cursor warping and vnc server

I just noticed that cursor warping seems not to work when using
the Windows VNC client to view the Plan 9 VNC server.  For example,
in Acme, when you right-click on selected text to look for the next
occurence, you expect the cursor to get warped to that location.

What I am seeing is: the cursor appears to get warped, but then the
moment I move the mouse it jumps back in its old location.

Is this a Plan 9 VNC server bug, or a Windows VNC client bug?
Permalink | Reply | 0 comments |
headers
rob pike, esq. | 1 Jun 2002 01:44
Favicon

Re: problem with cursor warping and vnc server

The VNC protocol has no mechanism to move the cursor.

-rob
Permalink | Reply | 0 comments |
headers
Russ Cox | 1 Jun 2002 03:55
Favicon

Re: problem with cursor warping and vnc server

> The VNC protocol has no mechanism to move the cursor.

The Plan 9 VNC protocol uses an extension to do this,
but I'm not sure whether we made it up ourselves or whether
it's actually used elsewhere.  I suspect the latter.  It was
put in by Dong Lin, who uses the X VNC client quite a bit.

In any event, it's trivial enough to add to the Windows
client.  I don't remember the call off the top of my head,
but the drawterm source does it.

Russ
Permalink | Reply | 1 comment |
headers
Michael Baldwin | 1 Jun 2002 05:35

spaces in filenames

really, what is the big deal with spaces in filenames?  yeah, there are 
some file formats here and there, and some shell files that maybe aren't 
so careful, so it's not a cakewalk, but it isn't some Big Huge Problem.  
using shells like rc that manage lists of string works quite well; if 
you need a list of files use "ls" not "echo"; if you really want to use 
the output of a command with backquote, set ifs to \t\n.

geoff talks about how maddening it is to use filenames with spaces on 
mac os x.  i use mac os x too, and have lots of files with spaces, and i 
use quotes on the occasion that i refer to them in the shell.  i haven't 
noticed any "problem" that would cause me to go mad, and everything 
works just fine from the shell and the gui for me.  i send spacey 
filenames to web sites, attach/detach them from mail messages, move them 
about, and things work.  what am i missing?  now that i can use spaces, 
i kinda like using space instead of _ in names -- easier to type and 
easier to read.  why banish the poor lowly space character?  so call me 
a communist for my radical views.

the only problem i've had with spaces is getting to spacey files on 
windows and unix from plan 9 and inferno.  i took out the space 
restriction in inferno and things work swimmingly.  yeah, i know there 
are gotchas here and there, but they really haven't been an issue.  i 
much prefer the ability to manipulate files to the odd gotcha.

oh, the non-printable range also includes 7F, so it's really 00-1F and 
7F-9F that are restricted.  it does seem to be a Good Thing that \t and 
\n are not allowed, leaving them usable as delimiters.  unix lets you 
create such files, but they definitely seem rare, and it is a bit harder 
to do from a gui.  who cares if they don't work right.  but leave poor 
space alone.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geoff Collyer | 1 Jun 2002 07:02

Re: spaces in filenames

Okay, you're a communist.  ☺

On Unix, part of the problem is scripts that use $* when they should
use "$ <at> ", but the need to quote file names containing spaces
interactively is an on-going nuisance.

If you're going to allow spaces, then why not allow tabs?  They have
traditionally been considered equivalent whitespace, with a few
exceptions (e.g., make, tbl).  I don't see a compelling reason to
allow spaces but not tabs.  And if you allow spaces and tabs, why not
newline, it's whitespace too.  And as long as we're allowing any old
character in file names, why not allow slashes in file name
components?  Sure, we'll have to introduce some ugly hack like having
the kernel understand /this\/is\/all\/one\/component, but by now we're
not afraid of a little quoting, right?  And why discriminate against
NUL?  Shouldn't one be able to have a file name like 'This is a
history of the \0, \\ and \/ characters in computing, © 2002 <a
href="http:\/\/pedant.com\/peter.jpg">Peter Pedant<\/a>', where \0
represents a NUL byte?

We could also adopt another Mac OS tradition, case-insensitive file
names.  Pretty soon our file names will be as ungodly a stew as
anything ever parsed by MVS or VMS.
Permalink | Reply | 1 comment |
headers
Michael Baldwin | 1 Jun 2002 15:41

Re: spaces in filenames

> On Unix, part of the problem is scripts that use $* when they should 
> use "$ <at> "

yeah, so fix them, if it's so easy.  are there lots of these around?  i 
haven't noticed.

> but the need to quote file names containing spaces interactively is an 
> on-going nuisance.

i guess if you think 'quoting' is a nuisance.  yes, you have to quote 
spaces in shell args.  i also have to quote '=' in rc args, and i have 
to quote ( ) { } * ? and a bunch of other characters.  so what?

> If you're going to allow spaces, then why not allow tabs? ... why not 
> newline ... why discriminate against NUL ...

because filenames are supposed to be printable "labels" for things.  
tabs are control characters to adjust the "carriage", like CR and NL 
are.  NUL is a control character.  space is just a space, and is thought 
of as printable.  putting spaces in labels is not a radical idea.  ever 
label a paper folder "Mom's recipes"?  i don't feel obligated to put an 
underscore in there instead.  and let me tell you, her stuffed peppers 
are to die for.

and i've already said it is very useful to have characters that are 
guaranteed to be useful as separators.  slashes are used for pathname 
element separation, and for the same reason, it seems a good idea to 
have a character that always works as an element separator.

so stop confusing the issue.  i'm talking about space.  JUST SPACE.  not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Cox | 1 Jun 2002 15:46
Favicon

Re: spaces in filenames

looks like you pulled in a big one, geoff.
where do you get such great lures?
Permalink | Reply | 5 comments |
headers
Richard Miller | 1 Jun 2002 15:56
Picon
Picon

Re: spaces in filenames

I got myself into trouble recently by misunderstanding the syntax
of the kfs 'rename' command.  If you do something like

  disk/kfscmd 'rename /tmp/xxx /tmp/yyy'

you end up with a file in /tmp with slashes in its name.  Exercise
for the reader: how do you get rid of it?

-- Richard
Permalink | Reply | 0 comments |
headers
Russ Cox | 1 Jun 2002 16:01
Favicon

Re: spaces in filenames

> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
> 
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
> 
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

That's one of the first Plan 9 mistakes I ever made.
I killed off the partition and started afresh.  (Not the right answer.)

Anyhow, you didn't misunderstand the syntax.
That should have worked.  That's how the
install moves your old file system into /3e.
The case where src and dst are in same
directory must use the wrong name.

Russ
Permalink | Reply | 0 comments |
headers
Russ Cox | 1 Jun 2002 16:10
Favicon

Re: spaces in filenames

> You should be able to rename it again; maybe you'll need to rename
> it in to another directory if there is a bug.

BZZT!  How do you rename it?  When you pass
the path to kfs or the kernel, it will tokenize
it into

	'tmp' 'xxx' 'tmp' 'yyy' 

instead of

	'tmp' 'xxx' '/tmp/yyy'

as is necessary.
Permalink | Reply | 0 comments |

Gmane