feat: add an option to pass in a command to session before opening

[jcelaya775]

I thought this option would be useful since it's portable if you want to execute a one-off command or integrate t into a script. You can still utilize .t scripts along with the command argument. For example, say you have some projects that contain this .t script:

#!/usr/bin/env bash
tmux new-window
npm run dev
tmux select-window -t 0
nvim .

You might want to run a script to open a couple of these projects, pull the latest code, and create docker-compose files (idk random scenario), while still having your .t scripts being executed. You can accomplish that by doing this (in fish shell):

for project in project1 project2 project3
    t $project --command "git pull && touch docker-compose.yml" --priority 0 # (default -> runs the command before .t)
end

You can use -c or --command and -p or --priority with values 0 (default) or 1 to determine if the command or the .t script gets executed first (if a .t script exists). The only caveat is that if you include a command argument to open an interactive program like neovim or less, then exiting that program will not automatically close the window, unlike before. But, if you run t without a command argument, it will behave the same as before.

[joshmedeski]

Hey! So I adjusted my strategy in a recent live-stream.

I want to move away from a .t in every project and create some centralized place to configure startup scripts and configure them with something like yaml.

I like some of the ideas here, but I'm not sure I want the prioritization flag as it complicates the logic.

I'm also thinking we move away from the startup script being executed directly on session creation and run it independently, so when the startup script ends the session continues to run (right now the session closes when the script ends).

Let me know your thoughts, there was a but of fumbling in the last live stream so I'll be revisiting this again soon (maybe this Wednesday!).

[joshmedeski]

Hey, there are some merge conflicts. I'm open to getting this merged in the next week if you can fix them.

p.s. I'm currently working on a rewrite in GoLang! Check it out here

[jcelaya775]

Awesome! I plan on resolving the merge conflicts within the next few days. I can remove the priority flag if it makes things simpler. Is the .t script still going to be used? If so, we should decide whether to run the user command run before/after the .t script. Please let me know if you have any other suggestions, too. Thanks!

The new project looks very interesting, I'll definitely check it out.

[joshmedeski]

I think we'll be reworking how startup scripts work, probably focused on a configuration file based approach instead of an executable file in the project's directory.

But that's still a little ways off. I'll be live streaming it in a few weeks when I finish getting sesh up and running!

[jcelaya775]

Hey, sorry that took longer than I expected. This isn't perfect and there are some edge cases that can be handled better (e.g., passing a query and a repo at the same time), but the core functionality works and you can also mix and match commands where it makes sense. I didn't want to add more complexity to the code than I already had. I'm definitely open to refactoring the way we handle flags/arguments.

One Idea I had in mind was to create a list that should contain the command-line arguments. First, we loop through all command-line arguments and append them to a list (e.g., (("QUERY", "my-project"), ("COMMAND/", "echo\ hi")), and if we run into an invalid argument, we exit the program right away. This gives us the chance to stop the program immediately if given bad input. Otherwise, all arguments are valid, and we would then loop through the list and process the flags/arguments. This would particularly solve the cases when combining --help and/or --repo with other flags. But it's quite a lot of changes, so I'm definitely open to keeping it simpler and maybe just limiting the amount of options for the user (i.e., not being able to pass in arguments in any order).

[joshmedeski]

Hey, thanks for doing this! My sesh rewrite is going well and will fix a lot of what you're bringing up. We will also be able to make this much more flexible and add more features.

Would you like to see this merge soon? Or we can port this over to the new project. My only concern is potential edge-cases that will require bug fixes, which this project is going to be deprecated soon anyways (hopefully the next 2 weeks!).

Let me know your thoughts, I really do appreciate the work, it will help a lot as it gets translated to GoLang.

[jcelaya775]

Yeah I agree, I was worried about edge cases, too. It does make more sense to start using a better programming language as the project grows, so I'm totally down to potentially porting this over to sess. Thanks again for your patience, looking forward to the new project!

[joshmedeski]

Me too, thanks for being understanding!