werner@aecom.yu.edu (Craig Werner) (01/05/90)
This started when I mentioned the simple fact given a text file
(say from a download) you can't display its contents at the level of the
Desktop.
You can't.
True, you can display it. And I do it all the time. It involves
a 7 step sequence using software I have readily available, and it is more
complex than Unix 'more' or even a PC's 'type.'
Over twenty people wrote mail, giving about 15 different ways to
do this, some of which were quite elegant. But that's not the point.
It's a simple task, and it should have a standard solution. I mean the
fact that fifteen people have found fifteen different ways to do
something does not reflect favorably on machine that prides itself on a
consistent user interface.
--
Craig Werner (future MD/PhD, 4.5 years down, 2.5 to go)
werner@aecom.YU.EDU -- Albert Einstein College of Medicine
(1935-14E Eastchester Rd., Bronx NY 10461, 212-931-2517)
"Someone write me a letter. I need to know that I'm still alive."hpoppe@bierstadt.ucar.edu (Herb Poppe) (01/05/90)
In article <2706@aecom.yu.edu> werner@aecom.yu.edu (Craig Werner) writes: > > This started when I mentioned the simple fact given a text file >(say from a download) you can't display its contents at the level of the >Desktop. > You can't. Speak for yourself. A feature of the Versaterm terminal emulation program allows one to set the creator string for the TEXT files it produces. All such files can then be displayed by simply double clicking on them from the desktop. Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
casseres@apple.com (David Casseres) (01/06/90)
In article <2706@aecom.yu.edu> werner@aecom.yu.edu (Craig Werner) writes: > This started when I mentioned the simple fact given a text file > (say from a download) you can't display its contents at the level of the > Desktop. > You can't. > True, you can display it. And I do it all the time. It involves > a 7 step sequence using software I have readily available, and it is more > complex than Unix 'more' or even a PC's 'type.' It is true that you can't display a TEXT file from the Desktop, using today's Finder. The Finder is just a program and could be replaced with a program that has its own facilities for displaying TEXT files, or knows that you want to use TeachText (or MPW, or whatever) for TEXT files. This is a limitation of the present Finder, not of the Mac itself or the system software. As for a 7-step sequence, I don't know why you have to do that many steps. Launching TeachText and using it to open the file is a lot fewer steps than that, and it is certainly not more complex than "more" or "type." David Casseres Exclaimer: Hey!
lsr@Apple.COM (Larry Rosenstein) (01/06/90)
In article <2706@aecom.yu.edu> werner@aecom.yu.edu (Craig Werner) writes: > This started when I mentioned the simple fact given a text file > (say from a download) you can't display its contents at the level of the > Desktop. > You can't. You certainly can. What's true is that on the Mac you have to run a separate program or DA to display a file, while on UNIX or MS-DOS you "only" have to type a command to the shell. I could come up with specific things that are easier to do on the Mac, and it would be equally meaningless. One doesn't base a whole user interface around specific actions like displaying a file. > fact that fifteen people have found fifteen different ways to do > something does not reflect favorably on machine that prides itself on a > consistent user interface. I think you misunderstand what a consistent user interface means. It doesn't mean that every user has to do things the same way. Such an interface would be disasterous, because people don't do things in same way. Consistency means that different interactions still share common principles, which a user can easily learn and apply to new situations. Even UNIX has its UI principles. (A command line consists of the name of a command and parameters. You can redirect I/O. You can look things up in the on-line manual.) The Mac UI principles talk about metaphors, direct manipulation, user control, etc. For most users, these principles are more helpful than the UNIX ones. That's not surprising because UNIX was designed for programmers, so its principles are ones that best suit programmers. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
hui@joplin.mpr.ca (Michael Hui) (01/06/90)
In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: > >Speak for yourself. > >A feature of the Versaterm terminal emulation program allows one to set >the creator string for the TEXT files it produces. All such files can >then be displayed by simply double clicking on them from the desktop. Really? What program's creator code should I insert? Wouldn't the program then assume the file is in its internal format and generate interesting results? Michael Hui 604-985-6506 604-985-4214 hui@joplin.mpr.ca
levin@bbn.com (Joel B Levin) (01/06/90)
In article <1998@eric.mpr.ca> hui@joplin.mpr.ca writes: |In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: |>A feature of the Versaterm terminal emulation program allows one to set |>the creator string for the TEXT files it produces. All such files can |>then be displayed by simply double clicking on them from the desktop. | |Really? What program's creator code should I insert? Wouldn't the |program then assume the file is in its internal format and generate |interesting results? No, because while the creator field says what application should run it, the *type* field remains TEXT, which tells the application what the format is. ALL w/p type applications (and several others) recognize type TEXT and know what to do with it. = Nets: levin@bbn.com | "There were sweetheart roses on Yancey Wilmerding's or {...}!bbn!levin | bureau that morning. Wide-eyed and distraught, she POTS: (617)873-3463 | stood with all her faculties rooted to the floor."
6600pete@hub.UUCP (01/06/90)
From article <1998@eric.mpr.ca>, by hui@joplin.mpr.ca (Michael Hui): > In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >>A feature of the Versaterm terminal emulation program allows one to set >>the creator string for the TEXT files it produces. All such files can >>then be displayed by simply double clicking on them from the desktop. > Really? What program's creator code should I insert? Wouldn't the > program then assume the file is in its internal format and generate > interesting results? All applications should be set up to default to TeachText's creator code. If they're not, blame the applications, not the Mac. No, an application won't assume that the file is in its own internal format, because there is also a file type, which in this case would be TEXT. ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (01/06/90)
In article <2706@aecom.yu.edu> werner@aecom.yu.edu (Craig Werner) writes: > This started when I mentioned the simple fact given a text file >(say from a download) you can't display its contents at the level of the >Desktop. You display a text file "at the level of the Desktop" (which presumably means "from the Finder") by double-clicking the file. This is a fairly simple procedure, certainly no more difficult than typing "type" and a filename. It is possible, if you try, to create a text file whose creator signature does not correspond to any application you have available. If you are in this situation, you can open the file by double-clicking on a text editor or word processor (they'll all open plain text files) of your choice, choosing the Open menu item, and picking your file. Not quite as easy, but not what I'd call difficult either. > Over twenty people wrote mail, giving about 15 different ways to >do this, some of which were quite elegant. But that's not the point. >It's a simple task True. > and it should have a standard solution. It does. >I mean the >fact that fifteen people have found fifteen different ways to do >something does not reflect favorably on machine that prides itself on a >consistent user interface. I think you are mistaking consistency for the idea that there should be only one way to do a task. A system can be designed to respond to the same actions in analogous ways, regardless of context; that's not the same as designing it so there's only one way to perform a task such as opening a file. -- ====== jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.UUCP | compilation copyright without my permission. ___________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. | AppleLink: SQA.TEST
hpoppe@bierstadt.ucar.edu (Herb Poppe) (01/06/90)
In article <1998@eric.mpr.ca> hui@joplin.mpr.ca writes: >In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >> >>Speak for yourself. >> >>A feature of the Versaterm terminal emulation program allows one to set >>the creator string for the TEXT files it produces. All such files can >>then be displayed by simply double clicking on them from the desktop. > >Really? What program's creator code should I insert? Wouldn't the >program then assume the file is in its internal format and generate >interesting results? > >Michael Hui 604-985-6506 604-985-4214 hui@joplin.mpr.ca A little background first: Every file has associated with it two four-character strings. One string is the CREATOR and the other is the TYPE. Unless you use programmer's tools like ResEdit or disk utilities like MacTools you never see these strings; the Finder doesn't show them to you. For an application, the type must be APPL (otherwise is isn't an application). The creator string for an application contains the applications "signature". The signature for Microsoft Word 3.x and 4.0 is MSWD. There may be zero or more (different) document types associated with an application. The creator string for each document type is the application signature. All MS Word 3.x and 4.0 documents have the creator string MSWD. (Word 3.x can also create Word 1.x word processing documents that have the creator string WORD as well as MacWrite documents that have the creator string MACA.) Each different document type has a different type string. Word 3.x has many different document types: a help file (WHLP), glossaries (GLOS), spelling dictionaries (DICT), hyphenation file (WPRD), as well as word processing files (WDBN) and a straight text files (TEXT). From the Finder, you can select one or more files and double-click on one of them. If they all have the same creator string, the Finder will launch the application (APPL) with that creator string and pass the application a list of the files with their corresponding type strings. It is up to the application to do "the right thing" with each file. When VersaTerm creates a text file, the file is given the type string TEXT. Selecting "Extras..." under the Settings menu presents a dialog box where you can select the creator string; indirectly by clicking on a radio button associated with a popular word processor or text editor (Word 3.0, QUED, MacWrite, etc.) or directly by entering the creator string in an edit-text box. So to answer the question: >Really? What program's creator code should I insert? The creator string of an application that you have that processes files of type TEXT. Obviously, you wouldn't put in the creator string for MacPaint, which doesn't process TEXT files. If you did, MacPaint would be launched, it ignores the file because it is not the right type (PNTG), and it opens a blank "untitled" window. The mileage may vary for other programs. >Wouldn't the >program then assume the file is in its internal format and generate >interesting results? Since an application might use many different file types, it can't assume what the type of any file is. It doesn't have to: it is given the file types by the Finder. That is not to say that someone couldn't write an application that only worked with one file type, assumed that all files were of that type, and ignored the Finder info. Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
mls@cbnewsm.ATT.COM (mike.siemon) (01/06/90)
The defensiveness of Mac fanatics about the oddities of the system is
obscuring the point. It is particularly obnoxious to be told that all
applications "should" create files with the signature of Teach Text,
given that essentially none of them do, and given that what I might
*want* to do with a randomly created file is *not* necessarily page
through it.
The example of reading an arbitrary file is just that, an example of a
much larger general problem. If I have a file I may want to use it in
a number of different ways, totally unconstrained by the file's origin
or by my intentions when I create the file.
On my Mac (of which I am quite fond, by the way) an application *either*
- creates files in a special form, saying "mine, mine;" [like an excited
and possessive Daffy Duck] "nobody else can use this!" -- unless they
build in an infinity of "conversion" routines or one has a program/DA
doing nothing but conversions
*or*
- creates files in a "generic" format like TEXT or MacPaint or suchlike;
and then *nobody* can use it, without going through some such nonsense
as locating an application, invoking it in some utterly useless state
closing *that* state and hunting through some menus to get back to the
file you started with and are interested in.
May I point out that 5 years after the introduction of the Mac, it's still
regarded as a neat new commercial utility, heavily advertised in the pages
of the Mac rags, to have something that can actually *open* any given file.
Sure there are lots of ways to do this, some quite old. What is bizarre
is the *need* for it.
You can specify an arbitrary file, and get the application (if any) it is
associated with. You can specify an arbitrary application and get any files
it (thinks it) is prepared to cope with. But you cannot specify an arbitary
file and an arbitrary application TOGETHER. A new application may know all
sorts of neat conversions to operate on earlier kinds of output; the older
applications are then practically guaranteed to be unable to cope with the
output of the new one.
The Mac is wonderful for all sorts of one-off, custom jury-rigged situations
and for a small set of highly stylized standard applications. What it is
*very* bad at is generalization and abstraction -- areas where one has to
step *outside* the details and deal with them "algebraically" (as in the
regular expression matching of filenames or of text in a file or of patterns
of output in the intermediate stages of a complex operation.) The Mac is
slick (and often fun) on the immediate details, but every detail has to be
dealt with one at a time.
--
Michael L. Siemon I say "You are gods, sons of the
cucard!dasys1!mls Most High, all of you; nevertheless
att!sfbat!mls you shall die like men, and fall
standard disclaimer like any prince." Psalm 82:6-7hui@joplin.mpr.ca (Michael Hui) (01/06/90)
In article <37640@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes: ^^^^^ ^^^^^ >You display a text file "at the level of the Desktop" (which presumably >means "from the Finder") by double-clicking the file. This is a fairly >simple procedure, certainly no more difficult than typing "type" and >a filename. What you suggested does not work. I just downloaded a small file using Red Ryder 9.4 using Kermit text mode. I double clicked on the file. Why don't you try this yourself and see what happens ? Michael Hui 604-985-6506 604-985-4214 hui@joplin.mpr.ca
roths@dg-rtp.dg.com (Robert Rothschild) (01/07/90)
In article <2706@aecom.yu.edu> werner@aecom.yu.edu (Craig Werner) writes: > > Over twenty people wrote mail, giving about 15 different ways to >do this, some of which were quite elegant. But that's not the point. >It's a simple task, and it should have a standard solution. I mean the >fact that fifteen people have found fifteen different ways to do >something does not reflect favorably on machine that prides itself on a >consistent user interface. Consistent interface design has nothing to do with the number of methods to complete a task. In this context, "consistent" means each user input will be met with a predictable system response. Bob Rothschild roths@dg-rtp.dg.com
lai@Apple.COM (Ed Lai) (01/07/90)
In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > >On my Mac (of which I am quite fond, by the way) an application *either* > > - creates files in a special form, saying "mine, mine;" [like an excited > and possessive Daffy Duck] "nobody else can use this!" -- unless they > build in an infinity of "conversion" routines or one has a program/DA > doing nothing but conversions > My original purpose of posting a reply is what I am going to say later. But when I read about this I must say that a program/DA that does nothing but conversions is a neat idea, and I have spent a lot of my own time working on that. >*or* > > - creates files in a "generic" format like TEXT or MacPaint or suchlike; > and then *nobody* can use it, without going through some such nonsense > as locating an application, invoking it in some utterly useless state > closing *that* state and hunting through some menus to get back to the > file you started with and are interested in. [lines deleted] >You can specify an arbitrary file, and get the application (if any) it is >associated with. You can specify an arbitrary application and get any files >it (thinks it) is prepared to cope with. But you cannot specify an arbitary >file and an arbitrary application TOGETHER. A new application may know all >sorts of neat conversions to operate on earlier kinds of output; the older >applications are then practically guaranteed to be unable to cope with the >output of the new one. > If you want to specify an arbitary file and an arbitrary application TOGETHER, first put them in the same folder in they are not already in the same folder, then select both, then launch. As an example, if you have a text file generated by MPW, and you want to view it from TeachText, just select both and launch. You will then be looking at the MPW text file from TeachText. I think if more people know about this. A lot of the discussion on Text file maddness would go away. Back to what I said earlier, I think an independent utility that handles data conversion is the correct way to go. How else can an old application understand a new type of data? Of course this does not mean that it cannot be made more transparent, so that on seeing a data it cannot understand, it would automatically try to invoke the utility to try to convert it to something it can understand. /* Disclaimer: All statments and opinions expressed are my own */ /* Edmund K. Lai */ /* Apple Computer, MS75-6J */ /* 20525 Mariani Ave, */ /* Cupertino, CA 95014 */ /* (408)974-6272 */ zW@h9cOi
hui@joplin.mpr.ca (Michael Hui) (01/07/90)
In article <2001@eric.mpr.ca> hui@joplin.mpr.ca writes: >In article <37640@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) >writes: ^^^^^ ^^^^^ >>You display a text file "at the level of the Desktop" (which presumably >>means "from the Finder") by double-clicking the file. This is a fairly >>simple procedure, certainly no more difficult than typing "type" and >>a filename. > >What you suggested does not work. I just downloaded a small file using >Red Ryder 9.4 using Kermit text mode. I double clicked on the file. >Why don't you try this yourself and see what happens ? All right. I see the idea now. Yes, very logical and obvious. BUT: to a first time Mac user, Jeanne's reply would have still been puzzling, since no where was it mentioned that the file creater string must be set up to something corresponding to a text editor. RR 9.4 comes up with the string default to MACA. I suppose that's not MS Word, since that is the only text editor application I usually have on line. I will refrain myself from commenting on this whole saga as being indicative of a good or poor GUI. Let's move on to more interesting stuff ...
rht@smsdpg.uu.net (Randy Thompson) (01/07/90)
From article <1998@eric.mpr.ca>, by hui@joplin.mpr.ca (Michael Hui): > In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >> >>Speak for yourself. >> >>A feature of the Versaterm terminal emulation program allows one to set >>the creator string for the TEXT files it produces. All such files can >>then be displayed by simply double clicking on them from the desktop. > > Really? What program's creator code should I insert? Wouldn't the > program then assume the file is in its internal format and generate > interesting results? No, most word processors have the ability to read and write ascii text files. If you insert a creator of MSWD (Microsoft Word) for example, it will see that the file is ascii since the type is still TEXT. You can also use "ttxt" if you want to use TeachText, SSIW for WordPerfect, etc.. _________________________________________________________________________ Randy Thompson | uunet!smsdpg!rht -- Office SMS Data Products Group, Inc. | uunet!smsdpg!tailchasr!rht -- Mac@home 703/648-9400 | _________________________________________________________________________ * Constructive criticism is always appreciated * Send Flames to: Trash%tailchasr@smsdpg.UUCP _________________________________________________________________________
jtn@zodiac.ADS.COM (John Nelson) (01/07/90)
In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > >The defensiveness of Mac fanatics about the oddities of the system is >obscuring the point. It is particularly obnoxious to be told that all >applications "should" create files with the signature of Teach Text, >given that essentially none of them do, and given that what I might >*want* to do with a randomly created file is *not* necessarily page >through it. > >The example of reading an arbitrary file is just that, an example of a >much larger general problem. If I have a file I may want to use it in >a number of different ways, totally unconstrained by the file's origin >or by my intentions when I create the file. > >On my Mac (of which I am quite fond, by the way) an application *either* > > - creates files in a special form, saying "mine, mine;" [like an excited > and possessive Daffy Duck] "nobody else can use this!" -- unless they > build in an infinity of "conversion" routines or one has a program/DA > doing nothing but conversions > >*or* > > - creates files in a "generic" format like TEXT or MacPaint or suchlike; > and then *nobody* can use it, without going through some such nonsense > as locating an application, invoking it in some utterly useless state > closing *that* state and hunting through some menus to get back to the > file you started with and are interested in. > >May I point out that 5 years after the introduction of the Mac, it's still >regarded as a neat new commercial utility, heavily advertised in the pages >of the Mac rags, to have something that can actually *open* any given file. >Sure there are lots of ways to do this, some quite old. What is bizarre >is the *need* for it. > >You can specify an arbitrary file, and get the application (if any) it is >associated with. You can specify an arbitrary application and get any files >it (thinks it) is prepared to cope with. But you cannot specify an arbitary >file and an arbitrary application TOGETHER. A new application may know all >sorts of neat conversions to operate on earlier kinds of output; the older >applications are then practically guaranteed to be unable to cope with the >output of the new one. > >The Mac is wonderful for all sorts of one-off, custom jury-rigged situations >and for a small set of highly stylized standard applications. What it is >*very* bad at is generalization and abstraction -- areas where one has to >step *outside* the details and deal with them "algebraically" (as in the >regular expression matching of filenames or of text in a file or of patterns >of output in the intermediate stages of a complex operation.) The Mac is >slick (and often fun) on the immediate details, but every detail has to be >dealt with one at a time. >-- >Michael L. Siemon I say "You are gods, sons of the >cucard!dasys1!mls Most High, all of you; nevertheless >att!sfbat!mls you shall die like men, and fall >standard disclaimer like any prince." Psalm 82:6-7 -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
mgodwin@rpp386.cactus.org (Mike Godwin) (01/07/90)
In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > >The example of reading an arbitrary file is just that, an example of a >much larger general problem. If I have a file I may want to use it in >a number of different ways, totally unconstrained by the file's origin >or by my intentions when I create the file. > >[Some text deleted] >May I point out that 5 years after the introduction of the Mac, it's still >regarded as a neat new commercial utility, heavily advertised in the pages >of the Mac rags, to have something that can actually *open* any given file. >Sure there are lots of ways to do this, some quite old. What is bizarre >is the *need* for it. > >[More text deleted] >The Mac is wonderful for all sorts of one-off, custom jury-rigged situations >and for a small set of highly stylized standard applications. What it is >*very* bad at is generalization and abstraction -- areas where one has to >step *outside* the details and deal with them "algebraically" (as in the >regular expression matching of filenames or of text in a file or of patterns >of output in the intermediate stages of a complex operation.) Maybe I'm not understanding your argument, but it seems to me that the specific complaints about Mac text handling that you detail here are equally problems in the DOS world. Moving among word-processing file formats under MS-DOS is equally non-trivial. If you're simply comparing Macs to UNIX systems, I'd have to agree with you in general. But it's worth noting that much of the inter-application file compatibility in the world of UNIX text and word processing is based on the fact that (as far as my limited knowledge goes), there are relatively few proprietary file formats in the UNIX world. (I suppose that may change as the number of desktop UNIX installations increases.) Your mention of regular-expression matching of filenames reminds me of an issue someone else raised in the course of these threads: the organization of files by filename extensions. These can be easily done on the Mac, for those who genuinely have a need to do it--just put the extension at the *beginning* of the filename. Then view the disk or directory contents by name--they'll be grouped by (prefix) extension and alpha ordered within the group. The files within a group can then be moved, deleted, opened, or whatever with standard mouse movements or their keyboard equivalents. --Mike -- Mike Godwin UT Law School | "... and first I put my arms around him yes mgodwin@rpp386.cactus.org | and drew him down to me so he could feel my (512) 346-4190 | breasts all perfume yes and his heart was cs.utexas.edu!rpp386!mgodwin | going like mad and yes I said yes I will Yes."
lad@lad.scs.com (Lawrence A. Deleski) (01/08/90)
From article <2706@aecom.yu.edu>, by werner@aecom.yu.edu (Craig Werner): > You can't. Yes you can. > True, you can display it. And I do it all the time. It involves > a 7 step sequence using software I have readily available, and it is more > complex than Unix 'more' or even a PC's 'type.' > Over twenty people wrote mail, giving about 15 different ways to > do this, some of which were quite elegant. But that's not the point. And it looks as if you didn't read one of twenty replies. If you're so bent on using your 'seven step process', then fine. But all you need to do is follow everyone's advice. Reading ANY text file on a Mac is a ONE step process; open the document. It can't GET any simpler. Jeez. > It's a simple task, and it should have a standard solution. I mean the > fact that fifteen people have found fifteen different ways to do > something does not reflect favorably on machine that prides itself on a > consistent user interface. Arrrgggghhhhh! Fifteen different people gave you exactly the same solution. Oh forget it. Remind me to never visit your practice. If you read med journals like you read your news, your patients are in BIG trouble. > Craig Werner (future MD/PhD, 4.5 years down, 2.5 to go) God help us. -- Lawrence A. Deleski | Silicon Compiler Systems lad@sdl.scs.com | 15 Independence Blvd. uunet!sdl!lad | Warren, NJ 07060 MABELL: (201) 580-0102 | Ext. 216
lad@lad.scs.com (Lawrence A. Deleski) (01/08/90)
From article <1998@eric.mpr.ca>, by hui@joplin.mpr.ca (Michael Hui): > In article <5900@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >>A feature of the Versaterm terminal emulation program allows one to set >>the creator string for the TEXT files it produces. All such files can >>then be displayed by simply double clicking on them from the desktop. > Really? What program's creator code should I insert? The creator of your favorite WP program, or simply TEXT, the default. At least 10 different WP/text editing programs can open it without a problem. > program then assume the file is in its internal format and generate > interesting results? Nope, just generates text. Pretty simple. Unless, of course, you find text 'interesting'. I'm at a loss to explain why so many die-hard IBM'ers can't fathom opening a simple text document. Craig uses his patened 'seven step process'. Oh Jeez-sus..... -- Lawrence A. Deleski | Silicon Compiler Systems lad@sdl.scs.com | 15 Independence Blvd. uunet!sdl!lad | Warren, NJ 07060 MABELL: (201) 580-0102 | Ext. 216
minow@mountn.dec.com (Martin Minow) (01/10/90)
Many comments on Craig Werner's complaint about the way the Mac handles text seem to suggest that Craig is in some ways "at fault" -- for not understanding "The Macintosh Way" of doing things if for no other reason. May I suggest, on the other hand, that if you look at the Mac philosophy, Craig is completely correct: he has a problem, and the Mac doesn't offer him a solution that works THE WAY HE EXPECTS IT TO. Seen in this light, there is a application missing from the Mac: a text file display utility such as a Mac-specific implementation of, say, Unix more. It *might* be possible to work around the problem by using ResEdit to determine the Creator of the text files Craig's terminal emulator creates. Then, one could duplicate one's "favorite editor" and use ResEdit to set that editor's creator to the appropriate value. (There are Mac implementions of both MicroEmacs and Jove that might be suitable.) I haven't tried this, but it's hackish enough to work. (Background: all Mac files have a "creator" and "file type" -- double-clicking on a document starts the creator application, and an application typically tells the operating system which file types it accepts.) The real question remains: why hasn't anyone written a "Pager" utility? (display text in 9pt monoco, scroll, let the mouse copy selections to the clipboard, possibly write text in MacWrite format or print it out.) Martin Minow minow@thundr.enet.dec.com
davidl@leonardo.intel.com (David D. Levine) (01/11/90)
> The real question remains: why hasn't anyone written a "Pager" utility? > (display text in 9pt monoco, scroll, let the mouse copy selections to the > clipboard, possibly write text in MacWrite format or print it out.) Surprisingly enough, I use the ancient DA "Grep-WC" for this purpose. This is a DA that does limited regular expression search (Grep) and word counts (WC). It can read both TEXT and MacWrite files; it can put its output to the screen or to the screen and a TEXT file. It has a "Pause" button so you can pause and resume scrolling. It's free. The trick is that the default pattern matches all lines, so if you start it up and "search" a file, it just displays the file. This can also be used to translate MacWrite files to TEXT. It's one of my favorite DAs of all time! - David D. Levine, Intel IMSO Tech Pubs davidl@leonardo.intel.com "We control the horizontal; we control the vertical."
lai@Apple.COM (Ed Lai) (01/11/90)
In article <781@gandalf.littlei.UUCP> davidl@leonardo.intel.com (David D. Levine) writes: >> The real question remains: why hasn't anyone written a "Pager" utility? >> (display text in 9pt monoco, scroll, let the mouse copy selections to the >> clipboard, possibly write text in MacWrite format or print it out.) > >Surprisingly enough, I use the ancient DA "Grep-WC" for this purpose. This >is a DA that does limited regular expression search (Grep) and word counts >(WC). It can read both TEXT and MacWrite files; it can put its output to >the screen or to the screen and a TEXT file. It has a "Pause" button so you >can pause and resume scrolling. It's free. > If someone is looking for a free "Pager", he may consider the clipboard magician DA available SUMEX. The DA contains two text editors. If you really want a text editor DA then it is not good enough. But if you want something that is free and can display text, it should be good enough. The first editor is based on TextEdit, really basic but probably no worse than TeachText and it also allows different font and different point size. The second editor is based on PEEdit from Capps Editor toolkit, which means that there is no 32K limit (still limit by RAM size) but lines cannot be too long so it is good for program listing. It can read from Text file or Text resource. To read from WORD file, what I do is use the command that just reads the data fork and then declare the data to be TEXT, usually the content is quite readable. And since almost everything is done by code resource, it should not be difficult to add extension to read MacWrite files etc. There is also a Grep command, but it is only used to replace text. Data can be saved another file (or append to another file). It is free and it can also do a lot of other things that has nothing to do with TEXT. /* Disclaimer: All statments and opinions expressed are my own */ /* Edmund K. Lai */ /* Apple Computer, MS75-6J */ /* 20525 Mariani Ave, */ /* Cupertino, CA 95014 */ /* (408)974-6272 */ zW@h9cOi