minibuffer resizing for filled echo area content (was: Multi-line messages)
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Lars" == Lars Magne Ingebrigtsen
<larsi(a)gnus.org> writes:
>> It's also possible to resize the minibuffer/echo area window
>> permanently with enlarge-window.
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.
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>
* 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
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.)
--
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