Re: [9fans] home, end ^h^j^k^l

Re: [9fans] home, end ^h^j^k^l

[rob pike]

> The directory entry could be kept allocated like a zombie. disk space
> is cheap.  Of course this only handles the top of a deleted hierarchy,
> but for the purposes of knowing who deleted what it may suffice.

But how would you name it?  You're inventing a lot of mechanism
when the problem is already solved well enough.

-rob

Re: [9fans] home, end ^h^j^k^l

[nemo]

:  But how would you name it?  You're inventing a lot of mechanism
:  when the problem is already solved well enough.

I think you are right. 
But just to clarify, I meant to use the old name for the file---which
would require read() on directories to be able to return more entries
(the deleted ones) if asked to do so. Not worth given we have dump.

Re: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

> The directory entry could be kept allocated like a zombie. disk space
> is cheap.  Of course this only handles the top of a deleted hierarchy,
> but for the purposes of knowing who deleted what it may suffice.

zombies get reaped.  unreferenced files?  another piece of
code to handle them?  i certainly hope not.

Re: [9fans] home, end ^h^j^k^l

[nemo]

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

:  Then what do you do when the same file is created again?
:  Associate all the old info with the new file?
:  Rename the old file?  How do you handle collisions?

Just keep the last entry for a given name (deleted or not).  If the
file is created again, you could forget about the last deleted
directory entry w/ the same name. After all, you couldn't tell if the
file was just `modified' and the change was to rewrite it all. (Ok, you
can tell, but for the application it would be the same).



[-- Attachment #2: Type: message/rfc822, Size: 2657 bytes --]

From: Scott Merrilees <Sm@itntl.bhp.com.au>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] home, end ^h^j^k^l
Date: Tue, 22 May 2001 16:35:33 +1000
Message-ID: <200105220635.f4M6ZXZ02330@samarium.itntl.bhp.com.au>

>nemo@gsyc.escet.urjc.es:
>The directory entry could be kept allocated like a zombie. disk space
>is cheap.  Of course this only handles the top of a deleted hierarchy,
>but for the purposes of knowing who deleted what it may suffice.

Then what do you do when the same file is created again?
Associate all the old info with the new file?
Rename the old file?  How do you handle collisions?

If you really want to know who deleted a file, wouldn't it be easier to
just maintain a log somewhere?

Sm

Re: [9fans] home, end ^h^j^k^l

[Scott Merrilees]

>nemo@gsyc.escet.urjc.es:
>The directory entry could be kept allocated like a zombie. disk space
>is cheap.  Of course this only handles the top of a deleted hierarchy,
>but for the purposes of knowing who deleted what it may suffice.

Then what do you do when the same file is created again?
Associate all the old info with the new file?
Rename the old file?  How do you handle collisions?

If you really want to know who deleted a file, wouldn't it be easier to
just maintain a log somewhere?

Sm

Re: [9fans] home, end ^h^j^k^l

[nemo]

rob pike wrote:
> There's no other obvious place to record
> the information for deleting a file, since the file is gone.

The directory entry could be kept allocated like a zombie. disk space
is cheap.  Of course this only handles the top of a deleted hierarchy,
but for the purposes of knowing who deleted what it may suffice.

Re: [9fans] home, end ^h^j^k^l

[Douglas A. Gwyn]

rob pike wrote:
> There's no other obvious place to record
> the information for deleting a file, since the file is gone.

Oo, oo, recycle bin!

Re: [9fans] home, end ^h^j^k^l

[Douglas A. Gwyn]

Boyd Roberts wrote:
> > no, I meant that the cursor keys move the cursor
> with glass ttys you learnt pretty quickly not to use
> them across tcp connections.  things like vi would use
> a timer to collect a multibyte [arrow key] sequences.
> bad stuff would happen if part of the sequence arrived
> late.

That is an artifact of a certain combination of historical
design errors, and need not affect use of the modern
workstation where each keypress is encoded in a single datum.

Re: [9fans] home, end ^h^j^k^l

[Douglas A. Gwyn]

Quinn Dunkan wrote:
> Deleting text with backspace replaces the snarf buffer.  I often cut out
> something I want, and then do some editing to prepare a place for it, and wind
> up deleting a space or something, at which point my paste doesn't give what I
> expected.  I don't think the snarf buffer should be quite so ephemeral, but it
> probably also has something to do with how I work (i.e., if I want to snarf
> something, I snarf, and if I want to delete it, I delete).

It's not just you; I keep running into this problem using "sam".
Partly it's coupled to the behavior of backspace for a highlighted
region: to exactly delete what is highlighted, one has to cut it,
which overwrites the snarf buffer.
I would actually prefer an array of snarf buffers (a la TECO's
Q-registers), but then the complexity starts to overwhelm the
user.  I doubt it is possible to design a *small* interface that
best fits all usage patterns.

Re: [9fans] home, end ^h^j^k^l

[Douglas A. Gwyn]

Also, guys, please remember that there are numerous blind users
and programmers who need a non-graphically oriented user interface.
That doesn't mean that sighted persons should be confined to such
an interface, but rather than a GUI should not be the *only* way
to use a facility unless it is logically necessary.

Re: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

forget termcap

Re: [9fans] home, end ^h^j^k^l

[rog]

> What are other peoples most common acme 'gotchas'?

when button-3 clicking through a file, i quite often jiggle the mouse
slightly on the click, and end up searching for a single character
instead of the whole word.

perhaps a little attention to timing could help here:  if i'm selecting
some text, i think i always take more than 1/2 a second to do it, so
perhaps a down-up motion of less than 1/2 (1/3?) a second could always
be taken as a single click.

i reckon the "selecting more than one line" problem could be partially
due to the fact that it's difficult to make straight horizontal lines
with the mouse, as the hand tends to describe an arc around the wrist,
so it'll tend to be lower at the right end of the arc.

i look forward to chris's hysteresis modifications :-)

  rog.

Re: [9fans] home, end ^h^j^k^l

[Scott Schwartz]

| One thing in acme that quite often bites me is the tendency when
| chording a cut for the cursor to drop onto the line below and cut
| much more than I intended.

I've noticed that too. It also happens between characters on the same
line.  Your hysteresis idea seems plausible.  Send patches!

Re: [9fans] home, end ^h^j^k^l

[Chris Locke]

One thing in acme that quite often bites me is the tendency when
chording a cut for the cursor to drop onto the line below and cut
much more than I intended.

I must have a tendency of keeping the cursor close to the bottom of
the line when making a selection. The action of chording the middle
button is often enough to drop the cursor down a fraction onto the
lower line, just as the cut is done.

One thing that would make this much less likely to happen was if there
were some hysteresis in selecting across lines. i.e. the selection
would only extend into another line when the cursor had moved a
few pixels vertically into it.

Perhaps I should just be more careful!

What are other peoples most common acme 'gotchas'?

Cheers,
Chris.

Re: [9fans] home, end ^h^j^k^l

[Russ Cox]

> keys. I find it slightly cumbersome so reach for the mouse to move
> up a line in acme and I keep instinctively press the up key and lose
> my concentration when I find myself a page away.

I've been using Wily recently, and I keep instinctively
pressing the up key and lose my concentration when I 
find myself still on the same page but with a moved
cursor.

It's just different.  I'm not convinced one is better
than the other.  I do notice that when I try to use
the arrow keys to move the cursor, I get frustrated
with how much more time it seems to take than when
I use the mouse.

Give it a bit more time, you'll get used to (and
appreciate) both depending on your environment.

Russ

[9fans] home, end ^h^j^k^l

[Matt H]

Hello 9fans,

  here's my question for today

  over the years i've rather got used to home, end and the cursor
  keys. I find it slightly cumbersome so reach for the mouse to move
  up a line in acme and I keep instinctively press the up key and lose
  my concentration when I find myself a page away.

  So, is there a simple way to enable those keys to move as I expect
  them to (without hacking the source)?

  If not then my supplementary is why?
  What's the philosophy of not allowing the cursor keys to move the cursor?

  Same goes for the shell. I love the freeform nature of it but really
  miss home and end. Ctrl-U is about as good as it seems to get.

  I hope I'm missing something, I'd be disappointed to lose out on all
  that keyboard training.

-- 
Best regards,
 Matt                          mailto:matt@proweb.co.uk