Work-In-Progress: Integrated Terminal ⚙

[ryanabx]

This PR is a work-in-progress! Give it a whirl if you feel adventurous ;)

Resolves: #1976

This PR was inspired by the discussion in the issue above.

Why an integrated terminal? Why not Tmux/Zellij/?

• Windows support (Tmux and zellij don't support windows, and as I found out looking at zellij implementation would be very difficult)
• Integrated terminals are more accessible to users (No need to install and configure a terminal multiplexer)
• We can do further things like "clicking" (via keyboard or mouse) links to files in terminal output and jumping to that file.

Progress so far:
Screencast_20251026_224808.webm

What's left to work on?

• Initial PTY handling
• Split out relevant crates for helix-integrated-terminal to use (so helix-view doesn't have a cyclic dependency on helix-integrated-terminal
• Wire in basic keyboard input support
• Full Mouse support (so far scolling is implemented)
• Clipboard support
• Fix rendering glitches with the terminal
• Either make the terminal a pop-up (easy), or investigate embedding it into a View (hard)
• Finalize keybindings
• Cleanup

Feel free to contribute to the branch!

[ryanabx]

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

[gyreas]

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

all views are splittable: https://github.com/helix-editor/helix/blob/master/docs%2Farchitecture.md, so yeah it makes sense

[ryanabx]

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

all views are splittable: https://github.com/helix-editor/helix/blob/master/docs%2Farchitecture.md, so yeah it makes sense

It makes sense to me, but a lot of the View code is inherently tied to Documents, including several macros. It can definitely be rewritten, but that'd make the PR touch a lot more stuff, and the maintainers may not like the direction that would take it. Just didn't want to work on that unless it seems like a good direction 🤷

[ryanabx]

Everything seems to expect views to be attached to documents, sadly. This makes it very difficult to make use of the existing view logic.

For example, after updating the macros to return options to conditionally give a view and document only if they are of type View::Document, and after fixing about 100 errors to presumably get rust-analyzer to the next step of error reporting. I get this beautiful number of errors.

Maybe the Document structure is what should be updated instead. Looking at that next

[AbeEstrada]

I have a genuine question.

What are the benefits of integrating a terminal into Helix?

When you can take advantage of the multiplexer that several terminals offer, or even tmux

helix.mp4

[ryanabx]

I have a genuine question.

What are the benefits of integrating a terminal into Helix?

When you can take advantage of the multiplexer that several terminals offer, or even tmux

That's a fine question. The main benefit for me is windows support. Zellij and tmux don't support windows (except in WSL). Also, having the terminal integrated allows us to do some cool stuff in the future like CTRL+Clicking a file link in an failed compilation to go to the file, line and col that the error references.

[kiki-ala]

I don't think this makes sense or is needed
Clicking? This is helix...?

[ryanabx]

I don't think this makes sense or is needed Clicking? This is helix...?

There has historically been an interest in this feature, as can be found here.

I also have been interested in this feature for a while, so I decided to do some work to adapt the original PoC.

[wasinski]

I'd love to have "clickable" (by keyboard) file links!

[gyreas]

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

what do you think about making View a trait and have the current implementation be DocumentView? Consider also a ViewController that handles events and data to View

but I'm afraid this will touch a lot of code, so it's better as a separate PR because for example, plugins may one day want to support views that aren't attached to a document

[ryanabx]

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

what do you think about making View a trait and have the current implementation be DocumentView? Consider also a ViewController that handles events and data to View

but I'm afraid this will touch a lot of code, so it's better as a separate PR because for example, plugins may one day want to support views that aren't attached to a document

View could be a trait or enum, I don't mind either of those. I would like approval from a maintainer that it'd be a good idea before I put in the work.

Also, some ideas on what to do about all the code that expects a view to always have a document would be nice. There are several macros that are used all around helix that would have to be updated. What's the cleanest way to decouple all this?

cc: @the-mikedavis

Also worth considering is a generic of some kind. I think the problem with traits is that if we don't redo the order of things (aka a document has a view, not the other way around), we end up with functions on the view that aren't usable without downcasting.

[NSPC911]

I can vouch for the Windows support. I have been stuck on Windows due to a multitude of reasons, but an issue I kept facing is a toggleable terminal. Wezterm does handle most of my multiplexing needs, aside from a popup terminal, or a toggleable terminal. I will try to get this running on my fork maybe this week, I have way too much PRs merged there 😅

[ryanabx]

I can vouch for the Windows support. I have been stuck on Windows due to a multitude of reasons, but an issue I kept facing is a toggleable terminal. Wezterm does handle most of my multiplexing needs, aside from a popup terminal, or a toggleable terminal. I will try to get this running on my fork maybe this week, I have way too much PRs merged there 😅

If you bring it in as-is, just a reminder you'll need to set the SHELL environment variable to the path to PowerShell. I haven't gotten around to handling how it will be configured other than that yet.

Also there are rendering glitches and stuff, but please don't hesitate to provide feedback! :)

[jarjk]

there's a plugin for this already at https://github.com/mattwparas/steel-pty, might be worth checking out

[NSPC911]

I did check out the plugin.

[ryanabx]

I'm to the point in developing this where I feel like I need some direction from the maintainers, on whether this is actually wanted. If so, there are some design details we have to hash out. I don't want to put more work into this for nothing, if it won't get accepted upstream.

I don't particularly care about the plugin branch, nor do I want to use plugins. I prefer stock Helix. It wouldn't be the end of the world for me if this were not something wanted in Helix though. I'd probably just gravitate toward an editor that has an integrated terminal.

If we do want this upstream, the big question that would guide the direction of this PR is how we should present the terminal to the user?

• Should it be a pop-up, like the file explorer/browser? (Probably the easiest switch)
• Should it remain its own thing on the bottom half of the screen? (Current impl)
• Should it be integrated with Views? I think this would be the fanciest but also by far the most involved, which is why I wouldn't want to do anything on that unless the maintainers think it's a good idea.
• Or any other thing we can think of

There's also smaller details like how we want the UX to look for handling multiple terminals, modes for the terminal (INS, NOR, etc) and other stuff.

In order to make this PR actually appealing to upstream, I need to know these things before I put more work into it.

Thanks! :)

[gyreas]

I think you'll need to be a bit more patient on this. You might want to chat them up on matrix, there's higher chance of getting a response there.

I'm to the point in developing this where I feel like I need some direction from the maintainers, on whether this is actually wanted. If so, there are some design details we have to hash out. I don't want to put more work into this for nothing, if it won't get accepted upstream.

I think the bottom half placement is not a bad idea. A seperate PR can deal with other augmentations.

• Should it be a pop-up, like the file explorer/browser? (Probably the easiest switch)
• Should it remain its own thing on the bottom half of the screen? (Current impl)

• I'm not sure about the multiple terminals tho, but it'll certainly require a terminal manager of sorts.
• Using modes for the terminal is great too, IDEs tend to get this wrong since they forward keystrokes directly to the terminal so there tend to be a clash of keys at some point.

There's also smaller details like how we want the UX to look for handling multiple terminals, modes for the terminal (INS, NOR, etc) and other stuff.

[ryanabx]

I think you'll need to be a bit more patient on this. You might want to chat them up on matrix, there's higher chance of getting a response there.

Sure, I apologize if I sound impatient, I don't mind waiting for a response. I just don't want to go in a certain design direction and find out it would have been done completely different if the maintainers were involved.

I should ask on Matrix, but I didn't want to be a bother for the maintainers, I figured if the discussion were self-contained here, responses could come in whenever the maintainers have time. I'll send a message later today after work, to gather ideas and feedback 😅

I think the bottom half placement is not a bad idea. A seperate PR can deal with other augmentations.

I'm not sure about the multiple terminals tho, but it'll certainly require a terminal manager of sorts.
Using modes for the terminal is great too, IDEs tend to get this wrong since they forward keystrokes directly to the terminal so there tend to be a clash of keys at some point.

Yeah, the current impl looks something like this:

The faux "status-line" should probably be moved to the bottom, but basically it has tabs for each PTY spawned. There's a basic modal setup as well, with these keybinds:

• esc - Go from INS to NOR mode, or if in NOR mode, hide the terminal view.
• i - Go from NOR to INS mode
• left | h - Go to the tab to the left
• right | l - Go to the tab to the right
• n - Create a new PTY
• d - Delete the currently selected PTY. If all PTYs are deleted, the terminal view toggles itself off

Notably, there's no way to use esc in the terminal yet. The keybinds are just temporary for now.

Also, space-t is the current keybind to open the terminal view.

Thanks so much for the feedback by the way!

[the-mikedavis]

I don't have the review bandwidth for a change of this size, especially with the current size of the backlog. I'm also not super attached to the feature - I was not a huge fan of the embedded terminal in Vim and it brings in a lot of deps and changes. It may be better for the terminal to start as a plugin and become a core piece in the long run. So I'm not saying no to this feature out-right, just that I won't be able to commit the necessary effort to reviewing or guiding it any time in the near future.

[rushter]

I think the right way to do this is to integrate libghostty instead. There are so many details when it comes to implementing a fully compliant terminal.

Even neovim devs plan to switch to libghostty in the future.

[ryanabx]

I think the right way to do this is to integrate libghostty instead. There are so many details when it comes to implementing a fully compliant terminal.

Even neovim devs plan to switch to libghostty in the future.

Until there is an actual rust crate that integrates this (from what I can tell libghostty isn't even released yet), there's nothing actionable with that.

alacritty_terminal is widely used in the rust ecosystem, and works well.

[jgarte]

See what zed did with integrated alacritty

[RoloEdits]

Building helix would also then require a zig compiler if it depended on libghostty. Thats a pretty substantial thing to add, with zig not being even 1.0 yet.