[9fans] Sam Rewrite (Was: SAM snarf with X)

[9fans] Sam Rewrite (Was: SAM snarf with X)

[yard-ape]

(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

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Uriel]

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
> 

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Steve Simon]

Click to type is a concept that starts religious wars.
Howver rio (and 8½) are use it, to change sam
would mean plan9 would have mixture of modalaties.
Changing X sam only would mean switching between Unix
and sam would become painfull.

A mouse chording cut and paste interface exists, I saved
the details in /n/sources/contrib/steve/doc/sam-chord-patch.txt
Russ reworked this for p9p but discovered deep problems as I
rembember, the archives have the detail.

Configurable mouse - well, it wouldn't be my choice.

Unshared mouse buffer - well this is an artifact of history
but I for one am so used to it I find it strange when I use
Acme to find its not there.

Select whilst scrolling - I don't know this one.

A breakaway, more X11 style of sam was produced in 1993
odd. I don't know how bit-rotted it would be, but the code
probably exists somwhere in:
ftp://ftp.sys.utoronto.ca/pub/sam/sam-fans-list/

-Steve

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Russ Cox]

Go ahead, go nuts.  But you'll end up with a new program, not sam.
If you're good, you should be able to leave sam unaltered and just
replace samterm.

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

The die hard sam users would disagree vehemently with you.
The nice thing about sam is that it's one window, not many,
making it comfortable to edit a 30-file project without getting
caught up in managing windows.  Sam and rio both do
click-to-type and the windows look the same and that's
about the end of the similarity.

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

See above.  Cut/paste chording doesn't require giving up
the menus, by the way.  Those chords always start with button 1
being held down.

I still believe the chording code that's ifdef'ed out of the
plan9port version can be made to work.

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

If you want xemacs, you know where to find it.

>     4) The unshared snarf buffer issue is gone.

Again the sam die-hards will disagree with you on this one.

>     5) The select-while-scrolling problem is solved
>        (perhaps, again, with the simple Athena/XTerm
>        select mechanism).

I'm not sure I want to know what this really means, but
"simple Athena/XTerm" sure sounds like an oxymoron to me.

>     6) Redo!

This is already implemented.

          * u n    Undo the last n (default 1) top-level commands that
                   changed the contents or name of the current file,
                   and any other file whose most recent change was
                   simultaneous with the current file's change.  Suc-
                   cessive u's move further back in time.  The only
                   commands for which u is ineffective are cd, u, q, w
                   and D.  If n is negative, u `redoes,' undoing the   <<<<<
                   undo, going forwards in time again.

Russ

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Charles Forsyth]

>>Sort-of-seriously, Sam's clothing is starting to wear a bit.

i was going to suggest that perhaps it was
X11 that could do with a rethink!  that never seems
to me to have changed much since i first saw it.
of course, like an ageing star it has certainly had periodic face lifts,
but it still feels just as clunky.

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[erik quanstrom]

Russ Cox <rsc@swtch.com> writes

| The die hard sam users would disagree vehemently with you.
| The nice thing about sam is that it's one window, not many,
| making it comfortable to edit a 30-file project without getting
| caught up in managing windows.  

back when i was doing distributed search, i'd have sam running for
months with 200 files in the menu.

the irony was that sam was just perfect for those tedious games
one has to play on commercial projects -- like tweeking the copytight
header in each file. X:.: ,x... is your friend.

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

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.

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

| >     5) The select-while-scrolling problem is solved
| >        (perhaps, again, with the simple Athena/XTerm
| >        select mechanism).
| 
| 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.

erik

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Russ Cox]

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

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[erik quanstrom]

another difference is that double-left doesn't select until b1 is released
with samterm.

Russ Cox <rsc@swtch.com> writes

| I still believe the chording code that's ifdef'ed out of the
| plan9port version can be made to work.
| 

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[yard-ape]

Thanks for all the feedback, everyone, and I'm following up on all your leads.

-Derek

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[yard-ape]

Russ Cox wrote:

> The die hard sam users would disagree vehemently with you.
> The nice thing about sam is that it's one window, not many,
> making it comfortable to edit a 30-file project without getting
> caught up in managing windows.

Alright, but I'm not sure I get it.  Can you give an example?  I imagine Acme can boast a single, absolute UI policy only because it's a more general tool; sam(term) is just an editor, and so is always being used inside another UI setting---even if it's rio.  Rob apparently designed the behaviour for consistency with it's original setting, but woudn't it be simpler if it was determined automatically by its setting?  From "The Text Editor Sam":

	"...the most obvious [problem] is that it is poorly integrated
	into the surrounding window system. By design, the user interface
	in sam feels almost identical to that of mux, but a thick wall
	separates text in sam from the programs running in mux."

>>    3) Mouse is (gasp!) configurable...
> 
> If you want xemacs, you know where to find it.

Ouch!

> I'm not sure I want to know what this really means, but
> "simple Athena/XTerm" sure sounds like an oxymoron to me.

Granted.  *Old* Athena/XTerm, then: set dot with button one click, scroll, extend dot with button three click.

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

Thanks, I'll check that out.

>>    6) Redo!
> 
> This is already implemented.

Ah!---Seems my $MANPATH has been pointing to an obsolete sam.1!  This is a very nice surprise.

(Not sure who posted this bit):

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

I've thought the command line switch would be nice, too.

Thanks again,

Derek

Re: [9fans] Sam Rewrite (Was: SAM snarf with X)

[Russ Cox]

> Alright, but I'm not sure I get it.  Can you give an example?
> I imagine Acme can boast a single, absolute UI policy
> only because it's a more general tool; sam(term) is just
> an editor, and so is always being used inside another
>  UI setting---even if it's rio.

Rio and sam are different window managers.
If you've used both I fail to understand how you wouldn't
notice -- automatically expanding windows, the menu for
switching windows, etc.  They're different.  I also know people
who run sam under "standard" window managers like
those that come with Gnome.  I'm sure they don't want
their sam windows to behave like the rest of gnome.

Like Erik posted, do you really want to turn 200 text editor
windows over to Gnome and expect it to do something sensible?

> Granted.  *Old* Athena/XTerm, then: set dot with button
> one click, scroll, extend dot with button three click.

I thought this behavior (which, I believe, originated with PARC's 3-button
mouse and was the reason that the Mac went for the simpler 1-button
mouse) had been long acknowledged as a mistake.
On the other hand if you can make scrolling selection work like
in rio, that's the right thing to do.

For what you want, though, you can use the k command to set
a mark and then move the cursor and run ',. (or .,') to select the
region.

Russ