profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/imsnif/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

imsnif/bandwhich 6571

Terminal bandwidth utilization tool

imsnif/diskonaut 990

Terminal disk space navigator ๐Ÿ”ญ

imsnif/Awesome-Linux-Software 4

A list of awesome applications, software, tools and other materials for Linux distros.

imsnif/awesome-rust 3

A curated list of Rust code and resources.

amir-arad/resha 2

rak resha

CommaSword/noiz-generator 2

Generate background noise with varying volume

imsnif/awesome-tap 1

Useful resources for the Test Anything Protocol

imsnif/dear-github-2.0 1

๐Ÿ“จ An open letter to GitHub from the maintainers of open source projects

imsnif/agenda 0

Lightweight job scheduling for node

imsnif/AmoebaTerm 0

Under construction

issue commentzellij-org/zellij

Support multiple modifier keys

Thanks @klamonte for this great information!!

Being a multiplexer, I guess we would ideally have to support all of these. I'm very open to this change, but this seems like a bit of a tall order (especially since we're using Termion to parse stdin and unless I'm mistaken I don't think they support any of these specifications). Do you have any information about which one of these is the most common?

qwerty01

comment created time in 2 hours

issue commentzellij-org/zellij

Zellij won't read config changes to locked mode

@a-kenji - thanks! Do you think we can accept both suffixes?

qballer

comment created time in 2 hours

issue commentzellij-org/zellij

Zellij won't read config changes to locked mode

I think this is an issue of Zellij not reading the default configuration from ~/.config/zellij, because when I take this configuration and start zellij with zellij --config ~/.config/zellij it works. Maybe @a-kenji has an idea why?

qballer

comment created time in 19 hours

issue commentzellij-org/zellij

Support multiple modifier keys

Unfortunately I'm not 100% sure this is possible within the terminal emulator landscape we're working in. It's not just a question of how we store or configure the keys, but also a question of how we serialize/deserialize them from/to stdin. This is an issue I've hit several times and have not yet had a chance to fully investigate. I think most terminal emulators won't differentiate between a ctrl-j and a ctrl-alt-j, for example. There really is a limited amount of things we can do here.

If you (or someone else) would like to investigate this more, I'd be happy to give some pointers.

qwerty01

comment created time in 20 hours

startedKintaro/wtftw

started time in 2 days

pull request commentzellij-org/zellij

feat(ui): The status bar indicates that the panes are full screen and how many hidden panes are

