9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox <rsc@swtch.com>
To: erik quanstrom <quanstro@speakeasy.net>
Cc: 9fans@cse.psu.edu
Subject: Re: [9fans] Sam Rewrite (Was: SAM snarf with X)
Date: Sat,  8 Oct 2005 20:11:53 -0400	[thread overview]
Message-ID: <ee9e417a0510081711h5c9825eeu7b8d347e26ab5c1c@mail.gmail.com> (raw)
In-Reply-To: <20051008174658.484501301BD@dexter-peak.quanstro.net>

> | I still believe the chording code that's ifdef'ed out of the
> | plan9port version can be made to work.
>
> is there any particular senerio that causes a problem; i'd be
> willing to take a stab at this.

rob just played with it for a while and got it to break.
of course, the current code doesn't behave exactly as acme's
anyway, and it should.

> i know you've mentioned protocol jam but i can't picture how
> the protocol events would be different between b1+b2 and
> menu→cut. clearly, i'm missing something.

that's why i think it can be made to work.  i see the same thing.

> | >     4) The unshared snarf buffer issue is gone.
> |
> | Again the sam die-hards will disagree with you on this one.
>
> i would like to unshare the buffer; but i'm not intersted
> in offending. perhaps this could be switched either via
> command line or menu option. (ya, i know. don't kill me
> for the menu option idea.)

surprisingly this is easier in x than in plan 9.
the bad part about sharing the snarf buffer with x is that
if you're running sam -r over a long-distance connection,
then if you snarf some big piece just to paste in another
sam buffer, there's no reason to pull it all the way across
the connection just to send it back up.  x's snarf model
accomodates this, though that makes it much harder to
deal with in the easy cases.

> | I'm not sure I want to know what this really means, but
> | "simple Athena/XTerm" sure sounds like an oxymoron to me.
>
> uh, i really don't think that you need to be this radical. i've got
> some code that allows 9term to scroll-select. they're based on
> basically the same "struct Text", so i think it's doable.

i'm sure scrolling during select is doable and fine.
"simple Athena/XTerm" was the scary part.

russ


  reply	other threads:[~2005-10-09  0:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-08 12:44 yard-ape
2005-10-08 13:01 ` Uriel
2005-10-08 15:17 ` Steve Simon
2005-10-08 15:45 ` Russ Cox
2005-10-08 15:51   ` Charles Forsyth
2005-10-08 17:46   ` erik quanstrom
2005-10-09  0:11     ` Russ Cox [this message]
2005-10-08 18:02   ` erik quanstrom
2005-10-09  9:50 yard-ape
2005-10-09  9:53 yard-ape
2005-10-09 15:41 ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee9e417a0510081711h5c9825eeu7b8d347e26ab5c1c@mail.gmail.com \
    --to=rsc@swtch.com \
    --cc=9fans@cse.psu.edu \
    --cc=quanstro@speakeasy.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).