I did address that earlier, you know; I said that it would take testing. However, it seems to me that if you or I are going to test something... we would want to know what it is we're testing. Moreover, it seems likely that there has to be
some reason beyond inertia why the method has persisted. Inertia can explain a lot of crappy code, but not the use of basically the same design in several places when a potentially better one (the list of lines model) would appear to be simpler on the surface.
As for the source code to vim itself...
But a lousy implementation of an idea does not necessarily imply that the idea is lousy.
(BTW, Brendan, I keep meaning to ask why you consistently spell 'pus' as 'puss'. I know it isn't a Commonwealth vs Merkin thing, as every British dictionary I have seen spells it with one 's' - though Wiktionary does mention it as an alternate spelling, so I guess it isn't wrong per se. I don't know why, but it has always bugged me a bit.)
Is this even worth continuing with? If it is, then I suggest we
all (re-)read the Finseth book (it's free, after all, and not especially long) and see what his arguments are before deciding whether they make sense. Otherwise, it would be like arguing about a point on (say) FSA-driven lexical analysis when we haven't read the Dragon Book (or something equivalent).
In this case, it's even worse than that, actually, as
The Craft of Text Editing is pretty much the only textbook on the implementation of text editors at all, AFAIK. Now, that doesn't mean that he was right, or that things haven't changed since 1991, but it does mean that it is worth at least seeing what it says before dismissing the arguments.
(Keep in mind that I have already mentioned that my earlier gloss on the topic was wrong in at least some particulars, and I gave a partial correction on that. I may be wrong in other parts as well. Arguing his points based on my incorrect recall of them isn't going to work here, which is why I need to read it again myself.)
If we still disagree, we can test then.
EDIT: Sorry to keep doing this, but... it just occurred to me that no one, including myself, mentioned something that should be obvious: the input module - which, like the renderer, needs to be separate from the editing engine - cannot use standard stream I/O functions if it is to work as a full-screen editor. This is a bit of a side issue, since the editing engine is what we (well, I anyway) are focusing on, but still a useful point.
Even for a single line of text, anything that is meant to use any kind of in-line editing has to be able to accept whatever input the keyboard or terminal provides directly (scan codes, or at least some sort of 'rare' key codes, in the case of the PC) in order to be responsive to anything other than inserts. Collecting the input into a simple buffer until the ENTER key is struck, and then sending it all as a stream, isn't feasible.
This is easily forgotten today, since most current shells and TUIs (and pretty much all GUI text entry windows) provide a certain amount of editing capacity for you - the input is still being read as raw by the shell or textbox mini-editor, it's just that it is then sent to the application via stdin or the equivalent (or via reading the textbox buffer in the case of a GUI).
Why do a mention this? Because I am re-reading the Finseth book, and he is going about explaining this in the first chapter, by presenting examples of successive incomplete models of this - for the purpose of then dissecting them and explaining why they are inadequate. While the examples all use a nebulous 'KeyGet()' function, they are shown initially just putting input into a buffer until the ENTER is pressed. Now that I am reading it again, this quasi-Socratic Method (he even describes it that way in the preface) seems familiar, and I am pretty sure that he does indeed address the questions already raised. I think, however, you will need to see for yourselves if you find his arguments convincing or not.