Documentation tooltip issue with long structures shows too far down.

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),
            ]))
          ],
        ),
      ),
    );
  }
}

[wyattbiker]

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!

[DanTup]

I’ll answer your questions backwards since I think it’ll make more sense 😃

Which server are you talking about?

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).

And when you say Server issue

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 (https://github.com/dart-lang/sdk/issues/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.

Does this mean not final fix?

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).

Why is do you call it workaround?

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!