XEDIT and REXX for UNIX
W. J. Metzger
combinations for UNIX. (I ignore the XEDITs which do not allow REXX
macros and REXXes not reported to be usable from an XEDIT.)
1. THE + REGINA (free) (also for DOS)
2. Uni-XEDIT + Uni-REXX (commercial)
3. SEDIT + S/REXX (commercial)
Has anyone made a comparison of these? Are there reasons to prefer one
over the others? I assume that there are features of good old CMS
XEDIT that are missing in some or all of these implementations.
Thanks for any advice, Wes
Paul F. Kunz
Regina is twice as fast as uni-Rexx on the benchmarks written by Mike,
the author of Rexx. However, it lacks some user-friendly interfaces
to UNIX, all of which are not part of the Rexx language.
As far as XEDIT goes, IMHO Emacs is to UNIX as XEDIT is to VM;
namely there are so many things that run under emacs on UNIX, that you
can't fight it, you really ought to learn Emacs. For example, I read
this article and am posting a reply under Emacs; if I were using VM, I
would have made the same statement about XEDIT.
This message coming to you by an author of quite a number of useful
XEDIT macros, including prefix macros, written in Rexx. Now, I never
touch XEDIT except to give someone a gee-wiz demo of uni-XEDIT under
UNIX.
--
Paul F. Kunz Paul...@slac.stanford.edu (NeXT mail ok)
Stanford Linear Accelerator Center, Stanford University
Voice: (415) 926-2884 (NeXT) Fax: (415) 926-3587
Tom R. Loden *8^0
I have bought both Uni-XEDIT and SEDIT. At first, I thought SEDIT
was wonderful. (Oh, BTW, we have Sun SPARC2s). It had a few nice features
like (1) being X (2) having non-X versions (3) getting man pages
and a few others. But after awhile, I started using the Uni-stuff
almost exclusively (keep in mind I HATE windows & mice, but, what
are ya gonna do). With Uni-XEDIT 1.3, they fixed a fair amount of
some annoying bugs that makes it usable. Here's a list of annoying things
from both:
SEDIT Problems (non-exhaustive) on Sun SS2:
1. can't increase size of cmd buffer
2. "next field" goes to top of screen, not first line
(say when curl = 1 and set to 'm')
3. commands that don't exist
a. move
b. rhgtleft
c. recover (does have : undo - )
d. dup (does have : c_dup - )
e. query column
f. del -1
g. del /xxxxxx/
h. set trunc
i. recover
j. set arbchar
k. set wrap
4. "screen n" screws up "curline" setting
5. "sch" doesn't wrap
6. it is VERY slow
Uni-XEDIT Problems (non-exhaustive) on Sun SS2:
1. Things that are not available :
a. "query keybind" (there is an undocumented feature that does this)
b. "set hex on" (ED, ARE YOU LISTENING? HOW ABOUT THIS FOR A
CHRISTMAS PRESENT? 8^) )
c. "join"
d. "split"
2. "get" only works once
3. shift-tab does not work
4. delete key does not work
5. unixedit destroys the previous screen when exitting (must do
a refresh : OPENWINDOW CMDTOOL ONLY )
7. no "clear" key emulation
8. "del -1" starts at curline (I thought I remember this starting
on the curline - 1 on our mainframe)
9. "case u" forces cmdline commands to be in upper case.
10. "schange" :
a. won't wrap
b. does not get put inot the command buffer
c. starts at last find, not at cursor
d. misses strings. you have to goto :1 then reinvoke the command
11. the cmd buffer is very limited.
12. there are no blanks at the eol (set nulls off doesn't work?)
13. "hext" goes down one line after a return to editor.
14. there are problems with the f keys in an Open Look xterm
( you have to 'shift' pf6 - pf10 : in an xterm, f6 gives a
\E[17~, not \E[16~, etc.)
15. files with lines > 256 chars. get truncated
16. when I re-wrote si.xedit for the sun, i came across some 'set
pending' problems. it seems that the prefix area gets checked
for pending stuff ONLY after the prefix area has been changed
and not every time (enter or pf key).
==============================================================
Tom R. Loden MIT Lincoln Lab Marry a job.
Lexington, MA 02173 Buy a wife and kids.
617-981-3249 Have a house together.
Edward T Spire
It includes the following enhancements in the below mentioned areas:
Tom R. Loden *8^0 (lo...@ll.mit.edu) wrote:
: Uni-XEDIT Problems (non-exhaustive) on Sun SS2:
: 1. Things that are not available :
: b. "set hex on" (ED, ARE YOU LISTENING? HOW ABOUT THIS FOR A
: CHRISTMAS PRESENT? 8^) )
set hex works properly in V1.32
: c. "split"
There is an "msplit" macro in the sample library that does most of what
split does. We will do split and join eventually.
: 2. "get" only works once
You can "get" more than once in V1.32
: 3. shift-tab does not work
I don't think there's anything we can do about this. A curses
application is receiving the same character (a tab character) for the
tab key and the shift-tab key. There may be an X level key mapping
thing that will help...
: 4. delete key does not work
Once again, I wonder what it is sending. We would expect to receive
curses KEY_DELETE, but often the vendor supplied TERMINFO for the
effective TERM is not correct. I would urge you to run the keybind
utility and bind the delete key to the xedit DELETE action.
It would be nice if the vendor supplied TERMINFOs were complete.
Since that is not true, local keybind action is often required
to make some keys work the way you want. We do send sample keybind
sets, but I suspect you're running as an XTERM (not a sun-cmd)
and XTERMs vary from system to system, so it's hard to write a
single XTERM keybind set that will satisfy everybody.
(hey, what happened to 6?)
: 7. no "clear" key emulation
Please tell us the useful function that the 3270 clear key provides
for you, and how it adapts to the asnychronous terminals used in Unix.
: 8. "del -1" starts at curline (I thought I remember this starting
: on the curline - 1 on our mainframe)
The mainframe product works just as you describe uni-XEDIT working,
so I suspect your memory is faulty in this case.
: 9. "case u" forces cmdline commands to be in upper case.
This is fixed in V1.32
: 11. the cmd buffer is very limited.
How big should it be?
: 12. there are no blanks at the eol (set nulls off doesn't work?)
Ah, now here's a point worthy of discussion.
One way to interpret this remark is that the user would like all the
records in the file to be padded out to "lrecl" with blanks when the
file is saved. I sincerely doubt that that is the intent.
The more likely interpretation is that targets with blanks at the
end of the string doen't match data at the end of a line, since the
records in memory are not padded out to blank. We have several thoughts
on this, and would be interested in user comments.
- We could pad records out to lrecl with blanks when they are read in,
and trim trailing blanks when we write the data out again, which is
what CMS XEDIT does with variable format records. However, this would
cause any trailing blanks that were really present in the file to
disappear (something that may not be acceptable to some users), as
well as any trailing blanks that the user actually typed. It
would also cause the file to use much more memory than it currently
does (which has performance implications.)
- We could probably emulate the above algorithm without really using
a lot of memory (i.e., expand the record when it is internally accessed,
and trim trailing blanks when it is returned to the record buffer.)
But we would still want to be sure that users wouldn't object to the
loss of trailing blanks that may have previously existed in the file,
as well as trailing blanks that were actually typed. There would be
performance implications for this as well.
- Perhaps the best approach would be to keep the data as originally
found (or entered at the keyboard) and modify the target search
algorithms so they act as if there were some extra blanks at the end of
each record. The only drawback I can see in this approach is a
performance hit to the target search code (and effort in writing
a more complex search algorithm.)
It seems that CMS XEDIT does the first of the above (or maybe the
second, hard to tell), so the loss of preexisting (or typed) blanks
at the end of a line may be acceptable based on precedent. On the
other hand, it is possible that some typical unix file layouts will
require trailing blanks. Remember, in CMS, variable format files are
the exception, whereas in unix, all files are variable format.
BTW, set nulls seems to have no effect in this area in CMS, and I
continue to see no function that set nulls should provide in Unix.
Comments, please.
: 13. "hext" goes down one line after a return to editor.
This is fixed in V1.32
: 14. there are problems with the f keys in an Open Look xterm
: ( you have to 'shift' pf6 - pf10 : in an xterm, f6 gives a
: \E[17~, not \E[16~, etc.)
Ah, you **are** using xterm! Once again, these come from the xterm
implementation not matching the xterm terminfo definition. Both of
these are provided by the vendor. Judicious use of the keybind utility
can solve these problems.
Note that SEDIT is only available for Sun platforms, so it is easier for
them to deliver a product that is heavily customized for Sun's
configuration, warts and all. Our product runs on all popular
platforms, and it is just about impossible for us to be in-depth
experts on all platforms and deliver a product that is 100% configured
for every platform. Hence we leave some of the configuration work to
the installer, and provide utilities (in this case, the keybind utility)
to assist him. If this is a serious problem for the user community, I'd
like to hear about it, and perhaps we would change our intent in this
area.
: 15. files with lines > 256 chars. get truncated
This is fixed in V1.32
: 16. When I re-wrote si.xedit for the sun...
If you have really re-written si (i.e., if it contains no IBM
copyright code) perhaps you would care to contribute it for our
sample library...
The items that Tom mentioned for which I have not responded are
unchanged, but still on our list of things to do.
BTW, early next year, V2.0 will be out, which will be able to use
X resources (scroll bars, windows, mice) if present.
-Ed
ps: This discussion probably doesn't belong in this newsgroup
(even though there probably are a lrage number of interested parties
here) so if anyone objects, we should move it elsewhere.
--
========================================================================
===== "The heart must mediate between the brain and the hands" =====
Ed Spire e...@wrkgrp.com (on uunet)
Mark Hessling
Just a clarification on the first item. The '(also for DOS)' implies REXX
support for the DOS version. Unfortunately at the moment that is not the
case. Possibly it should have read '(also for OS/2)'; the OS/2 version
does have REXX support.
------------------------------------------------------------------------
Mark Hessling Email: M.Hes...@gu.edu.au
DBA,ITS Phone: +617 875 7691
Griffith University Fax: +617 875 5314
Nathan, Brisbane QLD 4111 ***** PDCurses Maintainer *****
Australia *** Author of THE and GUROO ***
------------------------------------------------------------------------
Horst Kiehl
in article <1993Oct7.2...@wrkgrp.COM>,
e...@wrkgrp.COM (Edward T Spire) writes:
>Tom R. Loden *8^0 (lo...@ll.mit.edu) wrote:
>: 12. there are no blanks at the eol (set nulls off doesn't work?)
>
>Ah, now here's a point worthy of discussion.
I agree (but what do I have to say - I'm not a uni-XEDIT user), ;-) so
I'll describe briefly what KEDIT does and give a slight suggestion.
>One way to interpret this remark is that the user would like all the
>records in the file to be padded out to "lrecl" with blanks when the
>file is saved. I sincerely doubt that that is the intent.
> - We could pad records out to lrecl with blanks when they are read in,
>and trim trailing blanks when we write the data out again, which is
>what CMS XEDIT does with variable format records. However, this would
>cause any trailing blanks that were really present in the file to
>disappear (something that may not be acceptable to some users), as
>well as any trailing blanks that the user actually typed. It
>would also cause the file to use much more memory than it currently
>does (which has performance implications.)
As I understand it, this is what KEDIT does by default, the only
difference being that it ppends blanks up to WIDTH and not only to
LRECL. To allow trailing blanks to be written to disk, KEDIT offers two
settings:
* [Set] RECFM Fixed|Varying
With RECFM Fixed, KEDIT writes a fixed number of characters for each
line; this number is the LRECL. With RECFM Varying, the default, it
writes all characters through the last nonblank character in each
line by default; this can changed by a non-default TRAILING setting.
* [Set] TRAILING ON|OFF|SINGLE|EMPTY
ON: the way uni-XEDIT behaves according to your description
OFF: the default, as described above
SINGLE: like OFF plus a single blank added to each line
EMPTY: like OFF plus a single blank added only to each *empty* line
To improve uni-XEDIT's compatibility, you might implement the ON and OFF
options of TRAILING. (That would be some compatibility with KEDIT; I
don't know hoe THE (or SEDIT for that matter) behaves.)
However, regarding (leading or) trailing blanks in the target (like in
/foo /), KEDIT seems to behave like uni-XEDIT, as it seems to compare
the target with what is actually in memory even when TRAILING is set ON,
and that is the full WIDTH for each line, padded to it with blanks.
This is based on KEDIT documentation and some testing. Anyone who knows
better, please correct me!
Horst
- - - - - - - - - - - - - - - - - - - - - - -
Horst Kiehl - Internet h.p....@kfa-juelich.de
Ian Collier
and directing followups there. Feel free to ignore this (at your peril :-) )
if you like.
In article <1993Oct6.1...@ll.mit.edu>, lo...@ll.mit.edu (Tom R. Loden *8^0) wrote:
>Uni-XEDIT Problems (non-exhaustive) on Sun SS2:
> 1. Things that are not available :
> b. "set hex on" (ED, ARE YOU LISTENING? HOW ABOUT THIS FOR A
> CHRISTMAS PRESENT? 8^) )
:-)
> 2. "get" only works once
How do you mean? Seems fine to me.
> 3. shift-tab does not work
The Sun does not seem to have a concept of "backtab", and so its Tab
key generates the same code whether or not you press shift. You are
more-or-less stuck with that unless you can hack the keymap (under X11R5,
the command `xmodmap -e "keycode 60 = Tab Something Tab"' does that, where
`Something' is some symbolic key name. Unfortunately, X does not seem to
have a symbolic name for a backtab key so you may have to use a function
key name like F35 and use uni-XEDIT to map the resulting sequence (on my
machine it's \e[222z) to the backtab key).
Similarly, the F11 and F12 keys do not seem to work on my machine unless I
use xmodmap to map them.
Neither of these (i.e., shift-tab and F11/12) are problems with Uni-XEDIT,
in my opinion.
> 4. delete key does not work
This is a bit odd, I agree, but you can easily map it with the command
SET KEYBIND \x7f KEY DELETE
Slightly irritating (but not on my top 16 list) is the fact that there
is no native "destructive backspace" key. You can do:
SET KEYBIND ^H COMMAND MACRO dbs
where dbs is a macro from the samples directory, but this key will not
work on the command line.
> 9. "case u" forces cmdline commands to be in upper case.
It does on VM XEDIT as well. However, the Uni-XEDIT behaviour is different
as it translates while you type rather than after you enter the text.
Uni-XEDIT does not change the case of a whole line when you modify it,
unlike VM XEDIT.
> 10. "schange" :
> a. won't wrap
> b. does not get put inot the command buffer
> c. starts at last find, not at cursor
> d. misses strings. you have to goto :1 then reinvoke the command
e. often doesn't seem to work at all.
f. does not use the most recent change command
> 12. there are no blanks at the eol (set nulls off doesn't work?)
The manual says that "set nulls" does nothing. However, it isn't usually
possible to tell the difference. What are you doing that needs nulls off?
> 14. there are problems with the f keys in an Open Look xterm
> ( you have to 'shift' pf6 - pf10 : in an xterm, f6 gives a
> \E[17~, not \E[16~, etc.)
This is probably to do with your terminal rather than with Uni-XEDIT.
I have a lot of problems with function keys, because they generate Sun
sequences (e.g. \e[224z for F1), whereas the terminfo description for
xterm gives VT100-like sequences (e.g. \eOP for F1). Therefore I have
to define all the key bindings myself.
> 15. files with lines > 256 chars. get truncated
Files with lines >80 chars and <256 chars cannot be viewed in line wrap mode
(as per VM XEDIT).
In exchange for my defence of Uni-XEDIT in several of the above points, here
is a short list of my own.
1. The message text for "Unknown command" is actually "Invalid operand".
2. Find and Findup do not appear to do anything
3. Changing the filename of a file and saving it periodically will lead to
repeated "That file already exists so use SSAVE" messages, even if the
file didn't exist before.
4. The backtab key does not work properly:
a. in the command line, when prefix is off,
b. in the file, during input mode.
5. Spltjoin does not split or join "aligned", that is, respecting the
indention of the line containing the cursor. Also, it can be used
to create lines with trailing spaces which shouldn't be there.
I have maintained the balance; I am neither for nor against Uni-XEDIT
(but I do use it, and I would like to stay in Ed's good books :-) ).
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Rodger Bagnall
>require trailing blanks. Remember, in CMS, variable format files are
>the exception, whereas in unix, all files are variable format.
2,897 have variable length records, 559 have fixed.
Tom R. Loden *8^0
>set hex works properly in V1.32
Thanx!
>There is an "msplit" macro in the sample library that does most of what
>split does. We will do split and join eventually.
Not really. Msplit is very limited. The 'whole point' of split is to
be able to use it from a function key.
>You can "get" more than once in V1.32
Excellent!
>
>: 3. shift-tab does not work
>
>I don't think there's anything we can do about this. A curses
>application is receiving the same character (a tab character) for the
>tab key and the shift-tab key. There may be an X level key mapping
>thing that will help...
OK. But how about another key-stroke for 'goto-last-field'?
>: 7. no "clear" key emulation
>
>Please tell us the useful function that the 3270 clear key provides
>for you, and how it adapts to the asnychronous terminals used in Unix.
Someone somewhere explained this to me. In the mainframe/3270 environment,
the whole screen is processed at once. So, one can type to their hearts
content, screw up, hit the 'clear' key, and bingo : none of the typing
is recorded (i.e., sent down the line to the mainframe - locally buffered?).
This is unlike UNIX, where each key-stroke is processed seperately.
How about
>: 8. "del -1" starts at curline (I thought I remember this starting
>: on the curline - 1 on our mainframe)
>
>The mainframe product works just as you describe uni-XEDIT working,
>so I suspect your memory is faulty in this case.
Nevermind.
>: 11. the cmd buffer is very limited.
>
>How big should it be?
Configurable or 20-50 cmds.
>: 12. there are no blanks at the eol (set nulls off doesn't work?)
>
>Ah, now here's a point worthy of discussion.
>
> ...(stuff)...
>
>Comments, please.
Well, how ever it's implemented, it's very nice to be able to use the
'blanks' at the end of the line in a search or change string:
'c/eol junk /something else/'
'all /another string /'
>BTW, set nulls seems to have no effect in this area in CMS, and I
>continue to see no function that set nulls should provide in Unix.
I should of done some homework (I haven't been on an IBM for 2 years
now). Your right. 'set nulls' is for using the insert key after the
end of line. Didn't it also prevent characters typed in after the eol
from crashing into the eol?
>: 14. there are problems with the f keys in an Open Look xterm
>: ( you have to 'shift' pf6 - pf10 : in an xterm, f6 gives a
>: \E[17~, not \E[16~, etc.)
>
>Ah, you **are** using xterm! Once again, these come from the xterm
I 'have to' as tcsh's up/down arrows don't work in a Sun's cmdtool.
>these are provided by the vendor. Judicious use of the keybind utility
>can solve these problems.
True.
>ps: This discussion probably doesn't belong in this newsgroup
>(even though there probably are a lrage number of interested parties
>here) so if anyone objects, we should move it elsewhere.
Maybe so but urexx-l isn't getting much traffic these days & comp.editors
has too much. But, whatever. Unfortunately, I'll be gone until 10/18.
(Damn, I love arguing about xedit %^) ).
Mark Hessling
>uni-XEDIT V1.32 is in test now, and should be out before Dec 25 :-)
>It includes the following enhancements in the below mentioned areas:
>It would be nice if the vendor supplied TERMINFOs were complete.
>Since that is not true, local keybind action is often required
>to make some keys work the way you want. We do send sample keybind
>sets, but I suspect you're running as an XTERM (not a sun-cmd)
>and XTERMs vary from system to system, so it's hard to write a
>single XTERM keybind set that will satisfy everybody.
Couldn't agree with you more !
>: 8. "del -1" starts at curline (I thought I remember this starting
>: on the curline - 1 on our mainframe)
>The mainframe product works just as you describe uni-XEDIT working,
>so I suspect your memory is faulty in this case.
Even THE works the same way :-)
>: 12. there are no blanks at the eol (set nulls off doesn't work?)
>Ah, now here's a point worthy of discussion.
>One way to interpret this remark is that the user would like all the
>records in the file to be padded out to "lrecl" with blanks when the
>file is saved. I sincerely doubt that that is the intent.
>The more likely interpretation is that targets with blanks at the
>end of the string doen't match data at the end of a line, since the
>records in memory are not padded out to blank. We have several thoughts
>on this, and would be interested in user comments.
> - Perhaps the best approach would be to keep the data as originally
>found (or entered at the keyboard) and modify the target search
>algorithms so they act as if there were some extra blanks at the end of
>each record. The only drawback I can see in this approach is a
>performance hit to the target search code (and effort in writing
>a more complex search algorithm.)
This is the approach I have taken with THE. It does make for an interesting
searching algorith, but I think it is a "common-sense" approach.
Cheers, Mark
Ian Collier
>>: 3. shift-tab does not work
>OK. But how about another key-stroke for 'goto-last-field'?
You can already map a keystroke to "goto-previous-field" (I don't know about
going to the *last* field, if that's really what you meant). I have this to
make control-A that keystroke:
SET KEYBIND ^A KEY BACKTAB
An X hack which seems to work (which I hinted at earlier) is to execute the
command:
xmodmap -e "keysym Tab = Tab Begin"
and then in Uni-XEDIT:
SET KEYBIND \EO\0 KEY BACKTAB
> Your right. 'set nulls' is for using the insert key after the
>end of line. Didn't it also prevent characters typed in after the eol
>from crashing into the eol?
The two commands "set nulls" and "set fullread" are closely related.
nulls off, fullread on => normality
nulls off, fullread off => characters typed in after the eol "crash" into
the eol
nulls on, fullread any => insert does not work unless you use the nullkey
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
Ian Collier
>Regina is twice as fast as uni-Rexx on the benchmarks written by Mike,
>the author of Rexx. However, it lacks some user-friendly interfaces
>to UNIX, all of which are not part of the Rexx language.
What are they?
>As far as XEDIT goes, IMHO Emacs is to UNIX as XEDIT is to VM;
>namely there are so many things that run under emacs on UNIX, that you
>can't fight it, you really ought to learn Emacs.
This really is flame-bait! XEDIT versions exist on Unix. There is nothing
wrong with using them. "vi" exists on Unix. There is nothing wrong with
using it (but most people on this group wouldn't bother). Also, "jove"
is a smaller, faster, and more manageable editor than gnu-emacs. I do
not wish to have anything to do with emacs. You are welcome to use it,
but please don't evangelise on this newsgroup.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Paul F. Kunz
>Regina is twice as fast as uni-Rexx on the benchmarks written by Mike,
>the author of Rexx. However, it lacks some user-friendly interfaces
>to UNIX, all of which are not part of the Rexx language.
What are they?
Well, for example Popen()
>As far as XEDIT goes, IMHO Emacs is to UNIX as XEDIT is to VM;
>namely there are so many things that run under emacs on UNIX, that you
>can't fight it, you really ought to learn Emacs.
This really is flame-bait! XEDIT versions exist on Unix. There is nothing
wrong with using them. "vi" exists on Unix. There is nothing wrong with
using it (but most people on this group wouldn't bother). Also, "jove"
is a smaller, faster, and more manageable editor than gnu-emacs. I do
not wish to have anything to do with emacs. You are welcome to use it,
but please don't evangelise on this newsgroup.
Well if you don't want to have anything to with Emacs then you need
nevertheless learn a way to read and send you mail, read and post to
netnews, compile programs and automatically get to source lines with
error, run a spell checker, and a whole host of other things that one
can do under emacs. Sort of like the large host of things one runs
under XEDIT on VM. When the set of needed XEDIT macros are available
in Rexx, then I'll believe your statement the one can use XEDIT
instead of emacs.
Don't get me wrong. I love Rexx as a language. Mike, the inventor,
and I have met many times. It's the use of XEDIT under UNIX that I
have a problem with. For those coming from VM to UNIX, it's very
handy. But in the long run it's damaging not to learn something
native to UNIX like emacs.