awful.tag.history.restore fails when previously selected tag was volatile

[jcrd]

Output of awesome --version:

awesome v4.3-222-g021bf689-dirty (Too long)
 • Compiled against Lua 5.3.5 (running with Lua 5.3)
 • D-Bus support: ✔
 • xcb-errors support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

How to reproduce the issue:
First add a normal tag and then a volatile tag to the screen. Select the volatile tag and spawn a client. Close the client, which destroys the volatile tag and focuses the first tag. Call awful.tag.history.restore for the given screen.

Actual result:
The first tag is unselected, leaving no tag selected.

Expected result:
Because there is no history to restore, the first tag should remain selected.

[frioux]

I think this also caused issues for my sharetags thing. I worked around it with help from @hoelzro by simply doing awful.tag.history.restore = function() end.

I think Rob notice some other issues in the tag history code but I'll let him speak for himself.

[Elv13]

The history of both tags and clients has to be burned to the ground and replaced by a better API. It's hopeless.

I have a partially written gears.history module in a branch. The general idea is to have an history object that can be used with everything (tags, clients, commands, screens, etc). This object would be easy to setup "by users" instead of a single instance provided by the API. This would allow filters and the ability to pause them for alt-tab like transactions.

Right now, it is low-ish in my priority list and I have little time for this to begin with. I am currently working on making the rules equally flexible and easy to share for various object types. I need this short term because it is required to complete the new notification API (for notification filters and custoesm domain specific notification styles) and high level clipboard API (new in v4.4). The problem I am facing right now is that it pulls a lot of threads. The history has the exact same issues. It has to fit all use case and provide an API I wont have to break 6 months later because it isn't flexible enough. My solution, which is the source of much delays, is to just implement every single use cases I can think of and learn from them...

The API looks like:

local h = gears.history {
    unique = true, -- deduplicate automagically
    count  = false,  -- keep track of the number of time an item was pushed
}

-- Listen to event to push/pop/remove objects.
client.connect_signal("focus"   , h.push_front)
client.connect_signal("manage"  , h.push_back )
client.connect_signal("unmanage", h.remove    )

-- Abstract way to select objects.
h:connect_signal("select", function(_, c)
    client.focus = c
end)

-- Support multiple iterators
local h_i = nil

-- Easy to use for transactions
awful.keygrabber {
    keybindings = {
        {{'Mod1'         }, 'Tab', function() h_i:select_next    () end},
        {{'Mod1', 'Shift'}, 'Tab', function() h_i:select_previous() end},
    },
    -- Note that it is using the key name and not the modifier name.
    stop_key           = 'Mod1',
    stop_event         = 'release',
    start_callback     = function() h.paused = true;  h_i = h:iterate_back() end,
    stop_callback      = function() h.paused = false; h_i = nil               end,
    export_keybindings = true,
}

-- Easy to iterate
for my_object in h:iterate_front() do
    -- something
end

If anyone is interested in implementing this, I would be grateful. My implementation is mostly the API skeleton and some stack code, so better start from scratch.