"Vladimir G. Ivanovic" <vladimir(a)acm.org&gt; writes: No, I like it the way it is. Sometimes you want to have one long line even if wordwrap is on (e.g. posting Sourcecode in an E-Mail). Therefor I really wouldn't like it if XEmacs did play on inserted linebreaks and it shouldn't refill when inserting a line in the middle of an other. Keep it exactly as it is. M-q isn't much work but fiddling around to get the original layout after a refill is. -- One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.

Vladimir> Sounds like this is where a user option is needed. BTW, Er, you have it. Open up the Tools -> Packages -> Install menu, install VM, use it. Most of the time, this kind of option does not belong in Emacs proper, but in the application program. If you want Emacs to act like Memopad, write a (minor) mode to emulate Memopad. Or maybe it's already been done. Look into "hard" newlines. This is a device where newlines are marked according to whether they were entered by the user (with the Return or Enter keys)---hard, or by the software in word wrap mode---soft. I have no idea whether it actually works as you want or not but the feature is there. Vladimir> I don't think the solution is for XEmacs to _add_ Vladimir> linebreaks, but for the display code to be smart enough Vladimir> to wrap. No chance. This is not something that should be done by the redisplay code. It's just not possible to get it right without both understanding the semantics of the buffer content and reading the user's mind about preferences. Not to mention that in the example you gave, you were looking at something that doesn't conform to the recommended format for its application (ie, < 78 character lines) and could easily be illegal if it got another couple hundred characters longer. Having display cover that up would almost certainly result in XEmacs generating similarly broken mail, which is not to be tolerated. If you want the display to be different from what's in the file, use either an indirect buffer or a separate presentation buffer as VM does, or a more complex hack like the one used by preview-latex. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Neato. Seems to work. Thanks. --- Vladimir ------------------------------------------------------------------------ Vladimir G. Ivanovic http://leonora.org/~vladimir 2770 Cowper St. vladimir(a)acm.org Palo Alto, CA 94306-2447 +1 650 678 8014 The lyfe so short, the craft so long to learne. -- Chaucer

