Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!apple!rutgers!soleil!slopoke.semi.harris-atd.com!thrush!del From: del@thrush.semi.harris-atd.com (Don Lewis) Newsgroups: comp.mail.mush Subject: Re: mushtool bugs and patches (long) Message-ID: <1989Nov22.064230.13339@semi.harris-atd.com> Date: 22 Nov 89 06:42:30 GMT References: <1989Nov21.055514.6990@semi.harris-atd.com> <5756@ogccse.ogc.edu> <128221@sun.Eng.Sun.COM> Sender: news@semi.harris-atd.com Reply-To: del@thrush.semi.harris-atd.com (Don Lewis) Organization: Harris Semiconductor, Melbourne, FL Lines: 191 In article <128221@sun.Eng.Sun.COM> argv@sun.UUCP (Dan Heller) writes: >> } The third problem causes the "f" or "r" flags to be set on a piece of mail >> } if you start to reply to or forward this piece of mail and then abort before >> } actually sending the the mail. This patch is a bit ugly. >> All the code for sending mail in 7.0.0.0 toolmode is more than a bit ugly, >> and has completely changed. I *know* this patch won't work on the latest >> mail.c, but I'll keep the bug report in case it's still a problem. > >Currently, this won't work anyway because of the event-driven nature of >the toolmode. For example, you can reply to a message and then resort >everything using the "sort" menu. If you successfully send the message, >you could potentially mark the wrong message as being replied to. > >Further, the is going to be a facility for multiple compositions. >This means that you could reply to the same message in different >windows, abort one message, but complete the other. Again, the >event-driven nature interferes. Someday, this will be fixed correctly. > This is worse than I thought. Sigh. >> } I have also noticed some problems with the function keys. >> } The function keys only work in certain windows. >> The function keys are going away altogether as I understand it. >All of the reasons bart mentioned for function keys going away are true. >But the function keys profice a nice way to "accelerate" actions within >the window. As a replacement (someday), there is going to be a "command" >window similar to dbxtool, maybe. That is, you will be able to enter >mush commands directly from a special window or prompt. > But in the mean time, the function keys are the only way to do useful operations that are not possible given the buttons and menus. I use one of the function keys to do "mail -f". So see below for a throwaway patch for this until we get the real thing. This is a simple patch to make the Open, Front, and Props function keys not do any bogus mushtool function key actions. It's not as easy is totally disabling the function key code, but at least the other function keys are still usable (at least in the subwindows that listen to them). *** ORIGselect.c Wed Sep 6 12:36:25 1989 --- select.c Tue Nov 21 23:39:45 1989 *************** *** 54,59 **** --- 54,60 ---- struct rect rect; static char lastchar; static int line, count; + Inputmask im; if (ID == WIN_REPAINT || ID == WIN_RESIZE) { if (exec_pid) *************** *** 61,71 **** msg_rect = *((Rect *) window_get(msg_sw, WIN_RECT)); crt = msg_rect.r_height / l_height(curfont); } ! else if (ID >= KEY_LEFTFIRST) ! if (ison(glob_flags, IS_GETTING)) ! print("Finish editing letter first"); ! else ! (void) func_key(ID); else if (isascii(ID) && (ison(glob_flags, IS_GETTING))) { /* * If editing a letter, then enter the keys typed. --- 62,81 ---- msg_rect = *((Rect *) window_get(msg_sw, WIN_RECT)); crt = msg_rect.r_height / l_height(curfont); } ! else if (ID >= KEY_LEFTFIRST) { ! input_imnull(&im); ! win_keymap_set_imask_from_std_bind(&im, ACTION_OPEN); ! win_keymap_set_imask_from_std_bind(&im, ACTION_CLOSE); ! win_keymap_set_imask_from_std_bind(&im, ACTION_FRONT); ! win_keymap_set_imask_from_std_bind(&im, ACTION_BACK); ! win_keymap_set_imask_from_std_bind(&im, ACTION_PROPS); ! if (!win_getinputcodebit(&im, ID)) { ! if (ison(glob_flags, IS_GETTING)) ! print("Finish editing letter first"); ! else ! (void) func_key(ID); ! } ! } else if (isascii(ID) && (ison(glob_flags, IS_GETTING))) { /* * If editing a letter, then enter the keys typed. *************** *** 110,115 **** --- 120,126 ---- { static int which_cursor; int line; + Inputmask im; if (ID == WIN_REPAINT) { if (is_iconic != (int) window_get(tool, FRAME_CLOSED)) { *************** *** 145,152 **** return; line = event_y(event) / l_height(DEFAULT); ! if (ID >= KEY_LEFTFIRST) ! (void) func_key(ID); else if (!msg_cnt || n_array[line] > msg_cnt) if (!msg_cnt) print("-- You have no messages -- "); --- 156,171 ---- return; line = event_y(event) / l_height(DEFAULT); ! if (ID >= KEY_LEFTFIRST) { ! input_imnull(&im); ! win_keymap_set_imask_from_std_bind(&im, ACTION_OPEN); ! win_keymap_set_imask_from_std_bind(&im, ACTION_CLOSE); ! win_keymap_set_imask_from_std_bind(&im, ACTION_FRONT); ! win_keymap_set_imask_from_std_bind(&im, ACTION_BACK); ! win_keymap_set_imask_from_std_bind(&im, ACTION_PROPS); ! if (!win_getinputcodebit(&im, ID)) ! (void) func_key(ID); ! } else if (!msg_cnt || n_array[line] > msg_cnt) if (!msg_cnt) print("-- You have no messages -- "); The following is a patch to what appears to be an real tool mode bug. I think this one actually bit me the other day. I hit the done button just about the time new mail was coming in and mushtool hung trying to read from fd 0. I don't really know if there should be some explicit tool mode code here, but the original is clearly wrong. *** ORIGmsgs.c Thu Sep 7 11:26:30 1989 --- msgs.c Wed Nov 22 00:57:28 1989 *************** *** 253,263 **** char buf[16]; if (iscurses) putchar('\n'), turnon(glob_flags, CNTD_CMD); ! if (!istool) print("%s [n] ", prompt); buf[0] = 0; if (!Getstr(buf, sizeof (buf), 0) || lower(*buf) != 'y') return 0; } } first = 0; --- 253,264 ---- char buf[16]; if (iscurses) putchar('\n'), turnon(glob_flags, CNTD_CMD); ! if (!istool) { print("%s [n] ", prompt); buf[0] = 0; if (!Getstr(buf, sizeof (buf), 0) || lower(*buf) != 'y') return 0; + } } } first = 0; I found the above when I was looking to see how hard it would be to modify mushtool so that it would go iconic before actually saving the mail folder. The present implementation is annoying if you have a large mail folder and you want to get mush out of the way to make some room on your screen. Unfortunately, this looks like one of those things that is not very easy to implement. Odds and Ends: I noticed that if you hit the update button and your folder is already up to date, mushtool doesn't ask if you want to update the folder, but it does go off and think for quit a while. It's not obvious what it is doing. I noticed in msgs.c that the permission checking on the folders is done by checking the owner permission bits returned by stat(). This is not correct if the folder is owned by another user. Shouldn't the access() system call be used instead? I'm really impressed by the different mouse buttons getting highlighted on the cursor in the header window ;-). -- 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