> Using a text editor to manipulate files with lines that are thousands > of words long seems like a not very good idea to me.
1st : I don't see why. I had a feeling there was some tendency (at least R Pike could have one) not to look at a file as on a list of lines, but as on a linear stream of bytes. I find it really frustrating when I see comments, like above, that eg. sed has problems with 'too-long' lines. 2nd: as long as you communicate with people who use common measuring instruments, you just have to edit such files. They are plain-text files but have long lines. That doesn't mean they are extraordinarily big; they may have only a few lines. And moreover, the structure of those file is sensible. 3rd: awk might be a good instrument (although eg. Raymond argues it is flawed) for analysis carried out automatically by machines, but it is, for me, not an editor for manual, human, interactive work. In the light of aforementioned: vim's ability to work in the nowrap mode and the ability to repeat commands (or regexps) [and I could add also the existence of column blocks] makes it superior to both acme/sam when editing considered files. As usually, this is the tax for sam/acme's simplicity. And, understand, I am for simple things. I somehow can understand why sam and acme don't have the nowrap mode and, followingly, the column blocks. It is, as far as I know, due to the stream-like character of sam/acme's view on files. What I can't understand is, why I can't repeat my commands / regexps. One of these would be right enough to easily do my task and many more. Correct me if I am wrong, but even the simplest regexps used in linux can have a number denoting repetition. Why plan9's regexp(7) doesn't have it? Thanks Ruda
