Pawamoy

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 :)

Great work, git-cliff devs!

> But again they don't export a Sphinx inventory so I cannot cross-reference their units

But they do! So you can!

The inventory is right here: https://textual.textualize.io/objects.inv. It's generated by mkdocstrings, the "autodoc" plugin for MkDocs. It's Sphinx compatible.

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.

Why not checking the contributors instead of the forks? Just pick the most regular ones, or the ones that contributed the most (in number of PRs).

My favorite as well.

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.

Check out Basher: https://github.com/basherpm/basher

Shameless plug: aria2p. I built an interactive interface very similar to htop to see your aria2 downloads progress.

https://github.com/pawamoy/aria2p

Woops, "didn't read", will delete later

Similar to https://github.com/dumb-password-rules/dumb-password-rules

echo -n hello world considered wrong as well.

Also

Question: Write the command that you use if you finish working with the terminal and you want to log out from the current session.

Your answer:logout

Correct answer:exit

There's git-bug: https://github.com/MichaelMure/git-bug

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.

Then throw it into space, whatever the direction. The universe is so vast, even if the entirety of the earth was garbage it would be nothing compared to it ;)

But using Python is very painful as well for shell use-case. Do you really want to open files, subprocesses, and create fifo manually instead of typing "cmd1 | cmd2 > output"?

Then you have Xonsh, but in my opinion, switching between the two contexts, shell and python, at each part of a command was too difficult. I was totally lost even at writing very basic commands.

I have to say that the LINENO variable does not have the expected behavior in process substitutions, especially when using multi-line commands (with backslashes at the end, or using multi-line strings).

LINENO will use the last line number of a multi-line "$(...)" command, offsetting all the commands' line numbers within the substitution. Since multi-line strings are concatenated by Bash internally, LINENO will only increase by one for those.

You end up with line numbers greater than the number of lines in your file, or overlapping with empty lines or comments. In this matter, Zsh's LINENO is way better as it will have the expected value (it will always be the line where the command was started, not an offset).

What about a simple "die" function that echoes a message and return an error code? Could be used both in scripts and in the interactive shell. It would use "exit" when SHLVL is more than 1, and "return" otherwise.

I use it in combination with a trap on DEBUG signal to compute information about each interactive command (start/stop timestamps, type, working dir, return code, and more) and save it in a big log file. I can then transform the data into pretty charts!

It's also used by the `z` command line tool to maintain its directory "frecency" list.

But aliases are not supposed to be available in subprocesses/scripts, unless you use shopt -s expand_aliases. Even if they were, you cannot ask all your users to rewrite their scripts to use \ls instead of ls.

Is its brightness slowly increasing or do you get flashed all of a sudden? For me, the latter would immediately trigger a very painful headache for the next 4 hours!