bskendig@phoenix.Princeton.EDU (Brian Kendig) (09/14/89)
How do I get more than 32k into a TextEdit window? If I can't squeeze it all into my TextEdit record, how can I simulate having it all there - especially with the scroll bars? Sample code would be greatly appreciated. -- | Brian S. Kendig | I feel more like I | bskendig | | Computer Engineering | did when I got here | @phoenix.Princeton.EDU | | Princeton University | than I do now. | @PUCC.BITNET | | Systems Engineering, NASA Space Station Freedom / General Electric WP3 |
earleh@eleazar.dartmouth.edu (Earle R. Horton) (09/15/89)
In article <10417@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >How do I get more than 32k into a TextEdit window? If I can't squeeze it >all into my TextEdit record, how can I simulate having it all there - >especially with the scroll bars? Sample code would be greatly appreciated. The following is quoted from Technical Note #203 "Don't Abuse the Managers." The words "text editor" may be substituted for "word processor" everywhere. In order to perform the operations required of a word processor it is necessary to use QuickDraw extensively. The expected Macintosh selection approach with autoscrolling, typing over selected text, cut/copy/paste, and so on are best implemented using QuickDraw directly. How the text is stored internally is the primary determining factor on how the word processor will perform. Don't be fooled by how easy it is to implement simple editing in an application. TextEdit is not a word processor. This is a pretty heavy-duty chunk of sample code you want here, to be sure. It has been done, but most of the good implementations I have seen are in products for which one cannot acquire the source code. I suggest you start off from scratch here, with a linked list of Handles to store lines or paragraphs of text. Gradually work your way up to a sophisticated memory management scheme so that the text is readily accessible to the display routines in your program. Finally, write a text display module which implements the full Macintosh interface for text. In order to avoid annoying limits, give your program the ability to swap unseen portions of documents to disk when memory gets tight. (This is optional, but it greatly increases the capabilities of any text editor.) Earle R. Horton
d88-jwa@nada.kth.se (Jon W{tte) (09/15/89)
In article <10417@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >How do I get more than 32k into a TextEdit window? If I can't squeeze it >all into my TextEdit record, how can I simulate having it all there - >especially with the scroll bars? Sample code would be greatly appreciated. The solution is simple yet astonishing; you don't. TextEdit can't handle as much as 8k efficiently (it's so SLOOOOOW !!!), and it's really just a support layer for the dialog manager. Inside Macintosh is quite right when it says that "TextEdit is NOT a word processor"... In fact, almost everything in the mac (including the disk cache !) is sequential lists. EVERYTHING in the toolbox bogs down if you use it too extensively, but the special case TextEdit is close to unusable. You're on your own. Don't forget to put in the Script Manager and support for more-than-one-byte characters in you own code :-) h+@nada.kth.se -- Old MacDonald had an agricultural real estate tax abatement.
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (09/15/89)
In article <15574@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >In article <10417@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU > (Brian Kendig) writes: >>How do I get more than 32k into a TextEdit window? If I can't squeeze it >>all into my TextEdit record, how can I simulate having it all there - >>especially with the scroll bars? Sample code would be greatly appreciated. > >This is a pretty heavy-duty chunk of sample code you want here, to be >sure. It has been done, but most of the good implementations I have >seen are in products for which one cannot acquire the source code. > ERH suggests using a linked list of handles for line-oriented text records. This is the easier approach if what you want is a WYSIWYG editor with fancy formatting capabilities, but on the other hand if you want just a text editor, the "big blob" of text approach is somewhat easier to implement. If I'm not mistaken, source code to two of these editors, MacJove and MicroEmacs (both of which are sort of emacs clones), is available. I don't remember from where, exactly. The display, editing, scrolling, etc., code from one of these may prove edifying. The other possibility is PEdit. Symantec has discontinued Capps', but they may have copies left in stock, which they will gladly sell you. I have nearly finished a PE-based text editing class which has some pretty nice features, but I'm not sure how or if I will be able to distribute it. If only they would "un-discontinue" Capps' ... alas! I will certainly distribute the source to my PE class if anyone wants it (don't expect it for a few weeks; I want to bash on it), and it will be PD. I doubt I'll be able to distribute it with the PE library in any form, though, so it won't be of much use to those of you who don't have Capps'. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (09/15/89)
In article <3956@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >In article <15574@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu > (Earle R. Horton) writes: >>In article <10417@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU >> (Brian Kendig) writes: >>>How do I get more than 32k into a TextEdit window? ... >ERH suggests using a linked list of handles for line-oriented text records. >This is the easier approach if what you want is a WYSIWYG editor with fancy >formatting capabilities, but on the other hand if you want just a text >editor, the "big blob" of text approach is somewhat easier to implement. The "big blob" approach will break down performance-wise once your text exceeds a few tens of kilobytes in size, maybe less. Since the point is to get more than 32k, this seems like a bad choice to me. Another approach is the "sectioned blob," a block of text with a hole or two in the middle. This should be only somewhat more difficult than the "big blob," but should afford acceptable performance if done right. The whole point of the Technote I quoted is that you will not get good performance with large text documents if you use TextEdit or anything like it. >If I'm not mistaken, source code to two of these editors, MacJove and >MicroEmacs (both of which are sort of emacs clones), is available. I don't >remember from where, exactly. The display, editing, scrolling, etc., code >from one of these may prove edifying. I mailed the MicroEmacs source code to sumex a few days ago. It has most of the stuff you will need except for multiple window support and hilighted selected ranges. It's not reentrant, either. With some heavy massaging, and a couple thousand more lines of C code, it might do what you want. My own feeling on this matter is that it would not be conceptually difficult to implement a general high-performance text handling package for the Macintosh. It would, however, take some time to produce anything that is as easy to use as TextEdit and robust enough to handle large blocks of text. Sadly, the amount of time involved significantly reduces the possibility that anyone is going to give something like this away. Earle R. Horton
gilbertd@silver.bacs.indiana.edu (Don Gilbert) (09/15/89)
In article <3956@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: .. >The other possibility is PEdit. Symantec has discontinued Capps', but they >may have copies left in stock, which they will gladly sell you. I have > ... so it won't be of much use to those of you who don't have Capps'. Symatec recently quoted me the price of $5,000 for Capps', at which price they will GLADLY sell to us... -- Don gilbertd at silver.bacs.indiana.edu
amanda@intercon.com (Amanda Walker) (09/15/89)
In article <15584@dartvax.Dartmouth.EDU>, earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Another > approach is the "sectioned blob," a block of text with a hole or two in > the middle. This should be only somewhat more difficult than the "big > blob," but should afford acceptable performance if done right. This is in fact the method that Capps' uses, as well as things like GNU Emacs. It works pretty well, and gives you most of the benefits of having your text in a (more or less) continuous stream, such as ease of searching and so on. Tastes great, less filling :-). -- Amanda Walker amanda@intercon.com
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (09/15/89)
In article <1451@intercon.com> amanda@intercon.com (Amanda Walker) writes: In article <15584@dartvax.Dartmouth.EDU>, earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Another > approach is the "sectioned blob," a block of text with a hole or two in > the middle. This should be only somewhat more difficult than the "big > blob," but should afford acceptable performance if done right. This is in fact the method that Capps' uses, as well as things like GNU Emacs. This is what I was referring to when I said "big blob of text." I just assumed, I guess, that everyone would mentally translate "big blob" to "big blob with required hole(s) in it." Oh, well. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.