On 6 Jul 2015, at 1:44, Matt Neuburg wrote:

Looking more closely, I think the problem is that the tooltip is appearing at the insertion point rather than the cursor, if the insertion point happens to be visible on the screen.

Correct, it prefers the insertion point, as that’s where the action is, and as many probably use TextMate without involving the mouse cursor, showing tool tips and other pop-ups at mouse cursor location would not be ideal.

So there is a serious inconsistency here, since sometimes it's at the cursor and sometimes it's not.

The mouse cursor is fallback for when the caret is hidden.

What sort of actions are you using where you have the “serious inconsistency” issue?

Perhaps a better heuristic would be to use mouse location (also) when the action (that results in tool tip or pop-up menu) is triggered by the mouse. Though it might also end up making it appear even more arbitrarily.

On 6 Jul 2015, at 17:23, Matt Neuburg wrote:

...

On Jul 5, 2015, at 11:39 PM, Allan Odgaard mailinglist@textmate.org wrote:

Correct, it prefers the insertion point, as that’s where the action is

What "action"?

Press Shift-Control-Option-H to turn this document into HTML. On my machine, there's a tooltip with additional options; I need to press 1, 2, or 3. I need to _see_ that tooltip in order to _make_ that choice.

This is the disambiguation pop-up menu which appear when multiple bundle items are bound to the same key or tab trigger.

In your case, the items in the bundle are for the entire document, but there are many items where this is not the case, for example if you press ⌃⇧X you’re asked to convert to/from hex, which refers to the text under the caret, or ⌃⇧C for calculations, or (in HTML) press ⌘& to see entity conversion items (which again refers to the text).

It makes even more sense for tab triggers, for example if you type border⇥ in a CSS file, the same disambiguation menu appears and contains completions for what was just typed.

So while it might not be related to your caret position for the HTML conversion item, many items are related to the text at the caret.

And none of them are related to the mouse cursor position. That would only be appropriate if the action that triggered the menu, was caused by a mouse operation, but that’s not possible.

I think perhaps the solution is that the tooltip just needs to die. Instead, a GREAT BIG window should pop up in the CENTER of the screen where I can't miss it.

I see your point for _some_ items, but certainly not as a general solution.

This is why I wanted examples, to figure out if a heuristic could be devised. Initially I thought you were referring to tool tips, for example if you press ⌃⇧N you get document statistics shown in a tool tip (at the caret) — had you invoked this same action via the mouse, I could see an argument for showing the tool tip at the mouse cursor, but that is not the case here.

I will need to think some more about this, but I am not too optimistic about finding an elegant solution, because as said, this same menu is often used for items that are clearly related to caret position, so we can’t make a general change, and I don’t think it makes sense as a preference either, rather, it might make sense as a preference for a subset of items, but then how to identify those items…

Am 08.07.15 um 16:23 schrieb Matt Neuburg:

I don't attach any mental meaning to _where_ the thing pops up; I don't understand it now, so I'm not likely to understand it based on some other or more refined rule. I'm really not concerned about "elegant". Just "visible"! Maybe just "bigger" would do it, if my centering idea seems like too much. Anyway, thanks for thinking about it! m.

As kind of a workaround you could try to press “cursor down” – this visually selects the first entry (changing the line's background color) and so could help in finding the menu. (Repeat if necessary.)

Stefan

Bigger can be done, try this:

defaults write com.macromates.TextMate.preview OakBundleManagerDisambiguateMenuFontSize -int 30

Wow! Well, between that and Stefan's suggestion to hit an arrow key, I'm now suddenly a pretty happy camper. Maybe all that's needed is to promote that preference to some public form. I still think that the principle of least surprise says that the thing should always pop up at the cursor, but I'm much less worried about that now that my _practical_ problem (visibility) is solved! m.

-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 8! http://shop.oreilly.com/product/0636920034261.do iOS 8 Fundamentals! http://shop.oreilly.com/product/0636920034278.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html