rcb@rti.UUCP (Randy Buckland) (09/28/88)
I am writing a program that is going to contain an intregrated text editor
and have a problem. I have the text editor part running, but can't find
a way to handle tab characters properly. It appears that TextEdit does
not understand tabs. Can something be rigged.
--
Randy Buckland (919)-541-7103
Research Triangle Institute
rcb@rti.rti.org [128.109.139.2]
{decvax,ihnp4}!mcnc!rti!rcboster@dewey.soe.berkeley.edu (David Phillip Oster) (09/29/88)
The last batch of tech notes included one with a name like "Don't abuse the Managers" that said that you shouldn't extend text edit to handle tabs. It also included documententation on new calls and hooks added to Text Edit in System 6.0, that in particular let you intercept text edit's measuring of text and drawing of text, to make it easy to implement tabs. You should read both.
tim@hoptoad.uucp (Tim Maroney) (09/29/88)
Nope, TextEdit doesn't handle tabs. I have no idea why they would add font
and style changes in the new version and still not handle tabs. For an ugly
workaround, you can tabify and detabify when inserting and extracting text,
which is a humongous pain in the sacral region and does not do what the user
would like, which is seeing tabs as single characters, and preserving tabs
when leading text changes. Think about managing end of line comments in a
C or Pascal program in a tabify/detabify editor -- every time the active part
of the line changed length, you would lose end of line comments' alignment.
There MAY be another hack you could use, but I haven't gotten the nerve to
try it yet. Use the QuickDraw text bottlenecks to special case tabs and fill
in the appropriate width for the current insertion point. This sounds like
a nightmare, but if it worked it would give you what you want. (Or me what I
want, anyway.)
Everyone agrees that TextEdit should handle tabs, except Apple. Unfortunately,
theirs is the only opinion that counts.
--
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Do what you wanna, do what you will;
Just don't mess up your neighbor's thrill.
And when you pay the bill, kindly leave a little tip
To help the next poor sucker on his one-way trip."
- Frank Zappa, "You Are What You Is"jcl@hpausla.HP.COM (Jeff Laing) (10/03/88)
>Everyone agrees that TextEdit should handle tabs, except Apple. Unfortunately, >theirs is the only opinion that counts. Hmmm. Now thats an interesting issue, isnt it? Just exactly what would happen if the MacProgrammer community started acting like the unix equivalents? What would happen if, instead of creating neat little hacks like QuickFolder, someone actually sat down and wrote a P.D (or shareware or whatever) version of PACK-3 that had the new functionallity in it? Can it be that hard? I know several people who have replaced CDEF-1 with the neato double-ended scroll bar version and are completely happy with it... could this work with other stuff? Yeh, it means your code might become System specific; isn't it heading that way already? I have just sent off for a copy of Capps' for LSC because I needed the facility of text editing in my program; what I would have liked instead is to have had SigmaEdit (the best of the D/A editors I've seen so far) respond to Control messages that instructed it to 'open specified file, scroll to specified line' from any application. That way I only have the one copy of the edit routines even if I develop multiple programs. What would have been best of all would be a TextEdit that automatically stuck scroll bars in the rectangle for me and handled all that stuff inside TEClick!!! Oops, starting to wander. Anyway, my point. Could some enterprising person out there have written the tab handling TextEdit and installed it over the old one? (I accept that they are going to trail behind on things like style, fonts, etc but thats another issue) I don't mind having to install it in my system The same argument could be applied to things like MDEF-0 (tearoff windows tend to require changes to the MDEF to allow the draggable image). MacTutor has published source which shows how .. why not make it a standard NOW??? Jeff Laing <jcl@hpausla> Hewlett Packard Australian Software Operation "Opinions? Me? I own a Macintosh! I got religion, not opinion "
usenet@cps3xx.UUCP (Usenet file owner) (10/05/88)
In article <2580001@hpausla.HP.COM>, Jeff Laing (jcl@hpausla.hp.com) writes: >>Everyone agrees that TextEdit should handle tabs, except Apple. >>Unfortunately, theirs is the only opinion that counts. > >Hmmm. Now thats an interesting issue, isnt it? Just exactly what would happen >if the MacProgrammer community started acting like the unix equivalents? > >What would happen if, instead of creating neat little hacks like QuickFolder, >someone actually sat down and wrote a P.D (or shareware or whatever) version >of PACK-3 that had the new functionallity in it? Can it be that hard? No, it probably wouldn't be that hard, if you looked at the code for the current one. But what would happen is simple: the Mac OS would be all screwed up and fragment into as many versions as UNIX. Are programs under UNIX portable? No way! There's System V, System III, BSD 4.2, BSD 4.3, Ultrix 1.x, Ultrix 2.x, SunOS 3.x, SunOS 4.x, .... Nobody would ever be able to write an application and guarantee it would work under someone else's system file. Remember, the system file is shared between ALL applications. What if you have a nifty package 3 which does QuickFolder things, and one which does SFVol things? How to combine them? There's a good reason why Apple forbids distribution of modified system files with applications: it means they don't have to look for bugs which aren't theirs. Let's keep it that way. +----------------------------------+------------------------+ | Anton Rang (grad student) | "VMS forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +----------------------------------+------------------------+
duggie@Jessica.stanford.edu (Doug Felt) (10/05/88)
For exercise I have been writing a replacement for textedit which supports tabs. I haven't looked at capps' prime, and don't have any means of editing files that are not all in memory. I'm planning to remove the 32K limit, support the script manager, and not crash when I run out of memory. I haven't tackled multiple styles/fonts/sizes etc. It a substantial job but not that big. I've been at it about a month, and am about 90% complete except for debugging (you may snicker quietly). Tabs are tricky. Who knows what tabs mean when you mix left-to-right and right-to-left text (arabic)? What standards are there for tabs that are not identically spaced? Inquiring minds want to know. Anyway, one suspects Apple will come out with something to support multiple scripts, if they are serious about the script manager. Whether they support tabs, columns, superscript, etc, however, is another question. I guess they have to leave something for people to make money at... Doug Felt Courseware Authoring Tools Project Sweet Hall 3rd Floor Stanford University Stanford, CA 94305 duggie@jessica.stanford.edu
kw1r+@andrew.cmu.edu (Kevin Whitley) (10/05/88)
Doug Felt said:
>Tabs are tricky.
I agree! (Said painfully, with battlescars to show.)
I'd like to know what the consensus is, if there is a consensus, about just
what a simple tab should mean when buried in the middle of non-left justified
text. What does a tab mean in centered text?
The solution I came up with for the editor in the cT programming environment
(which just got a nice mention in the microBytes section of Byte) was to left
justify everything before the last tab in the line and then put the
justification (centered, right, full) on the remainder of the line. Needless
to say this has some unwanted effects when lines with tabs wrap. But I was
driven by the syntax of the language my editor was for (which is command tab
arguments... making it very desirable to put the command, which is before the
tabs, all the way over to the left).
I am also curious about machine-independent file formats which save style
information. Our programming environment supports styled text over various
systems so we are forced to use some lowest common denominator (for instance,
everything must be 7-bit ascii and in the data fork). Anybody have any
experience on this?
Kevin Whitley
cT development
kw1r@andrew.cmu.edudenn@violet.berkeley.edu (Leonard Rosenthol) (10/06/88)
In article <3845@Portia.Stanford.EDU> duggie@Jessica.stanford.edu (Doug Felt) writes: >For exercise I have been writing a replacement for textedit which >supports tabs. I haven't looked at capps' prime, and don't have any >means of editing files that are not all in memory. I'm planning to >remove the 32K limit, support the script manager, and not crash when I >run out of memory. I haven't tackled multiple styles/fonts/sizes etc. >It a substantial job but not that big. I've been at it about a month, >and am about 90% complete except for debugging (you may snicker quietly). > I, for one, would very much like to see this when you feel it is stable enough to let out the door! >Tabs are tricky. Who knows what tabs mean when you mix left-to-right >and right-to-left text (arabic)? What standards are there for tabs >that are not identically spaced? Inquiring minds want to know. > I'm not sure if there are 'standards' for this type of activity, but there are applications out there (not in the states though) that support TABS and the Script Manager (ie. Script Manager compat word processors!), so they must have some way of doing it! >Anyway, one suspects Apple will come out with something to support multiple >scripts, if they are serious about the script manager. Whether they support >tabs, columns, superscript, etc, however, is another question. I guess >they have to leave something for people to make money at... > Well, I doubt that Apple will be coming out with a word processor of its own (or even improving TextEdit much) but TextEdit as it stands now is 'sort-of' script manager compatable. The old TextEdit (one font, etc.) is SM Compat and works just fine - true you only get one script - but... HOWEVER the new Styled TE is NOT fully SM compat (but they are working on it :-) /* ============================================================ */ /* Leonard Rosenthol | GEnie: MACgician */ /* President, Lazerware inc. | Delphi: MACgician */ /* | MacNet: MACgician */ /* denn@violet.berkeley.edu | AppleLink: D0025 */ /* ============================================================ */ /* Anything I say may be taken as truth, but you never know */ /* ------------------------------------------------------------ */
casseres@Apple.COM (David Casseres) (10/06/88)
In article <3845@Portia.Stanford.EDU> duggie@Jessica.stanford.edu (Doug Felt) writes: >Tabs are tricky. Who knows what tabs mean when you mix left-to-right >and right-to-left text (arabic)? What standards are there for tabs >that are not identically spaced? Inquiring minds want to know. There are no standards (though someone may have something they THINK should be a standard). Tabs just mean too many things in different applications. I believe if Apple or anyone else put some kind of tab support into a TextEdit, most developers would find that it didn't work the way they wanted, and they wouldn't use it, and it would just be a big waste. Nobody knows how text formatting (tabs are just one prong on the iceberg) should really be done. That's why there are so many word processors, all of them terrible in my humble opinion. That's why there's such a great opportunity for someone to forget all the existing ones, make a break- through, do it right, be a big hero, and become incredibly wealthy. That's why I hope Apple doesn't try to build a high-end text formatter into the system, unless of course someone at Apple happens to make that breakthrough! >Anyway, one suspects Apple will come out with something to support multiple >scripts, if they are serious about the script manager. Whether they support >tabs, columns, superscript, etc, however, is another question. I guess >they have to leave something for people to make money at... That last sentence says a lot. David Casseres and in case anyone wonders, Apple has shown little interest in my opinions.
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/06/88)
In article <18288@apple.Apple.COM> casseres@Apple.COM (David Casseres) writes: >In article <3845@Portia.Stanford.EDU> duggie@Jessica.stanford.edu (Doug Felt) writes: > >>Tabs are tricky. Who knows what tabs mean when you mix left-to-right >>and right-to-left text (arabic)? What standards are there for tabs >>that are not identically spaced? Inquiring minds want to know. The best implementation of tabs that I have seen [note: *opinion*] is in MicroSoft Word. Ignoring the merits of the word processor otherwise, MicroSoft has introduced a notion of a "typed" tabstop. Tabstop are exactly one of: left justifying (the usual kind) right justifying decimal aligning (right just. if no period is in it) centering These take priority over the paragraph formatting (centered, l/r/both justfied). In a situation with multiple tabstops, the tabulation binds (in English text) to the next tabstop to the right. Now for word processing in general, this is fine. For Outlines and programs, this is not so great. Tabs (at least in the ways that I use them) have two meanings: incremental indentation (e.g. C indentation style, outlines) positional fixation (e.g. MS Word tabs) The problem here is that one desparately wants *both* (e.g. emacs-style C comments in C-indented code). Note that these two kinds of tabs are *distinct*, and probably should be bound to different keys. The binding of tabs in mixed left to right (LR) and right-to-left (RL) languages is a difficult problem. I propose the following conventions for RL tabs: When the current language is right-to-left, <tab> should tabulate to the next tab stop to the *left*. MS-word style tabs should continue to be justify as they dofor LR languages. The problem for mixed text isn't particularly solvable in general - tabs are not *user-visibly* directional. By applying the above rules and having a way to specify the directionality of the tabs, one could solve most problems as efectively as one does in strictly LR text. The only other real alternative I can see is adding an attribute to each tabstop indicating whether it applies to LR/RL/both text. That would seem to me (without having tried it) to be counterintuitive in the common cases. Jon
jcl@hpausla.HP.COM (Jeff Laing) (10/07/88)
>>What would happen if, instead of creating neat little hacks like QuickFolder, >>someone actually sat down and wrote a P.D (or shareware or whatever) version >>of PACK-3 that had the new functionallity in it? Can it be that hard? > Nobody would ever be able to write an application and guarantee it > would work under someone else's system file. Remember, the system > file is shared between ALL applications. What if you have a nifty > package 3 which does QuickFolder things, and one which does SFVol > things? How to combine them? I agree. However, I dont see a lot of difference IN THIS PARTICULAR instance between an application not working with a PACK-3 which implements QuickFolder and FindFile features internally and the same application which doesnt work because QuickFolder and FindFile are installed. Besides, who would write an application which relied on having QuickFolder installed? I don't want to force it on the world; I would like the option for myself.