dnkl/foot
41
2.0k
Fork
You've already forked foot
243

**Feature request: built-in command completion notifications** #2390

Open
opened 2026年06月19日 15:05:13 +02:00 by Shyciii · 3 comments

Describe your feature request

Currently, foot's [bell] section correctly handles BEL-triggered notifications, but there is no built-in mechanism to detect when a shell command finishes and automatically fire a notification (or urgent hint).

To achieve this, users have to manually configure their shell to send a BEL character on each prompt — which requires either a PROMPT_COMMAND hack in bash, or a third-party library like bash-preexec to avoid conflicts with other tools that also use the DEBUG trap (e.g. oh-my-posh).

Ghostty handles this natively via its built-in shell integration: it detects command completion automatically and sends a desktop notification without any user-side shell configuration.

Proposed behavior:
An option (e.g. in [bell] or a new [shell-integration] section) to automatically send a desktop notification and/or set the urgent window hint when a command finishes — optionally only if the command ran longer than a configurable threshold (e.g. notify-after-seconds=5) and/or the window is not focused.

This would bring foot in line with what users expect from modern terminal emulators, and eliminate the need for fragile shell-side workarounds.

### Describe your feature request Currently, foot's `[bell]` section correctly handles BEL-triggered notifications, but there is no built-in mechanism to detect when a shell command finishes and automatically fire a notification (or urgent hint). To achieve this, users have to manually configure their shell to send a BEL character on each prompt — which requires either a `PROMPT_COMMAND` hack in bash, or a third-party library like `bash-preexec` to avoid conflicts with other tools that also use the `DEBUG` trap (e.g. oh-my-posh). Ghostty handles this natively via its built-in shell integration: it detects command completion automatically and sends a desktop notification without any user-side shell configuration. **Proposed behavior:** An option (e.g. in `[bell]` or a new `[shell-integration]` section) to automatically send a desktop notification and/or set the urgent window hint when a command finishes — optionally only if the command ran longer than a configurable threshold (e.g. `notify-after-seconds=5`) and/or the window is not focused. This would bring foot in line with what users expect from modern terminal emulators, and eliminate the need for fragile shell-side workarounds.
Owner
Copy link

Please don't use LLMs to write bug reports or feature requests. They're annoying to read and always full of made up half trues or straight up wrong.

Yes, making a shell emit bell and the end of a command requires setting e.g. PROMPT_COMMAND. But so does this so called "shell integration" it mentions (which I assume refers to the OSC-133 family). Neither bash nor zsh emit any OSC-133 sequences automatically, they need to be configured to do so. Guess how? By setting e.g. PROMPT_COMMAND.

That said, there is some merit to being able to emit notifications, or urgency, when we receive an OSC-133 command finished. Not because it's easier to configure the shell to emit this (compared to BEL), but because people often already have it configured.

So, I'm going to keep this open for a while, but on low priority. I'm still not fully convinced BEL isn't enough. And please, no more LLMs.

Please don't use LLMs to write bug reports or feature requests. They're annoying to read and always full of made up half trues or straight up wrong. Yes, making a shell emit bell and the end of a command requires setting e.g. `PROMPT_COMMAND`. But so does this so called "shell integration" it mentions (which I assume refers to the OSC-133 family). Neither bash nor zsh emit any OSC-133 sequences automatically, they need to be configured to do so. Guess how? By setting e.g. `PROMPT_COMMAND`. That said, there is some merit to being able to emit notifications, or urgency, when we receive an OSC-133 command finished. Not because it's easier to configure the shell to emit this (compared to BEL), but because people often already have it configured. So, I'm going to keep this open for a while, but on low priority. I'm still not fully convinced BEL isn't enough. And please, no more LLMs.
Author
Copy link

I'm sorry I used AI, but my English is limited, and it included my attempts into the code as well.
However, I couldn't find any instructions on what to put in bashrc if I want foot to work, so I had to use AI. I tried the code below. Do you think this is correct?

PS0+='${_foot_cmd_start:0:$((_foot_cmd_start=SECONDS,0))}'
_foot_bell() {
 local duration=$(( SECONDS - ${_foot_cmd_start:-$SECONDS} ))
 _foot_cmd_start=
 (( duration >= 5 )) && printf '\a'
}
PROMPT_COMMAND+=(_foot_bell)

But the reason I wrote this ticket is that I don’t use plain Bash (like most people, or those who use zsh), but rather oh-my-posh, which lets me customize the prompt within Bash. Oh-my-posh supports OSC-133 by default, but even when I enable it, foot can’t handle it. I found this on the oh-my-posh website; I don’t know if it will help you:
"enable shell integration using FinalTerm's OSC sequences. Works in bash, cmd (Clink v1.14.25+), fish, powershell and zsh"

