Built in integrated terminal

[Daeraxa]

So this has been discussed quite a few times in the past on Discord but I think it is a good idea to put it here to stop re-hashing conversations and provide links etc. for people to play with things and provide suggestions.

Most applications in this space come with a terminal in-built as one of its core features.
VSCode, Lapce, Zed, Fleet - they all come with integrated terminals out of the box which leaves Pulsar a bit behind as you need to then find one and install it via package.

platformio-ide-terminal is an extremely popular Atom package but it seems people have been having problems with it in Pulsar and worse, it is no longer actively developed.

Termination is a fork of the above and works nicely but it doesn't feel that great to me, the UI is a little off and it is fairly limited in terms of placement.

x-terminal however is almost perfect from what I can see. I actually started to write this post before I even knew about it and it has a lot of the features I really want to see from a default terminal. (thanks for introducing me to this one @Spiker985).

Features that I personally want to see in an integrated terminal:

• Easily opened and dismissed by shortcut, UI and command
• Customisable location (i.e. not locked to a bottom dock only)
• Startup options (choose shell, project folder path, cwd etc.)
• Selectable shells (particularly useful for Windows with WSL, CMD and PS all in common use)
• Integration with editor UI (e.g. dragging a file or folder will print the filename or path in the terminal)
• Multiple independent terminal panes
• Modal terminal
• Ligature and unicode support etc. (e.g. for "pimped" shell prompts)
• Theme support (if integrated then this could be its own selectable option in the themes pane alongside UI and Syntax).

I see a few options for this to happen:

• We ask if the maintainer of a package we choose is willing to help implement it as a default package in the Pulsar org.
• We fork a package we like and modify it ourselves
• We write a new one from scratch using a library like Xterm.js which not only powers some of the ones on the list but also the VSCode terminal as well as a whole host of other things. Well maintained and popular.

Honestly x-terminal already covers most of the things on my list above but things that are missing I'd like to see changed if we implemented it as default:

Ligature and unicode support

• I use fish shell with a fancy prompt and this kind of mangles it. VSCode does a bit better but not perfect. Check against Kitty for example. It looks like this can be done with an addon - https://www.npmjs.com/package/xterm-addon-unicode11
  • kitty
    
  • VSCode
    
  • x-terminal
    

Modal terminal

This is something from Zed that I really love and didn't know I wanted until I used it. On a command or shortcut you can open a terminal as a modal in front of your editor window, do what you want then push it away again where it remains active but in the background (x-terminal does have this but not in modal form). I like it as it is almost akin to having a separate terminal window but still within the editor, great for smaller windows but you still want it to appear in the middle of your screen.
(Technically Zed actually has an entire modal pane that can be used for buffers as well as terminals but that is another discussion entirely but a feature I'd love to see).

UI buttons and tweaks

Would be nice if a button could be added to the status bar to quickly create a new terminal rather than always having to open a new one by command or shortcut.

Also would be good to have other buttons for controlling it, things like a shell selector (great for Windows when using WSL, cmd and PS). I know it has profiles but it could be more accessible.

When opened in dock mode the UI should follow Pulsar a bit more (active tab colour + accent, pane split line)

Better integration in general

It feels a bit "tacked on" in its current form. See above UI stuff but also small things like the commands are X Terminal: which we would want as just Terminal:, confusing right click menus, separate split commands rather than the existing Pane: split commands.

---

Summary

The above comments are really just polish rather than requirements, it is functional but I think it needs to be more than just functional and should bring a bit a good level of fit and finish.

It goes without saying that it should also be as customisable and hackable as any of the rest of Pulsar.

[Spiker985]

From what I've seen just earlier today, X-Terminal looks to be our best bet for something that already exists

It's already built on xtermjs, and in my opinion would just need some polish

It's MIT, and is technically a fork, of a fork, of a fork.

It also integrates the provider services for Platformio IDE, which makes it a perfect drop in replacement for that terminal.

Otherwise, we'd definitely want to put cycles towards a custom implementation based off xtermjs - but I'm unsure how much of the wheel we'd want to reinvent

[Spiker985]

Something else to note regarding the ligature and unicode support - the package actually has a setting for font family and font size.

By default they match the editor's font, but you can change it independent of the editor. This should, in theory, allow you to simply select a font that does support unicode and ligatures

[Spiker985]

From the node_modules of the package itself:

[Spiker985]

From the terminal after adding Fira Code as a font

[Spiker985]

Unicode characters in the terminal

[Spiker985]

Including emojis!

[Daeraxa]

Weird, I just have it set to "use Editor's font family" which is already using a font that supports ligatures.

[preland]

I like this idea, however, it should be kept in mind that terminal packages can add significant lag to the app, as well as tending to be very picky with how and when they work.

I’m not against adding a terminal into Pulsar; in fact, I’m all for it. However, it should be easily toggle-able, with the feature being disabled by default so users who never use the command line don’t have to waste time loading things they won’t use.

[Daeraxa]

I think the opposite myself, it should be on by default because people are simply expecting it to be there - most actively developed modern editors in this "market" ship with it out of the box - VSCode, Lapce, Zed. After the first launch it is then very easy for people to disable it if they don't want that feature (the very first launch takes far longer anyway).

However one problem if we were to implement it "as is" is that it isn't obvious that the terminal is even there. So my proposal would be that if enabled, by default, it would show on screen in a dock or pane simply to make its presence known.

Otherwise one situation I can see easily arising, particularly with Atom users, is that they immediately go off to install a terminal package which ends up clashing with the core one which isn't a good experience no matter how you look at it.
Similarly they might do the same thing to find a terminal package only to later discover there is a perfectly good one just sitting there disabled in the core.

[confused-Techie]

Yeah on board with @Daeraxa, maybe for the first launch, we could alert the user this is enabled and could make things take longer to load, and allow an easy way to disable it? Just a thought, since if it's shipped in the core of the editor, I don't think there's a single other core featured disabled by default.

But the bigger point, is if we add a terminal that only sometimes works, and adds significant lag then it shouldn't be in the core until that's resolved. At least if we release it as a stable feature

[preland]

I guess this is a fair enough point. I personally just never saw much usage out of a built-in terminal, since I’d just use an external one out of habit instead 😂

I will note that, if we end up using x-terminal as the starting point package, I don’t think it currently works with Pulsar (at least, it wasn’t working for me)

[Daeraxa]

Honestly I never used to use it until I started playing around with Zed and it has some really nice features that I never considered, if I ever used a built in terminal at all (mostly in VSCode at work) I just used it as an alternative to a normal terminal.

Some of the more interesting stuff really comes when you consider its integration into the editor itself, like dragging and dropping files or folders from the tree-view or having it follow your project path. With the Pulsar services model I actually think some really cool stuff could be made for it.

[Spiker985]

I do have a fork of x-terminal that removed the deprecation warnings, but the original one worked just fine for me on an Arch based distro

Something to note is that the CI for that project fails, because it uses Atom, but the tests clear 100% on my Pulsar