Search
286 results for “YesJustWolf”
-
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
-
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
-
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
-
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
-
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
-
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
-
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
-
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
-
One nice thing about switching from #pyenv and #pyenvvirtualenv to #uv is that #CleanMyMacX used to throw away my pyenv virtual envs. They lived in a cache directory. That doesn’t happen any more.
-
Today my work machine graduated from Windows 11 to Ubuntu 24.04. The hardware hasn’t changed. I would have preferred Kubuntu. They gave me ext4 instead of btrfs. But my wishes there are nice-to-haves. What they gave me is a huge step!
-
#Atuin update: I've come to rely on it. It's a must have for my daily shell usage. Works great everywhere ... except on #GitBashForWindows. Lots of problems there. Here's how I solved them:
* Install `ble.sh`. Use `curl` to do this. Do not get it with Git. Do not attempt to build from source.
* Install by sourcing `ble.sh` at the **end** of your `.bashrc`. That's how the instructions about getting it with `curl` tell you to do it. The Git based instructions want you to say something different in your `.bashrc`. You want the `curl` instructions.
* In my install, #Ble was too slow out-of-the-box. Missed keystrokes, etc. I copied the `blerc.template` from the GitHub repo to a local `~/.blerc`, and edited it to disable almost every kind of completion and also syntax highlighting. Speed is now acceptable. (Might be that my #Windows box is too slow. That seems unlikely.)
* I use `vi` mode; #Vim. `ble.sh` picks that up from my `.inputrc`; #Readline. I use #Starship for my prompt. I had to disable in `.blerc` the showing of my current `vi` state (insert, visual, command, etc) and also edit `.inputrc` to not add characters to the prompt to show insert vs command mode. Those changes let me have my normal `starship` prompt.I do have one problem remaining. It's not related to `atuin`; it's related to the command line itself. In #Bash and #Zsh, it's easy for me to be on the command line and get what I've typed so far directly into my editor; #HelixEditor. Usually something like Esc-v or the like. `ble.sh` doesn't seem to have a way to do that, but maybe I just haven't found it yet.
-
#Atuin is working great for me (especially with a few configuration tweaks) everywhere and in every #Shell except in complex commands (i.e., commands with pipes and or sub-shells) in Git Bash for Windows #GitBashForWindows. My problem here probably has something to do with the Bash preexec hook or whatever it's called; and it might be fixable.
Here are my tweaks:
```toml
store_failed = true
invert = true # I think this value is a change from the default
search_mode_shell_up_key_binding = "prefix"
``` -
I work in three different platforms: #GitBashForWindows (mostly, because that’s the environment for my job), #macOS, and #Linux. My shell environment is pretty complex, and as #CrossPlatform a I can make it. The most annoying thing I have to handle in my scripts is the difference between paths on a Windows system vs anywhere else, and especially the leaky magic Git Bash for Windows employs to deal with it (that’s the main thing I want to communicate in this post).
I’m a very experienced #Bash user/programmer, but more and more I find myself converting Bash scripts to #Python.
These days my Python scripts are run via a #uv shebang line, which I love. uv creates an environment to run such a script. That environment is not active while I’m _editing_ the script (using #HelixEditor) so, Helix reports all the symbols that it could only have gotten from that venv. I don’t yet know of a non-brute-force way to fix that (that is the second thing I wanted to communicate in this post).
-
I use #Git. A feature of Git I leverage heavily is #Worktree. I usually have at least four around at a time. For small tasks, sure, a simple branch and then switch back, but bigger things: a worktree.
Making a worktree is actually annoying for me: not just the upfront decisions about branches and start points and where to put the new directory (and also immediately `cd`ing there: but getting all the #submodules (submodules suck by the way), hooking up `.envrc` if you use #Direnv (and you should be), which should then set up your virtual environment and path and stuff. Clone isn’t quite as bad but has some of the same problems.
I do this so often, I wrote a script. It might be useful to others with this workflow. It’s opinionated, and therefore I could really use some feedback! What did I do right? What did I do that’s only right for me? What is totally missing?
The script is stand-alone, though you do need #UV. (You don’t even need Python! `uv` will transparently get you everything!) Just download this one Python file, and get it on your `$PATH`. If you want the additional `cd` behavior, then add the shell function, too as described in the `README`. Everything is tested. The tests are right there, too.
https://github.com/wolf/dotfiles/blob/main/git/dot-config/git/bin/make-worktree.py
The `README.md` is right next to it.
I **do** see one thing I’m missing: I need to provide a way to automatically copy in your custom stuff. I’ll add that today.
-
There’s a strong urge to believe what you wish instead of what you can prove. Computer rumors are a great example. Many rumors have no basis other than being a feature someone wants. They call it "wish casting".
We want the world to be black and white. Some given statement is either true or false. But it’s not. Gödel #Godel describes at least three states: true, false, and unprovable (e.g., the statement "This statement is false". Can’t be true or false; it’s unprovable. Maybe there’s a better name.)
But it’s worse than that.
In science, a theory isn’t true … it’s just the best explanation we have so far. The whole endeavor of science is to keep finding better explanations. To make good decisions you don’t need the absolute best explanation, just one good enough to guide you to beneficial choices. (I said "prove" before, but to be more accurate I should be talking not about what you can prove, but about what you can’t disprove.)
#Bayes (really #Laplace) says a given notion isn’t true, it’s actually true-with-some-probability. Each new thing you observe impacts that #Probability. This is the actual math behind the #ScientificMethod. And it’s the truth of the world. Your beliefs must adapt to your observations, constantly, forever.
If you have unshakable faith in some set of "facts", you’re probably doing it wrong. Even when you’re right, you could be righter.
Of course, if you don’t adjust your beliefs with new input, if you don’t test, if you have "facts" instead of "very probable theories". If you believe things because of how strongly the person who convinced you believed instead of what they could actually show you. If you believe simply because that’s what your parents taught you. Then, well, you **might** be right (even a stopped clock is right twice a day). But at best you’re not going to make good decisions for yourself, and at worst you’re going to try to tell others what to do based on an inaccurate understanding.
It’s messy; and that’s just how it is.
-
Yes. I use #LightMode. Everywhere (just about). I know I'm in a minority. And light mode is often broken for things (like when using light mode in the #HelixEditor, the buffer tabs are wrong and deceptive).
For terminal windows that are ssh'd into some remote box _sometimes_ I'll use dark mode.
-
I think any large interesting program you might write could well have an embedded language within it, in which the user can write stuff that is just as good, and just as deep as built-in functionality. You want this. It’s a thing that makes programs compelling.
In #Vim, that embedded language is #VimScript. In #emacs, that’s #elisp (which in fact, I think the whole thing is written in). In a #smalltalk environment, you control the entire environment with Smalltalk, just as elisp applies to Emacs. For many, many things, that language is #lua ( #NeoVim, many games, #pandoc, #redis, this list goes on).
I used to think there were really two reasonable mainstream languages you could use here: #Python or #javascript. Between those two, for a long time I felt that JavaScript was the winner. I think that has changed as Python has gotten faster, more powerful, and better known. But also, I think the answer might actually not be either of these two. It might be Lua. Lua is simpler and faster than either JavaScript or Python. It’s more embeddable. It’s designed specifically for this purpose. It’s in much wider use as an embedded scripting language. I don’t want Lua to be the answer. I like Python better. But I think Lua actually is the right answer.
-
#Vim #NeoVim I found what was replacing all my argument lists with underscores: argtextobj.vim. This is one of my favorite plugins. It hasn’t been touched in 15 years, though. Probably something changed in the editor itself that broke it. I could abandon it; I could fix it; or I could rewrite it. I asked my friend what language it should be rewritten in. He said #vim9script of course! I disagreed. That would only work in Vim. #lua would only work in NeoVim. Maybe #vimscript from just before 9. Maybe #Python. Maybe #rustlang. All three of those would run in both. I kinda don’t want to use VimScript, but that’s technically the correct choice.
Of course it would be waaay easier if it used the #lsp. Otherwise you’re parsing patterns and brackets and strings. Not sure such a solution works in plain old Vim.
What does the #fediverse say?
-
I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).
Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.
-
I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).
Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.
-
I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).
Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.
-
I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).
Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.
-
By the way: switching to #Fastmail, including making my email address use my own domain and importing all my old email from #HeyEmail #Hey was quick, easy, and in the end cost something like 40% less. Of course I don’t know yet how much I will enjoy using the interface; but everything I’ve done so far is promising.
-
I love Bash. I used to write tons of Bash. There is a lot of Bash in my life, even to this day.
But here's my life now:
* Bash holds some stuff together (small stuff: usually setting variables, aliases, and/or piping together a few CLI tools. See https://github.com/wolf/dotfiles/tree/main/shells/dot-config/shells/topics for examples)
* Zsh is good at doing stuff when I type, so that's my login shell
* If I have to do something interesting, why not just a Python script? In modern times, with a `uv` shebang line and self-specified dependencies ... the only externally visible additional requirement is `uv` itself (you don't even need Python). Just like a shell-based answer: you end up with a single stand-alone file
I'm not going to argue about "but you have to install `uv`". You do you.
-
For all #Programming, I just want to reinforce one very important rule: your plan must never be to #Rewrite it from scratch. I've seen this tried many times. This is what killed #Netscape. They had a plan, the engineers nixed it. We explained to management that what they were suggesting was two years of work. Rick Gessner exercised all his sway on the higher-ups. Integrating his new style and rendering engine became the plan again. We didn't release the version that was ready. Instead, we worked for two years to do the thing they wanted, with no releases during that time. It was a bad decision.
Step-by-step. No matter how bad you think it is: step-by-step.
-
At home I have lots of devices connected to my "desktop" (which is really just my laptop, which I carry between work and home every commute day): monitors, desktop speakers, backup drives, an #OpalC1, a fancy podcast mic, each of the two halves of my #KinesisAdvantage360Pro keyboard. The thing that connects to all these devices is my @CalDigit #TS4 #ThunderboltDock. When CalDigit first started talking about the #TS5 and TS5+ (#TS5Plus), obviously, I wanted one ... probably the plus. My laptop has Thunderbolt 5. It can use the TS5. But none of my devices are Thunderbolt 5, and I don't need faster Ethernet, because I'm on WiFi. So it just didn't make sense.
There's a USB-A port on the front of the TS4 (there's a zillion ports on all three of the devices I've mentioned). I use this A port to charge wireless things. I have a cable, A on one end, and then any of Lightning, C, or USB-micro (maybe? Whatever plugs into old Kindles) on the other. I was trying to charge my headphones (@Shokz #OpenRunPro2). The LED wouldn't come on. I'll spare you all the different combinations of devices, cables, and chargers that I tested, but the result was that the front USB-A port of my (only) two year old TS4 had gone bad. I had bought it from Amazon. The manufacturer's warranty had expired. Amazon's warranty had expired. But! I had purchased the three year Asurion insurance. I filled out the web page, told them what was wrong, they agreed that satisfied the terms and sent me a shipping label. They promised the full purchase price returned as an Amazon gift card 24 to 48hours after receiving the defective device.
Great, I thought, that almost pays for the TS5+. Except I'm kinda dead in the water without a dock, it will take time for the TS4 to make it to wherever it's going, and neither Amazon nor CalDigit has the TS5 or TS5+ in stock.
Still Sunday night, I added a CamelCamelCamel watch on the TS5+ for just slightly above its retail price. Monday morning, CamelCamelCamel sent me email saying Amazon had one. InstaBuy ... actually on my way to the UPS Store to send off the old. TS5+ arrived that evening, and so did the Amazon refund.
Of course I bought the insurance on the TS5+.
-
My port of the Alabaster theme (family) for Helix was approved, merged to `main`, further modified as per requests, and modifications merged to `main`, too.
The time from creating the PRs to having them merged was really short. Now how long it takes to get from `main` into an actual **release**, that I don’t know.
My original repo (just the theme family) lives at https://github.com/wolf/alabaster-for-helix. The `README` there has screenshots; points to the works of Alabaster’s creator (Nikita Prokopov, “tonsky”), which includes the original themes, repo, and an article that explains it all.
I use this theme all the time and will continue to maintain it. I see further suggestions in Issues on my repo. I take suggestions, issues, and PRs seriously.
-
Published my port of the Alabaster theme family for Helix.
Alabaster is a minimal syntax highlighting approach by Nikita Prokopov (tonsky) - only 4 semantic colors: strings, constants, comments, and definitions. Everything else stays plain text because code structure is already clear from formatting.
I've ported all 6 variants (light/dark × standard/BG/mono) from the original Sublime theme (staying as close as possible to the original). Also submitted a PR to ship these with Helix upstream!
Original theme: https://github.com/tonsky/sublime-scheme-alabaster
Read tonsky's essay: https://tonsky.me/blog/syntax-highlighting/
My port: https://github.com/wolf/alabaster-for-helixI tried to duplicate the original exactly, however Helix has multiple selections so I made the colors distinct between "selection" and "primary-selection".
#HelixEditor #Helix #Alabaster #MinimalDesign #SyntaxHighlighting #TextEditor #Rust
-
This was going to be a question for the Fediverse: I use the #HelixEditor. I use a light-colored #Theme (dark foreground text on a lighter background; yes, I know that puts me in a narrow group). Currently, I use #Onelight, but with some tiny modifications (https://github.com/wolf/dotfiles/blob/main/helix/dot-config/helix/themes/onelight-fixed-bufferline.toml) to make buffer-line "tabs" look right.
Reading this (https://tonsky.me/blog/syntax-highlighting/ by Nikita Prokopov aka Tonsky, sorry couldn’t find a Mastodon address) article makes me feel like there could be something better.
I wanted a light colored theme like his but made for Helix (his theme is called "#Alabaster"). I was having trouble finding the right thing, but looked harder and found this: https://github.com/beebeeep/helix-alabaster. Maybe **that’s** the right thing. I’ll try and report back.
If anyone out there has suggestions, please reply!