rjg@sialis.mn.org (Robert J. Granvin) (04/24/89)
>The brackets mean "what's inside here is a message, what's outside isn't." >They are a delimiter, not punctuation. So why not break the mold of what >us computer folks expect and still retain by punctuation by changing > [Deleting your entire mailbox.] >to > [ Deleting your entire mailbox. ] >A very small change, but suddenly the message looks like what the >developers intended -- a tiny box holding a grammaticly correct >phrase. It no longer looks like a double-punctuated phrase. Note >the double-space at front, single at back. Yet another reasonable option for a "compromise". But in any case, the whole thing has always been a matter of aesthetics. It's certainly nothing serious. The double space is an interesting "optical illusion". It may actually not be noticed unless it's pointed out. >Or you could even go whole hog, drop the brackets, and highlight >the phrase. The only potential drawback to highlighting at all is the wide variety of terminals and varying quality emulators out in the world. VT100's handle video attributes "correctly" while Wyse-50s and others, require a character space for the video attribute. Wyse-50s also have the annoying habit of highlighting the entire screen from the start of the video attribute and then reverses the remainder of the screen when it gets the normal video attribute. A very distracting and unpleasing "feature". And of course, there are always the poor emulators out there that just barf on video attribute codes, or display them incorrectly. Granted, those monsters shouldn't need to be worried about (After all, how can you be happy about a VT100 emulator that chokes on inverse video and/or underlining codes? :-) It's an easy thing to deal with as long as both worlds are kept in mind at the time (and preferrably tested). In any case, we're right back at aesthetics again. (Actually, it's a good sign (and a nice change of pace from the rememberable past :-) that the majority of the discussion seems to be about visual impact, aesthetics and items that are covered in included (though usually unread :-) documentation). -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg
jbayer@ispi.UUCP (Jonathan Bayer) (04/24/89)
In article <1397@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: >>The brackets mean "what's inside here is a message, what's outside isn't." >>They are a delimiter, not punctuation. So why not break the mold of what >>us computer folks expect and still retain by punctuation by changing >> [Deleting your entire mailbox.] >>to >> [ Deleting your entire mailbox. ] > >>A very small change, but suddenly the message looks like what the >>developers intended -- a tiny box holding a grammaticly correct >>phrase. It no longer looks like a double-punctuated phrase. Note >>the double-space at front, single at back. This is a short patch to modify the bracketed messages. It adds two spaces before the left bracket, and one space before the right bracket. This is an unofficial patch. I have forwarded a copy to Syd Weinstein. JB *** builtin.c- Thu Mar 30 10:35:11 1989 --- builtin.c Mon Apr 24 10:19:44 1989 *************** *** 280,286 **** headers[current-1]->to); sprintf(title1, "%s %d/%d ", ! headers[current-1]->status & DELETED ? "[deleted]" : headers[current-1]->status & FORM_LETTER ? "Form": "Message", current, message_count); t1_len = strlen(title1); --- 280,286 ---- headers[current-1]->to); sprintf(title1, "%s %d/%d ", ! headers[current-1]->status & DELETED ? "[ deleted ]" : headers[current-1]->status & FORM_LETTER ? "Form": "Message", current, message_count); t1_len = strlen(title1); *** leavembox.c- Thu Mar 30 11:10:43 1989 --- leavembox.c Mon Apr 24 10:17:13 1989 *************** *** 306,335 **** if (to_store > 0) { if (to_delete > 0) sprintf(buffer, ! "[Keeping %d message%s, storing %d, and deleting %d.]", to_keep, plural(to_keep), to_store, to_delete); else ! sprintf(buffer, "[Keeping %d message%s and storing %d.]", to_keep, plural(to_keep), to_store); } else { if (to_delete > 0) ! sprintf(buffer, "[Keeping %d message%s and deleting %d.]", to_keep, plural(to_keep), to_delete); else ! sprintf(buffer, "[Keeping %s.]", to_keep > 1 ? "all messages" : "message"); } } else if (to_store > 0) { if (to_delete > 0) ! sprintf(buffer, "[Storing %d message%s and deleting %d.]", to_store, plural(to_store), to_delete); else ! sprintf(buffer, "[Storing %s.]", to_store > 1? "all messages" : "message"); } else { if (to_delete > 0) ! sprintf(buffer, "[Deleting all messages.]"); else buffer[0] = '\0'; } --- 306,335 ---- if (to_store > 0) { if (to_delete > 0) sprintf(buffer, ! "[ Keeping %d message%s, storing %d, and deleting %d. ]", to_keep, plural(to_keep), to_store, to_delete); else ! sprintf(buffer, "[ Keeping %d message%s and storing %d. ]", to_keep, plural(to_keep), to_store); } else { if (to_delete > 0) ! sprintf(buffer, "[ Keeping %d message%s and deleting %d. ]", to_keep, plural(to_keep), to_delete); else ! sprintf(buffer, "[ Keeping %s. ]", to_keep > 1 ? "all messages" : "message"); } } else if (to_store > 0) { if (to_delete > 0) ! sprintf(buffer, "[ Storing %d message%s and deleting %d. ]", to_store, plural(to_store), to_delete); else ! sprintf(buffer, "[ Storing %s. ]", to_store > 1? "all messages" : "message"); } else { if (to_delete > 0) ! sprintf(buffer, "[ Deleting all messages. ]"); else buffer[0] = '\0'; } -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP