"TM" == Timothy Moore moore@bricoworks.com writes:
TM> On Aug 9, 2005, at 9:28 PM, rpgoldman@real-time.com wrote: >> I'm afraid that hasn't really been my experience. I can often crash >> McCLIM when I do something that upsets its processing of ACCEPT, in >> particular, and updating output seems to work very, very badly with >> scrolling panes, so badly that I can't think of a single interaction >> which hasn't required me to iconify and de-iconify the frame to make >> it repaint reasonably. And usually I have to resize the frame by hand >> in the process. This seems to me to be pretty far from usable. TM> I'm not necessarily disagreeing about the state of accept (more TM> accurately input editing) and incremental redisplay, but I'm having TM> some trouble searching through the mail archives for specific TM> complaints. In particular I have not noticed problems with scrolling TM> and updating-output in my use of it. Do you mind (re)posting some TM> specific bugs?
Tim, sorry to have taken so long to get back to you. Rereading your email, I see that I have misled you. I was referring above to two *separate* problems. I.e., (1) I have found it very easy to toss my McCLIM app into the debugger by typing a bad character in the middle of ACCEPTing arguments and (2) I have frequently had trouble with updating output that has left me with a small subset of a scrolling window redrawn, and with the rest of that window a blank, gray area.
I'm not sure that (1) is a bug, per se. It's not that ACCEPT ever returns a bad value, it's just that it is not robust to getting bad input. I would have thought that ACCEPT should by default trap the INPUT-NOT-OF-REQUIRED-TYPE. As a programmer, I don't see how I can do this, if ACCEPT doesn't. I.e., when I write a define-<foo>-command form, it's internal CLIM stuff that handles getting the arguments for me, and if I type something wrong, I'd rather not have the application dumped into the debugger. So shouldn't that command processing exit somewhat gracefully by default?
Similarly, as I mentioned earlier, it would be nice if one could use the ABORT gesture in the middle of ACCEPT and have something good happen. Seems like if I type something bad and can't fix it in input-editing, I'm just doomed to complete the interaction, and then have the command fail into the debugger. I looked into this a little, and it seemed like there was no place in the %ACCEPT code that looked for an ABORT gesture, but the bottom layers of McCLIM are pretty mysterious to me. Is this a GOATEE thing, or should it be handle by %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be happy to try to fix it myself.
Best, R