What’s also interesting is that if I enable this shell integration in oh-my-posh but don’t add anything to my bashrc to handle jumping between prompts, then jumping between prompts works perfectly. So foot can interpret this from oh-my-posh, but it can’t handle the bell signal. That’s why I thought it would be nice if foot could handle this as well. If you feel that this isn’t foot’s job, but rather that oh-my-posh, then I’ll close this ticket.

I'm sorry I used AI, but my English is limited, and it included my attempts into the code as well. However, I couldn't find any instructions on what to put in `bashrc` if I want `foot` to work, so I had to use AI. I tried the code below. Do you think this is correct? ``` PS0+='${_foot_cmd_start:0:$((_foot_cmd_start=SECONDS,0))}' _foot_bell() { local duration=$(( SECONDS - ${_foot_cmd_start:-$SECONDS} )) _foot_cmd_start= (( duration >= 5 )) && printf '\a' } PROMPT_COMMAND+=(_foot_bell) ``` But the reason I wrote this ticket is that I don’t use plain Bash (like most people, or those who use zsh), but rather oh-my-posh, which lets me customize the prompt within Bash. Oh-my-posh supports OSC-133 by default, but even when I enable it, foot can’t handle it. I found this on the oh-my-posh website; I don’t know if it will help you: "enable shell integration using FinalTerm's OSC sequences. Works in bash, cmd (Clink v1.14.25+), fish, powershell and zsh" What’s also interesting is that if I enable this shell integration in oh-my-posh but don’t add anything to my bashrc to handle jumping between prompts, then jumping between prompts works perfectly. So foot can interpret this from oh-my-posh, but it can’t handle the bell signal. That’s why I thought it would be nice if `foot` could handle this as well. If you feel that this isn’t `foot`’s job, but rather that `oh-my-posh`, then I’ll close this ticket.
Owner
Copy link

"enable shell integration using FinalTerm's OSC sequences. Works in bash, cmd (Clink v1.14.25+), fish, powershell and zsh"

OSC-133 doesn't define any bell, urgency or notification system. They are merely a set of escape sequences to let the terminal emulator know where a shell prompt is, where program output starts and ends. That's it. What the terminal does with that is up to the terminal.

Foot currently uses the prompt markers for its prompt-jumping feature. It uses the program output start/end markers for its pipe-command-output key binding.

Foot currently does not use the markers to implement bell, urgency or notifications. But it could. That's why I said:

That said, there is some merit to being able to emit notifications, or urgency, when we receive an OSC-133 command finished. Not because it's easier to configure the shell to emit this (compared to BEL), but because people often already have it configured.

So, I'm going to keep this open for a while, but on low priority. I'm still not fully convinced BEL isn't enough. And please, no more LLMs.

> "enable shell integration using FinalTerm's OSC sequences. Works in bash, cmd (Clink v1.14.25+), fish, powershell and zsh" OSC-133 doesn't define any bell, urgency or notification system. They are merely a set of escape sequences to let the terminal emulator know where a shell prompt is, where program output starts and ends. That's it. What the terminal _does_ with that is up to the terminal. Foot currently uses the prompt markers for its prompt-jumping feature. It uses the program output start/end markers for its `pipe-command-output` key binding. Foot currently does _not_ use the markers to implement bell, urgency or notifications. But it _could_. That's why I said: > That said, there is some merit to being able to emit notifications, or urgency, when we receive an OSC-133 command finished. Not because it's easier to configure the shell to emit this (compared to BEL), but because people often already have it configured. > > So, I'm going to keep this open for a while, but on low priority. I'm still not fully convinced BEL isn't enough. And please, no more LLMs.
Sign in to join this conversation.
No Branch/Tag specified
master
osc-5522
sixel-heap-buffer-overflow
releases/1.27
releases/1.26
releases/1.25
releases/1.24
multi-cursor
releases/1.23
pixman-16f-2
releases/1.22
releases/1.21
releases/1.20
releases/1.19
releases/1.18
releases/1.17
releases/1.16
releases/1.15
releases/1.14
releases/1.13
releases/1.12
releases/1.11
releases/1.10
releases/1.9
releases/1.8
releases/1.7
releases/1.6
releases/1.5
releases/1.4
releases/1.3
releases/1.2
releases/1.1
releases/1.0
1.27.0
1.26.1
1.26.0
1.25.0
1.24.0
1.23.1
1.23.0
1.22.3
1.22.2
1.22.1
1.22.0
1.21.0
1.20.2
1.20.1
1.20.0
1.19.0
1.18.1
1.18.0
1.17.2
1.17.1
1.17.0
1.16.2
1.16.1
1.16.0
1.15.3
1.15.2
1.15.1
1.15.0
1.14.0
1.13.1
1.13.0
1.12.1
1.12.0
1.11.0
1.10.3
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.2
1.8.1
1.8.0
1.7.2
1.7.1
1.7.0
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.0
1.2.3
1.2.2
1.2.1
1.2.0
1.1.0
1.0.0
0.9.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/foot#2390
Reference in a new issue
dnkl/foot
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?