1:53 p.m.
In XEmacs,
(message "hello\nyes")
displays "hello" in the echo area. In Emacs, you see both lines.
Does XEmacs support multi-line messages by twiddling a variable of
some kind? I've looked around, but haven't found anything.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
2:28 p.m.
Lars Magne Ingebrigtsen <larsi(a)gnus.org> writes:
In XEmacs,
(message "hello\nyes")
displays "hello" in the echo area. In Emacs, you see both lines.
Lars, I can confirm this behavior with my
XEmacs 21.5 (beta26) "endive" (+CVS-20060406) [Lucid] (i586-pc-win32, Mule) of
Fri Apr 07 2006 on TANG
Does XEmacs support multi-line messages by twiddling a variable of
some kind? I've looked around, but haven't found anything.
None i know of.
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:26 p.m.
>>>> "Lars" == Lars Magne Ingebrigtsen
<larsi(a)gnus.org> writes:
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.
6:01 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
You can get multiline prompt and editing in the minibuffer with the
rsz-minibuffer package, but that is probably not what you want.
Nope.
It's also possible to resize the minibuffer/echo area window
permanently with enlarge-window.
Hm... that's a possibility. Although it might be a bit fragile.
What I'm using this for is to display "electric" completions in the
To/Cc headers. The new ecomplete package tries to be as (un)obtrusive
as the completion you get in Firefox/Thunderbird. The traditional
Emacs way of doing this is by popping up new buffers, which I think is
too obtrusive for this kind of thing.
Tooltips might be a possibility.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
6:44 p.m.
On 5/1/06, Lars Magne Ingebrigtsen <larsi(a)gnus.org> wrote:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> You can get multiline prompt and editing in the minibuffer with the
> rsz-minibuffer package, but that is probably not what you want.
Nope.
> It's also possible to resize the minibuffer/echo area window
> permanently with enlarge-window.
Hm... that's a possibility. Although it might be a bit fragile.
What I'm using this for is to display "electric" completions in the
To/Cc headers. The new ecomplete package tries to be as (un)obtrusive
as the completion you get in Firefox/Thunderbird. The traditional
Emacs way of doing this is by popping up new buffers, which I think is
too obtrusive for this kind of thing.
Tooltips might be a possibility.
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).
8:08 a.m.
>>>> "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.
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.
9:34 p.m.
"A.J. Rossini" <blindglobe(a)gmail.com> writes:
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).
I think it uses the minibuffer (which can be multi-line in XEmacs),
and not the echo area, which can't.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
9:38 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
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).
Hm... I've never actually used any of the gutter stuff. :-) Do you
have an easy example on how those are supposed to work?
Another possibility would be a pop-up menu, but that's rather
heavy in
its default form.
Yeah; the interaction needs to be very quick and snappy for the idea
to work comfortably, and pop-up menus don't seem responsive enough. I
think.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
4:32 p.m.
New subject: 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
6388
days inactive
6568
days old
8 comments
4 participants
participants (4)
-
A.J. Rossini -
Adrian Aichner -
Lars Magne Ingebrigtsen -
Stephen J. Turnbull