jonr@eecs.cs.pdx.edu (Jon Edmund Richards) (04/03/91)
My boss made the statement last week that, in many ways,
Xedit is better than vi and emacs. We argued about this
for awhile with the end result that by Friday I have to
present a paper either supporting my belief that Xedit
has outlived its usefulness or a description of how Xedit
surpasses my favorite Unix editors.
In my opinion, Xedit is a dinosaur and should be as much
a part of computing history as those punch cards that the
professors tell us about.
Does anyone have any good supporting arguments I could
provide? I would love nothing better than to convince my
boss that it's time to learn vi or emacs.
I read this news group almost daily and once in awhile I
see postings by Xedit users so I know they are still out
there in the world somewhere. Can any of you explain to me
the advantages of Xedit and why it's a good editor?
-----------------------------------------------------------------
| Jon Edmund Richards | Internet : jonr@cs.pdx.edu |
| Computer Science major | ICBM : 45 31 25 N 122 40 30 W |
| Portland State University | U.S.West : Jon @ (503)223-0297 |
----------------------------------------------------------------- stuart@mtu.edu (Tim Prodin) (04/04/91)
In article <2197@pdxgate.UUCP>, jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: |> |> |> My boss made the statement last week that, in many ways, |> Xedit is better than vi and emacs. XEDIT is the best editor to use if you are on any S/370 machine. Vi is my choice for UNIX editing. XEDIT isn't appropiate for UNIX, and vi is a unique chalange on S/370 platforms. |> I have to |> present a paper either supporting my belief that Xedit |> has outlived its usefulness or a description of how Xedit |> surpasses my favorite Unix editors. This whole debate has shades of "My editor can beat up your editor" arguements. The two editors run in different environments, and there is no real comparison. |> |> In my opinion, Xedit is a dinosaur and should be as much |> a part of computing history as those punch cards that the |> professors tell us about. |> My opinion is that you are on drugs. XEDIT is a unique tool that, when used properly on a S/370 machine, can equeal a whole set of UNIX utilities. XEDIT has a complete macro language, REXX, and very seamlessly integrates with the rest of the platform and operating system. Vi doesn't need these capabilities because there are other tools available, such as AWK and sed. The reason that I didn't address any issues about emacs is that I would rather dive into a pool of my own vomit than use it. Emacs may have a macro language, and may have all sorts of features, but you pay a severe penalty for having everything but the kitchen sink built into your editor. Most of non-programming computing is selecting the right tool for the job, Editing on UNIX means vi, Editing on S/370 means XEDIT. I don't like emacs because it attempts to be all things for all people, which is the wrong approach. -- ------------------------------------------------------------------------ "Complacent youth, thats all they want Timothy R. Prodin but if they want trouble they'll get it." stuart@mtu.edu
fin@norge.unet.umn.edu (Craig A. Finseth) (04/04/91)
In article <2197@pdxgate.UUCP> jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: > My boss made the statement last week that, in many ways, > Xedit is better than vi and emacs. We argued about this > for awhile with the end result that by Friday I have to > present a paper either supporting my belief that Xedit > has outlived its usefulness or a description of how Xedit > surpasses my favorite Unix editors. ... This is an argument that is impossible to win. On the other hand, there is no particular reason why it should be necessary to win it. There are several surface reasons why it is impossible to win. They all boil down to the same thing: one's choice of editor is a religious (used in the technical sense) issue. As such, it is not one that can be discsussed rationally. To each person, it is so obvious that their favorite editor is so much better than all the rest, they cannot understand why everyone else doesn't immediately convert. This "obviousness" comes from the editing models offered by each editor: the user's favorite editor has a model that matches that user's expectations. As long as we are discussing text editors, however, this is all a non-issue. All system editors can read and write the same files. Thus, if you want to use editor A on a file and your boss wants to use editor B, who cares? The resulting file is identical. (This argument gets more complex when you are discussing word processors with their *@%#! file formats, but that is not an issue here.) The way to win is *not* to say "editor A is better than editor B." Rather, it is to say "editor A is better than editor B for user X, and it is the other way around for user Y." Now, someone may come back and say "it is too much work to support both A and B." The counter argument must be made on those grounds: it takes X amount of work to install a new editor, but using it will improve user Y's efficincy by Z%, so the breakeven time is <some formula>." For example in my case, installing Gnu-Emacs took about 1/2 day. My performance improvement (vis-a-vis vi) is about 900% (i.e., I can work at least ten times more efficiently). I come out ahead in about a day. And if someone says, "it takes too much disk space, CPU time, etc.," then they really are lost in the 1960s and you need to ask them why they are using computers and not pencil and paper. This is, after all, 1991 and I run an Emacs-type editor on my RAM-disk-based laptop. What could be more disk-limited than that? Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.
joshi@m.cs.uiuc.edu (Anil Joshi) (04/04/91)
jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: > My boss made the statement last week that, in many ways, > Xedit is better than vi and emacs. We argued about this I think your boss is right. > for awhile with the end result that by Friday I have to > present a paper either supporting my belief that Xedit > has outlived its usefulness or a description of how Xedit You would not be able to do this. vi hasn't lived for long yet ironically it has outlived its time. > surpasses my favorite Unix editors. What is your favourite unix editor? > In my opinion, Xedit is a dinosaur and should be as much Just by saying that it is a dinosaur doen't make it so. Just by saying that vi is short for visual editor doen't make it so. I still fail to see how vi is a visual editor. Could somebody please explain this to me? In what way xedit is not visual and vi is anymore visual. > a part of computing history as those punch cards that the > professors tell us about. That's not true. > Does anyone have any good supporting arguments I could > provide? I would love nothing better than to convince my > boss that it's time to learn vi or emacs. It's time to unlearn vi or emacs. > I read this news group almost daily and once in awhile I > see postings by Xedit users so I know they are still out > there in the world somewhere. Can any of you explain to me Again if you are looking for number of vi/emacs users vs number of xedit/ISPF users the latter group outmnumbers the former by a very wide margin. > the advantages of Xedit and why it's a good editor? Best thing to do would be to go through the IBM manuals on XEDIT, REXX and vm/cms to see how it is better than vi/emacs. The documentation is ample and very definitive replete with examples. The same cannot said about either vi or emacs. Anil joshi@cs.uiuc.edu -- "Come the (computer) revolution, all persons found guilty of such criminal behaviour will be summarily executed, and their programs won't be!" - Press, Flannerty, Teukolsky and Vetterling
dfpedro@uswnvg.UUCP (Donn Pedro) (04/05/91)
In article <2197@pdxgate.UUCP>, jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes:
:
:
: My boss made the statement last week that, in many ways,
: Xedit is better than vi and emacs. We argued about this
: for awhile with the end result that by Friday I have to
: present a paper either supporting my belief that Xedit
: has outlived its usefulness or a description of how Xedit
: surpasses my favorite Unix editors.
:
: Does anyone have any good supporting arguments I could
: provide? I would love nothing better than to convince my
: boss that it's time to learn vi or emacs.
Maybe this isn't about which editor is the "best". I have no experience
Xedit but, maybe we can discuss why an editor needs to be better than
another, and why your boss feels the need for you to write a paper.
If you have both editors, why the discussion? You use the editor you like
and let him use the editor he likes. Proving him wrong doesn't seem
very productive to me. I would be tempted to address the issue of why vi
is the editor you choose to use instead of why your choice is better
his choice.
If my boss was forcing me to use an editor I did not prefer just because
he preferred it, there would be trouble. If this is the case for you, then
addressing your personal reasons for using vi might make sense.
Too much time is wasted discussing which editor is "best". The best
editor is the one which you are comfortable with and contributes to
your productivity.
dfpedro@uswnvg.UUCPstuart@mtu.edu (Tim Prodin) (04/05/91)
In article <3817@uc.msc.umn.edu>, fin@norge.unet.umn.edu (Craig A. Finseth) writes: |> |> And if someone says, "it takes too much disk space, CPU time, etc.," |> then they really are lost in the 1960s and you need to ask them why |> they are using computers and not pencil and paper. This is, after |> all, 1991 and I run an Emacs-type editor on my RAM-disk-based laptop. |> What could be more disk-limited than that? |> Well sure. If the resource is there, abuse it. No sense writing efficent programs that are easy to use, small, fast and polite, becuase we can just by larger machines. NOT! This attitude is really incredible. "My computer is really big, so why shouldn't I create a huge (1 Meg on a Symmetry Balance) editor that does everything (including playing Towers of Hanoi)? So what if I burn 8 Meg of swap to create Hello world?" I think I would rather be stuck in the 60's. -- ------------------------------------------------------------------------ "Complacent youth, thats all they want Timothy R. Prodin but if they want trouble they'll get it." (tim|timothy)@mtus5.cts.mtu.edu well!tim@apple.com trprodin@symmetry.cs.mtu.edu stuart@mtu.edu
fin@norge.unet.umn.edu (Craig A. Finseth) (04/05/91)
In article <1991Apr4.172610.27932@mtu.edu> stuart@mtu.edu (Tim Prodin) writes: >In article <3817@uc.msc.umn.edu>, fin@norge.unet.umn.edu (Craig A. Finseth) writes: > >|> And if someone says, "it takes too much disk space, CPU time, etc.," ... >|> all, 1991 and I run an Emacs-type editor on my RAM-disk-based laptop. >|> What could be more disk-limited than that? >Well sure. If the resource is there, abuse it. No sense writing efficent >programs that are easy to use, small, fast and polite, becuase we can just >by larger machines. NOT! > >This attitude is really incredible. "My computer is really big, so why >shouldn't I create a huge (1 Meg on a Symmetry Balance) editor that does >everything (including playing Towers of Hanoi)? So what if I burn 8 Meg >of swap to create Hello world?" I believe that you mis-read the message. My point was that even programs like Emacs (often mistakenly thought to always be "huge" and "awful") can still run on very resource limited environments. I don't consider a single, 384K RAM disk to be "really big," do you? (I leave my floppy open for data.) Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.
QQ11@LIVERPOOL.AC.UK (Alan Thew) (04/06/91)
At the risk of prolonging a fairly stupid discussion, I use vi (and jove & uE occasionally...I know vi better...been at it longer) with Un*x and XEDIT with CMS. Both are good for the job in their respective environments. Can we give this "my editor is better than your editor" thing a break please or create an alt.editor.flame group and let comp.editors be useful? Thanks.
andy@research.canon.oz.au (Andy Newman) (04/07/91)
In article <91096.084712QQ11@LIVERPOOL.AC.UK> QQ11@LIVERPOOL.AC.UK (Alan Thew) writes: >Can we give this "my editor is better than your editor" thing a break >please or create an alt.editor.flame group and let comp.editors be >useful? > Here, here. Why not change the tone to more of "What is good about editor X and how can we do that in editor Y" (with no religion). Xedit does some great things (the "all" macro is extremely useful to name but one feature), its very well integrated with CMS and Rexx is a great language for writing editor macros in (apart from other things). Sure xedit has problems but so do all editors. Given the constraint of a 327x terminal I think it does a pretty good job. -- Andy Newman (andy@research.canon.oz.au) Canon Info. Systems Research Australia "X: 2. An over-sized, over-featured, over-engineered window system developed at MIT and widely used on UNIX systems." from the jargon file.
dwork@brahms.amd.com (Jeff Dwork) (04/09/91)
In article <2197@pdxgate.UUCP> jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: > > In my opinion, Xedit is a dinosaur and should be as much > a part of computing history as those punch cards that the > professors tell us about. > > Does anyone have any good supporting arguments I could > provide? I would love nothing better than to convince my > boss that it's time to learn vi or emacs. > > I read this news group almost daily and once in awhile I > see postings by Xedit users so I know they are still out > there in the world somewhere. Can any of you explain to me > the advantages of Xedit and why it's a good editor? > > ----------------------------------------------------------------- > | Jon Edmund Richards | Internet : jonr@cs.pdx.edu | > | Computer Science major | ICBM : 45 31 25 N 122 40 30 W | > | Portland State University | U.S.West : Jon @ (503)223-0297 | > ----------------------------------------------------------------- Xedit has several nice features not available in emacs or vi. It's been several years since I moved all my work to unix, and I still miss these at least once a week: Column control for search (set zone): All search and replace commands look only between the specified columns for matches. Column control for display (set verify): This is a mapping of columns in the file to columns on the display. It's great for looking at a file wider than your screen where you want to see cols 1-10 and 100-130. Hiding of lines (set select and set display): Each line has a select level that may be assigned. There is a display level. Lines that have select lower (or higher - been a while) than display are invisible and are not affected by any editor operations except file save. There are macros to hide individual lines, blocks of lines, and all lines matching or not matching some regexp. Multiple windows: Both horizontal and vertical splits are possible - including both at once. Simple extension language: Macros are written in REXX, which is quite powerful and easy to learn. It allows one to transfer editor variables and text from the file into REXX variables. Prefix commands: These are nice to have to see where your block of text is before it gets moved, but I can live without them. Hexadecimal editing: You can display lines in hex and do search and replace with hex strings. Handy for quick patches or fixing funny data from other computers. Some negatives for Xedit: I don't miss 3270 terminals (or their emulations either). Insert mode is a crock. Using only the cursor keys to move the cursor is no fun. Emacs and vi are winners here. I'd like to see some of this stuff in emacs. I'd do it myself if I had the time and the talent, but both are in short supply these days. -- Jeff Dwork | 408-749-2356 | dwork@AMD.COM Advanced Micro Devices, M/S 45 |--------------------------------------- PO Box 3453 | The above opionions are mine, Sunnyvale, Ca 94088 | not AMD's.
gast@maui.cs.ucla.edu (David Gast) (04/12/91)
In article <1991Apr4.033238.9089@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: >Best thing to do would be to go through the IBM manuals on XEDIT, REXX >and vm/cms to see how it is better than vi/emacs. The documentation is >ample and very definitive replete with examples. The same cannot said >about either vi or emacs. Oh, I get it, XEDIT/REXX is better because it has 2000 pages of manuals. Another good thing about XEDIT/REXX, you get a virtual card punch and a virtual card reader. :-) Perhaps they come with CMS. Do you work for IBM? (I only ask because you have posted info about internal IBM programs). David
ken@hertz.njit.edu (ken ng cccc) (04/17/91)
In article<2197@pdxgate.UUCP> jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes:
: for awhile with the end result that by Friday I have to
: present a paper either supporting my belief that Xedit
: has outlived its usefulness or a description of how Xedit
: surpasses my favorite Unix editors.
Good luck. When I first started learning VM after learning Unix, I thought
Xedit was a real joke. But after getting to learn how to use it, I found
that it provided much functionality that vi sorely lacked.
: Can any of you explain to me
: the advantages of Xedit and why it's a good editor?
Good is relative, I use Xedit, vi, MS Word, and several other editors
daily. Each is good for certain jobs, each is absolute crap for others.
To answer the question of in what areas Xedit is better than vi, I would
say: very good integration with all the tools, ability to set ranges and
have to work performed only on the ranges requested (and keep the surrounding
material), simultanous screens (although not nearly as programmable as a
windowing system), and a REAL macro language (vi's :map doesn't cut it).
The last entry, a real macro language, is, in my opinion, the single
most important feature. It is the ability to put in anything that the
designers didn't, or to really customize various facilities.
There are a few things I think could easily be put into vi but are not
in there currently (or I have yet to find them). For example, is there
a way to do a case insensitive search? I find '/[Ss][Tt][Uu][Ff]' to be
a real drag (In Xedit, just do a 'set case m i'.). A retrieve facility
on the ':' would also be VERY nice (could you throw in line editing as
well?) I don't know how many times I wanted to try something from vi
but was off by one character (In xedit just set up a function key to do
a retrieve, or, prefix the command with '&' and the command stays on the
command line.) And lastly, sometimes I WANT BLANKS when I hit <cr> in
insert mode with autoindent enabled. I have yet to find a documented
switch that enables that. (Note: none of these are flames, if there is
an easy way to do them, I would like to know so I can use them.)
Back when I was more active under VM, I made major uses of Xedit's ability
to selectively hide text. For example: local documentation standards
dictated a documentation page at the beginning of each function. Most of
the time I didn't want to have to see it, so I just programed my profile
to search for and hide that section. If I wanted to see it, I just told
xedit to display everything. Another use: when writing Pascal routines,
I would use Xedit's hide facility to hide the implementations of subroutines
I was writing. Mostly I would page up to get the declarations of the various
routines, most of the time I had no interest in how the routines worked, I
just wanted to see the orders of the parameters, arguement types and return
values, etc. I wrote an Xedit macro to hide from the 'begin' to the 'end'
of each routine (getting recursion to work was fun :-)). In that way, when
I needed a routine definition, I just paged through the definitions, not the
bloody routines themselves each and every time.
Selectively hiding text could also be used as a primitive database. I
used to have many flat files and would fire up xedit and do an
'all/ugga/&/booga/' to show me all lines that had 'ugga' and then 'booga'
or lines with 'booga' and then 'ugga'. Or I would say 'all/ugga/&^/booga/'
to show all lines with 'ugga', but not 'booga' (Granted this one you can
do with 2 greps, but I don't think you could do the first with just grep.)
And, once I have that set of database hits, I can expand the surrounding
text around those areas that look interesting, and still keep the rest
'non-hit' text hidden.
--------------------------------------------------------------
JUST to make sure you folks don't think that I think Xedit is the greatest
program in the world, here is the other side:
Lack of real regular expressions. In spite of their line noise appearance,
sometimes regular expressions are useful. While Xedit does have the
arbchar facility, it is somewhat lacking (although you COULD write one
in REXX, since REXX has true if/then/else macro cabability :-)).
Better scrolling capabilities. With 3270 style screens, this is going
to be forever locked. However, with Mansfield's KEDIT, the scrolling is
quite acceptable.
Xedit lacks vi's ability to work on words directly (ie 'cw'). But on the
other hand, that is partly what lends to vi's cryptic nature.
Now, here is my question, in your report, are you going to include both
the good and bad points about Xedit, or just the bad ones?
PS: to the gnu emacs on 386 box users, does anyone have a mod that will
enable me to use the <alt> instead of the <esc> key as the meta key? I
think that will make the balance between <cntr> and <alt> key better.rozin@unix.cis.pitt.edu (Roman Rozin) (04/17/91)
In article <1991Apr16.193558.9369@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: [ ... ] >There are a few things I think could easily be put into vi but are not >in there currently (or I have yet to find them). For example, is there >a way to do a case insensitive search? I find '/[Ss][Tt][Uu][Ff]' to be >a real drag (In Xedit, just do a 'set case m i'.). In vi, you can just do :set ignorecase or just :set ic Roman Rozin
peter@ficc.ferranti.com (peter da silva) (04/17/91)
In article <1991Apr16.193558.9369@njitgw.njit.edu>, ken@hertz.njit.edu (ken ng cccc) writes: > There are a few things I think could easily be put into vi but are not > in there currently (or I have yet to find them). For example, is there > a way to do a case insensitive search? :set ignorecase > well?) I don't know how many times I wanted to try something from vi > but was off by one character Insert the command into the text, cut it, and execute it as a macro. > command line.) And lastly, sometimes I WANT BLANKS when I hit <cr> in > insert mode with autoindent enabled. Set tabstops to something ridiculous. > switch that enables that. (Note: none of these are flames, if there is > an easy way to do them, I would like to know so I can use them.) There you go. As for a good UNIX editor for naive users, dte seems pretty good. I'm going to have to port it to termcap, though. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
mstgil@ponder.csci.unt.edu (Marc Ph. A. J. St.-Gil) (04/18/91)
In <1991Apr16.193558.9369@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >In article<2197@pdxgate.UUCP> jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: >There are a few things I think could easily be put into vi but are not >in there currently (or I have yet to find them). For example, is there >a way to do a case insensitive search? I find '/[Ss][Tt][Uu][Ff]' to be >a real drag (In Xedit, just do a 'set case m i'.). A retrieve facility how about :set ignorecase in your .exrc file >Selectively hiding text could also be used as a primitive database. I >used to have many flat files and would fire up xedit and do an >'all/ugga/&/booga/' to show me all lines that had 'ugga' and then 'booga' all/ugga/&/booga/ = grep 'ugga.*booga' or /ugga.*booga because .* matches anything except a newline -- Marc Ph. A. J. St.-Gil mstgil@sol.acs.unt.edu
ken@hertz.njit.edu (ken ng cccc) (04/18/91)
In article <1991Apr12.034246.13274@cs.ucla.edu> gast@maui.cs.ucla.edu (David Gast) writes:
:Another good thing about XEDIT/REXX, you get a virtual card punch and
:a virtual card reader. :-) Perhaps they come with CMS.
They come from CMS.
:Do you work for IBM? (I only ask because you have posted info about
:internal IBM programs).
You don't have to work for IBM to gain access to some of IBM's internal
programs. Over the years they have published articles on several of their
internal projects. For example, they published articles on terminal
session data compression years before compression in MNP came out.
Kenneth Ng
"No problem, this is how you make it" -- R. Barclay, ST: TNGken@hertz.njit.edu (ken ng cccc) (04/18/91)
In article <mstgil.671924726@ponder> mstgil@ponder.csci.unt.edu (Marc Ph. A. J. St.-Gil) writes:
:how about :set ignorecase in your .exrc file
EXCELLENT! Thank you! Now can you tell me how to get a retrive and
command edit for ':!' and '!!'? Please?
:all/ugga/&/booga/ = grep 'ugga.*booga' or /ugga.*booga
:because .* matches anything except a newline
Not quite the same, I want all occurances of 'ugga.*booga' and 'booga.*ugga'.
AND I want to be able to selectively open up the text around the lines
as well. Yes I can do 2 greps and merge them together, but I then I
loose the line order they occurred on.
On another note, I've been told privately that GNU Emacs can do everything
I want to do with Xedit. Well, as soon as I get it running at home and
can print out the manual so I can learn how to use the bloody thing, I'll
try it out. Programming in Lisp does make me a bit quesy though.
Kenneth Ng
"No problem, this is how you make it" -- R. Barclay, ST: TNGmstgil@sol (Marc Ph. A. J. St.-Gil) (04/20/91)
ken@hertz.njit.edu (ken ng cccc) writes: >EXCELLENT! Thank you! Now can you tell me how to get a retrive and >command edit for ':!' and '!!'? Please? how about inserting your ':!' command on a new line in your document, then use something like "xdd to save to buffer x, then @x to execute which you can do more than once ('!!'), then to edit, "xp to put on new line, edit line, and "xdd again to save new copy in buffer x, etc... Not exactly simple or elegant, but functional. > >all/ugga/&/booga/ = grep 'ugga.*booga' or /ugga.*booga > >because .* matches anything except a newline >Not quite the same, I want all occurances of 'ugga.*booga' and 'booga.*ugga'. >AND I want to be able to selectively open up the text around the lines >as well. Yes I can do 2 greps and merge them together, but I then I >loose the line order they occurred on. Got me there. I misunderstood your example. :) >Kenneth Ng -- Marc St.-Gil, UNIX Systems Administrator mstgil@{sol,vaxa,vaxb}.acs.unt.edu University of North Texas 817/565-2324 mstgil@{ponder,solo}.csci.unt.edu Academic Computing Services DISCLAIMER: My employers had no idea I was PO Box 13495, Denton TX, 76203 going to say that.
phil@zorch.SF-Bay.ORG (Phil Gustafson) (04/21/91)
setmode(SOAPBOX); It's been a decade since I used Xedit, but I remember it well. If I had a 3270, it would be my editor of choice. If I had an ASR33 (or any of its followers, from ADM3 through xterm) I'd use vi or emacs. My brief encounter with Amdahl's vi-on-a-3270 left me with the notion that it was a typical compromise: a combination of the worst features of two perfectly good alternatives. I don't think anyone has even tried an Xedit-on-a-Teletype. setmode(CIVILIZED); For its time, the 3270 was a very fine data entry device. -- | phil@zorch.SF-Bay.ORG | Phil Gustafson | {ames|pyramid|vsi1}!zorch!phil | UN*X/graphics consultant | sgi!gsi!phil | 1550 Martin Ave., San Jose CA 95126 | phil@gsi | 408/286-1749
ken@hertz.njit.edu (ken ng cccc) (04/22/91)
In article <1991Apr21.011316.13111@zorch.SF-Bay.ORG> phil@zorch.SF-Bay.ORG (Phil Gustafson) writes: >setmode(SOAPBOX); :My brief encounter with Amdahl's vi-on-a-3270 left me with the notion :that it was a typical compromise: a combination of the worst features :of two perfectly good alternatives. I don't think anyone has even tried :an Xedit-on-a-Teletype. IBM's AIX/370 has a vi mode for the 3270 screen, believe me, it ain't pretty at all! I have used Xedit in line mode, its, um, interesting. Not as bad as vi on a 3270, but still pretty bad. Kenneth Ng "No problem, this is how you make it" -- R. Barclay, ST: TNG
ken@hertz.njit.edu (ken ng cccc) (04/22/91)
In article <mstgil.672097504@sol> mstgil@sol.acs.unt.edu writes: :ken@hertz.njit.edu (ken ng cccc) writes: :>EXCELLENT! Thank you! Now can you tell me how to get a retrive and :>command edit for ':!' and '!!'? Please? :[edit putting the command in text, and then executing it] Only usable if it can be done without setting the 'file modified' flag. :> >all/ugga/&/booga/ = grep 'ugga.*booga' or /ugga.*booga :> >because .* matches anything except a newline :>Not quite the same, I want all occurances of 'ugga.*booga' and 'booga.*ugga'. :>AND I want to be able to selectively open up the text around the lines :>as well. Yes I can do 2 greps and merge them together, but I then I :>loose the line order they occurred on. :Got me there. I misunderstood your example. :) I've been told that I can use egrep to do do the deed, unfortunately there doesn't seem to be a way to selectively open up the surrounding text. Kenneth Ng "No problem, this is how you make it" -- R. Barclay, ST: TNG
steveha@microsoft.UUCP (Steve HASTINGS) (04/23/91)
In article <1991Apr16.193558.9369@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >There are a few things I think could easily be put into vi but are not >in there currently (or I have yet to find them). For example, is there >a way to do a case insensitive search? :set ignorecase or, abbreviated, :se ic This affects the / and ? commands, even inside character classes; with ignorecase set, [a-zA-Z] and [a-z] and [A-Z] are all equivalent. It does *not* affect the f F t T commands. >A retrieve facility on the ':' would also be VERY nice (could you throw >in line editing as well?) This would be nice. Until someone implements it, you can type the command into the text of your file, yank the text into a named buffer, and execute with the @ command. For example, type the command, type "ayy to yank the line into buffer a, and type @a to execute. >And lastly, sometimes I WANT BLANKS when I hit <cr> in >insert mode with autoindent enabled. I have yet to find a documented >switch that enables that. (Note: none of these are flames, if there is >an easy way to do them, I would like to know so I can use them.) Well, you could run the whole file through detab when you are done. You could even map a key to do "1G!Gdetab" and hit this key before you save. Another trick to try: :set ts=80 :set sw=4 In vi, the "tabstop" is different than the "shiftwidth." The tabstop sets how wide tabs get, and shiftwidth sets how wide you want to indent. (In my example, I set this to 4 since I indent by steps of four spaces. You may set this to any value.) Set the tabstop to 80 and unless you indent over 80 columns, you will indent with spaces. This has the side effect of making any existing tabs in your document quite obvious! >I made major uses of Xedit's ability to selectively hide text. vi has no such feature, but I do sometimes hide stuff and restore it. To look quickly, I do a global search-and-delete to get rid of the extra lines, and then bring them back with undo. To look less quickly, I make a backup copy of the file with a name like "summary" and run the global on its contents. Then I can flip back and forth between the summary file and the real one. It's not the same, I guess, but it meets my needs. -- Steve "I don't speak for Microsoft" Hastings ===^=== ::::: uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
gast@maui.cs.ucla.edu (David Gast) (04/23/91)
In article <1991Apr21.011316.13111@zorch.SF-Bay.ORG> phil@zorch.SF-Bay.ORG (Phil Gustafson) writes: >setmode(SOAPBOX); >It's been a decade since I used Xedit, but I remember it well. If I >had a 3270, it would be my editor of choice. If I had an ASR33 (or any >of its followers, from ADM3 through xterm) I'd use vi or emacs. If I had to use a 3270, I would use Xedit too. Remember that for all practical purposes, vi and emacs expect to have a full duplex line and expect to be be in ``raw'' mode. A 3270 operates only in half-duplex mode and who knows if CMS can simulate raw mode. I guess there must be some horrible hacks out there, however. BTW, another poster keeps talking about opening up lines. What do you mean by opening them up? david
ken@hertz.njit.edu (ken ng cccc) (04/24/91)
In article <1991Apr23.024525.13795@cs.ucla.edu> gast@maui.cs.ucla.edu (David Gast) writes:
:BTW, another poster keeps talking about opening up lines. What do you
:mean by opening them up?
:david
Its me. Let's see. Let's say you have a pascal program with about a dozen
or so functions/procedures. You have already written the procedures, but
need to refer back to them every so often to get the parameters straight.
Instead of scrolling through the actual function source code each and every
time, if you could hide or close off certain sections of code from being
presently displayable, you could find the functions easier. If you were
not sure how function 'foo' works, you could open up/display the text that
was hidden.
For example, a fully displayed procedure:
procedure foo( var a, b, c : integer);
var
d, e: integer;
begin
d := a + b + c;
a := d / c;
end;
For example, a hidden procedure:
procedure foo( var a, b, c : integer);
----------------------- 6 lines not displayed ---------------------------
Now, if you only wanted to know what the args for 'foo' were, you only need
the hidden version of the display (also presuming you pick better variable
names). This beats having to scroll through the definition every bloody
time you wonder what the args to this or another procedure were.
Note: sometime last year (?) there was talk of this revolutionary new
concept called a 'folding editor'. From the description it sounds like
something that XEDIT had for years. But since I have not used it, I cannot
be sure.
Kenneth Ng
"No problem, this is how you make it" -- R. Barclay, ST: TNGtchrist@convex.COM (Tom Christiansen) (04/25/91)
From the keyboard of ken@hertz.njit.edu (ken ng cccc): :This beats having to scroll through the definition every bloody :time you wonder what the args to this or another procedure were. But it buys you little if you have multiple windows. --tom
jfr@locus.com (Jon Rosen) (04/25/91)
In article <1991Apr24.155049.21710@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >In article <1991Apr23.024525.13795@cs.ucla.edu> gast@maui.cs.ucla.edu (David Gast) writes: >:BTW, another poster keeps talking about opening up lines. What do you >:mean by opening them up? >:david > ><stuff deleted - see previous post> > >Now, if you only wanted to know what the args for 'foo' were, you only need >the hidden version of the display (also presuming you pick better variable >names). This beats having to scroll through the definition every bloody >time you wonder what the args to this or another procedure were. > >Note: sometime last year (?) there was talk of this revolutionary new >concept called a 'folding editor'. From the description it sounds like >something that XEDIT had for years. But since I have not used it, I cannot >be sure. Ken, you are correct that XEDIT has had line exclusion for about 10 years... In addition, ISPF (TSO's principal 3270-based screen editor) has had it for about 12 years... In addition, ISPF is better at handling exclusion by levels of indentation... However, better than either is Mansfield's KEDIT for the PC which gives you all of XEDIT's capabilities plus key-sensitive scrolling and function keys (unlike the 3270-based XEDIT and ISPF which limit you to the standard 24 function keys)... In addition, KEDIT comes with a complete integrated REXX-like facility called KEXX which allows you to write macros... In addition, you can get their Personal REXX and use it with KEDIT to make more powerful macros. I have several Pascal-sensitive macros in REXX with KEDIT that do much better line exclusion and reshowing, based on the use of keywords, etc. Not related to Mansfield Software, just a VERY satisfied customer for over 7 years... Jon Rosen ========================================================= "Another birthday? Well, don't worry about getting old until you can't make sense out of the simplest things... ... isn't it?" -- from my favorite 40th birthday card =========================================================
john@sco.COM (John R. MacMillan) (04/26/91)
|:This beats having to scroll through the definition every bloody |:time you wonder what the args to this or another procedure were. | |But it buys you little if you have multiple windows. Not really, there are a lot of other benefits. You don't have to keep the windows in sync, you can operate on only the selected portion, and you can do ``folding'' to organize the file in a hierarchical way. Multiple windows are certainly useful, but are not a complete substitute.
ken@sugra.uucp (Kenneth Ng) (04/26/91)
In article <1991Apr24.180108.5887@convex.com>, tchrist@convex.COM (Tom Christiansen) writes:
: From the keyboard of ken@hertz.njit.edu (ken ng cccc):
: :This beats having to scroll through the definition every bloody
: :time you wonder what the args to this or another procedure were.
: But it buys you little if you have multiple windows.
: --tom
Actually, multiple windows buys you little unless you either have only
one routine you refer to or you have a seperate window for each and
every function declaration (while I tend to have very busy windows,
this would be loony). Also, with XEDIT, I could write a program to
automantically mask off the proper areas. The only way I'm aware of
doing it with multiple windows is to manually open a seperate window
for each and every procedure, page down till you reach the individual
routines, and then shrink each window down till you have just the
declaration. In a phrase, yuck. And then, every time I want to see
a routine, I have to scan the screen and find the routine. With
XEDIT, I just search backwards. A "feature" of XEDIT is that text
that is hidden is not searched, its kind of useful, but it could be
hazardous if you don't remember you have text hidden.
--
Kenneth Ng
Please reply to ken@hertz.njit.edu until this machine properly recieves mail.
"No problem, this is how you build it" -- R. Barclay, ST: TNGles@chinet.chi.il.us (Leslie Mikesell) (04/26/91)
In article <1991Apr24.155049.21710@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >Its me. Let's see. Let's say you have a pascal program with about a dozen >or so functions/procedures. You have already written the procedures, but >need to refer back to them every so often to get the parameters straight. >Instead of scrolling through the actual function source code each and every >time, if you could hide or close off certain sections of code from being >presently displayable, you could find the functions easier. If you were >not sure how function 'foo' works, you could open up/display the text that >was hidden. >For example, a hidden procedure: >procedure foo( var a, b, c : integer); >----------------------- 6 lines not displayed --------------------------- If you just want to see something in vi without going there to edit it, you can use :g/pattern/p or some variation (:g/pattern/-1,+1p). to get the piece you want to see. It isn't the same thing at all, since you can't edit what you see, but it is sometimes handy. Les Mikesell les@chinet.chi.il.us
Dan_Jacobson@ATT.COM (04/28/91)
In article <1991Apr24.155049.21710@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >Instead of scrolling through the actual function source code each and every >time, if you could hide or close off certain sections of code from being >presently displayable, you could find the functions easier. If you were >not sure how function 'foo' works, you could open up/display the text that >was hidden. GNU Emacs got things like that: set-selective-display: Set selective-display to ARG; clear it if no arg. When selective-display is a number > 0, lines whose indentation is >= selective-display are not displayed. selective-display's value is separate for each buffer. narrow-to-region: Restrict editing in this buffer to the current region. The rest of the text becomes temporarily invisible and untouchable but is not deleted; if you save the buffer in a file, the invisible text is included in the file. C-x w makes all visible again. outline-mode: Set major mode for editing outlines with selective display. Headings are lines which start with asterisks: one for major headings, two for subheadings, etc. Lines not starting with asterisks are body lines. Body text or subheadings under a heading can be made temporarily invisible, or visible again. Invisible lines are attached to the end of the heading, so they move with it, if the line is killed and yanked back. A heading with text hidden under it is marked with an ellipsis (...). Commands: C-c C-n outline-next-visible-heading move by visible headings C-c C-p outline-previous-visible-heading C-c C-f outline-forward-same-level similar but skip subheadings C-c C-b outline-backward-same-level C-c C-u outline-up-heading move from subheading to heading Meta-x hide-body make all text invisible (not headings). Meta-x show-all make everything in buffer visible. The remaining commands are used when point is on a heading line. They apply to some of the body or subheadings of that heading. C-c C-h hide-subtree make body and subheadings invisible. C-c C-s show-subtree make body and subheadings visible. C-c C-i show-children make direct subheadings visible. No effect on body, or subheadings 2 or more levels down. With arg N, affects subheadings N levels down. M-x hide-entry make immediately following body invisible. M-x show-entry make it visible. M-x hide-leaves make body under heading and under its subheadings invisible. The subheadings remain visible. M-x show-branches make all subheadings at all levels visible. The variable outline-regexp can be changed to control what is a heading. A line is a heading if outline-regexp matches something at the beginning of the line. The longer the match, the deeper the level. Turning on outline mode calls the value of text-mode-hook and then of outline-mode-hook, if they are non-nil. ---------- etc. etc. and I probably forgot a few. Just more food for the standard editor war...
tchrist@convex.COM (Tom Christiansen) (04/28/91)
From the keyboard of ken@sugra.uucp (Kenneth Ng): :Actually, multiple windows buys you little unless you either have only :one routine you refer to or you have a seperate window for each and :every function declaration (while I tend to have very busy windows, :this would be loony). Also, with XEDIT, I could write a program to :automantically mask off the proper areas. Judicious use of a tags file can help a great deal. Plus I don't want to program every window with my editor; if I did, I'd use emacs. If a tag lookup on the function in another window doesn't make me happy, I'm content to do a "grep -C '^[a-z]' *.c" in a separate window as a rough hack at pulling out the function header. (That's using GNU grep's -C for context flag.) --tom
ken@sugra.uucp (Kenneth Ng) (04/29/91)
In article <1991Apr26.155233.7486@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: : In article <1991Apr24.155049.21710@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: : >For example, a hidden procedure: : >procedure foo( var a, b, c : integer); : >----------------------- 6 lines not displayed --------------------------- : If you just want to see something in vi without going there to edit : it, you can use :g/pattern/p or some variation (:g/pattern/-1,+1p). : to get the piece you want to see. It isn't the same thing at all, : since you can't edit what you see, but it is sometimes handy. Iffy, for trival routines its not too bad, for real work (and yes you can really do real work in pascal), it tends to break down for things like declarations that span multiple lines. At best it is a tweak because you can't edit what you displayed (as you said), and you have to execute it manually every time you want to do so rather than have an XEDIT macro do it for you automantically. And yes, you can add a span to the ':g...p' but then you have to remember which routines span a line and which don't, or you have to execute the command several times (YET ANOTHER PLACE A RETRIEVE KEY ON ':' WOULD BE VERY NICE). Remember, contray to popular opinion, the computer is supposed to work for the human, not the reverse. -- Kenneth Ng Please reply to ken@hertz.njit.edu until this machine properly recieves mail. "No problem, here's how you build it" -- R. Barclay, ST: TNG
tmb@ai.mit.edu (Thomas M. Breuel) (04/29/91)
In article <1991Apr26.024928.2260@sugra.uucp> ken@sugra.uucp (Kenneth Ng) writes:
[various reasons why XEDIT's hide-lines facility is better than
multiple windows for looking at procedure arguments]
Emacs has:
* hide-lines (or selective display), so that you can hide
procedure bodies if you want to
* multiple windows, so that you can look at the header/definition
file while editing the code/implementation file
* M-., so that you can quickly move to the source of
a function
* M-x arglist (for some languages), so that you can display
the argument list for the function you are trying to call
* M-x edit-callers (for some languages), for similar problems
* M-x grep, for quickly moving to arbitrary places in a collection
of source files by context (I usually use this instead
of M-.)
So, with Emacs you get your choice. "hide-lines" alone is a pretty
poor development tool.osan@cbnewsb.cb.att.com (andrew.vida-szucs) (04/30/91)
In article <1991Apr21.011316.13111@zorch.SF-Bay.ORG> phil@zorch.SF-Bay.ORG (Phil Gustafson) writes: >setmode(SOAPBOX); > >It's been a decade since I used Xedit, but I remember it well. If I >had a 3270, it would be my editor of choice. If I had an ASR33 (or any >of its followers, from ADM3 through xterm) I'd use vi or emacs. > >My brief encounter with Amdahl's vi-on-a-3270 left me with the notion >that it was a typical compromise: a combination of the worst features >of two perfectly good alternatives. I don't think anyone has even tried >an Xedit-on-a-Teletype. Dynasoft (somewhere in CA.) now has Xedit for UNIX. I have no idea how good it is (I am only familiar w/VM and Mansfields versions). Run $399 per site, if memory is sane... however it *might* be $299. They also have a REXX interpreter (and they stole the name of *MY* REXX implementation for UNIX, Uni-REXX). I would imagine it is useable as the macro interpreter for the editor. I love X/Kedit thought it has some shortcomings. Does anyone know how I might implement some of the word oriented vi functions such as '.' in REXX/KEXX. They are some of the few features of vi that I like and find lacking in X/kedit. Thanks for any help. --Andy Vida-Szucs
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/02/91)
In article <DANJ1.91Apr28061619@cbnewse.ATT.COM> might as well reply to netnews, it's the usual editor war writes: >In article <1991Apr24.155049.21710@njitgw.njit.edu> ken@hertz.njit.edu (ken ng cccc) writes: >>Instead of scrolling through the actual function source code each and every >>time, if you could hide or close off certain sections of code from being >>presently displayable, you could find the functions easier. If you were >>not sure how function 'foo' works, you could open up/display the text that >>was hidden. > >GNU Emacs got things like that: Plus don't forget CTAGS. If the reason you need all this hiding stuff is to find what function args are, just use the ctags system present in most unix editors. (and in this case windows are very usefull- one opens with the function you want already in it). -- #define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */ #define w 79 /* Width */ /* Amazing */ int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=2;while(d=(p>2*w?!a[p-w-w]?1:0:0)|( p<w*(h-2)?!a[p+w+w]?2:0:0)|(p%w!=w-2?!a[p+2]?4:0:0)|(p%w!=1?!a[p-2]?8:0:0)){do i=3&(r=(r*57+1))/d;while(!(d&(1<<i)));a[p+b[i]]=2;m(p+2*b[i]);}}main(){r=time( 0L);m(w+1);for(i=0;i%w?0:printf("\n"),i!=w*h;i++)printf("#\0 "+a[i]);}
ken@hertz.njit.edu (ken ng cccc) (05/02/91)
In article <1991May1.184113.14519@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: >In article <DANJ1.91Apr28061619@cbnewse.ATT.COM> might as well reply to netnews, it's the usual editor war writes: [edit ken@hertz talking about selective line displays in editors] :>GNU Emacs got things like that: :Plus don't forget CTAGS. If the reason you need all this hiding stuff is to :find what function args are, just use the ctags system present in most unix :editors. (and in this case windows are very usefull- one opens with the :function you want already in it). Showing function arguements is JUST ONE of the MANY possible uses of the XEDIT 'all' command, it is also an easy one to show why I find it useful. CTAGS sounds like a specific program to solve a specific problem. The GNU Emacs solution sounds like a GENERAL PURPOSE way to solve the problem, which will always tend to be my preference. Now, I know GNU Emacs has online documentation, but I'd still like to purchase a hardcopy manual for it somewhere. Hopefully the money will go toward supporting the GNU effort. Anyone know where I can get one? Kenneth Ng "No problem, this is how you make it" -- R. Barclay, ST: TNG
Dan_Jacobson@ATT.COM (05/03/91)
>>>>> On 2 May 91 12:27:05 GMT, ken@hertz.njit.edu (ken ng cccc) said:
ken> CTAGS sounds like a specific program to solve a specific problem. The
ken> GNU Emacs solution sounds like a GENERAL PURPOSE way to solve the problem,
ken> which will always tend to be my preference.
ken> Now, I know GNU Emacs has online documentation, but I'd still like to
ken> purchase a hardcopy manual for it somewhere. Hopefully the money will
ken> go toward supporting the GNU effort. Anyone know where I can get one?
Another convert! Ken, here's what I found in etc/DISTRIB.
[You can also copy a friend's manual, etc.]
================
GNU Emacs manual, ~300 pages, phototypeset, offset printed, spiral
bound, with a reference card.
________ $20 A single GNU Emacs manual.
________ $13 Emacs manuals, unit price for 6 or more.
The following documentation:
________ $1 One GNU Emacs reference card, without the manual.
________ $5 Packet of ten GNU Emacs reference cards.
________ $50 GNU Emacs Lisp Reference Manual, ~550 pages, spiral bound.
________ $200 Box of 5 GNU Emacs Lisp Reference Manuals.
________ If ordering from Massachusetts: add 5% sales tax
or give tax exempt number.
We pay for shipping via ground transportation in the
contiguous 48 states and Canada.
________ In Alaska, Hawaii, or Puerto Rico, for shipping:
- For Emacs Lisp Reference manuals, add $5 each,
or $20 per box. For all other items, add $5 base charge,
then $1 per item except Emacs reference cards.
If outside of U.S., Canada and Puerto Rico, for shipping costs:
- for tapes or unboxed manuals, please add $15, and then add
$15 more for each tape or unboxed manual in the order:
________ Shipping cost for tapes and unboxed manuals = $15 + $15 * n;
- for each box of Emacs manuals,
________ please add $70.
________ Optional tax deductible donation.
--------
________ Total paid
Orders are filled upon receipt of check or money order. We do not have
the staff to handle the billing of unpaid orders. Please help keep
our lives simple by including your payment with your order.
Please make checks payable to Free Software Foundation. Mail orders to:
Free Software Foundation, Inc.
675 Massachusetts Avenue
Cambridge, MA 02139
+1 617-876-3296
EFFECTIVE: February 1 1991 to June 1991
==========
Ken, by the way, emacs has all kinds of tags things too. Run "apropos"...ken@hertz.njit.edu (ken ng cccc) (05/04/91)
In article <DANJ1.91May2213247@cbnewse.ATT.COM> Dan_Jacobson@ihlpz.ATT.COM writes:
:Another convert! Ken, here's what I found in etc/DISTRIB.
:[You can also copy a friend's manual, etc.]
Now wait just a cotton picking minute! I will support the GNU effort, but
that does not mean I'm switching to GNU Emacs as my primary editor! I am
always willing to try something out, even if I'm a bit suspicious of it.
I do believe that GNU Emacs is probably a very good editor. My main problem
in using it is figuring out enough so that I can use it comfortably.
The thought of programming in Lisp after REXX does make me a bit
queasy though. Maybe it won't be so bad after I get used to it.
Anyone got a REXX interpreter in Lisp? 1/2 :-)
Kenneth Ng
"No problem, this is how you make it" -- R. Barclay, ST: TNG