st3r4g has quit [Quit: おやすみ]
ynakao has quit [Quit: WeeChat 3.3]
ynakao has joined #foot
ambasta has joined #foot
gtms has joined #foot
tsujp has joined #foot
ambasta has quit [*.net *.split]
rcf has quit [*.net *.split]
kmarius has quit [*.net *.split]
yyp has quit [*.net *.split]
benbrown has quit [*.net *.split]
ambasta has joined #foot
rcf has joined #foot
kmarius has joined #foot
yyp has joined #foot
benbrown has joined #foot
Arnavion[m] has left #foot [#foot]
ambasta has quit [Ping timeout: 252 seconds]
novakane has joined #foot
cbb has joined #foot
<
cbb>
dnkl: I was just reading keymap.h and was wondering what would cause the sequences under "DEFAULT_MODS_FOR_KP" to be emitted
<
cbb>
is it still possible to emit those?
<
dnkl>
cbb: yes; echo -e '\e[?1035l\e='
<
cbb>
Ah yeah, of course
<
cbb>
dnkl: I just noticed while I was reading it
<
cbb>
they kind of look like SS3 sequences
<
cbb>
but with muliple bytes
<
dnkl>
I think they are? I believe xterm documents them as such. But could remember wrong
<
cbb>
dnkl: I couldn't find them in the docs, but it does seem to emit the same sequences
<
cbb>
I was going to say they seem problematic for apps that parse input sequences according to ECMA-48
<
cbb>
but I guess it doesn't matter if they have to be requested first
<
cbb>
konsole does something similar for F1-F4
<
cbb>
...but by default
<
dnkl>
cbb: we also emit SS3-like escapes foot F1-F4. But only when unshifted. You mean konsole is doing something different?
<
cbb>
dnkl: yeah console emits sequences like \eO5P
<
cbb>
for F keys with modifiers
<
cbb>
I've been slowly converting the input parser in dte to parse sequence structurally like a client->terminal parser would
<
cbb>
but it's hard to know what to do with SS3 sequences with multiple bytes
<
cbb>
just special case them I guess
<
dnkl>
Not sure if xterm had changed recently, but I'm seeing it emit e.g \E3P for alt-F1, while we emit \E[1;3P
<
dnkl>
cbb: how common are the SS3 sequences for KP? I seem to remember them but being widely supported by terminals
<
cbb>
dnkl: the basic single-byte ones are quite common I think
<
cbb>
those ones are listed in the xterm docs
<
cbb>
I'm not sure about the multiple byte ones
<
cbb>
technically those aren't valid SS3 sequences according to the spec
<
cbb>
but then I'm not sure there really is any spec that applies to terminal->client sequences
<
dnkl>
At least none that I'm aware of...
<
cbb>
I just find it quite convenient that key sequences do conform to ECMA-48 99% of the time, because it makes writing a proper parser easier
<
cbb>
...and supporting the new kitty protocol pretty much requires a parser
<
cbb>
when all the extra modes are enabled
kmarius has joined #foot
novakane has quit [Ping timeout: 265 seconds]
kmarius has quit [Client Quit]
kmarius has joined #foot
ambasta has joined #foot
w0rm has joined #foot
cbb has quit [Quit: WeeChat 3.3]
tsujp has quit [Quit: Client closed]
gtms has quit [Remote host closed the connection]
cbb has joined #foot
cbb has quit [Ping timeout: 265 seconds]
novakane has joined #foot
cbb has joined #foot
cbb has quit [Client Quit]
Arnavion has quit [Quit: Arnavion]
Arnavion has joined #foot
Arnavion has quit [Client Quit]
Arnavion has joined #foot
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #foot
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #foot
novakane has quit [Quit: WeeChat 3.3]
diniwed has joined #foot
<
diniwed>
seems like I'm getting the wrong colours in GNU/screen ... e.g dark-blue is a very pale blue ... etc. colors are ok in tmux
<
diniwed>
know of a screen setting that might be causing this?
<
diniwed>
forgot to mention that I copied over my custom XTerm palette from .Xresources
<
diniwed>
... to .config/foot/foot.ini
diniwed has quit [Ping timeout: 246 seconds]
diniwed has joined #foot
ynakao has quit [Quit: WeeChat 3.3]
ynakao has joined #foot
hspak has joined #foot
diniwed has quit [Ping timeout: 265 seconds]
diniwed has joined #foot