Repository navigation
Documentation tooltip issue with long structures shows too far down. #1563
Description
When you have a long structure, E.g. a Scaffold, the tooltip will show all the way at the bottom close of the structure. This is an issue because you cannot move your mouse to scroll a long tooltip.
Not sure what the best solution is, but I see why it is this way. Android Studio does it the obvious way which is show tooltip right below the name.
import 'package:flutter/material.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(title: Text('Pictures')),
body: Column(
children: <Widget>[
Image.asset(
'assets/ship.jpg',
),
Text('Ship'),
RaisedButton(
color: Colors.blue,
child: Text("Press me!",
style: TextStyle(
color: Colors.white,
fontStyle: FontStyle.normal,
fontWeight: FontWeight.normal,
fontSize: 20.0)),
onPressed: () {}),
Center(
child: Column(children: [
Text('Hello, World!'),
Icon(Icons.star, color: Colors.green),
]))
],
),
),
);
}
}
Activity
DanTup commentedon Mar 27, 2019
I'm not sure I understand, can you provide a screenshot of what you mean? When I hover something with a long tooltip, it has a fixed height and scrolls:
To make the tooltip disappear (eg. if I want to see the code) I can just move my mouse up slightly (off the tooltip), and I can scroll the tooltip the same I'd scroll the doc (two finger swipe on MacBook).
wyattbiker commentedon Mar 27, 2019
Example, I hovered over Column() class. Notice how the tooltip shows on the closing paren. The Column() structure is highlighted automatically.
DanTup commentedon Mar 27, 2019
Oh, I see! I thought I'd fixed that ages ago. I'll take a look, thanks!
DanTup commentedon Mar 28, 2019
Actually, I investigate it before, but it turned out to be a server issue:
dart-lang/sdk#35386
I'll see if I can find a workaround in the meantime.
Work around large ranges on constructors for hovers
wyattbiker commentedon Mar 28, 2019
Hi, workaround works. Just for my curiosity. Why is do you call it workaround? Does this mean not final fix? And when you say Server issue. Which server are you talking about?
Thanks!
DanTup commentedon Mar 28, 2019
I'll answer your questions backwards since I think it'll make more sense :-)
I mean is "the Dart Analysis Server" which is a program in the Dart SDK that we run in the VS Code plugin (and the other editors do the same) which supplies a lot of the language services for powering the editor. We call it a server because it's a long-running process that we can send requests to while your editor is open - it's all local to your machine like any other program.
So the list of errors/warnings, the content of the tooltips, the locations at which code folds, etc. are all computed by the server. This means that the VS Code extension doesn't need to do its own parsing of the Dart code - and that means less work is duplicated across each editor that supports Dart/Flutter.
This is a very common way for providing language services to editors - in fact Microsoft creating a standard protocol for them (https://microsoft.github.io/language-server-protocol/) which will make it easier to connect an arbitrary editor to an arbitrary language server (if they both support LSP).
So, when you hover your mouse over something, we send the position of your mouse (as a character offset) to the server and ask it for information about the item that's there. As part of its response, it returns the range that this tooltip applies to - this means if you move your mouse around by a few pixels, we don't need to re-request the information from the server if we know that it's still within that range.
The issue (dart-lang/sdk#35386) is that for these constructors, the server is returning a huge range (the whole call, including all arguments). I believe this is a bug in the server because it's not consistent with function calls.
That's right - the preferred fix would be in the server - making it return a range that just covers the name of the constructor (or at least, provide that in addition to what it currently does). We can't figure out this range from inside the VS Code extension because we'd have to make assumptions about how Dart code is parsed, and we specifically don't want to do that (to minimise places that need to change as the Dart language evolves, for example).
I call it a workaround because it's not the "correct" fix. The fix is a bit of a hack. What we do is say "if the range the server gave us spans more than one line, then just ignore it". The result of this is that we don't give VS Code any range at all, and that means if you move your mouse around by just a few pixels, it will have no choice but to ask us for an updated tooltip, because it doesn't know if it's the same.
It's possible that this will show up in other editors too (depending on how their tooltips are implemented), and they'd have to make a similar hack. That's why it would be better fixed inside the server, which is common to them all :-)
It should work fine functionality (in fact, we never used to supply ranges at all). It's just a little bit wasteful, since we're sending extra round trips to the server that could otherwise be avoided.
Hope this all makes sense!
wyattbiker commentedon Mar 28, 2019
Great detailed explanation. Yes makes lot of sense and good to know how things work. I guess hard to tell what Android Studio is doing unless you look at their code. Thanks again!
Work around large ranges on constructors for hovers