Sorry, my relative inexperience w/ GitHub PRs is showing; only the last commit on this branch is relevant. I can restructure this so its on a branch with only commits related to this PR if needed.

You can rely on the text widths not changing, we run the tests with a special font where the ASCII characters all have exactly the same width as the font height.

I don't think we want to remove the leading width, it's intentionally there so that whether you have a leading widget or not, the labels are all aligned.

We could add a way to configure that, though I'm not sure what a good name for it would be...

I don't think that's what happens right now; the width there is on a container which is added to the ListTile only if the leading element was specified, so if there's no leading element passed then you won't get any extra spacing on the left.

Here's a screenshot that shows this in a Flutter app:

The ability to have no leading element is also needed to create a layout like this one from the Material spec:

Ah, right, I see.
Why would we remove it then? Wouldn't that lead to each widget with a differently-sized leading widget having a different left margin for the text?

@zzzev Can you elaborate on your desire to remove the explicit width on the leading widget?

@Hixie sorry for the delay. Removing the explicit width will allow the user to set a leading widget that's either narrower (probably not common) or wider (possibly more common, including e.g. in the test for this widget, which had text that overflowed the leading element's width) than 40dps.

I also realized when thinking about this that as is this will actually cause a regression for existing ListTiles which contain only an icon, which currently pick up some additional whitespace via this explicit width.

I think the ideal thing would be to add the padding for Icons to match the spec (which specifies that specifically icons and avatars should have the spacing that exists at head), and allow other Widgets to flow freely however they'd like, but I'm not sure that "looking into the leading" like that is necessarily a good idea.

Since this all was in the name of consistency between trailing and leading elements, and not a concrete use case that we need, I'm ok with just dropping this PR if you think the current behavior is good. If you think that users should be able to have leading Widgets with a non-40dp-width, I can update this to do the is-leading-an-Icon check I mention above, let me know what you'd prefer.

If this isn't a problem you are currently running into, I say we close it and wait for to solve it when we have a real problem so we can study it more carefully.

I have no objection to making the leading widget's size more customisable. There's various ways we could do this (e.g. ListTileTheme, an argument, etc).

Regarding the spacing not matching the material spec, I didn't quite understand what you meant but if you wouldn't mind filing a bug explaining the difference between what Flutter does and what the spec says we can definitely look into fixing this.

To clarify: the spacing for ListTiles at head does match the spec for leading elements that are Icon or CircleAvatar widgets, but the code in this PR would cause a regression for Icons (CircleAvatars need no extra padding, so they'd be the look the same with this code). The spec doesn't have any examples of leading elements that aren't Icons or CircleAvatars, so I think it's an area of somewhat undefined expectations.

I'll go ahead and close this PR for now and I'll revisit this if needed.