Stephen J. Turnbull writes: In this case I am glad to say you are wrong ;-) `vm-fill-paragraphs-containing-long-lines' is a variable declared in Lisp. -- loaded from "vm-misc" Value: nil Documentation: *Non-nil numeric value N causes VM to fill paragraphs that contain lines spanning N columns or more. Only plain text messages and text/plain MIME parts will be filled. The message itself is not modified; its text is copied into a presentation buffer before the filling is done. Best Regards, Marcus

Vladimir> The other is not being able to handle multiple, Vladimir> proportionally spaced fonts on a single line along with Vladimir> different styles (bold, italic, etc.) Vladimir> How do I create and display text that has "Times Roman" Vladimir> in Times Roman and "Helvetica" in Helvetica? There are a number of alternatives, depending on your application. XEmacs is not a wordprocessor, and it is unlikely to become one any time soon. I don't think any of the developers have much interest in doing that, and creating a redisplay that could handle accurate positioning, pagination, and all the rest would have to be done from scratch. It would not be hard to produce something that allows you produce Memopad-quality printed output most of the time, and not too much harder to do as well as Memopad all the time. But I don't think there are very many Emacs users who care. Most people who use Emacs prefer to use a real text justifier like TeX or troff for camera-ready copy, HTML for web pages, and so on. If you really want WYSIWYG, use Word or Framemaker or one of the *nix compatibles. If you want a semi-realistic display in XEmacs of what LaTeX will do very nicely, you can use preview-latex or AUC-TeX and customize the faces they use. PSGML will do the same for *ML documents. And if you just want to do it in XEmacs (progn (make-face 'tr "Times-Roman") (set-face-font 'tr "-adobe-times-medium-r-normal--*-120-*-*-*-*-iso8859-15") (make-face 'hv "Helvetica") (set-face-font 'hv "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-iso8859-15") (let ((here (point)) tre hve) (insert "Times-Roman") (setq tre (make-extent here (point))) (set-extent-face tre (find-face 'tr)) (insert " ") (setq here (point)) (insert "Helvetica") (setq hve (make-extent here (point))) (set-extent-face hve (find-face 'hv)))) does the trick. (The Windows version of the font name would be more compact, but otherwise the code is the same.) Granted, it wouldn't be hard (merely tedious) to cook up a library to allow you to do that operation the same way that Memopad allows you to do it. Why do we make it so "hard"? Because that's not what XEmacs is for. Typically the more complex text processing tasks already involve setting extents to delimit logical units of text, so you don't need to make an extent, just grab the appropriate one. And logical units (such as emphasis or comment or docstring) can be shared among applications, so such common semantics typically already have faces associated with them. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Vladimir> I noticed that Mozilla flows monospaced text perfectly Vladimir> in its message composition window. It does the same thing to patches. No, thanks. Vladimir> The problem is that the world is moving away from Vladimir> monospaced text editors and toward multi-font, Vladimir> proportionally spaced text with embedded graphics, etc. Good for the world. But so what? I don't object to the use of "multimedia", even in the simple form of a proper italic face for emphasis, instead of /slashes/ or _underscores_. Of course, I don't see either of those in email, because Gnus washes them into italics automatically. Graphics are good, so are audio and video clips. But what I've experienced so far suggests that the text:format ratio is the single best indicator, after author identity, of whether I want to pay attention or not. It doesn't have to be that way, but sadly enough, it is. Vladimir> I find it painful to read and answer an HTML-formatted Vladimir> email message with XEmacs+MH-E. So use Gnus or VM to read it as HTML. If you want mh-e to wash your HTML mail into something good-looking, talk to the mh-e people. It's not an XEmacs problem. Nor is message composition. Vladimir> XEmacs and TeX are similar in that part of their Vladimir> internal models are obsolete. How can they be obsolete? They're exactly what I want. ;-) Vladimir> Why should we read monospaced text? So change the default font, already. Vladimir> Isn't that just a holdover from ASR-33 teletype Vladimir> machines, just like 80x24 is? No. As far as I'm concerned, there's no such thing as "monospaced text." Text is a stream of characters. How you choose to format and display that may be monospaced or proportional, bidirectional or vertical. If you don't want text presented in a monospaced face, don't have it presented that way. Set your default face to use font Times Roman or Helvetica. A lot of people do exactly that for their mail and news buffers. Although I think text/plain in Times looks pretty good, I don't use that option. The mail and news that's important to me often contains code or patches; it's useful for that to be monospaced. Vladimir> We don't use monospaced type when we set books, and the Vladimir> typography of Don Knuth's code (not the literate Vladimir> programming stuff, just the code) in his book MMIXware Vladimir> is pleasantly readable. Books are rather hard to run grep(1) on though, aren't they? That evidently doesn't matter to you. It's extremely important to me. Vladimir> Why should my choice of width and margins be your choice Vladimir> of width and margins? Because nobody implements RFC 2646, which would make both of us happy. In particular, my precious patches would not get wrapped, while your text (including quoted lines in messages) could be flowed if you chose to display it that way. Vladimir> P.S. It's Notepad, not Memopad. In Japanese, it's Memopad. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Glynn> OTOH, a lot of code uses units of character cells, Yes, this is ancient breakage. What we should do is rip out all that code and force it to use pixel metrics. Hard, of course. Glynn> Well, there is such a thing as text which *should* be Glynn> displayed in a monospaced font, e.g. the output from "ls Glynn> -l", ps, netstat, od etc, ls -l output, for example, can easily be parsed to substitute a single tab for any whitespace. Many "proportional" fonts are deliberately designed so that each digits occupies the same fixed width, which basically leaves the initial modes that need to be done in a fixed-width font. I bet that most of these would look reasonable run through a filter which parsed the first line for # of chars to beginning of each field and heuristically set (pixel-based) tab stops. Sure you'd have to have a moderately smart shell, but why not? And I think it would require some additions to XEmacs internals to add pixel-based tab stops (pixel-based spacing could easily be kludged for backward compatibility with 1xn xpms using only the transparent color, of course). Glynn> ASCII-art, "screen dumps" from curses programs. While the Glynn> use of proportionally-spaced text may be increasing, Glynn> monospaced text is definitely here to stay. True. However, although I disagree strongly with him, Vladimir's point is well-taken: it's reasonable to consider defaulting to proportional fonts. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Glynn Clements <glynn.clements(a)virgin.net&gt; writes: Also note that many Asian languages, with Chinese, Japanese, and Korean as ideal examples, prefer monospaced characters. There are very strict rules for typesetting and even ordinary computer display of CJK text, and these require either that everything be monospaced or that very complex and hard to apply kerning be done to only certain classes of characters (punctuation, kana, roomaji, etc). Also word-wrapping is a very touchy subject in CJK text as therearenospacesbetweenwordswhichcanconfusetradtionalwordwrappingalgorithms. (Try M-q'ing that.) Also, there are no hyphenations in CJK text either (at least none that I've ever heard of). Suffice to say that although many people like antialiased text and proportional fonts, in the text editing biz there's very little incentive to dispose of monospace text. 'james -- James A. Crippen <james(a)unlambda.com&gt; ,-./-. 61.2204N, -149.8964W Lambda Unlimited: Recursion 'R' Us | |/ | Anchorage, Alaska, USA, Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System, Y(F) = F(Y(F)) \_,-_/ Milky Way.