Personally, I think it would be a total blast to do some long form writing on the old Atari, similar to what I do from time to time on the Apple. Apples are still productive actually. Yeah, it's mouse text, and it's got various clunky things, but one can do real stuff. One day, an Atari will join that club. Again, damn cool.
There is something just golden about doing that. Heck, maybe write up a few game reviews on the thing. (We need an ASCII output option in LW, if it's not there already.)
A word processor will probably be the biggest hurdle of all, but fortunately most of the groundwork's already been done in LW and I have a few optimisations up my sleeve which I was considering using there but didn't, so I think we have enough slack to make a responsive editor. For example, I confirmed via an experimental version of LW that the only thing which needs to refresh after each keystroke is the current line - all the rest of the text below can shuffle into place when the user stops typing for a moment. This is going to be key to our success, because there's no way we can redraw fifteen or so lines of text in a paragraph (assuming they all realigned at once) every time the user types a character. So once the important stuff is redrawn (the current line), the next keystroke in the buffer will cause the redraw to abort. This is surprisingly acceptable in practice, although - as I say - LW doesn't do it. Word processors / text editors are my favourite applications bar none, so I'll be spending extra time getting those right. The ASCII output option is a great idea, by the way: something I was planning on putting in the GUI wp, but I can also build it into the non-GUI version of LW. In the GUI, we have 256 character fonts and code pages, and thus Unicode support (or a flavour thereof), so getting text between the PC and the Atari should be straightforward. In point of fact there's no particular reason to use $9B as the EOL character in the GUI anyway, so we could use either ASCII or ATASCII internally (dynamically converting text files to suit either way).
Regarding the ST: yes it was developed quickly, and GDOS, etc, put some things right later on, but I'm just puzzled why modern OSes for the ST / TT / Falcon still persist with the fixed-pitch system font. As for the meticulous work going into this project and why TOS perhaps wasn't as efficient comparatively speaking: I've already said that I have no choice at all but to code this GUI in assembler, to take my time about it, and to painstakingly develop new ways of doing things. I wouldn't expect developers for 16-bit machines, in a commercial scenario, to spend two years hand-coding everything in assembler. That said, though, MrFish raises a good point: we have one person writing the code, and one person doing all the resources. Surely software houses have big, full-time, payrolled teams?
Seriously, though: we're talking with the benefit of hindsight here, and we've gotten used to nice proportional fonts, etc, over the past twenty years. TOS did its job just fine when it came out. If the A8 GUI compares favourably in performance or aesthetics to the ST / Amiga / Mac, then that's a plus for us as opposed to a minus for those other machines. It was a different world back then.
Edited by flashjazzcat, Thu May 10, 2012 4:01 AM.