minibuffer resizing for filled echo area content (was: Multi-line messages)

[Adrian Aichner]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

>>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi at 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 at 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 at xemacs.org
 http://www.xemacs.org/