[Proposal] Buitin support for `Integrated Terminal`

[hh9527]

Nowadays, I switch to helix + Zellij (a modern tmux alternative) + Alacritty, the combo are very powerful.

But sometimes, I miss the time when I was using vscode (with vim extension). The Integrated Terminal feature is very useful.

What if we got an Integrated Terminal feature inside helix?

• Unconflicted key combo (think about this: ctrl-r/ctrl-n both used in zellij & helix
• Unified pane/tab resize & other management functions
• Share same clipboard
• Easy history management of command line
• Persistentable pane layout (via $workspace/.helix/layout-config)

[David-Else]

Seems like a lot of effort for little gain. Surely it is the job of your terminal to be your terminal? Adding another terminal inside Helix seems a bit much. If your terminal software has Window management and tabs (like kitty) then you can do what you want? In kitty I just write little bash scripts to open workspaces setup how I want them.

I think I am the wrong audience for this, I tried tmux for a while and hated it, seems like a pointless idea. Remembering SSH sessions was cool, but why not just use a better terminal that does what you want? The author of Kitty has some good points on tmux and clones https://github.com/kovidgoyal/kitty/issues/391#issuecomment-638320745

Sorry to sound negative, if people want it then go for it! I just thought I would chime in with my personal opinion, people will have different views I am sure.

[andreytkachenko]

Neovim has integrated terminal and it is super useful to me both in toggle and float modes. It seems to me a good approach is not depend on some GUI terminal application (like kitty) and have everything you got used to have and do in any terminal emulator.

[hh9527]

Neovim has integrated terminal and it is super useful to me both in toggle and float modes. It seems to me a good approach is not depend on some GUI terminal application (like kitty) and have everything you got used to have and do in any terminal emulator.

Yes, I do agree. I want integrated terminal too.

and @David-Else somehow, I agree with you about terminal multiplexer is hacky, so I don't want a tmux, nor zellij, I need an integrated terminal to play a role to support multi-pane/tab inside helix.

[kirawi]

This was discussed in the past on Matrix and there seems to be a desire to implement it, but it's pretty complicated and would take a lot of work.

[archseer]

A fully functioning xterm environment is a lot of work and slightly inefficient as pointed out by the comment above, we need to re-parse all possible terminal escape sequences and reinterpret them (https://github.com/alacritty/vte can help but that's just the parsing bits).

You're essentially building a virtual terminal that renders to a part of the application. It would be about as much work as rebuilding tmux/zellij in helix.

I'd be interested in a proposal/experiment that implements this but I don't intend to work on this feature any time soon: personally I just always use tmux so I don't have a lot of motivation to focus on this.

[andreytkachenko]

There is implemented terminal which can be included (with some code reduction, like vi mode etc.) - https://github.com/alacritty/alacritty/tree/master/alacritty_terminal

[n0s4]

This would probably be quick to be made as a plugin, whenever plugin support is complete. It'd be a reasonable compromise; keeping the core from bloat whilst the people that really want it can just install it.

[workingj]

maybe look in to guake (linux) and conemu (win), those are configurable as drop down (quake style) consoles, hidden and only a shortcut away. following you to the active workspace and your cursor with multiple displays. even working well with i3 quite awesome dev tools in my opinion :> Edit: forgot to mention split views and tabs..

[i3elj]

I have to say that what made me happy about helix was it's non-bloated build. Maybe adding a built-in terminal it's a bit too much. I understand that this feature is useful, but I agree with @David-Else

Surely it is the job of your terminal to be your terminal? Adding another terminal inside Helix seems a bit much.

I just wanted to leave my comment here for you guys think about

[hh9527]

If helix could work in client-server mode, each win/pane (include terminal) is a standalone client/process, share same server instance, same lsp server, same clipboard, and can communicate/cooperate with window manager(eg. wezterm) to provide interaction functions (eg. jumping to file, switching pane/tab). That would make sense, and no need for built-in terminals.

[adamkpickering]

I would really like this feature. This is the only thing that is keeping me from switching from neovim to helix.

I understand the argument that there are other tools that can be used to get helix and a terminal in the same window, but in different panes. This is very "Unix philosophy" thinking, and generally I'm a fan of it.

However, I want a setup that I can take to any OS, including config files, without having to worry about other tooling (as much as possible, since obviously LSP servers etc need to be installed separately). Recently I have had to do some dev work on Windows, and it has been impossible to bring the tmux + nvim setup I usually use on Linux to this environment. I have ended up setting neovim up with a toggle-able integrated terminal to fit this use case.

Also, an integrated terminal would be helpful once helix has a graphical mode. Without this, the user is left switching windows in order to get to a terminal - that seems like a bad user experience to me.

[premell]

I just want to quote a comment from the plugin discussion

I don't want to use anymore a text editor which relies for 95% on plugins to do the work. I think plugins, when overused like they are in Neovim world, are a total mess for the following reasons:

* UI/UX inconsistencies (between themselves and/or the editor)

* conflicting/overlapping features (between themselves and/or the editor)

* distribution and versioning problems (some plugins require the nightly version, some don't)

* a lot of copy/paste configuration that you see one time in your life and forget or don't understand anymore

* often are unreliable and become unmaintained or broken over time

To give plugins total freedom it's the easy path at first because you avoid the problem of designing a good set of APIs, but it's a road to hell.

One of my favorite things about Helix is that it includes quite a lot of functionality out of the box. One might see this as bloat, but honestly, something like vim feels way more bloated once you've added all plugins to achieve the same functionality. To have a terminal, fuzzy finder, file tree, lsp, snippets etc in vim it feels like something breaks every month.

I would guess around 80% of people want to have a integrated terminal (even if they dont use it all of the time). Also it is a standard feature in every modern editor, so I think it would be missed heavily by many people who use it daily.

[i3elj]

Is there anyone working on this? I would like to help if possible

[wojpawlik]

Could I configure fish to fg on ^Z? :think:

[txtyash]

Since adding a built-in terminal would be an overkill, resolving binding conflicts by looking at common applications would be a much better solution.

Zellij is obviously doing things right. Easier to press shortcuts instead of something like "Ctrl+Shift+`, etc. And it is modal so lesser area for conflicts. IG the problem lies in helix using the alt key as well. Super is left out which would be used by WMs.

Looking at all your points @hh9527:

• These conflicts can be resolved by helix. I think any editor should have the full privilege of using the very common "Ctrl" key. Helix should go easy on "Alt". This could be done by nesting bindings under leader like keys(match mode, space mode, etc.) Some people don't seem to like this idea tho.
• Zellij already seems to be a great option for that
• This doesn't seem like a problem to me. Copying to and from anything to anywhere seems easy.
• For things like this there could be scripts or plugins for integrations with terminals and external applications.
• This could be requested at zellij. Rusty applications like nushell, helix, zellij, alacritty, wezterm, etc. could have plugins and scripts to integrate with each other to do fancy stuff.

[kirawi]

Adding support for Windows to zellij might be a more straightforward path.

[txtyash]

Could I configure fish to fg on ^Z? :think:

I have the same binding

[dead10ck]

Personally I don't think this belongs in core. The Unix philosophy is not hard and fast, as I think many people who use helix agree, but an entire terminal emulator and a text editor are about as orthogonal in functionality as it gets. This is the definition of bloat.

[nezuo]

I don't use helix because it has no integrated terminal. I'm very attached to the vscode workflow where I press a hotkey to create a terminal in the directory I'm working in. I could possibly replicate this workflow using other tools but I'm not aware of them and it would be convenient if it was built in. I would be fine if it was plugin feature but that seems like it is a far ways off.

[ArikRahman]

I would be fine prefixing all my commands with a :sh but that doesn't work for programs needing input. The videos presented in the documentation are also unfriendly, regarding on how to debug, which seemed to require the use of tmux as well.

[xJonathanLEI]

If even vim has this feature, it's probably not much of a bloat IMO.

[xJonathanLEI]

Sorry for spamming this thread, but I see tmux being suggested here as an alternative so I just wanna add my two cents as a heavy tmux user. I do everything inside tmux. I just attach to the tmux session right after SSH-ing into the machine, as this allows me to pick up my work anytime from another device very easily.

Personally, using tmux just for getting a terminal doesn't really work for me, as I already use <PREFIX> l for quickly switching between workspaces. Using tmux for simulating an integrated terminal would mean much more effort when switching between the 2 workspaces I'm working on at the same time, cuz I'll now have to actually look up that workspace window (instead of reflexively hitting <PREFIX> l), and actually also attach to the other workspace's "terminal window" first, just to set that terminal window as the "last window" so that I can use <PREFIX> l for getting into the terminal of that target workspace later on.

(A possible workaround for this is to put each workspace inside a tmux session instead of window, and use <PREFIX> L to switch between workspaces instead. However, this just throws the issue one level up and heavy users of tmux sessions are still screwed...)

That said, the neovim integrated terminal is far from perfect, and I actually indeed use tmux "just" for getting a terminal when I need to use it seriously. However, sometimes I just want to run a quick command (e.g. cargo clippy), and a quick and dirty terminal inside of the editor is very helpful without messing up my tmux window history.

[Bugbert]

Is there any idea on how this could be implemented? I was thinking it might be possible to use a pseudo terminal crate like portable-pty, turn it into a Document and use helix-veiw to display it.

[adambubenicek]

I would like to +1 @hh9527 comment - a client-server architecture would allow users seamlessly switch between helix and terminal windows. I think Kakoune has done this right:

With Kakoune, you can collaboratively edit the same file: all new windows created by the editor are clients, and can simultaneously modify the content of a file. As such, windows are fully under the control of your X11 window manager or can be managed in a single terminal through Kakoune's tmux support. - https://kakoune.org/

Because of this, they don't have to implement a full blown terminal emulator or even a window manager. All while users can move between their editor and terminal (and, of course, any other application like a web browser) with a single set of shortcuts.

[theaungmyatmoe]

+1 for that feature cuz it can be speed up my workflow out of the box.

[I60R]

I use neovim as terminal multiplexer in alacritty and it's very convenient. Why do I need tmux?

Also, integrated terminal could be reused to make text editor work as pager. Why do i need less?

[lukepighetti]

I don't think we should have an integrated terminal in Helix. There are too many good multiplexers out there. I see no point in adding the complexity to core.

[xJonathanLEI]

There are too many good multiplexers out there.

I use tmux and zellij a lot but I still want the integrated terminal.

IMO the point of an integrated terminal is that it's, well, integrated. It's not meant to be just another terminal.

For example, I can run a linter, get some warnings with file paths and line numbers. Then focus on the path, press gf and I get a buffer opened for that file (and even exactly at that line). This is not something a multiplexer can do. And this is just one example.

[ksandvik]

:sh that returns all the output to a scratch buffer, instead of the popup, ex sh cargo run, any interactivity is missing but at least unit tests and print output is shown. That might cover 80% of terminal needs. If the output is formatted like nushell, i.e structured return values, JSON and so on, even better. Then this could be handled intelligently by other helix core functions.

[lukepighetti]

There are too many good multiplexers out there.

I use tmux and zellij a lot but I still want the integrated terminal.

IMO the point of an integrated terminal is that it's, well, integrated. It's not meant to be just another terminal.

For example, I can run a linter, get some warnings with file paths and line numbers. Then focus on the path, press gf and I get a buffer opened for that file (and even exactly at that line). This is not something a multiplexer can do. And this is just one example.

Having trouble understanding your point. To me this feels like a use case for copying a linter warning file path and line number to system clipboard so it can be used outside Helix. But if there's a specific flow you can share to help me understand I would appreciate it.

[RomeoV]

Chiming in to mention that I love an integrated terminal in order to easily run a REPL. In Neovim, I like to open a terminal split and run a REPL there (say Python, Julia, etc.) Then I visual select some code, and use the NeoTerm plugin to paste the selection straight into the terminal/REPL. This is a very (for me) productive workflow, that seems to not be possible in helix.

[archseer]

There's a prototype PR draft so I don't think we need more convincing :) https://github.com/helix-editor/helix/pull/4649

Then I visual select some code, and use the NeoTerm plugin to paste the selection straight into the terminal/REPL.

You could use tmux splits, then space y / space p the code between the repl and the editor

[goyalyashpal]

• Issue for Server-Client thing: #312

[debajyoti1990]

As a windows user, even I too think integrated terminal is not much worthy. Windows terminal will let you use tabs and splits. So for running code / REPL sort of things are easily addressed. Integrated terminal must be in the core if we ever get a GUI application in future.

[goyalyashpal]

Integrated terminal must be in the core if we ever get a GUI application in future.

u mean core as in

• technical name - i.e. helix-core (the designated part/area of helix) or
• general daily usage core - i.e. just inbuilt

[debajyoti1990]

Integrated terminal must be in the core if we ever get a GUI application in future.

u mean core as in technical name helix-core (the designated part of helix) or general core (i.e. just inbuilt)

I meant general core.

[nathan-at-least]

It seems clear from the discussion here that there are different groups of users with different environments and needs.

I'm in the tmux camp (and I'm zellij-curious). I always run hx within tmux. In fact, 99% of the terminals I ever open are running tmux. Because of this, reproducing the same functionality within hx has no appeal for me.

But, I can understand how users who don't use tmux or just a terminal with panes (like @david-else w/ kitty) would have this need. So… why not use tmux or zellij or kitty or some tool that provides exactly what you need?

For the record, I use a separate tmux session for every project I'm hacking on, and hx is in one of the screens. The sessions are started in the project directory, so if I need a new terminal in the project directory, it's a single tmux command. tmux can do pane layout, so I can show both hx and an interactive terminal session on the same screen. Since each project has a tmux session and I can close terminals and reattach later, or switch to different project sessions and the state (such as current directory) are specific to that project.

I simply can't see how hx could hope to reproduce all of that functionality. Would hx terminal support have sessions? Reattachment? Pane layouts? What would all the keybinds be? If it did have that functionality, what would I do if I needed that kind of functionality but I don't want to edit files (or run LSPs, etc…)? Then I'd have to reach for something like tmux anyway.

So, I'm firmly in the anti-terminal emulator camp, because I already have a tool that does this for me.

[ArikRahman]

I changed my mind on the topic, coming into ZelliJ. Realizing terminal functionality is a lot trickier to implement, especially one comparable with zellij, I've come to the conclusion that Helix has better things to worry about.

[quantonganh]

Although I like the Zellij's floating panes feature, I don't want to nest one more layer in my terminal. So, here's how I integrated WezTerm into Helix:

Firstly, I created a script to split WezTerm:

wezterm-split-pane.sh:

#!/bin/sh

pane_id=$(wezterm cli get-pane-direction down)
if [ -z "${pane_id}" ]; then
  pane_id=$(wezterm cli split-pane)
fi

wezterm cli activate-pane-direction --pane-id $pane_id down

Secondly, to run code in the newly created pane:

run.sh:

#!/bin/sh

source wezterm-split-pane.sh

program=$(wezterm cli list | awk -v pane_id="$pane_id" '$3==pane_id { print $6 }')
if [ "$program" = "lazygit" ]; then
  echo "q" | wezterm cli send-text --pane-id $pane_id --no-paste
fi

filename="$1"
basedir=$(dirname "$filename")
basename=$(basename "$filename")
basename_without_extension="${basename%.*}"
extension="${filename##*.}"

case "$extension" in
  "c")
    run_command="clang -lcmocka -lmpfr -Wall -O3 $filename -o $basedir/$basename_without_extension && $basedir/$basename_without_extension"
    ;;
  "go")
    run_command="go run $filename"
    ;;
  "scm"|"rkt")
    run_command="racket $filename"
    ;;
