Tooltipping enhancement request

Tooltipping enhancement request

[Eric M. Ludlam]

Hi,

  I've got four enhancement requests based on some tools I've been
writing.  I think some of you already are familiar with some stuff
I've been doing called "cedet" which you can read about here:

  http://cedet.sourceforge.net

  A feature I've been working with lately is called "intellisense" in
other editors.  I thought it would be nifty to write something better.
I've opted to use an Emacs 21 tooltip to display completions.  Some of
that code was donated, and I had since attempted to fix some problems
I encountered.

  You can see a screenshot of what it should look like here:

http://cedet.sourceforge.net/intellisense.shtml    - page
http://cedet.sourceforge.net/inlinecompletion.png  - picture

  Here are the requests:

1) A function that takes a frame, window, and buffer position and
   returns an X/Y location on the screen that would allow
   accurate tooltip positioning.

At this time, a means of positioning the mouse pointer over a
particular character is used to then position the tool-tip.  That
requires that the mouse move.  In addition, things like header lines,
split windows, and toolbars seem to effect the accuracy of that
mechanism.

2) A means for accepting input from a tooltip (a strange idea)
   or a way to make a regular Emacs frame look like a tooltip.

The tooltip is pretty good for me.  I don't use the mouse much, but I
watch others use this feature in other editors, and they all like to
go clicky-clicky on the completion list.  I think it would help
mouse-bound users.

The tooltip part is important because a timer can cause Emacs to go
into this completion mode.  Splitting windows and moving the mouse
makes the feature difficult to accept.

Here are two other requests unrelated to tooltips:

3) A means of having an overline cross the entire window.

Also in the .png above, you can see some C definitions have a blue
line over them.  This overline is added to mimic a feature of IntelliJ
that has a thin line over all big functions, effectively dividing up
the buffer.  It is an interesting thought, which I quickly got used
to after implementing it.  It would be nice if that overline could
stretch across to the right side of the window to complete the effect.


4) Let multiple tools add header lines.

The mode line has had a means of management that lets different little
apps share it.  The header line does not.  I have a simple tools that
makes the function definition that is clipped at the top of the screen
appear in the header line.  I think it's pretty cool and quite
helpful.  That then conflicts with tabbar.  I had to turn it off in
the picture above because it changed how the tooltip was positioned.

The header line theme seems to be that tools use the entire line for
their purposes.  It would be nice if some official API made it easy
for apps that wish to use add a header line to be given something that
they can configure for their purposes without interfering with other
tools attempting to do the same thing.


Thanks for listening.
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Tooltipping enhancement request

[Masatake YAMATO]

> 2) A means for accepting input from a tooltip (a strange idea)
>    or a way to make a regular Emacs frame look like a tooltip.
> 
> The tooltip is pretty good for me.  I don't use the mouse much, but I
> watch others use this feature in other editors, and they all like to
> go clicky-clicky on the completion list.  I think it would help
> mouse-bound users.
> 
> The tooltip part is important because a timer can cause Emacs to go
> into this completion mode.  Splitting windows and moving the mouse
> makes the feature difficult to accept.
> 

What kind of input do you expect?

About VisualBasic like completion selection, I think it is better 
to extend the behavior of popup-menu. The popup menu of emacs configured
with --with-gtk can do
1) select a menu item with cursor keys, and
2) pass other keys to the behind buffer and close the popup menu itself.

The biggest problem is that there is no elisp function to pop down the 
popup menu. (Correct me if I write wroing.) So you cannot use the popup
menu with timers.

Masatake

Re[2]: Tooltipping enhancement request

[Eric M. Ludlam]

>>> Masatake YAMATO <jet@gyve.org> seems to think that:
>> 2) A means for accepting input from a tooltip (a strange idea)
>>    or a way to make a regular Emacs frame look like a tooltip.
>> 
>> The tooltip is pretty good for me.  I don't use the mouse much, but I
>> watch others use this feature in other editors, and they all like to
>> go clicky-clicky on the completion list.  I think it would help
>> mouse-bound users.
>> 
>> The tooltip part is important because a timer can cause Emacs to go
>> into this completion mode.  Splitting windows and moving the mouse
>> makes the feature difficult to accept.
>> 
>
>What kind of input do you expect?
>
>About VisualBasic like completion selection, I think it is better 
>to extend the behavior of popup-menu. The popup menu of emacs configured
>with --with-gtk can do
>1) select a menu item with cursor keys, and
>2) pass other keys to the behind buffer and close the popup menu itself.
>
>The biggest problem is that there is no elisp function to pop down the 
>popup menu. (Correct me if I write wroing.) So you cannot use the popup
>menu with timers.
  [ ... ]

I'll call what I want a "completion tip" to separate it from both
tooltips which do their job just fine, and menus.

A usage of a completion tip be this:

1) popup from a timer or keypress, showing possible completions
2) accept any length text, and show a scrollbar if too long
3) remove itself in case of non-completion-tip actions.
4) not disappear on valid completion tip actions which include:
   a) scrollbar actions
   b) cursor up/down navigation
5) allow highlighting/coloring of one or more in the list

I think I can simulate a bunch of of this with tooltips and clever use
of text characters and images, but I'm not sure about the flashing of
the tip on each keystroke.

A problem with menus is that they won't go away after non completion
tip type actions.

Thanks
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Tooltipping enhancement request

[Jan D.]

> About VisualBasic like completion selection, I think it is better
> to extend the behavior of popup-menu. The popup menu of emacs 
> configured
> with --with-gtk can do
> 1) select a menu item with cursor keys, and
> 2) pass other keys to the behind buffer and close the popup menu 
> itself.
>
> The biggest problem is that there is no elisp function to pop down the
> popup menu. (Correct me if I write wroing.) So you cannot use the popup
> menu with timers.

No, you are not wrong.  Can you elaborate more exactly what you want to
do, and why a timer is needed?  There may be some other means to do what
you want.

	Jan D.

Re[2]: Tooltipping enhancement request

[Eric M. Ludlam]

>>> "Jan D." <jan.h.d@swipnet.se> seems to think that:
>> About VisualBasic like completion selection, I think it is better
>> to extend the behavior of popup-menu. The popup menu of emacs 
>> configured
>> with --with-gtk can do
>> 1) select a menu item with cursor keys, and
>> 2) pass other keys to the behind buffer and close the popup menu 
>> itself.
>>
>> The biggest problem is that there is no elisp function to pop down the
>> popup menu. (Correct me if I write wroing.) So you cannot use the popup
>> menu with timers.
>
>No, you are not wrong.  Can you elaborate more exactly what you want to
>do, and why a timer is needed?  There may be some other means to do what
>you want.
  [ ... ]

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.

b2.1) user sees the field wanted, and clicks on it to complete.


Other options might be that a user must press some key to start the
program, or perhaps "." or "->" automatically starts it, though it is
also useful for symbols in the root namespace, or even just ispell
type completion.

Thanks
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Re[2]: Tooltipping enhancement request

[Jan D.]

> 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
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.

	Jan D.

Re[4]: Tooltipping enhancement request

[Eric M. Ludlam]

>>> "Jan D." <jan.h.d@swipnet.se> 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:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org