Some things might use the vt100 scrolling region, which behaves like an atomic delete+insert line.
File change notifications are always delivered asynchronously. So they can only ever tell you what part of the file to examine later, not exactly what all has happened there at the time you are looking. Which is to say, it serves as a wakeup and a clipping region for what might have changed before the wakeup was sent, but it doesn't provide a complete undo-record of the changes to the file. I think this points to the fundamental overhead of your current console design. The functional splits make sense, but one way or another flicker just seems real likely. I have an idea for a way to make this style of update correct, though it has overhead just as big or bigger. That is, a different form of notification that preserves all the information. What I'm thinking of is a request for "update propagation" that would give a file port on which the fs would send regular io RPCs (with no reply ports) as notification of changes. It could in the trivial case reflect every io RPC it performs, but would be allowed to coalesce into larger chunks at will (including perhaps sending an io_write with interpersed bits of unchanged data). We could then add a call or two something like io_edit to perform insertion/deletion. Any fs could implement this as an optimization over combinations of extend/truncate, read some, write it elsewhere, or punt with a canonical error for a case it didn't want to think about (or just implement the data copying itself). For a disk filesystem this could be a useful optimization for some other programs to use, so that inserting/deleting a block or more just diddles the inode instead of touching the data in the whole blocks. With that, you could have emacs mmap mkfile'd nodes for buffers and use io_edit for gap operations--then writing the buffer out just does dir_link on the node. Anyway, a random thought. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
