1 10/11/83  Enhancements to the read_mail command
  2 
  3 This info segment briefly describes the enhancements made to the
  4 read_mail command in various system releases.
  5 
  6 
  7 10/11/83  List of enhancements in MR10.2:
  8    (1) forwarding with comments,
  9    (2) new forward request control arguments,
 10    (3) recipient notification in forward and reply,
 11    (4) improved mailbox selection,
 12    (5) improved message selection,
 13    (6) improved control over message display format,
 14    (7) improved message summaries, and
 15    (8) use of the Acknowledge-To field
 16 
 17 
 18 Forwarding with comments:
 19 The forward request is now able to add a comment to a message before
 20 forwarding the message.  This feature is requested by using the new
 21 "-add_comments" control argument on the forward request line.  When
 22 this control argument is given, the user is prompted for the text of
 23 the comment; this text may be edited in the same way that the message
 24 created by send_mail is edited before transmission.
 25 
 26 The text of the comment is placed in the new "Redistributed-Comment"
 27 field which is added by this request in addition to the standard
 28 redistribution header fields.  The original copy of the message is not
 29 modified by this operation.
 30 
 31 For more information, type:
 32      help forward
 33 
 34 
 35 New forward request control arguments:
 36 The following control arguments are now supported by the forward
 37 request:
 38 
 39 -acknowledge, -ack
 40    specifies that each recipient of the forwarded message will send an
 41    acknowledgement to the user who forwarded the message after they
 42    have read the message.
 43 -no_acknowledge, -nack
 44    specifies that the user forwarding the message does not want to
 45    receive acknowledgements.  (Default)
 46 
 47 
 48 -log
 49    causes a copy of the forwarded message to be placed in the user's
 50    logbox.  If the logbox does not it exist, it will be created and a
 51    message to that effect will be displayed.
 52 -save path, -sv path
 53    causes a copy of the forwarded message to be placed into the savebox
 54    with the specified pathname.  The suffix "sv.mbx" is added if
 55    necessary.  If the savebox does not exist, the user will be queried
 56    for permission to create the savebox.  If the user refuses to give
 57    permission, the forward request will be aborted without actually
 58    sending the message to any of the recipients.
 59 
 60 
 61 Recipient notification in forward and reply:
 62 The forward and reply requests now permit the user to indicate whether
 63 or not the mail system should send "You have mail." notification
 64 messages to the recipients of the message.  This facility is controlled
 65 by the following new request control arguments:
 66 
 67 -notify, -nt
 68    specifies that the mail system should send a "You have mail."
 69    notification to each recipient of the message.  (Default)
 70 -no_notify, -nnt
 71    specifies that the mail system should not send notification messages.
 72 
 73 
 74 Improved mailbox selection:
 75 The read_mail command now permits the name of an entry in the system
 76 mail table to be used to specify the mailbox to be examined.  For
 77 example, the command line
 78 
 79      read_mail Palter
 80 
 81 will now examine the contents of the user Palter's default mailbox
 82 provided that there is no mailbox or savebox in the working directory
 83 named Palter.mbx or Palter.sv.mbx, respectively, and that the the mail
 84 table entry for Palter specifies his default mailbox as its value.
 85 
 86 For more detailed information, type:
 87      help read_mail -ca -user; help read_mail -section mailbox selection
 88 
 89 For more detailed information about the mail table, type:
 90      help mail_table.gi
 91 
 92 
 93 Improved message selection:
 94 The read_mail command now provides greater flexibility in determining
 95 which messages in the mailbox are to be examined.  This new capability
 96 is provided by the following read_mail control arguments:
 97 
 98 -accessible, -acc
 99    specifies that read_mail should only select those messages in the
