Changes goto_previous to accept an integer number of which previous

[kristopolous]

This addresses a long outstanding issue I've had ... I often want things like a basic alt+tab without a lot of cognitive load. goto_previous was fine if the desire is 2, but oftentimes it's 3 and the problem is then we're either managing window placement, doing directional cycle, which takes mental bookkeeping or doing the focus-list cycle which takes 1 keystroke to bring it up, then another to cycle through, another to select it. These are all very inconvenient.

So this is a patch to make goto_previous accept a number. If it's 1, then it works as before. If it's 2 then it cycles between 3 windows. If it's 3, then it cycles between the previous 4 and so on.

It is a breaking change and I'll be proposing another PR that has a more complicated notion of both directionality and offset which will have a new function signature and not be breaking.

Feel free to accept this, the other, or neither.

[mbenkmann]

I don't understand your gripe with the focuslist. My current binding is this:

kpress("Mod1+Tab", "mod_menu.grabmenu(_, _sub, 'focuslist', {sizepolicy='center'})"),

So switching to the previously focussed window is one keystroke only: Alt+Tab. If I want to switch to the window focussed before the previously focussed one it's 2 keystrokes: Alt+Tab+Tab.

I don't see how you could go lower in keystrokes than that?

And if you want to limit the choices or change the ordering, I suggest you write Lua code to maintain your own list of N choices and just call grabmenu() with your own list. I don't see a need for a change to the Notion base code at all to achieve what you want. It should be possible to do completely in Lua.

[kristopolous]

I don't understand your gripe with the focuslist. My current binding is this:

That was extremely dismissive, aggressive and hostile.

Is this how you intend to respond to people volunteering and trying to make things better?

[mbenkmann]

There seems to be some misunderstanding here. I don't know why you think I am being dismissive or hostile. And in fact I am trying to help you achieve your goal. Please help me understand what I said that upset you.

[mbenkmann]

To be perfectly clear: I saw your pending pull request and that it isn't being accepted, probably because it's a breaking change. So I thought I could help you find another way of achieving your goal that has more chances of being accepted. But because I do not fully understand what your issue is, I asked you to explain more. I think I was being perfectly reasonable and polite.

[mbenkmann]

I am suggesting an alternative implementation purely in Lua that is based on the existing focuslist and grabmenu. That would have a good chance of being accepted because it wouldn't break anything. But in order to understand if I am even correct that this would be possible I need to understand why the currently existing focuslist combined with grabmenu does not meet your requirements.

[raboof]

that it isn't being accepted, probably because it's a breaking change

TBH, it was probably not merged yet because I'm fairly busy these days ;) . This PR said "I'll be proposing another PR", being #375 - which has a comment that it doesn't currently work. I think I then figured I'd give @kristopolous some room to figure out a preference, and then just forgot about it ;)

[mbenkmann]

Sorry for spamming this issue, but the accusation that I was being hostile has upset me, so I feel the need to explain myself.

I don't understand your gripe with the focuslist.

When I wrote this, I meant it exactly this way: I don't understand. There is no hidding meaning, no implication that you are wrong or anything like that. Just the fact that I do not understand why you are dissatisfied with the focuslist.

My current binding is this: ...

This and the following stuff I am writing to tell you how I use the focuslist. I am writing this so you know what I am talking about, because I think we might be talking about different things. I was not being condescending, not trying to tell you how you should do things. I was just telling you what I do, so that you know what I am talking about.

I don't see how you could go lower in keystrokes than that?

Again, there is no hidding meaning here. Just the statement that I don't understand how one could make this more efficient. I am NOT saying that you are wrong and it can't be made more efficient. But from your description of your PR I don't understand it. I am perfectly willing to accept that the problem in understanding is with me. But I want to understand how it can indeed be made more efficient.

And if you want to limit the choices or change the ordering, I suggest you write Lua code to maintain your own list of N choices

This should tell you clearly that even though I don't understand exactly why the existing functionality does not fit your requirements, I accept that it doesn't. I am suggesting to write an alternative to the existing focuslist because I accept that your issue is valid and cannot be met with the existing focuslist.

I don't see a need for a change to the Notion base code at all to achieve what you want. It should be possible to do completely in Lua.

This was not intended as a criticisim of your code. It was just because pure Lua contributions have a higher chance of being accepted that I was suggesting going that route.

So again, please help me understand why what I wrote upset you? It was certainly not my intention.

[kristopolous]

ok so here's the use case:

Let's say you want to cycle between the 2 previous windows, 3 total. Yuur model is

key + tab + tab ...

What my model allows you to do is set a cycle window length so Instead of one action cycling the current and the previous, it's of variable length ... let's put this in your terms

Press Mod1 + tab + tab + tab
Then repeat those 4 keystrokes a bunch of times

You've now essentially established your working set being those 4 windows in a ring buffer - you can make it 3, you can make it 6, make it what ever you want. It's a different way to group things without spacially grouping them.

So what I did was have a way to set this number based on my workflow then I cycled through the group without having to keep mental track of a stack in my head or even having to read a list. I pressed the button and it was always one of those 3, or of those 4, or whatever. I clip my bound and manage the subset by cycling the ring.

This is because sometimes you are working with things that need their own geometry - maybe window 1 is full screen, 2 is split, whatever ...

Maybe there is a pure lua way of doing this and if I could have figured that out, I wouldn't have filed a ticket, I wouldn't have hunted this down it in the code and I wouldn't have done a PR.

If you can pull it off pure lua, I'd be happy. But for now I'm still running this patch locally

[mbenkmann]

Take a look at this:

curated_focuslist.txt

If I understand correctly, this should give you the behaviour as if goto_previous(2) was being used. Even if it's not exactly what you want, it shows the approach I was talking about. It should be possible to tailor this further to meet your needs. There are also things with this approach that might be interesting to you that goto_previous(n) can't achieve. E.g. you could add a sort() to the entries. This would result in a consistent activation order based on the window title, regardless of the order in which the windows were previously activated. And the order would stay the same even if you switch to a window out of order. I think this would go well with your theme of reducing mental load. Another idea would be to filter certain windows out of the list. Let's say you are working with application windows A,B and C, but sometimes you need to check your emails. You could make it so your mail program never shows up in the list. So even if you occasionally switch to your mail program, the modified Alt-Tab with the curated focuslist would always bring you back to your ABC rotation without replacing one of the 3 windows with the mail program.

[mbenkmann]

And if you don't want the grabmenu, you just want the goto_previous(2) functionality, you can bind it like this

defbindings("WScreen", {
    kpress("Control+Mod4+Tab", "alt_tab_n(3)[1].func()"),
})

Note that my numbering is different, so you have to use alt_tab_n(3) to get the functionality goto_previous(2)

IOW:

function goto_previous_n(n)
   alt_tab_n(n+1)[1].func()
end

together with the rest of the code should be an exact replacement for your goto_previous(n), written purely in Lua with no breaking change.

[raboof]

@kristopolous does the alternative described by @mbenkmann work for you or would you still like to see this change get merged?

You say it's a breaking change but you're not changing any of the default configuration - does that not need changes?

[kristopolous]

it's fine, forget about it. I've got no interesting battling with people. I'll just take my fork and go with it.