Lars> Does XEmacs support multi-line messages by twiddling a Lars> variable of some kind? I've looked around, but haven't Lars> found anything. No. The echo area has always been a single line. The practice has always been to use the display-warning or help facilities; nobody has ever really felt the need to support multiline output from `message'. You can get multiline prompt and editing in the minibuffer with the rsz-minibuffer package, but that is probably not what you want. It's also possible to resize the minibuffer/echo area window permanently with enlarge-window. -- School of Systems and Information Engineering 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.

On 5/1/06, Lars Magne Ingebrigtsen <larsi(a)gnus.org&gt; wrote: Any reason that the iswitchb approach won't work? I'm pretty sure it works in XEmacs. (it grows the minibuffer to provide a big list of buffers which might be completed -- I've seen a variant used with programming language objects, as well). best, -tony blindglobe(a)gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).

Lars> Hm... that's a possibility. Although it might be a bit Lars> fragile. Yes, that's why I'm _not_ doing handstands and generally being totally enthusiastic about the idea. Lars> What I'm using this for is to display "electric" completions Lars> in the To/Cc headers. The new ecomplete package tries to be Lars> as (un)obtrusive as the completion you get in Lars> Firefox/Thunderbird. The traditional Emacs way of doing Lars> this is by popping up new buffers, which I think is too Lars> obtrusive for this kind of thing. Lars> Tooltips might be a possibility. But not on TTYs. I don't know how hard an automatically resizing echo area would be to implement, but I'll push it on the task stack for that case alone. For display-only on GUI, how about using the top gutter? You can put a string there just as easily as a tab control (in fact, the way we put the tab control there is in a bag on a kludge ... ahem, in a glyph on an extent on an empty string). Another possibility would be a pop-up menu, but that's rather heavy in its default form. A custom dialog would be possible, too, but might be a lot of work. (One issue is that getting the pixel geometry right, especially the positioning, is quite kludgy.) -- School of Systems and Information Engineering 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.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Hi Lars, Steve, I wanted that feature for a while too. For the longest time I thought it was a bug that messages in the echo area were not fully displayed when resize-minibuffer-mode was enabled. I understand minibuffer and echo area are separate features. Anyway, here is a crude prototype implementation of multi-line echo area. I am just filling the echo area, which is crude, and resizing the minibuffer according to the line count of the echo area, not checking whether resize-minibuffer-mode is even enabled. It's good enough to get a feeling for the usefullness of the feature. Please try it out and provide your feedaback. Best regards! Adrian ChangeLog Addition: 2006-10-28 Adrian Aichner <adrian(a)xemacs.org&gt; * simple.el (raw-append-message): Implement minibuffer resizing based on requirements filled echo area content. Patch: --- c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\lisp\simple.el.~1~ 2006-05-01 10:55:25.000000000 +0200 +++ c:\Users\AichnerAd\el\simple.el 2006-10-28 17:07:09.519625000 +0200 ＠＠ -4301,7 +4301,14 ＠＠ (defun raw-append-message (message &optional frame stdout-p) (unless (equal message "") (let ((inhibit-read-only t)) - (insert-string message " *Echo Area*") + (with-current-buffer " *Echo Area*" + (insert-string message) + (fill-region (point-min) (point-max)) + (enlarge-window + (- + (count-lines (point-min) (point-max)) + (window-displayed-height (minibuffer-window))) + nil (minibuffer-window))) ;; Conditionalizing on the device type in this way is not that clean, ;; but neither is having a device method, as I originally implemented ;; it: all non-stream devices behave in the same way. Perhaps -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta