Making a directory and then immediately navigating into it is such a common occurrence, eventually on stackoverflow I found this:
alias mkcd='{ IFS= read -r d && mkdir "$d" && cd "$d"; } <<<'
this post was submitted on 11 Sep 2024
12 points (92.9% liked)
Ask Programming
76 readers
2 users here now
founded 2 years ago
MODERATORS
A have it so that my shell always opens tmux, unless it's a login shell or dumb shell.
# ~/.bashrc
## Top of your RC
[[ $- != *i* ]] && return # If not running interactively, don't do anything
[ -z "$PS1" ] && return # If not running interactively, don't do anything
[[ $TERM == dumb ]] && return # If called from emacs, don't do anything
## Put the rest of your code here
## Bottom of RC
shopt -q login_shell && return ## If this is a login shell, load all except tmux
if command -v tmux &> /dev/null && [ -n "$PS1" ] && [[ ! "$TERM" =~ screen ]] && [[ ! "$TERM" =~ tmux ]] && [ -z "$TMUX" ]; then
tmux attach || exec tmux new-session
fi
That way, I always have persistent terminal sessions and don't need a terminal emulator that has tabs since I can just do multiplexing in tmux
I have an alias venv, which checks if "./.venv" exists, and if not, creates a virtualenv there, and then activates it.
Kitty’s builtin functions are pretty darn useful. I use the icat & ssh functions daily as well as the Unicode insert (tho I wish they would strip that ‘Nerd Font’ noise). Also still a long-time fan of fish’s completions.
icat
I wish alacritty would just implement sixel already. I love the project but the dev can be hostile towards features that other terminals have had since years.
That being said, it's his project, and he shouldn't be bound to the whims of the fanbase
Would be nice, but sixel has some pretty obvious limitations Kitty tries to solve
that's news to me, anywhere I can read some more on this?
https://github.com/kovidgoyal/kitty/issues/2511
Stuff in this Microsoft GitHub thread… no alpha, no color profiles, etc. Kitty has some of the best performance for terminal emulators too for graphics.
I just read the thread - it sounds like Kitty's image protocol is better, but it does seem tone deaf to not implement Sixel (as a safe Rust library or whatnot) after so many terminals have.
please don't write "Microsoft Github". I know it's been true for years, but just out of respect for what it once was, can you just call it "Github"
Microsoft Windows. Microsoft Exchange. Microsoft Office. Microsoft Word. Microsoft Teams. Microsoft SwiftKey. Microsoft Bing. Microsoft SQL Server. …So yes, Microsoft GitHub unless we want to fail to recognize their neo-EEE strategy of purchasing/creating of as well npm, Azure, LinkedIn, VSCode, Language Server Protocol, TypeScript, etc. & trying to create “the ecosystem”.
But also, zero respect for MS GitHub. Code forges now turned into a social media & marketing platforms, you have starhacking, anxiety for how green your chart is, pressure to build a portfolio on a proprietary + non-self-hosted platform. They have always required you create an account to submit patches. They also invented the horrible pull request model that doesn’t scale + blocks/slows teams down significantly; it also turns maintainers into commenters instead of merging patches & changing to fit their nits later instead putting all of the onus on contributors that usually just want a fix in—not to understand the maintainers whole process or even chosen programming language. It is bad. Gaining the seemingly-unshakable popularity the platfrom has, even the alternatives continue to copy MS GitHub’s bad ideas & propagate these ideas for ‘compatibility’ offering very little beyond X but FOSS (folks wonder why not a lot of others are moving to Forgejo, well, it doesn’t offer anything new or solves actual UX & workflow problems to be better (rather literally moved from Gitea’s CI to copying all the grossness of Microsoft GitHub’s Actions)). The only thing it did that was good was making free software cool while ironically on a totally proprietary platform.
Github used to be such a great place to discover new coding projects that weren't corporate monorepos, no other platform came close in that sense of discover ability and the communities that developed around small niche projects.
Also, what's wrong with PRs? and what's the alternative?
We need a decentralized alternative similar to Lemmy that encourages self-hosting or finding your collective. D in DVCS is distibuted so we do not need centralization.
Your alternatives are going to be patch-based like mailing lists where email is the primary method but no reason a different UX/transport could be used—or stack-based like Gerrit & friends. Most folks that try these methods swear by it, but hegemony for pull requests marches on. Both methods are more similar in that they don’t block on review & promote maintainers maintaining. One resource I ran into today: https://www.stacking.dev/. If choosing Git out of the one of many DVCSs, there is things like this as well: https://pr.pico.sh/ …but there are loads of alternative systems, platforms, & version control systems (like those even built for patches)
As someone who peddles in email patches from time to time (guix, org-mode), I can tell you that PR's are far more intuitive: there's no ambiguity in which branch to apply the diff on, the order of diffs is implicit, and it is far easier to comment.
Email patches are fine, but can be nightmare if you've waited too long and the dev branch has changed and the patches are no longer valid, or worse, the author reset the numbering so its not clear what needs to be applied where.
Which is why I said there is clear room for UX improvement—the flow itself is fine. Not that patches or pulls are really that different (where like Bcachefs sends pull requests to the Linux Kernel mailing list), but the UX between these flow is what is the real separator. Patches flows are don’t get your code blocked in review since patches are nebulous things in the æther not tied to branch or anything so I get what you are saying.
In the same sense the UX for PRs (from a web UI as most ‘know’ it) leads to folks either pushing bad history with ‘fix X for review’ commits or rebases that fix this history but none of the big forges show a good UX for these version & make the reviewer feel they need to re-review—or worse maintainers employing a squash–merge process which fixes the useless fix commits but destroy a good history into a single commit. …Where stacked flows like Gerrit do not destroy this history (rebasing fixes are expected with UI showing it) & doesn’t block on review phase.