История изменений

Немного переделал решение под себя.

    awful.key({ modkey, "Control" }, "t",
        function (c)
            local c_tags = c:tags()
            local t_name = c.class or "N/A"
            for _, t in pairs(c_tags) do
              if t.name == t_name then return end
              -- Already on the corresponding tag
            end

            local new_t = awful.tag.find_by_name(c.screen, t_name)
            if not new_t then
              new_t = awful.tag.add(t_name, {screen=c.screen, volatile=true})
              if not new_t then return end
            end

            table.insert(c_tags, new_t)
            c:tags(c_tags)
            c:move_to_tag(new_t)
            awful.tag.viewtoggle(new_t)
        end ,
        {description = "move client to a new tag", group = "client"})

Среди изменений:

1. Если клиент уже находится на нужном теге, создание нового такого же и перемещение клиента на него, которое уничтожит старый тег и в сумме не даст совсем ничего, кроме сброса layout’а и т.п., не произойдёт.

2. Часть посередине добавлена, чтобы не создавать дублирующиеся теги с одинаковым именем. Так оно работает в изначальном варианте, и это вполне себе не баг, а фича, но мне удобнее без дублей.

3. После перемещения клиента происходит не переключение на свежесозданный тег, а лишь добавление его к списку активных. Мне так больше нравится, т.к. операция не деструктивная и переключиться на свежесозданный тег вручную всегда легче, чем возвращать обратно ранее активные теги после принудительного переключения. Есть ещё очень похожий вариант, где вместо перемещения клиента на новый тег и затем просмотра нескольких тегов одновременно делается почти то же самое – клиент добавлялся на новый тег, и не убирается при этом со старого, но под мой юзкейс более подходит то решение, которое описано в коде.

Думал придумать для правил что-нибудь подобное третьему пункту на замену switchtotag = true, чтобы правила тоже не переключали меня на новый тег, а лишь добавляли его к активным, но решил не заморачиваться, вручную и так легко это сделать, а надобность есть не то что бы постоянно.

Спасибо ещё раз за помощь.

Немного переделал решение под себя.

    awful.key({ modkey, "Control" }, "t",
        function (c)
            local c_tags = c:tags()
            local t_name = c.class or "N/A"
            for _, t in pairs(c_tags) do
              if t.name == t_name then return end
              -- Already on the corresponding tag
            end

            local new_t = awful.tag.find_by_name(c.screen, t_name)
            if not new_t then
              new_t = awful.tag.add(t_name, {screen=c.screen, volatile=true})
              if not new_t then return end
            end

            table.insert(c_tags, new_t)
            c:tags(c_tags)
            c:move_to_tag(new_t)
            awful.tag.viewtoggle(new_t)
        end ,
        {description = "move client to a new tag", group = "client"})

Среди изменений:

1. Если клиент уже находится на нужном теге, создание нового такого же и перемещение клиента на него, которое уничтожит старый тег и в сумме не даст совсем ничего, кроме сброса layout’а и т.п., не произойдёт.

2. Часть посередине добавлена, чтобы не создавать дублирующиеся теги с одинаковым именем. Так оно работает в изначальном варианте, и это вполне себе не баг, а фича, но мне удобнее без дублей.

3. После перемещения клиента происходит не переключение на свежесозданный тег, а лишь добавление его к списку активных. Мне так больше нравится, т.к. операция не деструктивная и переключиться на свежесозданный тег вручную всегда легче, чем возвращать обратно ранее активные теги после принудительного переключения.

Думал придумать для правил что-нибудь подобное третьему пункту на замену switchtotag = true, чтобы правила тоже не переключали меня на новый тег, а лишь добавляли его к активным, но решил не заморачиваться, вручную и так легко это сделать, а надобность есть не то что бы постоянно.

Спасибо ещё раз за помощь.