In a recent note, Craddock, Chris said: > Date: Mon, 16 May 2005 08:12:56 -0500 > > 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. > Assembler presents quite a challenge, here. It's painfully hard to tell what's an apostrophe-delimited string vs. what's an attribute introduced by a single apostrophe, 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. > Consider even XEDIT, which (optionally) allows displaying a long file line in multiple screen lines, formatted as a single 3270 field for easy insertion and deletion. IIRC, in ISPF, in contrast, if I delete a single character from a partially visible line compensates (in its view) by introducing a blank at the right edge of the screen, rather than ignoring the null echoed by the READ MODIFIED. Has there ever been a Requirement for an ISPF mode in which long lines would be displayed wrapped on the screen, rather than by horizontal scrolling? > Yep! It is a royal PITA. And a no-brainer in a more flexible > editor :O( > I agree strongly. Although Shmuel points out terminals nowadays are not limited to 80 columns, there's always a residual use for lines wider than any particular terminal. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
