David Low said; > > > Hmm... I would hate to have to scroll 32K to the right... I > definitely > > prefer 72 columns in 400+ lines to 32k columns in 1 line > > - -- > > I agree, it is nice to have all the data accessible such that > only vertical scrolling is required. But what if you coded > one of those lines wrong and had to shift data by one byte? > Have fun re-wrapping all the subsequent lines.
That's why most of the "other platforms" editors are more context sensitive. Re-flowing lines -can- be completely automatic in a moderately intelligent editor designed for the language you're using. Same goes for syntax colorization, auto-completion etc. etc. This is one of those areas where ISPF's archaic limitations show through. It's wonderful for editing row/column oriented data with less than (say) 80 bytes per line. It sucks for long(er) lines and more fluid data content. We've all used it for so long, and in essentially the same way, so it has been easy to overlook how cumbersome it is for editing >80 byte lines. > Many HFS paths are much longer than 80 bytes. I've mistyped > HFS paths more than a few times to know that it's a tedious > process having to cut/paste/shift lines around to correct > them. A one-liner to fix would be a quick BNDS command and a > shift left or right. Yep! It is a royal PITA. And a no-brainer in a more flexible editor :O( CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
