9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Uriel <uriell@binarydream.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Sam Rewrite (Was: SAM snarf with X)
Date: Sat,  8 Oct 2005 14:01:20 +0100	[thread overview]
Message-ID: <20051008130120.GA5588@server4.lensbuddy.com> (raw)
In-Reply-To: <4347bf3c.jG0d8omwXYyqNEYo%yard-ape@telus.net>

I think that one of the nice things about sam is that it works
identically on all systems.

For everything else, there this acme and p9p

uriel

On Sat, Oct 08, 2005 at 05:44:44AM -0700, yard-ape@telus.net wrote:
> (Just read that comp.os.plan9 isn't working, so I'm reposting here on 9fans.)
> 
> > would it be utter sacrilege and or a complete waste of time
> > to add some acme features to samterm like:
> > 
> > 1. sharing the snarf buffer with the window system.
> > 2. cording
> > 
> > i've been thinking about this for a while, but haven't gotten
> > to it.
> 
> If we're going to talk sacrilige, how about a complete rewrite for a more conventional window managment setting?  (This should probably continue, if at all, on comp.editors, where I've also posted it.)
> 
> Sort-of-seriously, Sam's clothing is starting to wear a bit.  Acme might make most of that irrelevant for most Plan 9 users; but those of us using X11 *and* devoted to sam notice the aged (and alien) artifacts alot more.  And that's a shame, because with a smart window manager, a good terminal program, and some p9p tools, a pared-down, X-conscientious sam would be wonderful:
> 
>     1) X-conscientious-Sam doesn't need its own
>        window system (with mux policies); the
>        window manager can all do this (allowing
>        point-to-type, and whatever else).
>     2) "1)" means that more than half of the mouse
>        menu items are shed, allowing for more
>        responsive cut/paste behaviour (such as
>        Acme's, or the conventional Athena/XTerm
>        behaviour).
>     3) Mouse is (gasp!) configurable---via Xrdb
>        if nothing else.  This would cut down
>        on news traffic about mouse behaviour.
>        And Xclipboard would be a neat external
>        mouse-based snarf-buffer array solution.
>     4) The unshared snarf buffer issue is gone.
>     5) The select-while-scrolling problem is solved
>        (perhaps, again, with the simple Athena/XTerm
>        select mechanism).
>     6) Redo!
> 
> I should add that I don't know what I'm talking about; I've never written an a whole X client before.  But some of you have.  How hard could it be!
> 
> -Derek
> 


  reply	other threads:[~2005-10-08 13:01 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 [this message]
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
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=20051008130120.GA5588@server4.lensbuddy.com \
    --to=uriell@binarydream.org \
    --cc=9fans@cse.psu.edu \
    /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).