* Re: Samx - one more time ...
@ 2000-04-26 20:25 Paul Jackson
0 siblings, 0 replies; 9+ messages in thread
From: Paul Jackson @ 2000-04-26 20:25 UTC (permalink / raw)
To: sam-fans, Bengt Kleberg
Bengt wrote:
|> I am (very low-key) maintaining sam as it is, ...
and grateful we are for your work
|> Perhaps we complement each other? I maintain sam as it is,
|> you enhance it?
As I concluded in a private email thread that branched
off this public thread:
Seems like what I am dreaming of is really
yet-another-editor, likely using sam+samx as a code base,
and for its core design element integrating the gui and
command interface, but undergoing some major surgery, aimed
entirely at X11 environments.
Looks like I should choose yet-another-name for such a
beast, if it ever gets past being my private toy. I will
read the license that comes with Sam again, to be sure I
am fitting comfortably within its terms.
Not sure if I will go down this path or not - if you're
uncomfortable with it, let me know.
I might call it 'tam' -- because 't' comes after 's',
and because I used to work with a fine chap called
Sam Tam.
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-27 20:17 Russ Cox
0 siblings, 0 replies; 9+ messages in thread
From: Russ Cox @ 2000-04-27 20:17 UTC (permalink / raw)
To: sam-fans
One thing: Does this mean that libXg also needs changes?
The graphics model has changed quite a bit,
and there is not currently anything approximating
libXg, at least in such a form. I have vague notions
of it being a nice thing to have a libXg equivalent
for the new graphics model, and I do have many
of the pieces, but not all, and they're not packaged
correctly.
Rob should correct me if I'm wrong, but I believe
that the protocol between sam and samterm has not
changed, so that you could pick up the aforementioned
sam changes and keep using the current samterm,
if you were not inclined to do battle with X.
Russ
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-27 8:04 Bengt Kleberg
0 siblings, 0 replies; 9+ messages in thread
From: Bengt Kleberg @ 2000-04-27 8:04 UTC (permalink / raw)
To: rob, sam-fans
> From: "rob pike" <rob@plan9.bell-labs.com>
> There have been many other changes triggered by
> changes in Plan 9, rendering the Plan 9 source quite
> different from the publicly available version of Sam,
> but if someone is interested in doing the work I will
> send them the code.
Yes please. I would like to try updateing sam to the current Plan9 version.
One thing: Does this mean that libXg also needs changes?
As is perhaps known I only look after sam/samterm, not libXg.
The latter is handled by a skilled person by the name of Mark H Wilkinson.
Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. bengt@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-26 22:34 Paul Jackson
0 siblings, 0 replies; 9+ messages in thread
From: Paul Jackson @ 2000-04-26 22:34 UTC (permalink / raw)
To: sam-fans, rob pike
|> Around here, we spend most of our time avoiding adding
|> sam features.
it's already pretty damn good.
|> But we did add one recently: Redo.
excellent
|> but if someone is interested in doing the work I will
If I am able to free up a block of time, and if
Bengt is willing to pick up the merge (this would
be pure 'sam', no samx or whatever I'm doing),
then I'd like to do that. But I can't right now.
If I did that for the public sam fans, then I would
feel better about using this code base for my own
endeavors - which tend to blend Rick Davis's zip
(jot) with sam, focused on X11.
If someone else gets there first - more power to them.
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-26 22:26 Paul Jackson
0 siblings, 0 replies; 9+ messages in thread
From: Paul Jackson @ 2000-04-26 22:26 UTC (permalink / raw)
To: sam-fans, Alex Danilo
|> So, what I'm saying is that anything that changes 'sam'
|> from the Lucent release makes it not sam.
Yes - that agrees with my conclusions so far.
Ah but I'll miss the name 'sam'. That's my son's name ...
|> SGI's Open Source Server [vs] SourceForge
If it gets to the point that either I am not at SGI or that
there is enough to involve others, then definitely SourceForge.
And if it happens that I left SGI unexpectedly and suddenly, I
can certainly start the SourceForge project at that time, from
the SGI OSS base.
Perhaps sooner to SourceForge, perhaps not. Doesn't matter
much yet.
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-25 14:38 Bengt Kleberg
0 siblings, 0 replies; 9+ messages in thread
From: Bengt Kleberg @ 2000-04-25 14:38 UTC (permalink / raw)
To: pj, sam-fans
> pj@sam.engr.sgi.com
> I worry that I might be "splintering" sam
I am (very low-key) maintaining sam as it is, just doing bug fixes and adding
ports \x19(ie making sure that configure works for any new platforms).
Sometime in the future, if time permits, I will try to remove any hardcoded limits
(like the 512 characters samterm -> sam message limit).
I will not attempt to add features.
You have clearly a much broader scoop in your interest for sam.
Perhaps we complement each other? I maintain sam as it is, you enhance it?
Effectivly creating two sams, ofcourse. Presumably sam-as-it-is will stop beeing
used, and that does not matter to me since I am not doing anyhting anyway.
However, have you looked at wily? This is generally considered as a alternative to sam,
and it has loads of the things you seem (to me) to be interested in. Perhaps it would be better
to devout your energy to wily instead?
Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. bengt@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
@ 2000-04-25 12:42 rob pike
0 siblings, 0 replies; 9+ messages in thread
From: rob pike @ 2000-04-25 12:42 UTC (permalink / raw)
To: sam-fans
Around here, we spend most of our time avoiding adding
sam features. But we did add one recently: Redo. Sean
Dorward and I plugged Acme's file management stuff
into Sam a few months ago. This made it much faster
(a factor of 6 or 7) at reading big files, and made redo
possible. (The command syntax is u with a negative count;
u- redoes the last undone change).
There have been many other changes triggered by
changes in Plan 9, rendering the Plan 9 source quite
different from the publicly available version of Sam,
but if someone is interested in doing the work I will
send them the code.
-rob
^ permalink raw reply [flat|nested] 9+ messages in thread
* Samx - one more time ...
@ 2000-04-21 2:08 Paul Jackson
2000-04-25 10:59 ` Alex Danilo
0 siblings, 1 reply; 9+ messages in thread
From: Paul Jackson @ 2000-04-21 2:08 UTC (permalink / raw)
To: sam-fans
I continue to work in my spare time (slowly) adding features
to sam+samx.
I worry that I might be "splintering" sam - creating a fork of
development off the main stream. But so far as I can tell, no
one else is touching the code.
I'd like to openly consider desires and directions suggested
by others. But so far as I can tell, no one else cares.
If anyone is interested, or worried, let me know. Meanwhile, I'm
having fun adding some sugar to a really fine editor.
--
My most recent completed change is:
This patch adds two Samkeys to push and pop the current
Sam window, so that Samkeys macros can safely restore the
current window after intentionally switching to another.
This way, Samkey macros don't have to assume that they
are only invoked in the work window, say.
I have also gotten my patches working cleanly on Linux, in
addition to Irix, where I started.
I am seeking to make this work available on SGI's Open Source
Server, http://oss.sgi.com - perhaps within the next month or
two, at the leisurely pace this is proceeding. If anyone wants
it by other means or sooner, let me know. Or if Bengt or anyone
objects to this, let me know. Later on, if there is interest,
and if I get to it, I might also include this on SGI's freeware,
so that it is accessible to our Irix users as well (oss.sgi.com
is focused on Linux users).
--
My current, biased entirely to my idiosyncracies, "todo" list is:
1) Add KD_pushwin/KD_popwin so can write Samkeys macros
that don't assume starting in work window, but can
always return to whatever was the starting window.
[Done - April 17, 2000]
2) KD_markline that extends dot to full lines, and
that always extends right end of dot at least one char.
Hence repeated invocations cause dot to grow forward
by another line.
3) KD_reverselook - search upward for dot
4) debug loss of samterm/sam sync.
5) package sam+samx onto http://oss.sgi.com reasonably.
6) add samd, samb to package (for situation where
you want to control foreground vs separate window
display: samd invokes "sam -d", for when invoking
from other tools that expect an editor to not fork;
samb goes background if DISPLAY is set, else foreground,
for when invoking from other tools that should behave
differently depending on whether coming from the X11
server (gfx head) or remotely (rsh/ssh/telnet/...).
[samb, samd coded and working on March 27, 2000.
Need to package.]
7) Finish the above samkeys_parse stuff, and add Makefile
that will install sam*_* scripts as part of install,
fixing #!...perl... header along the way. [Done -
April 14, 2000]
8) Need updated samparse_keys, and add Makefile
configure stuff to handle samx as part of sam-9libs.
[Done April 13, 2000]
9) Package as rpm (source and Linux binary) with patches
called out.
10) Adapt configure/Makefile.in so that it picks up X
headers and libraries on Linux from /usr/include/X11
(or where ever X11 headers normally go) and from
/usr/X11R6/lib (in addition to /usr/lib for other
libraries).
11) Brief like Home & End key KD_BriefHome, KD_BriefEnd
support (press Home 1, 2 or 3 times to go to beginning
of line, page or file).
12) Do something about undo working off screen, and not
undoing pure motion. As it works now, I find it
surprising that doing (a) a change, (b) another
change, then (c) large motion, followed by an undo
appears to do nothing (but undoes (b)), and if the
undo is repeated, again appears to do nothing (but
undoes (a)). Either motion should be considered an
undoable event, or undo should force some part of
what it changes on screen, or ...
13) Redo sure would be nice, if I can learn sam well
enough to implement it. For one, it would help
ameliorate the botch that I get into with item (12),
undoing more than I realize or can easily recall.
14) Just as with Python's Idle (at least until recent
changes in the developers branch), it seems too easy
to get the cursor off the command line in the sam
window, and get confused as to what it means to
press enter. I'd like a tighter control by sam of
the sam window cursor, more like working at a shell
prompt, or at least along the lines of what I hear
tell has recently been done to Idle to improve its
interface there.
15) More X11 like mouse behaviour, at least when on X11,
would be nice. Though its not clear I have the skills
to implement this. The middle mouse <exch> thing is
a minor unpleasant complication.
16) The Rick Davis jot (aka zip, only on Irix) editor had
several accessible buffers for what was most recently
entered, removed, ..., making it easy to do things like
entering the same text in multiple places - typing it
once, and using the mouse and Insert key to place
duplicates of it. I miss that.
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Samx - one more time ...
2000-04-21 2:08 Paul Jackson
@ 2000-04-25 10:59 ` Alex Danilo
0 siblings, 0 replies; 9+ messages in thread
From: Alex Danilo @ 2000-04-25 10:59 UTC (permalink / raw)
To: sam-fans
pj@sam.engr.sgi.com (Paul Jackson) wrote:
>I continue to work in my spare time (slowly) adding features
>to sam+samx.
>
>I worry that I might be "splintering" sam - creating a fork of
>development off the main stream. But so far as I can tell, no
>one else is touching the code.
I'm sure there are many people 'touching' the code, it's just that
there is no formalised source project base on the 'sam' distribution,
it's just an 'as-is' release.
From what I've seen, there is a huge reluctance by the developers
(i.e. Rob) to add any 'features'. This is in line with the original
interface which is mouse for movement, and keyboard for entry only.
It is minimalistic, and is meant to be so - things like auto-indent
were never meant to be in 'sam', it isn't a user-interface ideal.
The released code was supposed to be just that - a release, and if
you want to add stuff to it, then go for it, but it won't be part
of 'sam' proper. I offered some simple mods to do implement cursor
keys a while ago in the comp.os.plan9 list, but no-one wanted it.
So, what I'm saying is that anything that changes 'sam' from the Lucent
release makes it not sam. So, if you want to add 'features', that
should be done as some alternate project, like 'samx' which is of
course sam with Xtensions.
>I am seeking to make this work available on SGI's Open Source
>Server, http://oss.sgi.com - perhaps within the next month or
I'd honestly consider creating a new project on SourceForge, as
that is (sort-of) vendor-neutral, and it can be maintained after
you leave SGI.
> 4) debug loss of samterm/sam sync.
This, as far as I can see is the only bad bug which exists in the
Lucent release. If you open a big batch of files, and do something
like:
X/.*/,x/<cr>/d
to nuke carriage returns in all your source files, sam and samterm
get out of sync and barf. This is a really nasty bug, and the Windows
version created by Sean Quinlan doesn't seem to exhibit it - so I
guess it may have been fixed internally to the Labs, but never made
it out into the public release.
By all means add new features if you wish, but it should be made a
distinct stream of development from that which we know as 'sam'.
Perhaps we could call it son-of-sam:-)
Alex
--
Alex Danilo <alex@ishtek.com> http://www.ishtek.com/alex
PO Box 333 Forestville NSW 2087 +61-2-9975-2297
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-04-28 3:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-26 20:25 Samx - one more time Paul Jackson
-- strict thread matches above, loose matches on Subject: below --
2000-04-27 20:17 Russ Cox
2000-04-27 8:04 Bengt Kleberg
2000-04-26 22:34 Paul Jackson
2000-04-26 22:26 Paul Jackson
2000-04-25 14:38 Bengt Kleberg
2000-04-25 12:42 rob pike
2000-04-21 2:08 Paul Jackson
2000-04-25 10:59 ` Alex Danilo
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).