🚀 go-pugleaf

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