[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[4]: Tooltipping enhancement request
From: |
Eric M. Ludlam |
Subject: |
Re[4]: Tooltipping enhancement request |
Date: |
Fri, 12 Mar 2004 07:47:44 -0500 |
>>> "Jan D." <address@hidden> seems to think that:
>> Here is an example of interaction.
>>
>> 1) User types in foo->b
>> 2) User thinks, "Hmmm, what was that member again?"
>> 3) Emacs becomes impatient, and pops up a list of options.
>>
>> Here you can now branch.
>>
>> b1.1) user sees the field wanted, and types some more, or presses TAB
>> for
>> completion. Each key press updating the list.
>
>I still don't see why this needs a timer. But you would need to
I don't think the completion calculation code should run in a post
command hook. The process needed for calculating the list is already
managed by timers to reparse needed buffers, and analyze the current
point to determine the datatype needed at point (int, float, some
struct, etc). Once all that is done, and if there is no user input
waiting, then finally the completion list is calculated, then
displayed.
If it were bound directly to a key so you had to push something to
make it happen, that could be acceptable. I'm trying to push the
envelope and have the list just pop up after a few seconds of idle
time, in case you were trying to remember where that thing came from.
>dynamically update the popup menu while it is popped up. I am not sure
>any of the toolkits Emacs uses (GTK, Motif/Lesstif, Lucid) even
>supports it.
>I think it would be better to implement these lists in a kind of
>buffer/window, that appears over a window. Enhancing the current tool
>tip
>would probably break things, so other mechanisms is probably better.
>I'm thinking of some sort of "overlay windows" that may appear on top of
>other windows, and without the usual window manager decorations. How to
>handle input is something to figure out. There is a bigger chance to
>get
>this to work on all ports of Emacs than if popup menu code is enhanced.
>
>>
>> b2.1) user sees the field wanted, and clicks on it to complete.
>
>This is more in line with what popup menus can do now.
[ ... ]
I think it is important to handle both of these cases (a and b.)
It is similar to C-x C-f. if you hit TAB and the completion list
shows and is way to long, you type in more characters, then hit TAB
again. With the field of options reduced, then it is more tempting
to go and click on the option you want.
Given a choice for my own usage, I opt to sacrifice the clicking
ability for the typing one. It would be nice to support both though
as that is what is generally expected in other IDEs.
Here is an external URL that talks about it more:
http://www.peerfear.org/rss/permalink/2002/11/22/1038009860-Emacs_Needs_Floating_Windows_Advanced_Tooltips_for_IntelliSense_Support.shtml
Here is the competition:
http://www.activewin.com/reviews/software/devl/vsnet2003/features.shtml
The window in question is about 5 example images down I think.
Thanks
Eric
--
Eric Ludlam: address@hidden, address@hidden
Home: http://www.ludlam.net Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org