Also in regards to the popup can we get the :before and :after (if not already) stuff there?
Dev Build 3070
Wow, this is great!
I already see that it ends in a âI want this tagâŚâ
I only have time to play later but I was wondering whether we can come up with a âofficialâ or unofficial sanitizer that converts full html to ST tooltip html by deleting unsupported tags or printing a warning to the console etc. That would be very helpful considering that a lot of content might come from existing documentation.
[quote=âjbrooksukâ]Holy mother ofâŚ
Yes Jon! Thatâs it now, you can disappear again <3[/quote]
lol
Awesome!
Along with the nice addition of the tooltip API, thanks for the bugfixes - and especially for the show_quick_panel() one(s).
I will need to experiment with tooltips popups a bit more I suppose, but here is some (constructive) feedback already:
-
As mentioned, the popup doesnât disappear when the active window changes (and ST is not even visible anymore)
-
<br>
tag is recognized but<br />
is not (old habit). -
Scrolling the popup with the mouse wheel does not work. When you add that, please consider adding this to the completions popup as well :>
-
When the popup is scrolled out of view it gets âhiddenâ. While I think this might be by design, I also think that some plugins would like their popup to stay open if the user scrolls back to it. It would also be nice to know why exactly a popup was hidden, e.g. which key was pressed, to update it accordingly or when selection was changed, so I was thinking of a parameter to
on_hide
that states why it was hidden. And maybe a parameter to make it persist when scrolled out of view. -
When the view is scrolled, the popup is not scrolled smoothly. Very minor issue, but the same happens for the completions popup as well - I just never noticed.
And finally a suggestion regarding key bindings: In a similar fashion to the above with knowing why a panel was hidden, there is no way currently to define key bindings that donât consume the event. Well, I guess you could define a context callback that gets called with a certain parameter and always returns false, but I think a general approach to define non-consuming key bindings that are always evaluated before the consuming ones (meaning: they are not as easily overridden as normal bindings) sounds interesting. Would like to hear other thoughts on this.
Example use case: Update the popup contents by highlighting another parameter if ,
or )
was pressed, but without consuming other keybindings.
Edit: Are there currently any other constants than HTML
?
[quote=âgregor.hochâ]
I only have time to play later but I was wondering whether we can come up with a âofficialâ or unofficial sanitizer that converts full html to ST tooltip html by deleting unsupported tags or printing a warning to the console etc. That would be very helpful considering that a lot of content might come from existing documentation.[/quote]
Thanks Jon!
Just sent a pull request to tern_for_sublime for optional tooltip support. github.com/marijnh/tern_for_sublime/pull/61
The tooltips look amazing! Thank you!
If you click somewhere else in the text, the tooltip disappears. But if you click so that the selection doesnât change, such as on the current insertion point or below the text in a short file, then the tooltip doesnât disappear.
Could the text inside the tooltip be selectable? This would allow copying and pasting of things in the tooltip that arenât otherwise hyperlinked and plumbed through.
Thanks again!
Similar to the popup being drawn on top of other windows: if you move the Sublime Text window, the popup doesnât move with it.
The API right now can only show one popup, which maybe is actually a great idea. But if you get a popup with a link to documentation, and click that, it might be neat to be able to show another popup.
Finally, the popup is tied to a text location. Is there any chance the popup could attach to other things? For example, *(https://i-msdn.sec.s-msft.com/dynimg/IC613189.png) This behavior could be faked relatively easily if the popup could capture keystrokes.
Iâm excited!*
Will all of these new features be added to the API Reference soon? Hopefully the âUnofficial Docsâ will be updated as well.
FWIW, we are actively working on a more detailed and more complete API reference/documentation in the undocs.
I think the new tooltip api will give us much needed flexibility and allow us to make our plugins even more friendly than before. I do agree with some of the other members that we need to be cautious when adding this feature to our plugins as we may be overriding tooltips from another plugin. Definitly include an option to enable/disable tooltips for YOUR plugin when you add this feature to give the end user the option to pick and choose what tooltips get used.
Aside from that, I forgot to ask for one feature in my last feature request post. I think adding an api to access the indexed symbols would be very helpful. Right now we can make a call to look_up_symbol_in_index, but only if we know the symbolâs name. If we were given the ability to query the index or retrieve a list of the indexed symbols we could being to add project symbols to the auto-complete list. The auto-complete list that is currently generated is very helpful but limited as it only displays variables and symbols from the current file. We have most of the pieces to make this work already, weâre just missing the methods to link them all together.
Along with the new index API, I would like to see the ability to trigger the indexer manually. I have run into a few cases where I create a new function, close the file containing the new function, call the new function from another file, and then try to jump to definition and the function is not found (phew! ). This is very much an edge case as leaving the file open would solve this problem, but I have seen the disconnect a few times. If you do implement this feature, I would recommend adding some sort of timed delay such that the even if the function gets called 200 times, it will only trigger once every 30 seconds or what ever you deem appropriate.
Just to circle back to my last set of feature requests, I think adding this new index API and allowing us to include folders for indexing, either hidden from the sidebar or by creating a new entry for index only folders within the project, would open so many doors for plugin developers.
Having sublime under active development again has made my job much more enjoyable! Already looking forward to the next release!
Anyone know how to make a tooltip whose content is scrollable? It seems the tooltips are not scrollable when content exceeds height and/or width. Using CSS to make elements scrollable hasnât worked for me either.
Even if scrollable elements will not be allowed via CSS, I feel the tooltip itself should respond to scroll wheel if content is too big. I donât know, anyone else want to weigh in?
@facelessuser: My test tooltip (view.show_popup("some text <br>" * 20)
) has a vertical scrollbar attached to it, but mouse wheel is not supported, similar to the completions popup (which I mentioned in my first post).
Do you mean scrollable html elements (code {overflow: auto; max-height: 100px}) or horizontal scrolling?
Ahh, I have the auto hide scroll bars, so you canât see them unless you click where they are supposed to be. I would also prefer for the scroll wheel to also work in a tool tip.
Hmm, yeah, I use OSX at home, but I tested this at work on a Windows box.
If you have the option to hide the scroll-bars enabled on Windows, then it just sucks. You canât see the tool-tip scroll-bars, and they donât appear on hover or mouse wheel, and if you have a lot of content in the tool-tip, you have to snipe the invisible scroll-bar puck. If you are lucky and nail it, when you drag, it will scroll.
So, I guess I will clarify, Windows should allow the mouse wheel to cause tool-tips to scroll .
Edit: I had a hard time posting this because the forum kept saying "Words similar to "ktchn" are banned due to spam" (I canât post exactly what it is because the filter is evil). The bad phrase was clck it (as in what you do with a mouse). I am all for fighting spam, but seriously, letâs not make it hard to talk on the forum; I should be able say click in a phrase without getting flagged.*
âsk*p the next stepâ is blocked too. I could also mention that the server clock is set to DST and then still 1:45m off, but this is not the right thread for that.
One thing Iâve noticed while playing with the tooltip API and ternjs is that thereâs competition between it and the autocomplete popup which causes a flicker effect. I can see where having both open at the same time could be useful, such as reading a doc snippet provided or a list of params available in the tooltip while still wanting the niceties of the autocomplete for words.
Would having an option to show the tooltip on top/ascender line be doable while still preserving the autocomplete popup at the descender line?
This is amazing. Since you asked for feedback, I just wanted to share a couple of ideas:
- Is there a way to âclickâ a link in a popup using only the keyboard? My relationship with my mouse has been headed downhill for years.
- It could give plugin developers a truly insane level of flexibility if there were a âbuilt inâ-ish way of registering custom URL schemes (or at least relying upon a singe âsublime://â one that forwarded clicks to a callback in a given plugin). What I was envisioning is, in the simplest implementation, the ability to open tabs/windows and do other core sublime-y stuff upon clicking a tooltip link.
Thanks for the work youâre putting into the updates, Jon!
Got home and played around with the new tooltip API. ScopeHunter can now utilize the tooltips viewtopic.php?f=5&t=11008#p65944. So if you use ScopeHunter, you can configure it to use popups and see the tooltips in action. CSS is completely configurable.