<k-man>
is it possible to map ctrl+shift+u to something else? (for url)
ynakao has quit [Quit: WeeChat 3.3]
ynakao has joined #foot
<k-man>
am i mad to try and run foot under gnome?
sosodank has quit [Quit: Leaving]
<rcf>
k-man: see the [key-bindings] section in foot.ini, specifically show-urls-launch
<rcf>
k-man: also yes, definitely.
hill has quit [Remote host closed the connection]
<k-man>
oh well - no madder than i was before trying
<k-man>
it works but backspace does weird things
<k-man>
and gnome intercepts ctrl+shift+u hence me asking if it can be rebound
hill has joined #foot
hill has quit [Remote host closed the connection]
hill has joined #foot
hill has quit [Remote host closed the connection]
hill has joined #foot
pranjal has joined #foot
caveman has joined #foot
diniwed[m] has quit [Quit: You have been kicked for being idle]
hill has quit [Remote host closed the connection]
hhirtz has quit [Remote host closed the connection]
<dnkl>
ifreund: thanks! Will have to take a look!
<dnkl>
k-man: all key and mouse bindings can be rebound in foot... :)
hill has joined #foot
hill has quit [Remote host closed the connection]
hill has joined #foot
hill has quit [Remote host closed the connection]
pranjal has quit [Quit: WeeChat 3.4]
<lh>
just wanted to say the DPI-aware scaling is sick as someone with a 1440p and 1080p monitor on GNOME. except now I hate all my apps using GUI toolkits that can't do it 😅
<dnkl>
lh: thanks, really appreciate the feedback!
ashpil has joined #foot
<ashpil>
Hey guys, I'm trying foot for the first time and one thing I can't get seem to work is proper scrolling speed in vim. The `scrollback.multiplier` option works fine for just normal terminal scrolling, but scrolling in vim the same (super slow) no matter what I set it to. Any idea what the issue could be?
<ashpil>
For reference vim scrolling speed is great in alacritty
<dnkl>
ashpil: the scroll multiplier isn't applied on the alt screen. There should be a vim setting you can use instead.
<dnkl>
(this is how e.g xterm works as well)
<ashpil>
Hmm interesting. That makes it even more odd that I experience different behavior in foot and alacritty, though. Oddly enough, when I scroll (with trackpad) in vim+alacritty, vim tells me the `~@k` command is issued, which according to this: https://stackoverflow.com/questions/7305108/viewing-a-file-over-a-network-meaning-of-k indicates arrow key
<ashpil>
usage. No such command is issued when scrolling in vim+foot, though, which makes me think alacritty is somehow doing additional scrolling at the same time with the arrow keys, which is why it is much faster? Something is weird either way
<dnkl>
scrolling on the alt screen can be done in two ways
<dnkl>
if the app enabled mouse support, the terminal send mouse events to the application
<dnkl>
if not, the terminal can "simulate" arrow key presses
<dnkl>
so, it depends on how you've configured vim
<dnkl>
what kind of pointer is the mouse, in foot, when you hover over the terminal window (while inside vim)?
<dnkl>
a beam, or a "normal" arrow pointer?
<ashpil>
it's a beam, same as alacritty
<dnkl>
so that means foot is also sending faked arrow keys
<dnkl>
I think we're still behaving like XTerm, and others (though obviously not as alacritty). Still, it isn't obvious whether the scroll multiplier should be applied in this case or not
<dnkl>
I can always compare with a couple of other terminals, to see what the "normal" behavior is
<dnkl>
but it'll be a couple of days before I have the time
<ashpil>
Hmm is it possible the difference then is simply that alacritty sends the fake arrow keys more rapidly than foot?
<dnkl>
in the mean time, one option for you is to enable mouse support in vim, and then try to configure the scroll speed there
<dnkl>
yeah, alacritty probably applies the scroll multiplier
<dnkl>
so each scroll event gets translated to e.g 3 arrow presses
<ashpil>
Yeah I've tried enabling mouse support in vim, but the issue with that is then vim changes the behavior of the scrolling (it moves the window rather than the cursor), which I don't want.
<ashpil>
Personally to me it makes sense to apply the multiplier in this case, as it ensures scroll speed remains consistent across alt/normal screens.
<ashpil>
I appreciate the replies and you looking into this! Take your time - it's good enough to know this is something that is being thought about