> > Resurrecting tooltip-use-echo-area is unrelated to making the tty version > > support tooltips. > > IMO, it is related.
OK. I've just installed changes that try to restore the behaviour of tooltip-use-echo-area. I guess I should try to give people what they want rather than what I think they should have. I have made it an obsolete variable because its ugly to turn tooltip-mode on and then set a flag so that it behaves like its turned off. Jason, can please you tell me if this change actually gives you the behaviour that you want. > > It was just a flag that re-directed the output of tooltip-show-help > > to the echo area i.e. in the case of normal tooltips back to where > > it was displayed before tooltips were turned on. > > If you mean to say that turning tooltips off would still display the > tooltip text in the echo area, then I agree with Jason: that's a bug > that should be fixed. It should be possible to have 1 of 3 situations > wrt tooltips: I don't think it is "tooltip text" but "help text". tooltips come later and can choose to display "help text". > (1) no tooltips and no messages in echo area > (2) tooltip text is displayed in the echo area > (3) tooltips are displayed as small floating windows I think that (1) isn't possible but this is a separate issue to Jason's point. Perhaps there could be another mode, help-text-mode say, that turns messages on and off in the echo area, but IMHO this should wait till after the release. > > Normal tooltips and GUD tooltips have quite different internals and > > putting their associated code in separate files was much more modular. > > Previously if tooltip-use-echo-area was set to t so that normal tooltips > > displayed there, then GUD tooltips would display there. > > Internals aside, from the user's point of view, if I want tooltip text > to be displayed in the echo area, I want ALL tooltips to behave like > that. Why in the world would I like these two variants of tips to > behave differently? GUD tooltips are more distracting and easier to activate inadvertantly. Emacs is generally about choice, they don't have to behave differently if you don't want them to. Nick _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
