Re: tooltip-use-echo-area disappeared

[Jason Rumney]

Nick Roberts <address@hidden> writes:

>  > >Setting tooltip-use-echo-area to t meant that normal (and GUD) tooltip
>  > >strings were displayed in the echo area i.e not really as tooltips.
>  > >They can now be displayed there independently. For GUD tooltips set
>  > >gud-tooltip-echo-area to t. For normal (help) tooltips, just turn
>  > >tooltip-mode off.
>  > >  
>  > >
>  > Meanwhile, tooltip-use-echo-area has been abducted by gud for use as an 
>  > alias, breaking existing code that assumed it was a general user option 
>  > for controlling the display of tooltips.
>
> Or even kidnapped by gud.  Rather than use dramatic language to heighten
> your case, it would be more helpful if described what code it breaks, and
> how it breaks it.  We could then decide what to do.

It's been reported twice before, it breaks semantic, which uses
tooltip-use-echo-area in a test to determine whether to enable a
certain feature which would be excessively annoying if displayed in a
resizing echo area.

>  > Shouldn't turning tooltip-mode off disable tooltips completely, whether 
>  > they are displayed in frames or the echo area?
>
> Having tooltip-mode on and tooltip-use-echo-area set to t wasn't
> exactly the same as having tooltip-mode off.

Even more reason not to remove tooltip-use-echo-area.

> With the former, messages were displayed in the echo area in the
> manner of a tooltip i.e they required the mouse to pause over the
> text etc.  With the latter, help messages appear instantly like
> mouse-face.

They shouldn't appear at all.

> It is not a tooltip and might even predate them, which
> might explain the apparent anomaly.  AFAIK, this is how it has
> always been, and no-one has found a problem with it.

So why the need to remove tooltip-use-echo-area then, and why is gud
so special that it still needs this variable (or a specialized version
of it), while other code apparently doesn't?