del@thrush.semi.harris-atd.com (Don Lewis) (12/06/89)
It would be real nice if when a folder is updated, the current message location is preserved, rather than setting the current message back to the beginning of the folder. This is gets a little tricky if the current message gets deleted from the folder in the update. In this case, the current message should get set to the nearest following (or preceeding) message that will be saved in the folder. -- Don "Truck" Lewis Harris Semiconductor Internet (if you're lucky): del@semi.harris-atd.com PO Box 883 MS 62A-028 Internet (if not): del%thrush@trantor.harris-atd.com Melbourne, FL 32901 UUCP (works): rutgers!soleil!thrush!del Phone: (407) 729-5205
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (12/07/89)
In article <1989Dec6.031050.12607@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes: } It would be real nice if when a folder is updated, the current message } location is preserved, rather than setting the current message back to } the beginning of the folder. This is gets a little tricky if the } current message gets deleted from the folder in the update. In this } case, the current message should get set to the nearest following (or } preceeding) message that will be saved in the folder. It gets a little tricky if *any* messages preceding the current one are deleted, let alone if the current one is deleted. The current message is stored only as an offset into an array of messages, and that array is completely flushed and reloaded by an update. It might be possible to do some arithmetic in the process of re-writing the folder to compute what the "new" current message number should be .... In any case, you can create much the same effect yourself. cmd update '\ eval -h set current_id = %i; \update;\ pick -h message-id "$current_id" | from -' By cmding "update" to call itself (note the backslash to prevent a recursive cmd) you will cause *all three* modes (line, curses, tool) to perform this operation! The curses [update] command and toolmode <Update> button will call your "update" cmd. (I *hope* the "from -" doesn't cause toolmode problems; it won't in the next release.) Of course, not all messages in all folders have a message-id, so you might choose some other highly-likely-to-be-unique field, like the date. -- Bart Schaefer "I seem to have run into a novel problem with the electronic mail. My computer's demanding an electronic female." schaefer@cse.ogi.edu (used to be cse.ogc.edu) "Preferably brunette."
tneff@bfmny0.UU.NET (Tom Neff) (12/07/89)
One way to store the current position in a saved folder would be by adding a Status: flag. The penalty is that multiple users eating out of the same folder could not maintain different current locations, but the advantage is that it's completely stable. -- War is like love; it always \%\%\% Tom Neff finds a way. -- Bertold Brecht %\%\%\ tneff@bfmny0.UU.NET
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (12/07/89)
In article <14983@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: } One way to store the current position in a saved folder would be } by adding a Status: flag. The penalty is that multiple users eating } out of the same folder could not maintain different current locations, } but the advantage is that it's completely stable. I considered mentioning that, but saving the current message across *changing* folders wasn't the question -- saving it through update of the current folder was. But any scheme that depends on saving that sort of information in the folder itself opens a can of worms; not only is there the question of what to do with multiple "eaters", but of where to place the current message when there is new mail, what to do with that status bit if the message is saved to a different folder ("... but I want the last message I put there to become the current message for that folder!"), etc. etc. At least retaining the current message within a single session with the same folder has easily defined semantics. Essentially, one complication is that the only difference between "update" and "folder %" is that "update" doesn't forget the name of the previous folder (accessed as "#"). If the temp file were never actually emptied until quit or folder change, you could keep track of the current message by its seek offset in the temp file (which "sort" does in 7.0whatever). But that would be an unacceptable waste of disk space for long sessions. A second complication is that the code organization makes it difficult (not impossible, just difficult) to pass the information about where the current message should end up, from the function that writes the folder to the one that reads it back in. Somewhere in mush's "maybe someday" clause is generalized user tagging of messages, at which point everybody can figure this one out as most pleases them. -- Bart Schaefer "I seem to have run into a novel problem with the electronic mail. My computer's demanding an electronic female." schaefer@cse.ogi.edu (used to be cse.ogc.edu) "Preferably brunette."
del@thrush.semi.harris-atd.com (Don Lewis) (12/07/89)
In article <5995@ogicse.ogc.edu> schaefer@ogicse.UUCP (Barton E. Schaefer) writes: >In article <1989Dec6.031050.12607@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes: >} It would be real nice if when a folder is updated, the current message >} location is preserved, rather than setting the current message back to >} the beginning of the folder. This is gets a little tricky if the > >It gets a little tricky if *any* messages preceding the current one are >deleted, let alone if the current one is deleted. The current message >is stored only as an offset into an array of messages, and that array >is completely flushed and reloaded by an update. It might be possible >to do some arithmetic in the process of re-writing the folder to compute >what the "new" current message number should be .... This is pretty much what I had in mind. It doesn't look like it should be all that hard to figure out what the new message number should be. I haven't looked at how hard it will be to get mush to use this when it reloads the folder, though. -- Don "Truck" Lewis Harris Semiconductor Internet (if you're lucky): del@semi.harris-atd.com PO Box 883 MS 62A-028 Internet (if not): del%thrush@trantor.harris-atd.com Melbourne, FL 32901 UUCP (works): rutgers!soleil!thrush!del Phone: (407) 729-5205