It's a "for" loop.
Could you elaborate?
Readit Newsmarklgr commented on Show HN: Linux CLI tool to provide mutex locks for long running bash ops github.com/bigattichouse/... · Posted by u/bigattichouse
marklgr commented on Show HN: Speech Meter – Improve Your English Pronunciation speechmeter.com/... · Posted by u/jeanmayer
As a French native who learned English by reading books and later spent a couple of years in English speaking countries, I'd really like to have a tool to help me fix my pronunciation.
So with that in mind I tried your tool and I was enthusiastic about seeing a score for each words, but then what? I tried a few sentences manually (the random button doesn't work) and for example it seems that I have an issue with the pronunciation of "to" where I always get around 50%, but there's no way to know what's wrong. As it is I'd stop using the tool after about a minute.
I'd suggest adding something to hear the correct US/UK pronunciation of the words.
I've been using the Boldvoice app (no affiliation), it's not perfect but pretty good; my spoken English has definitely improved in a few months. I would recommend it.
marklgr commented on Magnetism may have given life its molecular asymmetry quantamagazine.org/magnet... · Posted by u/rbanffy
There are species of ocean life that use the earth’s magnetic field to find oxygen after they are newly alive.
A small percentage go the wrong way for millennia and die immediately, but they pass along their generations gene when the magnetic field flips of the earth.
Always found that fascinating to consider…
Can't be natural selection, can it? Sheer luck?
I understand why gorhill doesn't ask for donations, but I still wish there was some sneaky way I could send him some money anyway.
If someone finds a way, I'm in.
The main high-frequency bits are filesystem navigation and incrementally building pipes.
cd foo/<tab>
# oh, too many options
<ret>
ls -la
cd bar/baz
git status
cat quux | grep xckd
cat quux | grep -i xckd
cat quux | grep -i xkcd
cat quux | grep -i xkcd | xargs ...
The trial-and-error command refining is arguably what REPLs are for. It's the filesystem navigation that are the odd part.
(INB4: don't give me the "useless use of cat", it factors out better like this and everyone does it anyway.)
FWIW, if you just like the filename on the left, you still can save forks with:
`<quux grep xkcd`
Let me be frank: ELisp is a terrible programming language. I have a number of Emacs packages (in ELisp) and Sublime Text packages (in Python), and the development effort difference between the two is not even funny.
That said, Emacs relies rather heavily on unique features such as dynamic binding, advice, and autoloads. These are more or less impossible to replicate in modern languages, so I don't think there's a reasonable path to rewriting major parts of Emacs in, say, Javascript.
But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. A similar thing could happen in Emacs.
> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface.
It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons.
Anyway, it is not directly related to your point, but I think that example is not that compelling.
marklgr commented on A Vim Guide for Advanced Users thevaluable.dev/vim-advan... · Posted by u/behnamoh
Table of contents for this user manual: https://vimhelp.org/usr_toc.txt.html (`:h usr_toc.txt`)
Here's the reference manual: https://vimhelp.org/#reference_toc (`:h reference_toc`)
There's also a cheatsheet: https://vimhelp.org/quickref.txt.html (`:h quickref`)
Reading the docs and searching into it on a regular basis is the single best advice I could give to Vim users wanting to improve. The odd cheatsheet, the post with a few tricks and cool plugins, all those can be well and good, but nothing beats sitting down and reading the docs. I've been use Vim daily for 10+ years, and I still check help files very regularly. Knowing _how_ to search efficiently is also a skill worth acquiring.
Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.
marklgr commented on Shell script best practices, from a decade of scripting things sharats.me/posts/shell-sc... · Posted by u/sharat87
Hands down, shell scripting is one of my all time favorite languages. It gets tons of hate, e.g. "If you have to write more than 10 lines, then use a real language," but I feel like those assertions are more socially-founded opinions than technically-backed arguments.
My basic thesis is that Shell as a programming language---with it's dynamic scope, focus on line-oriented text, and pipelines---is simply a different programming paradigm than languages like Perl, Python, whatever.
Obviously, if your mental model is BASIC and you try to write Python, then you encounter lots of friction and it's easy for the latter to feel hacky, bad and ugly. To enjoy and program Python well, it's probably best to shift your mental model. The same goes for Shell.
What is the Shell paradigm? I would argue that it's line-oriented pipelines. There is a ton to unpack in that, but a huge example where I see friction is overuse of variables in scripts. Trying to stuff data inside variables, with shell's paucity of data types is a recipe for irritation. However, if you instead organize all your data in a format that's sympathetic to line-oriented processing on stdin-stdout, then shell will work with you instead of against.
/2cents
> "If you have to write more than 10 lines, then use a real language"
I swear, there should be a HN rule against those. It pollutes every single Shell discussions, bringing nothing to them and making it hard for others do discuss the real topic.
marklgr commented on Shell script best practices, from a decade of scripting things sharats.me/posts/shell-sc... · Posted by u/sharat87
And THIS is the primary source of my furious hate in my toxic love-hate relationship with bash.
Guy is writing bash FOR 10 FUCKING YEARS and still apparently doing it wrong in 10 letter oneliner.
When it comes to bash search for even simplest command/syntax always ALWAYS leads to stackoverflow thread with 50 answers where bash wizards pull oneliners from sleeves and nitpick and argue about various intricancies
It's a case of knowing the wooledge website (and working with shellcheck), or not. Picking snippets on stackoverflow will probably do more harm than good, tbh.
RPL tokens were addresses of machine code routines (stored in 20 bits)
I still remember 3223 :)