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

[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

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

[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[2]: [9fans] home, end ^h^j^k^l

[Matt H]

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

my other one is one I'm learning to deal with

in windows if you select some text and press backspace you delete the
selected text. If you select some text in acme it replaces the current
text with a backspace so it also deletes the character to the left of
your selected text. So, as you must do, I select one less then the
ones I want to delete.

functioning cursor keys would still be a speed benefit.


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

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

[Quinn Dunkan]

> CL> What are other peoples most common acme 'gotchas'?
> 
> my other one is one I'm learning to deal with
> 
> in windows if you select some text and press backspace you delete the
> selected text. If you select some text in acme it replaces the current
> text with a backspace so it also deletes the character to the left of
> your selected text. So, as you must do, I select one less then the
> ones I want to delete.

Nowadays, I get surprised by Linux and Windows when backspace doesn't
delete backwards like it's supposed to.  Plan9's behaviour works nicely
for deleting words.  Otherwise, I've learned to use a cut chord, which
only removes that which is selected.  Since you're using the mouse
for selecting anyway, it's easy to just cut out your text.

> functioning cursor keys would still be a speed benefit.

They do function!  Oh, you mean functioning *your* way ;)


My acme gotchas:

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).

New windows rarely appear where I want them.  I gather the heuristic is
optimized for a particular pattern of use, and I recall seeing that
documented somewhere, but can't find it now.

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

[Matt H]

>> functioning cursor keys would still be a speed benefit.

QD> They do function!  Oh, you mean functioning *your* way ;)

no, I meant that the cursor keys move the cursor

I'll accept that maybe on average the mouse might be quicker but to
move 1 character in any direction but I'm stopping talking now :)

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

[Boyd Roberts]

> 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.

if you take this 'put it all on the keyboard' philosophy
to the limit you'd have an unworkably large keyboard,
and it'd always be missing a key.

it'd probably be easier to move to japan.  some of
the keyboards are something else; overlays to re-map
the array of functions/keys/...

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: Re[2]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

From: "Matt H" <matt@proweb.co.uk>
> in windows if you select some text and press backspace you delete the
> selected text. If you select some text in acme it replaces the current
> text with a backspace so it also deletes the character to the left of
> your selected text. So, as you must do, I select one less then the
> ones I want to delete.

no, you hit cut.

plan 9 gets it right, windows gets it wrong.

plan 9 replaces selected text by the typed text.  if the replacement
text is a backspace then it does exactly as advertised.  ie. there is
no special case for backspace.  special cases are a curse.

consider how drag and drop works on windows with the file mangler.
it does a copy if you drag from a: to c: but it does a move if you
drag and drop on c: -- totally counterintuitive.  it would be like
if cp(1) made an excutive decision based on source and target.

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

[Boyd Roberts]

forget termcap

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

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

[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: Re[4]: [9fans] home, end ^h^j^k^l

[rob pike]

> That's pretty cool. I suppose it would be a waste of space to
> record who deleted a file as well?

The directory will have its muid set to the most recent deleter or
creator of a file within.  There's no other obvious place to record
the information for deleting a file, since the file is gone.

-rob

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

[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

[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

[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

[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.