Remove unneeded title format string values.tree/8078_treetabwidget_misc_cleanups

These two values are already defaulted in the parent class, so we don't need
to set them in the child (and weren't doing it consistently anyway).

I'm trying to identify places where we can't keep the tree tabs
knowledge self contained and speculate how we could handle that for
actually external code like extensions. So, thinking about how we would
gracefully handle some non-core code adding tab title format
placeholders, especially when that code could be disabled (eg, an
extension):

TabWidget will throw a KeyError if you have a format specifier which isn't
filled in. So we would have to decide how to handle that. Log a warning and
ignore it? Silently set it to `''`? Leave it as the literal `{thing}`, curly
braces and all? Presumable that API would look something like
`register_title_format_placeholder(placeholder: str, getter:
Callable[AbstractTab])`.

The `FormatString` config type used by `tabs.title.format` would have to
change as well to pull allowed placeholders from some global registry instead
of having the specified ahead of time in configdata.yml.

Even then, if you disabled an extension so it didn't register its placeholder
and you have the placeholder configured in your format string, what should
happen?

PS: jinja defaults to `''` for placeholders without values.

ref: #30

2 files changed, 11 insertions, 8 deletions

diff --git a/doc/treetabs.md b/doc/treetabs.md
index f32ee5449..d52a08de3 100644
--- a/doc/treetabs.md
+++ b/doc/treetabs.md
@@ -185,10 +185,17 @@ filled in for the tab title template string, with a lot of help from the data
 structure. It also handles hiding or showing tabs for collapsed
 groups/branches. Hidden tabs are children of tabs with the `collapsed`
 property set, they remain in the tree structure (which is held by the tabbed
-browser) but they are removed entirely from the tab widget. It also handles
-making sure tabs are moved to indexes corresponding to their traversal order
-in the tree if any changes to the tree structure happen via the
-`tree_tab_update()` method that is called from several places.
+browser) but they are removed entirely from the tab widget. The
+`tree_tab_update()` method, which is called from several places, also handles
+making sure tabs are moved to indices corresponding to their traversal order
+in the tree, in case any changes have been made to the tree structure.
+
+One place in the tab widget classes where tree tab specific code isn't
+contained entirely in TreeTabWidget is the `{tree}` and `{collapsed}`
+tab/window title format attributes. A key error will be thrown if a
+placeholder is in the format string but no value is supplied for it. So the
+parent class initialize them to an empty string in case users have them
+configured but have tree tabs turned off.
 
 A fair amount of tree tab specific code lives in *commands.py*. The six new
 commands have been added, as well as a customization so that these commands
diff --git a/qutebrowser/mainwindow/treetabwidget.py b/qutebrowser/mainwindow/treetabwidget.py
index fac96daee..8e8b6f29e 100644
--- a/qutebrowser/mainwindow/treetabwidget.py
+++ b/qutebrowser/mainwindow/treetabwidget.py
@@ -92,10 +92,6 @@ class TreeTabWidget(TabWidget):
                 f"difference={difference} tree={rendered_tree[1:]} tabs={tabs}"
             )
 
-        # Return dummy entries for now. Once we finish whatever operation is
-        # causing the current irregularity we should get proper values.
-        fields["tree"] = ""
-        fields["collapsed"] = ""
         return fields
 
     def update_tree_tab_positions(self):