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