<dnkl>
it allows neovim to disambiguate keys, to a much greater extent than before. Simple example: by default, <tab> and <ctrl+i> emit the exact same sequence, making it impossible to assign different actions to those two key combinations.
<dnkl>
but with the kitty protocol, those two key combinations will emit different sequences
an3223 has joined #foot
an3223_ has joined #foot
an3223 has quit [Ping timeout: 240 seconds]
rcf has joined #foot
<Nuc1eoN>
Ok that sounds great!
cbb has joined #foot
<cbb>
dnkl: do you know of a good way to detect/query support for OSC 52?
<cbb>
(other than using $TERM)
<cbb>
...and if not, do you think it'd be reasonable to invent one?
<novakane>
so I was reading my zshrc and I'm curious, is there any reason that the OSC7 examples use \e instead of \033 or \1xb?
<dnkl>
only that it's easier to read
<dnkl>
('e', as in ESC)
<novakane>
allright, just saw that usually it's better to not use \e , just learning a bit more about osc, made me curious
<dnkl>
depends on the context. In C, it's not a standard escape, and should be avoided. But shouldn't be a problem with e.g. echo in zsh and bash
<novakane>
oh ok, thanks for the explanation
cbb has joined #foot
<baltazar>
dnkl: how stable is the master branch considered to be? should I report bugs on it?
<dnkl>
yes, please report all issues. Master is supposed to be stable, as most new features are implemented in branches
<dnkl>
(and, fwiw, I always run latest master as my daily driver)
<baltazar>
ok alright
<baltazar>
I found a crash with scrollback search but it might not be the same as the issue you already added
<dnkl>
if you have a way to reproduce, or a backtrace, then please report it. Otherwise I'm currently running a debug build of foot, hoping to trigger the crash again...
<baltazar>
I can't reproduceit 100% but it happens quite often when I press ctrl-w to extend selection while on a secondary screen. I do have a coredump if that helps
<baltazar>
e.g. open `man foot`, `ctrl+shift+r`, type `foo`, `ctrl+w` crashes (but not always)
<dnkl>
Sounds similar to what I've been seeing, though I've never been able to trigger it intentionally...
<baltazar>
well I managed to trigger it 7 times since I mentioned it this way
<dnkl>
Can you do that with an unstripped debug build?
<dnkl>
I'll try your way tomorrow, but if I still can't reproduce, your input would be helpful
<baltazar>
I'll try compiling a debug build, the current backtraces are just a bunch of `#0 0x000055e533e243cd n/a (foot + 0x303cd)` and such
<dnkl>
Yeah, not very useful, I'm afraid
<dnkl>
Which compositor are you running?
<dnkl>
And if you open an issue, can you also include your foot config?
<baltazar>
sway (wlroots)
<baltazar>
dnkl: should it be a separate issue then?
<dnkl>
Hmm.. actually no. I do think we're seeing the same issue
<dnkl>
Just post a comment in the existing one
<baltazar>
alright
<baltazar>
very strange. took a couple of attemts to reproduce but I did crash it eventually
<baltazar>
wait. was I supposed to do something else other than enable debugging symbols? I see your stacktrace has stuff from debug.c
<baltazar>
either way, I think it's actually a different bug
<dnkl>
My stack trace was from a branch where I added me assertions
<dnkl>
Without them, we'd crash "for real" in some other place
<dnkl>
That branch was merged to master earlier today
<dnkl>
s/me/more
<baltazar>
well, I did just build this from the latest master
<dnkl>
Post what you have in the existing bug. We can split it off later, if it turns out to be a different issue
<baltazar>
alright
<dnkl>
Got to sleep now, but will try to reproduce again tomorrow
<baltazar>
ok. I posted my comment in the meantime
cbb has quit [Quit: WeeChat 3.5]
newchair has joined #foot
replaycoding has joined #foot
replaycoding has quit [Client Quit]
replaycoding has joined #foot
replaycoding has quit [Remote host closed the connection]