[opensuse] Silly little text file editing question............
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF. And I know about vi, kate, and kwrite BUT these are NOT full screen "text" editors - these are full screen "line" editor. Unlike, XEDIT, where you can move, copy, insert, delete, etc - easily - "blocks" of lines I know versions of these exist, like the "THE" editor. However, why haven't these become the "standard" ? (Even XEDIT, starts basically in character basic "console" mode (no graphics capabilities needed), which could be run in a Linux console session) Having a "system programming" background, I just don't understand why anyone would put up with a "line" editor. Seeking insight, Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
They were never ported. OS/2 or VisualAge came with LPEX, which was very good. I think it's in WebSphere now.
And I know about vi, kate, and kwrite BUT these are NOT full screen "text" editors - these are full screen "line" editor. Unlike, XEDIT, where you can move, copy, insert, delete, etc - easily - "blocks" of lines
You can certainly do that in kate too, just as in vi and emacs.
I know versions of these exist, like the "THE" editor. However, why haven't these become the "standard" ? (Even XEDIT, starts basically in character basic "console" mode (no graphics capabilities needed), which could be run in a Linux console session)
Because Unix and Linux already have vi as _the_ standard. No need for another standard.
Having a "system programming" background, I just don't understand why anyone would put up with a "line" editor.
It's not about ones background, it's about habit. I too have worked with MVS, VM and TPF - 20 years ago I would also have argued the case for ISPF and XEDIT, but unless I'm sat behind a 3270 screen or emulator, I don't need them. -- Per Jessen, Zürich (0.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
They were never ported. OS/2 or VisualAge came with LPEX, which was very good. I think it's in WebSphere now.
LPEX was a development based on EPM, which came with OS/2. LPEX was most probably ported to Linux, but afaik, it's not freely available, probably only with websphere or z/os. -- Per Jessen, Zürich (2.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 02/28/2013 02:49 AM:
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
They were never ported. OS/2 or VisualAge came with LPEX, which was very good. I think it's in WebSphere now.
And I know about vi, kate, and kwrite BUT these are NOT full screen "text" editors - these are full screen "line" editor. Unlike, XEDIT, where you can move, copy, insert, delete, etc - easily - "blocks" of lines
You can certainly do that in kate too, just as in vi and emacs.
Duane, I think you had better clarify what you think the deficiency is, because Per is right. Perhaps its just that you don't know VI etc well enough. There's an excellent book from O'Reilly: http://shop.oreilly.com/product/9780596529833.do and many cheat-sheets. I'm not sure where you gripe comes from since many of the 'mainframe' editors were/are essentially '80-column card image' editors. There was similar in the DEC world where text file types were line oriented - either fixed length (80 column) or zero-delimited. The real distinction that separated UNIX from the mainframe/mini world is that it doesn't have all these ridiculous file types - a file is a continuous array of bytes. Its up to the application to apply semantics.
I know versions of these exist, like the "THE" editor. However, why haven't these become the "standard" ? (Even XEDIT, starts basically in character basic "console" mode (no graphics capabilities needed), which could be run in a Linux console session)
Because Unix and Linux already have vi as _the_ standard. No need for another standard.
Its no so much that "vi" is the standard as that, as I say above, UNIX files are array of bytes. There is no OS level file typing. I recall annoyance that when working with DEC/VMS I would enter code with a text editor that the compiler couldn't read. It had many types of text files and the the editor produced one that the compiler couldn't handle. This can't happen with UNIX. Many of the interpreters and compilers under UNIX/Linux treat input as 'array of bytes', the line orientation is just for the convenience of the users reading the code. See, for example, the highly compressed 'obfuscated' contests.
Having a "system programming" background, I just don't understand why anyone would put up with a "line" editor.
"Lines" are semantic concepts with UNIX.
From a 'systems programming' POV its the mainframes that are 'line oriented'
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [02-28-13 10:10]:
Per Jessen said the following on 02/28/2013 02:49 AM:
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
I don't see Hechler's posts, but his problem is more of not looking or not looking in proper places as kedit is provided in kdeutils3-extra: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... and xedit is provided: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
* Anton Aylward <opensuse@antonaylward.com> [02-28-13 10:10]:
Per Jessen said the following on 02/28/2013 02:49 AM:
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
I don't see Hechler's posts, but his problem is more of not looking or not looking in proper places as kedit is provided in kdeutils3-extra:
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... Duaine was looking for kedit, an enhanced xedit. http://en.wikipedia.org/wiki/KEDIT
and xedit is provided: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86...
http://en.wikipedia.org/wiki/XEDIT -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 02/28/2013 11:46 AM:
Duaine was looking for kedit, an enhanced xedit.
http://en.wikipedia.org/wiki/KEDIT
and xedit is provided: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86...
<quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote> That sounds pretty limited and crippled compare to what's available for Linux. VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available. I wonder why Duaine wants to regress? -- You can't hold firewalls and intrusion detection systems accountable. You can only hold people accountable. -- Daryl White, DOI CIO -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 11:46 AM:
Duaine was looking for kedit, an enhanced xedit.
http://en.wikipedia.org/wiki/KEDIT
and xedit is provided:
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86...
<quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>
That sounds pretty limited and crippled compare to what's available for Linux.
It isn't. The description above is very poor and/or biased.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress?
He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. -- Per Jessen, Zürich (1.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 02/28/2013 01:04 PM:
Anton Aylward wrote:
[snip,snip, snip]
That sounds pretty limited and crippled compare to what's available for Linux.
It isn't. The description above is very poor and/or biased.
Perhaps you'd care to amplify that -- or even correct the Wikipedia article.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress?
He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto.
Ah, that I can understand. My fingers know VI. All these editors that require me to take my hands off the keyboard and fiddle with mouse and menus and icons - and lets face it, icons range from incomprehensible to 'culturally specific'[1]. Still, it took me a decade to reach that level of programming my fingers. And then along came Microsoft, WordPerfect, Word and then Windows. BAH! Thank God I could escape to AIX! [1] garden shears? floppy disks? pencils? billiard balls? balloon? side view of Rubick's cube? go in every direction? big "A" (is that for 'apple')? 'the alphabet' - forward and reverse? soccer ball? jigsaw piece? hand whisk? 'into the box'? -- "Everybody comes to Rick's" - Cassablanca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 01:04 PM:
Anton Aylward wrote:
[snip,snip, snip]
That sounds pretty limited and crippled compare to what's available for Linux.
It isn't. The description above is very poor and/or biased.
Perhaps you'd care to amplify that -- or even correct the Wikipedia article.
I would if I could. It's difficult - partially because I am biased, mostly because one has to experience both to really understand. And that goes for either side. There is a lot of "religion" in it. There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress?
He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto.
Ah, that I can understand. My fingers know VI. All these editors that require me to take my hands off the keyboard and fiddle with mouse and menus and icons - and lets face it, icons range from incomprehensible to 'culturally specific'[1].
Very true. I have written a lot of code in ISPF and later xedit. Around the same time I started working with LPEX, which was a big step forward at the time (mid-90s) (syntax highlighting for starters). When I decided to switch to Linux, VI was my weapon of choice, but it took me six-seven years to get really effective with it. I did have a short affair with Eclipse in between, and today when I need to write C, I still pick kate. One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character. -- Per Jessen, Zürich (0.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 02/28/2013 03:15 PM:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 01:04 PM:
Anton Aylward wrote:
[snip,snip, snip]
That sounds pretty limited and crippled compare to what's available for Linux.
It isn't. The description above is very poor and/or biased.
Perhaps you'd care to amplify that -- or even correct the Wikipedia article.
I would if I could. It's difficult - partially because I am biased, mostly because one has to experience both to really understand. And that goes for either side. There is a lot of "religion" in it.
"Religion" I can understand.
There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.
Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.
One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.
Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length. Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length, and the code just dealt with that dynamically. That Henry Spenser addressed the input buffer-overflow issue back in the early 1980s, long before the Morris Worm, just shows how lacking our education system is. -- “When dealing with people, remember that you are not dealing with creatures of logic, but creatures of emotions.” —Dale Carnegie -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 03:15 PM:
There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.
Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.
Not the interface, the technology. Everything you send to a VT-100 is line base, one long string, optionally with ANSI control characters. A 3270 is more like a directly addressable full screen. Well, I guess whatever comes down the line is a string too, but that's what a 3270 looks like to a programmer.
One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards. However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.
Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.
Definitely.
Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length,
Hmm, don't they follow email standards? I'm sure USENET is where we first saw base64 encoding folded into neat lines of 76 bytes. Even the linux kernel likes the 80 character limit: "The limit on the length of lines is 80 columns and this is a strongly preferred limit."
Anyway, we're way OT. -- Per Jessen, Zürich (2.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Everything you send to a VT-100 is line base, one long string Not the ones I used to work with. Generally, you press one key and one character goes out the serial port. Same on receive. The text was displayed on the screen as it came in. BTW, back in those days, I was working with a variety of terminals, including mechanical teletypes, Texas Instruments Silent 700s, VT-100s, VT-220, DEC Writers and others. There was even one terminal that was so dumb, it was retarded, where anything beyond inserting or deleting a character required sending the entire screen to the computer and sending it back with the changes made or function performed.
Of course, back in those days, some text editors were line based. As I recall, the Edit editor on Pr1me computers was even worse than the Edlin that came with Microsoft DOS. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 03/01/2013 05:57 AM:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 03:15 PM:
There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.
Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.
Not the interface, the technology. Everything you send to a VT-100 is line base, one long string, optionally with ANSI control characters. A 3270 is more like a directly addressable full screen. Well, I guess whatever comes down the line is a string too, but that's what a 3270 looks like to a programmer.
And its just the same with VI and other applications that used the ncurses package and the like (ncurses was 'extracted' from the original VI's mechanisms). They maintain a internal screen logical image. IIR Bill Joy's VI kept this as a linked list. I once had to work on that code and boy was it crufty! One man's really optimized work and almost unintelligible to mere mortals. the code-base for VIM is so much nicer. So, to the programmer working with ncurses the programming model was a directly addressable full screen. You updated it and then did a 'sync' -- "refresh()', and the algorithms worked out the best/optimal/minimal stuff to send to the terminal. http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#updating And there in is the difference. TERMCAP tried to support cursor addressing and such things as as region (not just single line) updates. Some terminals could update a region in the middle of the screen: specify a bounding box and fill it thusly. So using ncurses was efficient on bandwidth (great over a slow modem). The programming reality was that there were higher level layers of code that made the manipulation of such easier, all the way up to 'layers' which implemented a text-based windows system. (e.g. http://osr507doc.sco.com/en/man/html.M/layers.M.html, http://osr507doc.sco.com/en/man/html.C/layers.C.html) You might also find the referred to as 'panels' http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#panels Of course this got rapidly replaced when the IBM PC came out and made cheap graphics and eventually GEM and MS-Windows available. I still have the SVR4 and USG manuals .. moment. Here we are: AT&T System V Interface Definition Volume 2, Part VI Terminal Interface Extension Definition. P426 Curses - CRT screen handling and optimization package. ISBN: 0-932764-10-X
One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards.
I had to for a very short time. I hated it and soon found a PDP-11 running RSTS that supported RJE. That PDP-11 was then knobbled by some post-grads to run UNIX version 5, and I didn't want to let go, so they took me along as test case for their work on compiler development and I got to play with the new languages they were dreaming up. And UNIX. Eventually I did system and kernel hacking on V6 and V7, then on System III and System V commercially.
However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.
Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.
Definitely.
Strictly speaking email doesn’t limit itself to 80 columns. Much of the mail I get seems to have been composed with long lines - one line per paragraph, and its up to the display to do the soft line wrap. So if I shrink or grow the width of the window the individual lines alter in length. Well, maybe. I've set Thunderbird to wrap at 79 no matter what, but its easy to see this behavior if you use a word processor such as OpenOffice/LibreOfice. Oh, right, that's cos its HTML mail. EVIL!
Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length,
Hmm, don't they follow email standards? I'm sure USENET is where we first saw base64 encoding folded into neat lines of 76 bytes.
I'm talking about the HEADERS not the body. See http://www.tldp.org/LDP/nag/node258.html <quote> A site may find out about all other sites the article has already traversed by looking at the Path: header field. This header contains a list of all systems the article has been forwarded by in bang path notation. </quote> I'm not talking about 'source based routing' as with UUCP, though that might apply a well. No, I'm talking about Henry's code in C-News that read lines of indefinite length with NO BUFFER OVERFLOW.
Even the linux kernel likes the 80 character limit:
"The limit on the length of lines is 80 columns and this is a strongly preferred limit."
That's about readability of the sources. The kernel itself has no such requirement.
Anyway, we're way OT.
Getting there .... -- In view of the stupidity of the majority of the people, a widely held opinion is more likely to be foolish than sensible. --Bertrand Russell, Marriage and Morals -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards.
I had to for a very short time. I hated it and soon found a PDP-11 running RSTS that supported RJE. That PDP-11 was then knobbled by some post-grads to run UNIX version 5, and I didn't want to let go, so they took me along as test case for their work on compiler development and I got to play with the new languages they were dreaming up. And UNIX. Eventually I did system and kernel hacking on V6 and V7, then on System III and System V commercially.
A looong time ago, I had a PDP11-04 in my basement - I still have the main processor card somewhere. Four 4-bit TTL 74ALU's. Bitslicing.
However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.
Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.
Definitely.
Strictly speaking email doesn’t limit itself to 80 columns.
I know it's mostly a convention now, the RFC says 998 per line.
Even the linux kernel likes the 80 character limit:
"The limit on the length of lines is 80 columns and this is a strongly preferred limit."
That's about readability of the sources. The kernel itself has no such requirement.
Well, that's not important - the key thing is that the 80 characters ,just like the old-fashioned 80x25 video format, can be traced by to ancient IBM punchcards. -- Per Jessen, Zürich (2.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Even the linux kernel likes the 80 character limit:
"The limit on the length of lines is 80 columns and this is a strongly preferred limit."
Anyway, we're way OT.
That is out of date. Kernel coders dropped that a couple years ago. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/2013 02:43 PM, Greg Freemyer wrote:
Even the linux kernel likes the 80 character limit:
"The limit on the length of lines is 80 columns and this is a strongly preferred limit."
Anyway, we're way OT.
That is out of date. Kernel coders dropped that a couple years ago.
but it's still used in other projects, e.g. in coreutils it's even enforced by the 'make syntax-check' rule "sc_long_lines": http://git.sv.gnu.org/cgit/coreutils.git/tree/cfg.mk#n223 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 12:04 PM, Per Jessen wrote:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 11:46 AM:
Duaine was looking for kedit, an enhanced xedit.
http://en.wikipedia.org/wiki/KEDIT
and xedit is provided:
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... http://en.wikipedia.org/wiki/XEDIT <quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>
That sounds pretty limited and crippled compare to what's available for Linux. It isn't. The description above is very poor and/or biased.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress? He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. That is correct. In fact so superior, since it interacts with REXX, you can write shell scripts to copy and invoke the editor, for the lack of a better turn, in "script" mode, manipulate files and do what you want with them afterwords.
Now, THIS, is just one of the other capabilities I'm used to - which I can't find in Linux - yet ! Examples: The first file is a basic "shell" file with all changeable parameters setup with and & in front: * $$ JOB JNM=&VOLSER,CLASS=P,DISP=D,USER='DUAINE HECHLER' * $$ LST DISP=H,CLASS=Q * $$ LST LST=06E,DISP=H,CLASS=U,JSEP=0,RBS=0,RBM=0 // JOB &VOLSER PRINT AGE BROKER STATEMENT FROM XEROX TAPE // OPTION LOG,NODUMP // LIBDEF *,SEARCH=PRD2.SYSPROG // TLBL TAPEIN // ASSGN SYS005,&DRIVE // PAUSE **** MOUNT AGE BROKER XEROX TAPE &VOLSER ON DRIVE &DRIVE **** // MTC REW,SYS005 // ASSGN SYS009,06E // EXEC AFPPRINT,SIZE=80K /* /& * $$ EOJ This is the script file that makes global changes, files it and submits it to run: PARSE UPPER ARG VOLSER DRIVE 'ERASE AGE2XRX TEMPJCL A' 'COPY AGE2XRX SHELLJCL * AGE2XRX TEMPJCL A' QUEUE 'TOP' QUEUE 'C /&VOLSER/'VOLSER'/* *' QUEUE 'TOP' QUEUE 'C /&DRIVE/'DRIVE'/* *' QUEUE 'FILE' 'XEDIT AGE2XRX TEMPJCL A' 'EXEC SUBPROD AGE2XRX TEMPJCL A' 'ERASE AGE2XRX TEMPJCL A' EXIT -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 02:30 PM:
On 02/28/2013 12:04 PM, Per Jessen wrote:
Anton Aylward wrote:
[snip, snip, snippty snip]
I wonder why Duaine wants to regress? He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. That is correct. In fact so superior, since it interacts with REXX, you can write shell scripts to copy and invoke the editor, for the lack of a better turn, in "script" mode, manipulate files and do what you want with them afterwords.
Now, THIS, is just one of the other capabilities I'm used to - which I can't find in Linux - yet !
Examples:
Not a problem! VI and variants support the ability to pipe the file though a (possibly parametrized) script. VI (and variants) also have embedded scripting. It has its own scripting language which is often used to extend its functionality http://www.ibm.com/developerworks/linux/library/l-vim-script-1/index.html http://vim.wikia.com/wiki/VimTip1359 and there's an archive of scripts http://www.ibm.com/developerworks/linux/library/l-vim-script-1/index.html On top of this, there are versions of VI (and variants) which have the common *NIX scripting languages as plug-ins -- perl, python and even ruby. More examples at the wiki, for example, you were talking about manipulating blocks... http://vim.wikia.com/wiki/Applying_substitutes_to_a_visual_block When I run "zypper search vim" I get many plugins. And yes, you can run VI in binary more and use it as a hex editor. I’m sorry, Duaine, anything you're going to say you can do with your mainframe editors I can do with VI (and variants). The fact that I do it differently is not really relevant; UNIX/LINUX is not a copy of VM/CMS or VAX/VMS and shouldn't be. Languages like perl and ruby are more modern and sweeter than REXX and more familiar to many Linux users. But if you insist on REXX, then yes, there's a Linux version: http://regina-rexx.sourceforge.net/ as well as http://www.cs.ox.ac.uk/people/ian.collier/Rexx/rexximc.html and YES you can invoke it from VI (and variants) -- How inappropriate to call this planet `Earth' when it is quite clearly `Ocean'. -- Arthur C Clarke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 12:04 PM, Per Jessen wrote:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 11:46 AM:
Duaine was looking for kedit, an enhanced xedit.
http://en.wikipedia.org/wiki/KEDIT
and xedit is provided:
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... http://en.wikipedia.org/wiki/XEDIT <quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>
That sounds pretty limited and crippled compare to what's available for Linux. It isn't. The description above is very poor and/or biased.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress? He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto. AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.
-- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 02:32 PM:
AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.
RTFM <quote src="man 1 vi"> -b Binary mode. A few options will be set that makes it possible to edit a binary or executable file. </quote> -- Insanity is hereditary. You get it from your kids. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 02:35 PM, Anton Aylward wrote:
Duaine Hechler said the following on 02/28/2013 02:32 PM:
AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.
RTFM
<quote src="man 1 vi"> -b Binary mode. A few options will be set that makes it possible to edit a binary or executable file. </quote>
BUT, can you be IN the file and SWITCH back and forth ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 03:53 PM:
On 02/28/2013 02:35 PM, Anton Aylward wrote:
Duaine Hechler said the following on 02/28/2013 02:32 PM:
AND, I know at least on the mainframe side, you can invoke an option to edit the file in "hex" mode.
RTFM
<quote src="man 1 vi"> -b Binary mode. A few options will be set that makes it possible to edit a binary or executable file. </quote>
BUT, can you be IN the file and SWITCH back and forth ?
Why do I have to google for the answers when you could find them yourself at the site I've already recommended you peruse: http://vim.wikia.com/wiki/Improved_hex_editing#Easily_enter_and_leave_hex_mo... -- Security should be as intuitive as possible. -- Bruce Schneier -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 12:04 PM, Per Jessen wrote:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 11:46 AM:
Duaine was looking for kedit, an enhanced xedit.
http://en.wikipedia.org/wiki/KEDIT
and xedit is provided:
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86... http://en.wikipedia.org/wiki/XEDIT <quote> XEDIT is a visual editor for VM/CMS using block mode IBM 3270 terminals. [1] [2] It is much more line-oriented than modern PC and Unix editors. For example, it supports automatic line numbers, and many of the commands operate on blocks of lines. One of the features is a command line which allows the user to type arbitrary editor commands. Because IBM 3270 terminals do not transmit data to the computer until certain special keys are pressed (such as enter and function keys) XEDIT is less interactive than many PC and Unix editors. For example, continuous spell-checking as the user types is impossible. </quote>
That sounds pretty limited and crippled compare to what's available for Linux. It isn't. The description above is very poor and/or biased.
VI has line numbering, can work on blocks of lines, and has a command line option. There are also programming plug-ins available.
I wonder why Duaine wants to regress? He doesn't want to regress, he wants to be effective. He is used to working with those editors and feel that they are way superior to vi et al. I completely understand where he is coming from. I have yet to reach the same level of fluency with vi that I had/have with the ISPF editor or the LPEX ditto.
In other words, I'm used to: when I'm working with a block of lines: (cc = copy / mm = move / i = insert (for copy and move) / dd = delete (which can be used anywhere in the file - can cross multiple screens of lines) cc==== ........... ........... cc==== ........... ........... i===== None of this ctrl + m, etc. Or having to deal with ONLY the lines that on the current screen. (crap). -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 03:11 PM:
In other words, I'm used to:
when I'm working with a block of lines: (cc = copy / mm = move / i = insert (for copy and move) / dd = delete
(which can be used anywhere in the file - can cross multiple screens of lines)
cc==== ........... ........... cc==== ........... ........... i=====
None of this ctrl + m, etc. Or having to deal with ONLY the lines that on the current screen. (crap).
I think you're getting confused with emacs or something. Copy, delete, cut-and-paste (which is what 'move' really is' can be done anywhere in the file and can work on more lines than appear on the screen. You can set - depending on language - patterns for ranges or groups of lines to work on automatically. Yes the syntax is different, but the capability is there. In fact I think the capability in VI (and variants) is more comprehensive. So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 02:42 PM, Anton Aylward wrote:
Duaine Hechler said the following on 02/28/2013 03:11 PM:
In other words, I'm used to:
when I'm working with a block of lines: (cc = copy / mm = move / i = insert (for copy and move) / dd = delete
(which can be used anywhere in the file - can cross multiple screens of lines)
cc==== ........... ........... cc==== ........... ........... i=====
None of this ctrl + m, etc. Or having to deal with ONLY the lines that on the current screen. (crap).
I think you're getting confused with emacs or something.
Copy, delete, cut-and-paste (which is what 'move' really is' can be done anywhere in the file and can work on more lines than appear on the screen. You can set - depending on language - patterns for ranges or groups of lines to work on automatically.
Yes the syntax is different, but the capability is there. In fact I think the capability in VI (and variants) is more comprehensive.
So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).
Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors ! -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 03:54 PM:
On 02/28/2013 02:42 PM, Anton Aylward wrote:
[..] So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).
Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors !
It would take :827,844m212 I don't see that as complicated. I you wanted to do it graphically, the key strokes might be 827G17dd212Gp That is, Goto line 827 Yank into the transient buffer 17 lines while deleting them Goto like 212 Put the contents of the transient buffer after the current line. I'll grant you there is the issue of 'familiarity'. Everything new looks difficult when you first see it. In practice I may make use of markers so I don't have to count lines, but then again it will depend on context. Those 17 lines might be a paragraph or a region in some kind of syntactic bracketing and I could use that instead. Many UNIX languages use "{" and "}" and its easy enough to say "move the stuff between the bracket the cursor is on and the matching one. This is why I hate HTML and XML! -- "Education must precede motivation." Jim Rohn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/28/2013 03:13 PM, Anton Aylward wrote:
Duaine Hechler said the following on 02/28/2013 03:54 PM:
On 02/28/2013 02:42 PM, Anton Aylward wrote:
[..] So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).
Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors !
It would take
:827,844m212
I don't see that as complicated.
I you wanted to do it graphically, the key strokes might be
827G17dd212Gp
That is, Goto line 827 Yank into the transient buffer 17 lines while deleting them Goto like 212 Put the contents of the transient buffer after the current line.
Again, its called easy of use. In the other editor, you don't NEED to know the LINE NUMBERS + again, CRYPTIC !!!!! <snip> -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 02/28/2013 04:56 PM:
On 02/28/2013 03:13 PM, Anton Aylward wrote:
Duaine Hechler said the following on 02/28/2013 03:54 PM:
On 02/28/2013 02:42 PM, Anton Aylward wrote:
[..] So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).
Well, I'm not that deep in VI and maybe so BUT its not as simple as the other editors !
It would take
:827,844m212
I don't see that as complicated.
I you wanted to do it graphically, the key strokes might be
827G17dd212Gp
That is, Goto line 827 Yank into the transient buffer 17 lines while deleting them Goto like 212 Put the contents of the transient buffer after the current line.
Again, its called easy of use. In the other editor, you don't NEED to know the LINE NUMBERS + again, CRYPTIC !!!!!
Again, you are missing the point - its called "easy of use" - at the editor command line (while editing the file) - I just say "hex on" or "hex off" - NO "ESC + :" - or - "ctrl" - or any CRYPTIC shit.
Please: don't reply to BOTH me AND the list. Its redundant. As for 'ease of use', that's a matter of opinion. There's nothing cryptic about single letter abbreviations - G for goto, m for move, p for put, d for delete and so forth. The more 'obscure' abbreviations - ctl or meta - are because the users want speed and something like 'go to command line mode, type explicit words' is a but unwieldy for a 'common command'. VI only does that for 'settings'. As for line numbers, I thought you were boasting earlier that those mainframe line editors showed line numbers. VI only does if you explicitly ask it to. As I said, mostly you deal with the syntax. I only illustrated with line numbers since that is independent of language. Normally when I 'shuffle' stuff in VI I use the pattern capability or the marker capability. But you're probably call that 'cryptic'. But its the normal way of working with VI. As I said, so many *NIX languages use "{ ... }" bracketing that its normal to put the cursor on one bracket, VI finds the matching one, and you do an operation on what's in between. You can redefine - per language - what VI thinks of as a 'paragraph' and delimiters, break markers, comment strings and so forth. Line numbers are normally for when you're talking to someone else as in "you have a bug at line 1243" ... that's comment across all architectures! I recall when the PC and MS-DOS proliferated, there were keyboard templates for things like WordPerfect that gave the mnemonics for the function keys. GEE WOW! UNIX grew up with a terminal independent environment, not like your dedicated IBM terminals. The reason for TERMCAP et al was that the programmers didn't know what terminal applicability a program could expect. So we relied on things like ctl key sequences that could be types on ANY terminal. That you now have a 105-key PC keyboard and 9-button mouse with 3-d scroll-wheel is fortunate. But we didn't have any of that back when it was a cheap terminal that incorrectly and incompletely emulated a VT-100. It's nice that modern VI will allow you to re-define just about any sequence you want. -- This isn't life in the fast lane, it's life in the oncoming traffic. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
It's nice that modern VI will allow you to re-define just about any sequence you want.
I'm surprised noone has bothered pointing out how OT this all is :-) Anyway, Unix runs in a multitude of environments, MVS and VM don't - that is a very important difference too. -- Per Jessen, Zürich (1.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 03/01/2013 04:33 AM:
Anton Aylward wrote:
It's nice that modern VI will allow you to re-define just about any sequence you want.
I'm surprised noone has bothered pointing out how OT this all is :-)
Anyway, Unix runs in a multitude of environments, MVS and VM don't - that is a very important difference too.
I was at a Novell presentation a while back when they were pushing Suse - SLED and SLES - and there was a presentation from IBM about how they were running Suse as their virtual Linux on a mini-mainframe. This box about the size of a bar fridge could support over 4,000 virtual instances of Suse Linux. I WANT ONE! I also want Google Glasses running Linux ... -- People who won't quit making the same mistake over and over are what we call conservatives. - Richard Ford, in his novel Independence Day -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Per Jessen said the following on 03/01/2013 04:33 AM:
Anton Aylward wrote:
It's nice that modern VI will allow you to re-define just about any sequence you want.
I'm surprised noone has bothered pointing out how OT this all is :-)
Anyway, Unix runs in a multitude of environments, MVS and VM don't - that is a very important difference too.
I was at a Novell presentation a while back when they were pushing Suse - SLED and SLES - and there was a presentation from IBM about how they were running Suse as their virtual Linux on a mini-mainframe. This box about the size of a bar fridge could support over 4,000 virtual instances of Suse Linux.
Yeah, Linux/390 - it's pretty cool stuff. I did some work on porting SAPDB to it some years back.
I WANT ONE!
Look up the Hercules project, you can start your training there. You might even get to run some old ISPF editor :-) -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
So, can you do move lines 827 though 844 to before line 212 in one go? Trivial in VI (and variants).
Not in one go, no - ISPF edit doesn't work with line numbers in the same way that e.g. vi does. To do what you ask, in ISPF edit you would first mark the lines you want to move with 'mm', then you would scroll to the target line and place an 'a' or a 'b', then hit enter. Last I worked with ISPF edit (late 80s) I remember installing some copy and paste macros too, they made a lot of stuff much easier. -- Per Jessen, Zürich (2.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 03/01/2013 05:27 AM:
Last I worked with ISPF edit (late 80s) I remember installing some copy and paste macros too, they made a lot of stuff much easier.
macro capability is good. Every serious editor should have that capability. Confession: I've rather overloaded the :map on my VI -- Me...a skeptic? I trust you can prove that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-02-28 a las 14:11 -0600, Duaine Hechler escribió:
None of this ctrl + m, etc. Or having to deal with ONLY the lines that on the current screen. (crap).
Any of the text editors in Linux can copy text outside the current screen. You are confusing the editor capabilities with the plain X mouse copy/paste, which is limited to the current screen or terminal. Besides vi and emacs, which are both very powerful (and difficult) text editors capable of starting wars between their respective proponents, there are other simple text based text editors, such as joe (with several variants) or mcedit. And then there are several graphical text editors, some simple and some complex and powerful. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlEv7XEACgkQja8UbcUWM1wVxgD/Z5e3mWoVJGX0Vq5sL/FCiXUT J47l8T3dLMtsiMxdb6EA/jtU0ySW9OERnYq5optqN8+j8ojvlh4zOwQsBi+m9lBp =Zeq3 -----END PGP SIGNATURE-----
Duaine Hechler wrote:
Since I've been out of the mainframe world for about 13 years, what happened to the mainframe style "full screen" text editors being standard in Linux. Like, XEDIT, KEDIT, ISPF.
I understand Emacs can be used as an editor. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
Duaine Hechler -
Greg Freemyer -
James Knott -
Patrick Shanahan -
Per Jessen