Ah yes you can tell by the post title:

best linux terminal emulator

Oh, is that #4948?

For me: Wezterm. It does pretty much everything. I don’t think Alacritty/Kitty etc. offer anything over it for my usage, and the developer is a pleasure to engage with.

Second place is Konsole – it does a lot, is easy to configure, and obviously integrates nicely with KDE apps.

Honorable mention is Extraterm, which has been working on cool features for a long time, and is now Qt based.

Just note that the comment was inaccurate, in that their weird encryption is indeed open source at least.

I suggest trying this one for Zsh, over the more common one: https://github.com/zdharma-continuum/fast-syntax-highlighting

As someone else said, setting less’ jump value is helpful.

Another tool I use, mostly for the zshall manpage, is https://github.com/kristopolous/mansnip

Thanks, yes, I use nox and github actions for automated environments and testing in my own projects, and tox instead of nox when it’s someone else’s project. But for ad hoc, local and interactive multiple environments, I don’t.

If it didn’t bring something more to the table, besides speed, no one would care

I’m literally saying its speed in certain operations makes an appreciable difference in my workflows, especially when operating on tens of venvs at a time. I don’t know why you want to fight me on my own experience.

I’m not telling anyone who doesn’t want to use uv to do so. Someone asked about motivation, and I shared mine.

The convention

That’s one convention. I don’t like it, I prefer to keep my venvs elsewhere. One reason is that it makes it simpler to maintain multiple venvs for a single project, using a different Python version for each, if I ever want to. It shouldn’t matter to anyone else, as it’s my environment, not some aspect of the shared repo. If I ever needed it there for some reason, I could always ln -s $VIRTUAL_ENV .venv.

Learn pyenv

I have used pyenv. It’s fine. These days I use mise instead, which I prefer. But neither of them dictate how I create and store venvs.

Shell scripts within Python packages is depreciated

I don’t understand if what you’re referencing relates to my comment.

I have a pip-tools wrapper thing that now optionally uses uv instead. Aside from doing the pip-tools things faster, the main advantage I’ve found, and what really motivated me to support and recommend uv with it, is that uv creates new venvs MUCH faster than python’s venv module, which is really annoyingly slow for that operation.

I use my own Zsh project (zpy) to manage venvs stored like ~/.local/share/venvs/HASH-OF-PROJECT-PATH/venv, so use zpy’s vpy function to launch a script with its associated Python executable ad-hoc, or add a full path shebang to the script with zpy’s vpyshebang function.

vpy and vpyshebang in the docs

If anyone else is a Zsh fan and has any questions, I’m more than happy to answer or demo.

CLI flow: run command, print output below

TUI flow: navigate and interact with a layout that updates in place

If you haven’t checked them out you might be interested in aconfmgr or pacdef.

mpv+uosc is my jam these days.

No, that’s not used by Zsh.

Glad you have it working. This may also work:

_stfu () {
  shift words
  (( CURRENT-=1 ))
  _normal -P
}
compdef _stfu stfu

FWIW I’ve read an Arch dev complain that folks using any 3rd party installer are not in fact “running Arch” and should not claim to be doing so.

Huh? Is this relevant, or some kind of bot spam?

For anyone else wondering:

Navidrome is an open source web-based music collection server and streamer. It gives you freedom to listen to your music collection from any browser or mobile device. It’s like your personal Spotify!

So far, this isn’t much of anything.

Telegram already closes public channels reported for copyright violations.

Some excerpts from this post:

Compared to other platforms, we do not see the seriousness of Telegram to cooperate.

. . .

In May 2023, progress appeared to be going in the wrong direction. Telegram was reportedly refusing to cooperate with the Ministry of Communications and Digital on the basis it did not wish to participate in any form of politically-related censorship.

. . .

With no obviously public comment from Telegram on the matter, it’s hard to say how the social platform views its end of what appears to be an informal agreement.

Telegram will be acutely aware, however, that whatever it gives, others will demand too. That may ultimately limit Telegram’s response, whatever it may be, whenever it arrives – if it even arrives at all.