Window auto-tagging

[HalosGhost]

When utilizing a tags-as-tags system (that is, using views as workspaces and tags as tags), creating a window on a tag does not correctly assign the tag to the new window. For example, on view 1, if you create a window on tag 1, even if you toggle tag 1's visibility, the window will remain visible until you explicitly move the window to tag 1.

The preferred behavior would be for new windows to be auto-assigned to the first (in order) tag currently visible on the view the window was created. That is, if I have tags 3, 4 and 5 visible on view 1, and I create a new window, it would be helpful if it were auto-assigned tag 3.

[TrilbyWhite]

The intended behavior is for a new window to be placed on every tag that is currently active. It seems part of the "tags as tags" systems is that windows don't need to be restricted to a single tag. If you have tags 3 4 and 5 active and open a new window, that window is added to tags 3 4 and 5.

I realize upon reading this that new windows probably also get the active tags in the alternate view - this is bad and will be fixed. But I'd like to keep the assignment to all active tags.

[HalosGhost]

Actually, having it be assigned to all active tags is fine too. The point though is that the window appears to not be assigned to any tag until explicitly assigned by the user. The first example I give is very reproducible.

[TrilbyWhite]

I was wrong about it needing to be fixed to not also be added to the other view - it works as I intended.

I can't replicate your problem here though. Can you describe it "kindergarden" style.

1) First tag (and first tag only) is active/selected (i.e. it shows the underline). 2) Mod+Enter to open a terminal 3) Mod1+Mod2+1 to toggle tag one's visibility leads to terminal being hidden as expected.

That is what I get.

[HalosGhost]

Okay, so I have Mod1+# to toggle tag visibility. If I have only one tag active (tag 1 for example), and I open a window (Mod+enter for termite, for example), it appears on the tag which I am viewing.

Mod1+1 to toggle tag 1's visibility off correctly does so (tag 1 is no longer underlined), but the window remains visible until I use Mod1+Mod2+1 (my binding for moving windows to given tag) to place the window on tag 1. I can make a short screen cast demonstrating this if it would help.

[TrilbyWhite]

That would be a bug, but I cannot replicate it. It works as expected for me.

Can you try with the default config - which would mean using the MOD1+MOD2+N binding.

[HalosGhost]

Sure, I will recompile, using the defaults and give it a run.

[HalosGhost]

Alright, I was wrong about one aspect of the bug, it appears to only apply when view 2 is active. But, the bug is reproducible using the default config. That is, new windows created after view 2 is assigned tags do not appear to be assigned to any tag until explicitly assigned.

[TrilbyWhite]

Ah, that's true. I kind of liked the byproduct of the view mechanism that when you initially switch to the alternate view you have a clean slate of no active tags. But this is a nasty result of that.

I may have to have tag one as a default active for both views.

[HalosGhost]

If that would fix the bug, it would be preferrable. Even though the clean-slate is a nice concept, I don't personally think it is worth the breakage.

[TrilbyWhite]

I just pushed the fix. What I wanted to (and managed to) avoid was having the overline indicator for tag one on startup.

If someone doesn't want to use the alternate views, I didn't want that odd line there serving no purpose but to confuse.

So I had it only set a default tag=1 if/when a window was created when no tag was selected. This will also prevent from issues coming from deselecting all tags and trying to open a window.

[HalosGhost]

Awesome, the fix works perfectly. Closed per 4805ca8