esac

echo "${run_command}" | wezterm cli send-text --pane-id $pane_id --no-paste
# wezterm cli activate-pane-direction up

And finally, I just added the following into the Helix config file (need this PR to expand filename):

[keys.normal.";"]
r = ":sh run.sh %val{filename} > /tmp/run.log 2>&1"

Now, I only need to press ;, followed by r to run my code.

For example, I can run a linter, get some warnings with file paths and line numbers. Then focus on the path, press gf and I get a buffer opened for that file (and even exactly at that line). This is not something a multiplexer can do. And this is just one example.

@xJonathanLEI WezTerm can do that:

• Turn your local file path into hyperlink:

config.hyperlink_rules = wezterm.default_hyperlink_rules()

table.insert(config.hyperlink_rules, {
  regex = '^/[^/\r\n]+(?:/[^/\r\n]+)*:\\d+:\\d+',
  format = "$0",
})

• Open your file in Helix pane:

wezterm.on('open-uri', function(window, pane, uri)
  local user = os.getenv('USER')
  local start, _ = string.find(uri, '/Users/' .. user)
  if start == 1 then
    local direction = 'Up'
    local hx_pane = pane:tab():get_pane_direction(direction)
    if hx_pane == nil then
      local action = wezterm.action{
        SplitPane={
          direction = direction,
          command = { args = { 'hx', uri } }
        };
      };
      window:perform_action(action, pane);
    else
      local action = wezterm.action.SendString(':open ' .. uri .. '\r\n')
      window:perform_action(action, hx_pane);
    end
    -- prevent the default action from opening in a browser
    return false
  end
  -- otherwise, by not specifying a return value, we allow later
  -- handlers and ultimately the default action to caused the
  -- URI to be opened in the browser
end)

[t-cadet]

I think the real benefit of having a terminal in the editor is to be able to use all of the editor's actions & movements in the terminal.

Writing a small bash script and tweaking Helix's config, we can cover most of the above use case. Here is the result:

https://github.com/helix-editor/helix/assets/33122682/1a87227f-87f5-4f2f-8626-7f657f4695d8

Bash script

export TERM=xterm # disable color
export PAGER=""

if [ -e ~/.config/helix/exec.env ]; then
  source ~/.config/helix/exec.env 2> /dev/null
fi

if [ -e "$PWD" ]; then
  cd "$PWD"
else
  PWD=$(pwd)
fi

stdin=$(cat)
echo "$stdin"
echo
eval "$stdin"
echo '['"$PWD"']$'

env > ~/.config/helix/exec.env 2>/dev/null

Helix config:

[keys.insert]
C-t = ["extend_to_line_bounds", ":pipe sh ~/.config/helix/exec.sh 2>&1", "normal_mode", "open_below"]

[keys.normal]
C-t = ["extend_to_line_bounds", ":pipe sh ~/.config/helix/exec.sh 2>&1"]

[keys.select]
C-t = [":pipe sh ~/.config/helix/exec.sh 2>&1"]

This simple solution has issues, e.g. it isn't really interactive but just reports the output when the command ends, and it probably has a lot of other quirks (use at your own risk).

However in practice I find most shell commands end quickly so it's not much of an issue and the workflow seems "good enough" to be useful.

Reading through the thread it is not clear this proposition intends to enable Helix's movements & actions in the terminal, but I hope this is where it is headed.

Also (I am new to the topic but) rather than embedding a terminal in Helix, isn't possible to reuse Helix's parent terminal to execute commands and plug on its inputs/outputs?

PS: I couldn't map command execution on enter as I initially wanted (this would be annoying when typing text in insert mode in other buffers) which is slightly confusing. If anyone knows how to remap shortcuts on one buffer only I am interested.

[gerion0]

Like already said here a few times, I think the real benefit of an integrated shell in comparison to a terminal multiplexer is an understanding of the editor for shell concepts:

• Similar to Kitty: Understand which of the lines is a prompt and which of the lines is output. This gives a few possibilities:
  • Jump with hotkeys between prompts (extremely useful for longer compilation commands with lots of output)
  • Special for Helix: Provide selections of the prompt and command output together with a hotkey to switch between them/select the next one (this can be even more finegrained in the prompt: abbility to select the prompt, the command, and the command output)
• Much more advanced: Input and edit shell commands transparently with Helix (often, terminals have some kind of Emacs/Vim mode but a native „Helix mode“ would be awesome of course.

This way, a user can scroll much more comfortable within the terminal and is able to select (and copy) conceptually belonging parts really fast (into a new buffer for example).

More interpretation is possible:

• Detection of paths within the command output and a hotkey to open this file in a new buffer.
  • This can be extended with a detection of a path + line (like a compiler often outputs) to open a buffer directly there.
• Interpretation of the command output for selected commands (maybe, here a plugin would be more suited).
  • One example would be a single compiler command in a ninja or make output (an actual use case for me for example, since I regularly copy a multi line compiler command into an editor buffer to split after space and be able to analyse the compiler flags)
  • Another example would be an output like the one of ripgrep/silversearcher/git grep/grep.

To prevent editorception, it would also be really handy, when a call of hx some/file would open the file in a new buffer of the editor itself and not in an editor within the editor.

Edit: I forgot: Open something in a helix buffer does not only affect calling hx directly but also every invocation of $EDITOR (like git commit) and should also be helpful for all usages of a pager (using terminal commands like less, man, systemctl status, ...)

[willelind]

After reading this thread I am surprised to see no one mention the ability to have all of your normal text manipulation bindings from the editor while still in the terminal. Extremely nice feature in my opinion.

And I also agree with the one commenter above that an integrated terminal avoids duplicated keybindings. Sure, you can rebind your multiplexer to not use the same keys for creating split windows as your editor, but you would still need to remember both keymaps and switch between them. It's vastly more efficient (from a keymap perspective) to have all of your keybindings inside the editor.

[luccahuguet]

hi, yazelix guy here

yazelix is a glorified config (that wanted to be a plugin) and it stabs at

• filetree
• unconflited keybindings between zellij and helix (https://github.com/luccahuguet/zellij?tab=readme-ov-file#keybinding-remaps)

Helix is nearing a plugin system release and Yazelix will change to accommodate that.

• Since we're getting a file tree plugin, yazelix will remove the yazi sidebar (yazi is a rust-written powerful TUI file-explorer) and instead offer yazi as an opt-out zellij swap layout that shows yazi as a single pane (or remove it entirely)
• of course, if more zellij keybinding conflicts arise, yazelix will keep solving them (things could become easier with https://github.com/zellij-org/zellij/issues/735)
• I've remapped things from the zellij side, because learning to use a modal editor (with the default keybindings) is hard enough 🤣

I probably won´t be writing any plugins myself but Yazelix is happy to work with or as part of file-tree helix plugins or integrated terminal plugins that arise

The important thing here is that everything works together nicely and integrated

[DaniD3v]

I really like jetbrains "Run Configurations", where I just need to press Ctrl-F10 and my projects gets run/tested and with Ctrl-F9 I can even bring up the debugger automatically.

That would honestly be my main use of a built in terminal. I could do something like this

Having the terminal directly in the editor would allow e.g. jumping to file specified in the terminal output (see my cursor at the screenshot). Pressing gf on cargo output and going to the right file automatically sounds pretty nice.

I don't really know a lot about lsps or ansi escape codes but wouldn't it be possible to write an lsp that highlights ansi escape codes? If that wouldn't be possible with the current lsp protocol I'm sure we could just add a small extension.

That way we don't have to mess with the core code of helix + people that don't want the bloat could just not install the ansi-lsp.

That'd also allow us to write custom lsps for command line output. goto definition could work when cargo test fails running a test function. Not sure if that is really feasible considering how specific to programming languages the lsp protocol is.

[ondrej-ivanko]

Combining zellij with helix pretty much solves any issues regarding the terminal. Multiple tabs and popup panes(especially that) does solve all my concerns. Floating panes also allows automatic commands to be run.

[adriangalilea]

Combining zellij with helix pretty much solves any issues regarding the terminal. Multiple tabs and popup panes(especially that) does solve all my concerns. Floating panes also allows automatic commands to be run.

I disagree, it's still fragmented, buffers are different, edits on one pane need to be reloaded in the other one and so on. It seems good at first but you realise that it falls short and create other kinds of annoyances.

[ondrej-ivanko]

I disagree, it's still fragmented, buffers are different, edits on one pane need to be reloaded in the other one and so on. It seems good at first but you realise that it falls short and create other kinds of annoyances.

Have you tried Ctrl-t-s for complete tab synchronization and than splitting it to multiple panes? Than you can make changes in all panes/buffers at the same time. Hopefully that's the usecase you're looking for.

This setup can be built with customized layout and run on every zellij/shell startup.

[TornaxO7]

I really like jetbrains "Run Configurations", where I just need to press Ctrl-F10 and my projects gets run/tested and with Ctrl-F9 I can even bring up the debugger automatically.

That would honestly be my main use of a built in terminal. I could do something like this

Having the terminal directly in the editor would allow e.g. jumping to file specified in the terminal output (see my cursor at the screenshot). Pressing gf on cargo output and going to the right file automatically sounds pretty nice.

I don't really know a lot about lsps or ansi escape codes but wouldn't it be possible to write an lsp that highlights ansi escape codes? If that wouldn't be possible with the current lsp protocol I'm sure we could just add a small extension.

That way we don't have to mess with the core code of helix + people that don't want the bloat could just not install the ansi-lsp.

That'd also allow us to write custom lsps for command line output. goto definition could work when cargo test fails running a test function. Not sure if that is really feasible considering how specific to programming languages the lsp protocol is.

I've that in my workflow with zellij included:

You just need the EditScrollback action.

[gerion0]

This is a good starting point, but Helix is not able to understand the scrollback, isn't it? So it does not get that "helix-term/src/commands.rs:104" does point to a line of the file that is opened on the left and it could directly jump there (additionally, the two Helix instances do not talk to each other).

Does zellij opens the whole scrollback in Helix or just the last command output (so is zellij able to interpret the prompt)? For example for C++ compiler output, it is a good rule of thumb to just handle the first error message given by the compiler so one need to jump the last prompt and scroll down from there on. Helix shouldn't be able to interpret the prompt, so the whole scrollback is only partially helpful here.

[TornaxO7]

This is a good starting point, but Helix is not able to understand the scrollback, isn't it?

Yes.

So it does not get that "helix-term/src/commands.rs:104" does point to a line of the file that is opened on the left and it could directly jump there (additionally, the two Helix instances do not talk to each other).

No, but I don't mind. I just switch back to helix and open up the picker and go to the given line number.