[7760:0116/122818.642576:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
[7760:0116/122818.642619:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.
fish: Job 1, './TerminalOne-1.3.1.AppImage' terminated by signal SIGSEGV (Address boundary error)

Ozone variables set in ~/.config/electron-flags.conf:

--enable-features=UseOzonePlatform
--ozone-platform=wayland

AND electron25-flags.conf:

--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto

setting of acrylic: true caueses the app to look like this on MacOS:

setting it to false shows proper behavior. There are no errors in the logs.

{"level":"info","message":"Loaded config from /Users/stephan/Library/Application Support/Terminal One/config.js}: {\"acrylic\":true}","timestamp":"2024-01-16 15:01:14.820"}
{"level":"info","message":"app started","timestamp":"2024-01-16 15:01:15.945"}

It seems that tabs can not be renamed, it just named by numbers

When in tmux the block cursor starts to flicker a lot, but it does not appear in recordings though.
It is comparable to z-fighting in video games.

I'm honestly really loving this terminal so far. It's shockingly good and fills the niche I happen to be part of: native Windows development while also having to cycle between Linux and Mac.

Feature Request

It would be nice to bind keys with and without leaders. In fact, I think this should be generalized to any arbitrary sequence of keys, similar to Vim keybinds. This would also open the door for other QOL enhancements, such as "which-key" types of menus often found in NeoVim configs.

One way to accomplish this from a configuration perspective could be something like this hypothetical config.js:

keybinds:  [
  { keys: ['leader', 'c'], action: 'createTab' },
  { keys: ['alt+w'], action: 'closeTab' },
]

Not a priority, but action could be generalized down the road to accept arbitrary JS functions, too. I'm not tied to this schema, I was just giving an example to illustrate the point.

If you want I can make a figma concept. The design of this terminal feels very off place. Some of the changes would be having the tabs at the same height of the window controls, etc.

xterm.js dev here - just saw your reddit post and ppl being concerned about performance with (yet another) JS driven terminal.

Want to give you a few of my own impressions in that field (and since I dont have a reddit account I'll do it here, hope you dont mind):

As you already might have figured, xterm.js has taken some lengths to optimize execution performance (and still does, partially even with WASM drop-ins), be it for input processing, buffer handling or screen render performance (3 different renderers - sounds silly when just looking at this number). So whats the deal here?

Well since the invention of JIT and the constant improvements done to JIT engines like V8 Javascript isn't slow anymore per se - it is now more a mixed case ranging from 1,5 - 5x execution time for typical programming tasks. Where your very own code ends up in that range depends alot on how well you abide to assumption/pattern the JIT can easily optimize (to name a few we had to apply to xterm.js):

• many JS-ish pattern are still poison for the JIT (got somewhat better over time), so Javascript is its own enemy when it comes to perf requirements
• short functions / methods with stable type interfaces - any interface change or even accessing a value on an outer context might cause a bailout/de-opt in the JIT with bad perf again or the need to recompile
• sync vs async (eg. promises) - promises are way slower that plain sync code (async always involves some additional bookkeeping for the queue execution / stack reordering)
• the garbage collector is "garbage" for high perf needs - you will need object pooling/recycling or GC/allocation pressure will kill the fun
• perfwise JS strings are spoiled, they have seen some optimizations at various ends, that will bite you back at other ends, resort to typed arrays instead
• any data processing in JS is still worse than in high perf compiled languages even with typed arrays, prolly mainly due its deref needs when accessing values in container types (thats where even the JITed execution loses ground) - here WASM can bring you closer to C/C++ speed with 1-1.5x execution time

So when you read over the points above you might get the feeling whats going on - writing very C-ish code in Javascript/Typescript still gives you the fastest results before entering any WASM trickery. This is contradictory to what most webdevs learn these days, esp. regarding the GC (most ppl dont care for memory management at all anymore) with all the downsides - JS apps are perceived as fat and slow. And sadly thats true for most apps. But not because the language/engines cannot do any better - I tend to blame the devs, that dont learn anymore, how to write efficient code due to all the goodies the languages offers (which all come to a price). A quite infamous example is the runtime difference of a for-of-loop vs. a classical C-ish for-loop with index access.

It is even slower than it is in the recording. It renders in as a 90s image on the internet. It might also be because it is an intel app on M1. Also there is a weird stretching going on. Github doesn't allow me to record the screen because of file size limits, so I will give a screenshot.


Startup time is also extremely slow.

Hey, firstly, congrats on this project!

Just a quick thing I noticed: I can zoom out with ( CTRL - ) , but then can't zoom back in with ( CTRL + ).

Thanks!

When terminating a shell (for example, using the exit command), the tab remains open.

Steps to reproduce:

1. Open a shell in TerminalOne.
2. Exit the shell via command line.
3. The shell process terminates.

Actual:

The tab remains open.

Expected:

The tab is destroyed. If it's the last tab, then the whole window should be destroyed.

Environment:

OS: Windows 11 Pro, 23H2, 22631.3007
TerminalOne: rel v1.3.1

As it stands, the block cursor (such as Vim normal mode) obscures the underlying character, like so:

In this example, the comma is completely hidden.

It would be nice if we could set a different foreground color or even a function to intelligently pick a contrasting color with the cursor block.

Wasn't sure if this is a feature request or a bug... It could be argued both ways. lol