<w0rm>
b) I don't presume to speak for the author but I'd guess unlikely - organizing windows is a job of a WM/Compositor
<ambasta>
Not outputs
<ambasta>
Unless you meant ctrl+shift+r , in which case searching and the searching previous with ctrl+r falls searches last instance of search term, followed by fallback to command history
<ambasta>
Ooh, did not realize I could use commands while in scrollback search mode
<ambasta>
I used to follow up ctrl + shift + r with search term and return key
<w0rm>
ambasta: I would not guess how your shortcuts are set up but generally speaking ctrl-r searches shell command history. Man 4 foot.ini has the correct default foot shortcut, guess the git README could use an update...
<ambasta>
The man page and README are both correct, I just didn't realize not to press "return/enter" after providing the search term
<ambasta>
Though it would be nice if the terminal did not exit scrollbar search mode w/o the same modifiers as used to enter it (like vim)
<w0rm>
ah, right "start a scrollback search" is higher up - ctrl-r is the binding within scrollback search
<dnkl>
ambasta: you can change the bindings for both starting and exciting scrollback search mode
<ambasta>
dnkl, thanks.. will do that! Can they share the same keybinds?
<dnkl>
ambasta: yes, because the "start" binding is defined in the normal key binding section, while the "exit" one is defined in the scrollback search section
<ambasta>
This is beautiful, just verified that it works perfectly
<ambasta>
Thank you w0rm, dnkl
<dnkl>
Regarding tabs, that's a no. There are no plans to implement that
<ambasta>
Yeah, what w0rm said made sense
<ambasta>
I'll try to figure out a way to create tab groups in my twm for terminal
novakane has joined #foot
ambasta_ has joined #foot
ambasta has quit [Ping timeout: 245 seconds]
ambasta_ is now known as ambasta
hill has quit [Remote host closed the connection]
dunc4nn[m] has joined #foot
<dunc4nn[m]>
hi, thanks for foot, great piece of software. Have two issues though. Wrapped lines dont get selected when double clicking and could not unbind control+Return. Any tips?
travankor has joined #foot
<dnkl>
dunc4nn[m]: wrapped lines _do_ get selected when double clicking. Make sure you're on the latest foot, not running tmux, screen, weechat or anything else that could be splitting up the lines.
<dnkl>
not sure what you mean by "unbind control+return"? It isn't bound in foot. We do however pass on an escape sequence, containing modifier info (in other words, foot does *not* pretend control+return is the same thing as a plain return). It may be that the application doesn't recognize that sequence. If this is indeed the case, it can usually be worked around by manually binding control+return in the
<dnkl>
affected application(s). This can be done in both bash and zsh, for example
<dunc4nn[m]>
I'm on latest foot, did a pgo build, does that matter? Shall I try without?
<dunc4nn[m]>
regarding control+return, I use zsh with vim keybinds. Pressing control+return exits insert mode and does increment, that translates to Esc + Ctrl-A in vim. If I do that over mosh session it prints ;5;13~, so looks like some sort of escape sequence indeed. This does not happen on alacritty
<dunc4nn[m]>
regarding control+return, I use zsh with vim keybinds. Pressing control+return exits insert mode and does increment, that translates to Esc + Ctrl-A in vim. If I do that over mosh session it prints ;5;13~, so looks like some sort of escape sequence indeed. This does not happen on alacritty
<dnkl>
dunc4nn[m]: no, pgo has nothing to do with this. Have you tried e.g echo:ing a very long line in a plain shell (no tmux etc), and then selecting it?
yyp has joined #foot
<dunc4nn[m]>
Sorry for spam, buggy matrix client :/
<dunc4nn[m]>
Echoing a very long line does indeed work, how does it differ from ie. dmesg or catting a file?
<dnkl>
dunc4nn[m]: alacritty maps control+return and return to the same escape sequence (meaning, it is impossible for any application to differentiate between the two)
<dunc4nn[m]>
Both scenarios in plain shell
<dnkl>
Cat:ing should work as well
<dnkl>
But any application that does soft line wrapping by itself will not work
<dunc4nn[m]>
Does alacritty do some magic around soft wrapping?
<dunc4nn[m]>
Many times I need to select long lines when compiling stuff, which does not seem to work.
<dunc4nn[m]>
Catting indeed works
<dnkl>
Not aware of any magic in alacritty. That said, the logic for determine whether a line is continued or not may still be different
<dnkl>
As for compiler output, I guess it depends on the build framework. Pretty sure raw gcc output will work
<bapt>
dnkl: would you accept freebsd support patches for yambar?
<dnkl>
bapt: sure
<bapt>
great, I ll consider adding it then
ambasta has quit [Remote host closed the connection]
<dnkl>
bapt: the base set of bsd patches for fnott, fuzzel and foot looked the same. Guessing yambar has the same issues...
<dunc4nn[m]>
@dnkl thanks for the help. I use these tools daily and selecting wrapped lines dont work with any of them: zig, dotnet, cargo and python-pip
<dunc4nn[m]>
As for the escape sequence, is it possible to change the behaviour of ctrl+return ?
<dunc4nn[m]>
Guess I could patch it for myself
<bapt>
dnkl: I am more in where to read the battery informations etc
<bapt>
I did the support for i3bar long ago
<dnkl>
dunc4nn[m]: sure, you can patch foot. I don't remember if control+return is defined in keymap.h, or handled run-time in input.c
<dnkl>
dunc4nn[m]: I guess it would be a good idea to say least try to figure out what's happening with those tools. I.e verify it is in fact soft line wrapping, and not something else.
<dnkl>
I don't use any of those on a daily basis
<dnkl>
But will try to remember to test them when I can find some time
<dunc4nn[m]>
How can I verify it's soft wrapping? Print raw input somehow?
<dunc4nn[m]>
Not familiar with terminal emulators :)
<dnkl>
dunc4nn[m]: it's a bit difficult. One way is to enable debug logging in vt.c, do a debug build and run "foot -d debug". But, might be more logging that has to be enabled.
<dnkl>
The goal would be to see if the application prints e.g. a "\n" I'm the middle of what you think is a long, continuous line
<dunc4nn[m]>
Commenting out the line I pasted previously fixed the ctrl+return, may I ask, what is the purpose of that escape sequence?
<dunc4nn[m]>
I'm gonna take a look at the debug build later
<dnkl>
dunc4nn[m]: same purpose as all other input escape sequences - it tells the application which key(s) were pressed. The '5' in the sequence indicates "control", and '13' is "\r" (i.e. carriage ret)
<dnkl>
dunc4nn[m]: I'm looking at pip right now, and it isn't obvious to me what's happening. It doesn't appear to emit any newlines, but I'll keep looking
<dnkl>
dunc4nn[m]: (and in case it isn't obvious - you need that escape sequence - for control+return - to be able to bind "return" and "control+return" to different actions in e.g. vim, emacs, or any other application)
<dunc4nn[m]>
Ah right, so the point is to pass that signal to terminal application and handle it there, allowing us to have more modifier + keybind combinations available for the application itself
<dnkl>
dunc4nn[m]: exactly
<dnkl>
dunc4nn[m]: btw, I think I
<dnkl>
I'm on to something
<dnkl>
wrt line selection
<dnkl>
triple-clicking to select a line, first involves a double-click, which selects the word under the cursor
<dnkl>
it appears that extending that word selection to a line selection fails
<dnkl>
echo and cat also fails, if the line-wrapping word is different from the initially selected word
<dunc4nn[m]>
Not sure if it's the irc bridge or my matrix client, but I see messages coming from IRC with a huge delay. Posted mine 02:01 and got yours after that with 01:58 timestamp
<dunc4nn[m]>
Ah right, so it might be a bug afterall?
<dnkl>
w0rm: I read their response to alacritty request, a long time ago. I don't have a link, but it basically came down to "can't you rename it to alacritty-color"
<dnkl>
ah, yup, that's the one
<w0rm>
well *direct* at least will make that work
<dnkl>
w0rm: the one I'm hoping we can remove at some point :D
<w0rm>
heh
<dnkl>
w0rm: I just do eval $(env TERM=xterm256-color dircolors) in my zshrc
<dnkl>
but it'd obviously be better if it just worked, out-of-the-box
<w0rm>
I mean - you have it in FAQ so not that big of a deal for people who can read
<bapt>
yeah I got backlight working and battery on yambar, audio will require a oss.c and network will be 100% different code
<lemontree>
when i press right-alt and q, my input is deleted in my shell. i don't want that. for similar things, i would bind such a keycombo to accept-line in my shell.
<lemontree>
and this works for instance with ctrl+return or something.
<lemontree>
however, when i use the suggested foot keybinding to find out what i have to put into the bindkey command (pressing ctrl+v, as suggested in the issue), it returns ^[q
<lemontree>
i think it doesn't recognize my right alt-key properly so it doesn't work
<lemontree>
^[ is ESC, but not right alt
<lemontree>
context for this question: i switch a lot between german and english keymaps, and in the german keymap, right alt and Q is @, so i use that regularly
<lemontree>
ah, i notice my question doesn't make much sense
<dnkl>
lemontree: ESC is how alt is encoded for many keys
yyp has quit [*.net *.split]
travankor has quit [*.net *.split]
kayw has quit [*.net *.split]
yyp has joined #foot
travankor has joined #foot
kayw has joined #foot
<lemontree>
dnkl: ah, thanks
hspak4 has joined #foot
ponky_ has joined #foot
Nulo_ has joined #foot
lemontre1 has joined #foot
Nulo has quit [Ping timeout: 265 seconds]
ponky has quit [Ping timeout: 265 seconds]
lemontree has quit [Ping timeout: 265 seconds]
hspak has quit [Ping timeout: 265 seconds]
lemontre1 has quit [Quit: WeeChat 3.1]
lemontree has joined #foot
sterni has quit [Ping timeout: 264 seconds]
V has quit [Ping timeout: 252 seconds]
V has joined #foot
sterni has joined #foot
st3r4g has joined #foot
novakane has quit [Quit: WeeChat 3.3]
cbb has joined #foot
<cbb>
dnkl: w0rm: you can work around the dircolors problem by just setting $LS_COLORS manually from your shell config
<cbb>
(after first checking if the terminal supports color)
<cbb>
that's what I do
<cbb>
...just check $COLORTERM, then $TERM (against a short list of known terminals) and fall back on `tput colors`