100    mailbox that the user is permitted to read.  If the user has read
101    (r) extended access on the mailbox, read_mail will select all
102    messages in the mailbox; if the user has own (o) extended access on
103    the mailbox, read_mail will select only those messages which the
104    user sent to the mailbox.  (Default)
105 -all, -a
106    specifies that read_mail should select all messages in the mailbox
107    regardless of who sent them.  Use of this control argument requires
108    read (r) extended access on the mailbox.
109 
110 
111 -own
112    specifies that read_mail should select only those messages in the
113    mailbox that the user himself sent to the mailbox.  Use of this
114    control argument requires own (o) extended access on the mailbox.
115 -not_own
116    specifies that read_mail should select only those messages in the
117    mailbox that were not sent by the user.  Use of this control
118    argument requires read (r) extended access on the mailbox.
119 
120 
121 Improved control over message display format:
122 The read_mail print request now provides four levels of detail for the
123 information displayed from the message header.  Which level of detail
124 to use is specified by one of the following request line control
125 arguments:
126 
127 -long_header, -lghe
128    specifies that the print request is to display all information from
129    the message header including network tracing information even if
130    some of the information is redundant.  (Ie: if the From, Sender, and
131    Delivery-By fields are all equal, this option will force the print
132    request to display all three fields when it prints the message).
133 -header, -he
134    specifies that the print request is to display all information from
135    the message header including user-defined fields while excluding the
136    message trace and redundant information.  (Default)
137 
138 
139 -brief_header, -bfhe
140    specifies that the print request is to display the minimal amount of
141    information from the message header.  The date and authors are
142    always displayed; the subject is displayed if it isn't blank; the
143    number of recipients is displayed either if there is more than one
144    recipient or the user is not the sole recipient of the message; if
145    the message was ever forwarded with comments, these comments will be
146    displayed.
147 -no_header, -nhe
148    specifies that the print request is to display absolutely no
149    information from the message header.  Only the message number,
150    message body line count, and message body will be displayed.
151 
152 
153 The above control arguments are also available on the read_mail command
154 line in order to change the detail level default for the print request
155 within a particular invocation.
156 
157 In addition, the print_header request now accepts the "-long",
158 "-default", and "-brief" control arguments to select amongst the first
159 three levels of detail described above.
160 
161 For more information, type:
162      help message_format.gi
163 
164 
165 Improved message summaries:
166 The message summary produced by the list request has been enhanced to
167 include two new flag characters after the message number.  The "A" flag
168 will appear for any message which will be acknowledged after it is
169 printed.  The "&" flag will appear for any message which can not be
170 deleted due to insufficient access.
171 
172 
173 Use of the Acknowledge-To field:
174 The read_mail command now uses the contents of the last Acknowledge-To
175 or Redistributed-Acknowledge-To field in the message to determine to
176 whom it should send message acknowledgements.
177 
178 
179 
180 10/06/82  List of enhancements in MR10.1:
181    (1) an improved mailbox selection capability,
182    (2) the print_header request,
183    (3) the apply request
184    (4) elimination of the "-all" control argument,
185    (5) extended message selection,
186    (6) improvements to the reply request,
187    (7) request line abbreviation processing,
188    (8) new standard requests,
189    (9) improved self-documentation facilities,
190   (10) new request name abbreviations,
191   (11) new command line control arguments,
192   (12) protection from accidental deletion of messages,
193   (13) minimal video system support, and
194   (14) improved acknowledgements.
195 
196 
197 Enhanced mailbox selection:
198 The read_mail command now uses a different interpretation of a
199 non-control argument on its command line when selecting a mailbox.
200 This new interpretation was chosen to simplify the selection of
201 mailboxes and saveboxes in the working directory.
202 
203 The new interpretation is:
204 STR
205    is any non-control argument and is first interpreted as:
206          -mailbox STR
207    if no mailbox is found, this specification is then interpreted as:
208          -save STR
209    if no savebox is found, this specification is then interpreted as:
210          -user STR
211 
212 
213 print_header request:
214 The print_header request prints the message header of the selected
215 messages.  It is intended as a replacement for the "-header_only"
216 control argument available with the print request.  The "-header_only"
217 control argument is now undocumented but will be retained for one
218 release to allow users to convert their exec_coms (if any).
219 
220 
221 apply request:
222 The apply request executes an arbitrary command line on a segment in
223 the process directory containing the header and text of a message.
224 
225 For example, the following request line will issue an output request
226 for the current message:
227 
228       apply "do ""copy &1 ===; eor &1 -dl"""
229 
230 Due to lack of appropriate mail system primitives, the apply request
231 can not be used to modify the actual message in the mailbox.
232 
233 
234 Elimination of the "-all" control argument:
235 Three new control arguments -- -include_deleted, -only_deleted, and
236 -only_non_deleted -- are added to all requests to replace the "-all"
237 control argument.
238 
239 The now obsolete "-all" control argument caused a request to operate on
240 deleted messages in addition to non-deleted messages.  However, the
241 choice of "-all" for this control argument caused considerable
242 confusion as it is too similar to the "all" message specifier which
243 selects all non-deleted messages in the mailbox.
244 
245 The "-all" control argument is now undocumented but will be retained
246 for one release to allow users to convert to the new control arguments.
247 
248 
249 List of control arguments replacing "-all":
250 -include_deleted, -idl
251    includes all messages in the mailbox whether or not they have been
252    deleted when processing any message_specifiers to determine which
253    messages to process.
254 -only_deleted, -odl
255    includes only those messages which have been deleted.  This is the
256    default for the retrieve request.
257 -only_non_deleted, -ondl
258    includes only those messages which have not been deleted.  This is
259    the default for all requests other than retrieve.
260 
261 
262 Extended message selection:
263 New control arguments are added to the list, print, print_header,
264 delete, and retrieve requests to allow selection of messages by date,
265 author, recipient, and/or subject.  A detailed description of these
266 control arguments can be obtained by issuing the following request
267 within the read_mail subsystem:
268       help selection_control_args.gi
269 
270 These selection facilities can be used with other requests by use of
271 the list active function.  For example, the request line
272 
273       log [list -before 10/1/81 -from Palter.Multics -subject /mail/]
274 
275 logs all messages sent by the user Palter.Multics before October 1981
276 whose subject contains the string "mail".
277 
278 
279 Improvements to the reply request:
280 Numerous enhancements have been made to the reply request:
281 
282 
283 Improved "Replying to" message:
284 The message printed by reply now lists as many of the recipients as
285 will fit on a single line rather than simply stating how many
286 recipients would receive the reply.
287 
288 For example:
289       Replying to Palter.Multics, Sibert.PDO, and 3 others.
290 
291 
292 Improved -include_original action:
293 The Date, From, and Subject fields of the original message are now
294 included in the reply along with the original text when the
295 "-include_original" control argument is used.
296 
297 
298 Improved interaction with send_mail:
299 The send_mail created to compose the reply message is created with the
300 same state of abbreviation processing and the same profile as the
301 read_mail invocation in which the reply request is given.  In addition,
302 if send_mail is exited without sending the reply, the reply request
303 will refuse to honor the "-delete" control argument.
304 
305 
306 New reply request control arguments:
307 The following control arguments are added to the reply request:
308 
309 -prompt STR
310    specifies the prompt to be used by the send_mail created to compose
311    the reply.
312 -no_prompt
313    specifies that the send_mail created to compose the reply will not
314    prompt for request lines if it enters the request loop.
315 
316 
317 -include_self, -is
318    allows a copy of the reply to be sent to the person composing the
319    reply if the request determines that such a copy should be sent from
320    use of the "-include_authors" or "-include_recipients" control
321    arguments.
322 -no_include_self, -nis
323    specifies that a copy of the reply only be sent to the person
324    composing the reply if explicitly requested by use of the "-to" or
325    "-cc" control arguments.  This is the default.  This default allows
326    the user to create a reply abbreviation which automatically logs the
327    reply without receiving an extra copy whenever "-include_recipients"
328    is specified.
329 
330 
331 Request line abbreviation processing:
332 The user can now request that abbreviations be expanded on read_mail
333 request lines.  Through the use of three new control arguments --
334 -abbrev (-ab), -no_abbrev (-nab), and -profile path -- the user can
335 specify whether abbreviation processing is enabled or disabled when
336 entering the subsystem and can also specify the profile to use to look
337 up abbreviation definitions.  If expansion is enabled and a profile is
338 not specified, the same profile used at Multics command level will be
339 used within read_mail.
340 
341 A new request, abbrev (ab), is also provided which allows the user to
342 enable or disable abbreviation processing and to change profiles once
343 within read_mail.
344 
345 
346 The use of separate profiles for subsystems and Multics command level
347 is encouraged to avoid problems where command level abbreviations
348 perform unexpectedly within a subsystem and vice-versa.
349 
350 For example, the user may define an "rdm" abbreviation to enter
351 read_mail with expansion enabled using the profile
352 "mail_system.profile" in the home directory as follows:
353 
354       .ab rdm do "read_mail -abbrev -profile [hd]>mail_system &rf1"
355 
356 
357 New standard requests:
358 The following new requests, supplied as part of the subsystem
359 utilities, are now available in read_mail:
360 
361 exec_com, ec
362    executes a segment containing read_mail requests.  The full
363    capabilities of the Multics exec_com processors (versions one and
364    two) are available.  The read_mail subsystem uses the suffix "rdmec"
365    for its exec_com segments to avoid confusion with exec_com's that
366    are intended for execution at Multics command level.  Additionally,
367    read_mail will search for the exec_com using the "mail_system"
368    search list.  The default content of this search list is:
369          -working_dir
370          >udd>[user project]>[user name]>[user name].mlsys
371 
372 
373 do
374 if
375 answer
376    are identical to the do, if, and answer commands available at
377    Multics command level except that they execute read_mail request
378    lines rather than Multics command lines.  These requests are
379    invaluable in the creation of abbreviations within read_mail.
380 
381 ready, rdy
382    prints a Multics ready message.
383 
384 ready_on, rdn
385 ready_off, rdf
386    control whether a ready message will be printed after the execution
387    of each request line.  By default, read_mail does not print ready
388    messages.
389 
390 
391 subsystem_name
392 subsystem_version
393    return the name and version of the current subsystem, respectively.
394    These requsts are invaluable in abbreviations which are shared by
395    multiple subsystem or which must know whether certain features of a
396    subsystem are present.  For example, a "quit" abbreviation may be
397    defined as follows which specifies "-force" only when in read_mail:
398          .ab quit do """quit"" [if [e equal [subsystem_name]
399                 read_mail] -then -force] &rf1"
400 
401 
402 Improved self-documentation facilities:
403 The "?" request now prints a multi-columnar list of the requests
404 available within read_mail.
405 
406 The list_requests (lr) request is added to read_mail to provide the
407 functionality of the old "?" request.  It produces a list of valid
408 requests with a brief summary of each request.  Additionally, the
409 list_requests request accepts request name topics and lists those
410 request which match those topics.  For example, the request line
411 
412       list_requests list
413 
414 will print the brief summary of the list, list_help, and list_requests
415 requests.
416 
417 
418 The help request is extended to accept most control arguments accepted
419 by the Multics help command.  In particular, the "-brief" control
420 argument can be used to produce a summary of any read_mail request
421 which includes the request's syntax line, arguments, and control
422 arguments.  In addition, the help request is changed to explain how to
423 obtain additional online information when it is invoked with no
424 arguments.
425 
426 
427 New request name abbreviations:
428 The following new abbreviations are now accepted for the listed
429 requests.  In addition, abbreviations available in prior releases
430 (shown in parentheses) are still accepted.
431 
432    first: f
433    last: l
434    current: c
435    forward (fwd): for
436    print (pr): p
437    delete (dl): d
438 
439 
440 New command line control arguments:
441 The following new control arguments are now recognized on the read_mail
442 command line:
443 
444 -count, -ct
445    prints the number of messages read from the mailbox before entering
446    the request loop.  (Default)
447 -no_count, -nct
448    does not print the message count.
449 -acknowledge, -ack
450    acknowledges messages which request acknowledgement.  (Default)
451 -no_acknowledge, -nack
452    does not acknowledge any message.
453 
454 
455 In addition, the following new reply request control argument are now
456 accepted on the read_mail command line to alter the default action of
457 the reply request:
458    -line_length N, -ll N
459    -indent N, -ind N
460    -include_self, -is
461    -no_include_self, -nis
462 
463 
464 Protection from accidental deletion of messages:
465 The user is now queried for permission to delete any message which
466 hasn't been listed, printed, saved, or written.  This change protects
467 the user from accidently deleting newly arrived messages without having
468 first examined them.  A new control argument (-force, -fc) is added to
469 the delete request to suppress this query.
470 
471 
472 Minimal video system support:
473 The print request now issues a "reset_more" control order after
474 printing each message.  This change allows users of the video system to
475 easily abort the printing of a single message when printing several
476 messages.
477 
478 
479 Improved acknowledgements:
480 The message sent when acknowledging a message now includes the subject
481 of the original message if present.