No need for a virtual machine (unless I'm missing something?)

On this branch, do:

  1. cargo make build-e2e
  2. Start the docker environment, ssh into the container (I think the user/password are test/test, but it should be specified in the docker-compose file)
  3. Run zellij and do what the test does (eg. open a new pane)
takezyou

comment created time in 4 days

pull request commentzellij-org/zellij

feat(ui): The status bar indicates that the panes are full screen and how many hidden panes are

Hum. Github doesn't seem to want to allow links to the build logs. Look for a line starting with "current_snapshot:" - this is a representation of what the test "sees on the screen", and in most cases there's the end of a stacktrace.

takezyou

comment created time in 4 days

pull request commentzellij-org/zellij

feat(ui): The status bar indicates that the panes are full screen and how many hidden panes are

@a-kenji - from a brief glance it looks like there's a crash with a stacktrace in (all?) tests inside the container (this is distinct from the stacktrace of the failing test itself - you can see the tail end of it in the provided snapshot), eg.: https://github.com/zellij-org/zellij/pull/450/checks?check_run_id=3654778354#step:12:2478

I would start by trying to replicate one test manually by SSHing into the container and doing all the steps that it does. You'll likely see the same stack trace and be able to understand what's causing it exactly.

I have a bit of a busy week, so not sure I'll have time to take a closer look soon unfortunately. If everyone is really stuck though I'll try to make time in one evening or the weekend.

takezyou

comment created time in 4 days

startedWilfred/difftastic

started time in 6 days

issue commentzellij-org/zellij

Allow panes to remain open after their process exited

How would you know that the user explicitly closed them? Does an explicit CTRL+C differ from a failed process...? Or you mean to implement a specific zelliz command (shortcut?) that closes the pane for you, so it knows it was triggered by you...?

Ctrl+C is sent to the process itself (either that or directly send it SIGTERM, not sure about the implementation yet) and then the process closes itself. This will not close the pane in such a case.

Closing the pane through Zellij (eg. by doing ctrl+p + x) will close the pane itself (and also kill the process) as happens now.

stratosgear

comment created time in 7 days

pull request commentzellij-org/zellij

fix(server): fix leakage of SessionMetaData

I hope it's okay if I chime in here: if this is in order to facilitate something else that hasn't been merged yet, maybe we can look into that first and then see if we still need this one? I guess @TheLostLambda will probably have some useful input regarding cached plugin disk metadata.

tw4452852

comment created time in 7 days

push eventzellij-org/zellij

Aram Drevekenin

commit sha 72b0474d024abc799a2f5e90a1078f68b150502a

docs(changelog): update cwd fix

view details

push time in 7 days

push eventzellij-org/zellij

spacemaison

commit sha 40e74d5b8543a779d20af86f3aa6e996136996b6

fix(cwd-pane): Fix for cwd not being inherited when switching tabs (#729) fixes #727 Inheriting the current working directory didn't work when switching between tabs. This happened because the event to notify the pty of an pane change was triggered when setting the active pane inside of the current tab, but switching between tabs will only cause a re-render of the newly selected tab and it's panes without setting the active pane. This was fixed by moving the event to notify the pty of the pane change into the tabs render method. Co-authored-by: Jesse Tuchsen <not@disclosing>

view details

push time in 7 days

PR merged zellij-org/zellij

fix(cwd-pane): Fix for cwd not being inherited when switching tabs

fixes #727

Inheriting the current working directory didn't work when switching between tabs. This happened because the event to notify the pty of an pane change was triggered when setting the active pane inside of the current tab, but switching between tabs will only cause a re-render of the newly selected tab and it's panes without setting the active pane. This was fixed by moving the event to notify the pty of the pane change into the tabs render method.

+22 -26

1 comment

1 changed file

spacemaison

pr closed time in 7 days

issue closedzellij-org/zellij

Working directory inheritence isn't quite working

I just noticed that when switching between tabs and then splitting into a new pane the current working directory is inherited from the previous tabs pane and not the pane that's focused after switching tabs. This is likely a because we're not updating the pty's active pane when switching between tabs. I will look into why this is happening later tonight and file a PR to fix it.

closed time in 7 days

spacemaison

pull request commentzellij-org/zellij

fix(cwd-pane): Fix for cwd not being inherited when switching tabs

Thanks for the quick fix!

spacemaison

comment created time in 7 days

issue commentzellij-org/zellij

Allow panes to remain open after their process exited

I think that could maybe be a good way? But I think to address the original issue we would want to add a keep_open or hold flag to the cmd configuration. Those would be 2 separate contexts then.

Hum... why do you feel it would be better to add it to the command context and not on the pane itself?

stratosgear

comment created time in 7 days

issue commentzellij-org/zellij

Do not close the pane, where a custom command was started, when the process ends

From your description I also assume that a CTRL+C will also result in this message from above, right?

Yes, exactly (well, assuming the process responds to ctrl-c by exiting, but yeah :) ).

I'm happy you like the approach. It isn't that much work to implement, and is a direction I personally want to take Zellij anyway. While on the whole this isn't more work than creating a tmux-like solution, the incremental implementation that I'd recommend taking here might mean that there will be a gap where we'll be a little less good than tmux before we add everything else. So I hope you'll bear with us. :)

I'm going to put a Help Wanted tag on this issue if anyone wants to pick it up. Otherwise I'll try to get to it sometime in the near future. Here's a rough plan for implementing this:

  1. Add the remain_open: bool flag to the Layout. These panes should only close if the user explicitly closes them, rather than if their process exits.
  2. Collect the exit status of such panes and keep it as an Option<u8> on the TerminalPane (a different solution can be found for plugins, but we can ignore them for now).
  3. Keep the Command from the Layout on TerminalPane as an Option<String>
  4. Change the BoundariesFrame to display the exit status if the pane exited (as well as the message in my ASCII drawing above) - bonus points if you'd like to change its color depending on the exit status (red for error, normal otherwise)
  5. In the "exited" state, if the TerminalPane receives the ENTER key, it should send a message to the Pty thread to run the command in a new async task.

I'd be more than happy to provide help and guidance if anyone wants/needs it.

stratosgear

comment created time in 8 days

issue commentzellij-org/zellij

Do not close the pane, where a custom command was started, when the process ends

Some background (in a simplified manner):

Any terminal window (including a Zellij pane) is talking to another program that's running on the other side of the pty. Normally this is the shell. When you run something from within the shell, the shell itself defers to that process and forwards its stdout to the terminal and the terminal's stdin to said process. Eg. your script. When the script exits, you drop back into the shell.

Zellij and tmux panes work in the same way. They run a shell by default and when you run processes in that shell, they talk to those processes (this whole system is transparent to the multiplexer of course).

When you tell tmux to run a command in a pane, what it does (presumably by what you describe, I have not looked at the code) is forward your command to a pane running your default shell just as if you typed it in.

Zellij can do this, but IMO this is a bit hacky and we can definitely do better here. I feel it can be very powerful to give users the power to decide what they'd like to do inside a new pane. They can run a command regardless of which shell runs there, and have the pane interact directly with the command. Imagine running your dev script in a pane normally, being able to interact with it just as you did, and when it exits, you will see something like this:

    โ”Œ <your script name> โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
    โ”‚ Your script output which you can scroll through and resize  โ”‚
    โ”‚ as you would any other pane                                 โ”‚
    โ”‚                                                             โ”‚
    โ”‚                                                             โ”‚
    โ”‚                                                             โ”‚
    โ”‚                                                             โ”‚
    โ”‚                                                             โ”‚
    โ”” EXIT STATUS: 2 (error), <ENTER> to rerun โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

