No. When such upper bounds are respected, they contaminate other packages, because you have to add them yourself to be compatible with your dependencies. Then your dependents must add them too, etc. This brings only pain. Python 4 is not even a thing, core developers say there won't ever be a Python 4.h
A friend shared his technique with me, and after adapting it to my needs, it works well. None of the other commonly mentioned techniques ever worked for me, because they ask for focus, which is the opposite of what my brain needs to fall asleep.
Here's his technique: pick a letter of the alphabet, and find as much words that start with this letter as you can. Once you can't find words anymore, pick the next letter. Doesn't work for me, my brain won't ever stop.
I noticed I have to visualize stuff in my head to fall asleep so my adaptation is to pick a single letter and a single word, and visualize it in my head, using it, manipulating it, experiencing it, whatever. For example: letter P, word Pineapple, imagine you're holding a pineapple, you feel the roughness of it's skin in your hands, you throw it in the air and catch it again, you take a knife and slice it on a wooden table on the beach, etc.. The dream kicks in seconds. Without external interruptions, after a few minutes I'm asleep (instead of rummaging for hours).
If you notice you're stuck in a loop/pattern (for me anything about text, like reading or writing, and voice, like listening and speaking, or stressful scenarios), just pick a new letter, pick a new word, visualize it.
I'll get a closer look at the code tomorrow, but maybe you can provide an answer in the meantime: how do you handle line numbers? Bash's LINENO is unreliable, contrary to Zsh's, see https://gist.github.com/pawamoy/cca35f0f5ccd56665d6421e9b2d2.... That's why I eventually gave up writing any profiling/tracing/debugging/coverage tool for Bash and moved to support these in Zsh instead. Unfortunately Zsh is missing a ZSH_XTRACEFD like Bash, but that's another story (never finished contributing one). Here's my own attempt at a shell profiler: https://github.com/shellm-org/profiler :)
I follow a sponsorware strategy: public version with basic features, paid version (monthly subscription) with more features. When a funding goal is reached (dollars per month), a subset of paid features become available to everyone. Paying users essentially fund the development of new features. I don't have any "app", only tools and libraries :)
Following the /llms.txt standard proposition, I create a MkDocs plugin that generates an /llms.txt file at the root of your site. So, same thing, but generates the Markdown document from your docs (possibly containing API reference) instead of your code.
I maintain git-changelog, which is a similar implementation in Python (started two years before git-cliff). When I discovered git-cliff a few months ago, I was very impressed by the number of things they support. Also, being written in Rust, it must be much more performant than my Python implementation (which indeed has trouble with huge Git histories). I have started recommending git-cliff to some of my users who request features I don't yet support :)
Author here (I'm a bit late!): indeed Griffe's goal is to be able to support any Python code, natively or thanks to extensions. Thanks for sharing by the way!
This is probably a bit off-topic, but I wonder if you know about the GenIDA project: https://genida.unistra.fr/. It's basically a research website where families can register and answer questionnaires about the everyday life of patients with rare diseases. The data can then be used to discover new things about these rare diseases. They have a Kleefstra cohort if I recall correctly.
Maybe you could get in touch with the people in charge, like Jean-Louis Mandel.
I think Terminator gave me a real boost on productivity. The split feature is great. And it has a lot more good things, like increase/decrease/reset text size, resize/rotate/expand or even drag-and-drop splits, grouping (to write in multiple splits at once), and the scrolling is done very well: scroll up a bit to stop following the output, scroll to bottom to follow again.
To expand on this, yes, you can force Bash to read more lines and keep them in memory before executing them by wrapping them in blocks. These blocks can be (), {}, functions, and maybe other structures.
In addition to this, you can make sure no appended code is ever executed by explicitly running "exit" at the end of your block. I actually used this trick in a self git-updating script (the updated version could contain more lines at the end).
I even have this problem with bikes. Not motor bikes, just bikes. Some of them have a front light that just blinds me. I can't determine their speed anymore, not the direction they're moving in, nor if there is something else between them and me. Once I even confused someone on their bike with a random street light, and almost crashed into them, because the angle and speed at which we were moving made it appear immobile. I often feel like a powerful light is far more dangerous than no light at all.
I don't know if it's because I'm so used to find, but I had a bad UX with fd. This is my thought process each time I use it: "Why separating the extension from the filename? Is this a default? Can we change it? What is the option, -e? Or -e is the option to 'exec'? What's the flag to include hidden files? Or are they already included? Does the pattern comes before the directory? Does it need a directory or does it search it the current one? man fd, man fd, man fd."
I guess my brain just refuses to remember these for some reason.