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

[Russ Cox]

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

type "esc", but beware that cuts it
rather than deleting it (i.e., it ends
up in the snarf buffer).

russ