To me this sounds like it not only gives you both cases, but saves you having to press the Up arrow (you just have to press ENTER instead) and gives you a clearer visual indication that the script has terminated. But maybe I'm missing something about your use case... what do you think?

stratosgear

comment created time in 9 days

issue commentzellij-org/zellij

Block selection not working

You can also bypass the whole mouse events being captured thing with shift, so if you do ctrl+shift and drag you get back mouse selection.

OMG - I definitely did not know that!!

@agluszak - if you still want to work on making this available by just doing ctrl like in a regular terminal, I'd be happy to provide guidance (though I'd have to take a deeper look tomorrow to find out the best way to go about this). Or if @tlinford's solution is good for you, we can definitely find you something else to do. There's lots :)

agluszak

comment created time in 9 days

push eventimsnif/zellij

Paulo Coelho

commit sha c09e65383ea5bbadc149cf8804d07807434a6632

fix(frames): don't pad empty pane title (#724)

view details

Aram Drevekenin

commit sha eaf72db29b54b0b6e51ca0c671ad4db5fa5666f1

docs(changelog): update pane title fix

view details

Aram Drevekenin

commit sha b1f17a624c90a21719c5f1a2b846cce0be82a401

fix(keys): bring back ctrl-n to get from scroll mode to resize mode

view details

Aram Drevekenin

commit sha 720a3ecbafbb6a0a66025ba560c63ccf3c9a40f1

Fix prompt line overflowing when resizing panes (#725) * fix(wrap): do not wrap empty lines and properly place cursor when resizing * fix(wrap): truncate last blank line wraps * fix(wrap): truncate lines right after unwrapping them * refactor(grid): remove unused method * docs(changelog): document change

view details

Aram Drevekenin

commit sha 4219266523a7f9de83d36c1cc50c65f65c87f2ea

chore(version): bump changelog version

view details

Aram Drevekenin

commit sha 1868816791caca222f8a17ab96e3d514dc2ae79f

chore(release): v0.17.0

view details

Aram Drevekenin

commit sha 0f3590adb519e52034019997ee2a5a33d1270ef7

chore(version): bump development version

view details

push time in 9 days

push eventzellij-org/zellij

Aram Drevekenin

commit sha 0f3590adb519e52034019997ee2a5a33d1270ef7

chore(version): bump development version

view details

push time in 9 days

created tagzellij-org/zellij

tagv0.17.0

A terminal workspace with batteries included

created time in 9 days

push eventzellij-org/zellij

Aram Drevekenin

commit sha 4219266523a7f9de83d36c1cc50c65f65c87f2ea

chore(version): bump changelog version

view details

Aram Drevekenin

commit sha 1868816791caca222f8a17ab96e3d514dc2ae79f

chore(release): v0.17.0

view details

push time in 9 days

issue commentzellij-org/zellij

Block selection not working

Now I get it! I think I didn't fully understand what "block select" means until I saw the video. Alright then - you can enable this in Zellij if you disable it's built-in mouse support by running it with zellij options --disable-mouse-mode - but that would remove Zellij's own mouse support (scrolling inside panes and changing pane focus with the mouse).

The problem is that if we take mouse control away from the terminal emulator, we have to implement all these things on our own. I'd be open to a "block selection" implementation if you or anyone else is interesting in working on it.

agluszak

comment created time in 9 days

push eventzellij-org/zellij

Aram Drevekenin

commit sha 720a3ecbafbb6a0a66025ba560c63ccf3c9a40f1

Fix prompt line overflowing when resizing panes (#725) * fix(wrap): do not wrap empty lines and properly place cursor when resizing * fix(wrap): truncate last blank line wraps * fix(wrap): truncate lines right after unwrapping them * refactor(grid): remove unused method * docs(changelog): document change

view details

push time in 9 days

PR merged zellij-org/zellij

Fix prompt line overflowing when resizing panes

Fixes https://github.com/zellij-org/zellij/issues/321

This makes sure we do not wrap empty lines when resizing panes.

+24 -4

0 comment

4 changed files

imsnif

pr closed time in 9 days

issue closedzellij-org/zellij

Resizing panes leads to prompt text glitches

Steps:

  1. Open a 4-pane layout via M-n
  2. Close the upper-right pane via C-p x
  3. Resize either of the lower panes via C-p r [hjkl]+

Result: Starship prompt is being smeared all over the lower half in both panels, cf. screenshot.

2021-04-22-171718_3840x1080_scrot

closed time in 9 days

surge9n

push eventzellij-org/zellij

Aram Drevekenin

commit sha f3a7a8de8bc3c390597ac70ee2d2d95e7582d13b

docs(changelog): document change

view details

push time in 9 days

issue commentzellij-org/zellij

Block selection not working

@agluszak - I'm not sure I understand. Could you describe a use-case or provide a screenshot? What are you trying to block select? Is it in a specific program, or?

agluszak

comment created time in 9 days