If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp.
Dired can filter files with regexp; you can even fall back on GNU ‘find’ (‘find-dired’). And you can execute shell commands on filtered files in Dired (‘&’), it’s like xargs without the confusing syntax—but, of course, you can just run ‘xargs’ from it, if that’s what you prefer.
A graphical file-manager is, I find, a much nicer interface for file-management than the command-line. I see all filtered files, and I can view and edit them anytime, as I please. With the command-line, it’s like I’m working with blindfolds on.
Dired can be a nice refuge even if you’re a command-line junkie, because in-spite of its own commands (abstracting the shell), you can always drop back to the shell, as you please. Funnily enough, my usage of Dired vis-à-vis the shell is kind of the inverse of what you described, I use the shell for either quick or really complicated operations and Dired for everything else—which ends up being over 95% of my use.
> If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp.
Preference is definitely a factor, I agree with you there. But while a programming language is obviously more flexible technically, most people don't want to write a program to perform a task on their computer.
My point is that the shell is easier to script than writing Lisp (for most people; I'm sure Lisp nerds would disagree), and is more flexible than whatever facilities dired provides out of the box. To be fair, I haven't used dired more than a few times even though Emacs is my primary editor, but even if it emulates xargs or allows you to drop down to shell commands directly, it will never be as flexible for file operations as just using the shell.
The shell is not just a file manager. That's one of its primary features, sure, but it allows you to operate on files in an infinite number of ways. This is because it exposes fairly simple primitives that allow you to combine programs in ways that even their authors hadn't anticipated. This is why the do-one-thing-well philosophy is so powerful.
The famous Knuth-McIlroy story illustrates this well. Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools. Knuth's was probably more correct, better documented, and handled edge cases better, but McIlroy's obviously required far less effort and would be easier to understand and expand. I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.
My points were, first, Dired is easier than the shell for 99% of file management, as it’s a graphical file manager with many advanced functions. It’s literally a graphical ‘ls -l’ that that you can freely move around, browse and act on; the same way vi was a graphical ed. And, second,
> it will never be as flexible for file operations as just using the shell
for the remaining 1% where the shell would be easier than a Dired built-in, I’d rather do them from Dired, because, being a graphical program, I have a dynamic directory listing that I can peruse as I please. And the shell is the shell, whether you open a command-line in your terminal emulator or run shell commands from Dired.
Maybe the shell’s primitives are too abstract and I prefer them abstracted behind Dired. Emacs Lisp has primitive functions, too, it’s just the higher-level functions are useful most of the time.
> Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools.
Yes, now let’s see McIlroy publish the C source of the Unix built-ins he used to be fair to Knuth in that comparison, who provided the whole source of his implementation.
Composibility was an afterthought when making C, and that’s what Unix inherits; redirecting text with pipes between different programs will never be as simple and elegant as an interface that was made for composibility and extension, from the programming language up—Lisp Machines. I have scarcely found shell one-liners to be elegant in the sense they make sense at first glance—granted I’m a user, not a programmer. Lisp functions—functional programming—on the other hand, when used together, have an intuitive flow, especially in how they modify input, that’s easy to wrap my head around.
But the word runs on Unix shell, much, much more so than a functional-programming-language REPLs—“worse is better” like you said earlier.
> I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.
Writing little Emacs Lisp functions—combining more abstract built-in Emacs Lisp functions—feels a lot like chaining shell command together, but better.
It’s unnatural to put the flags after the command. But sometimes I remember I’ve to use a flag after I’ve entered the input; other times, I notice a flag’s omission after executing it, and Control + P puts my cursor at the end, after the input.
Aren’t Hangul consonants joined with vowels to create syllabic blocks? Is that still an alphabet? It seems different to the distinct characters for letters and vowels that the Latin alphabet, for example, has.
I don’t get it, they named every major smartphone maker (“Samsung, Xiaomi, Motorola, Vivo, Lenovo and Realme”) excluding Apple—if everyone gets to do exclusive launches, isn’t that the opposite of anti-trust?
The response is in your comment itself "every MAJOR smartphone maker".
That means both that minor makers or sellers were excluded. And also that major sellers had to abide but Amazon or Flipkart rules to stay in the program. For example by selling new models exclusively on these platforms.
> … getting users hooked on to the extra features and switching to some propreitary backend …
If they do, they’ll have to bridge it to Matrix. The entire point of a Matrix messenger is being able to message Matrix; no matter how slick the GIFs or the local AI-models are—people won’t use a Matrix messenger that can’t message Matrix.
They will if there are sufficient users that communicate only within the app - it's basic Embrace Extend Extinguish. Introduce new features that don't work as well on other Matrix apps, "encourage" users to convince others to switch to this app (Apple has proven that all it takes sometimes is a different colour!), and relegate the Matrix connection to a low priority non-default option over time.
The problem with bootloaders is they really can’t spare a lot of storage. Storing different QR codes for all the common errors might be asking too much.
You don't need to store the whole QR code, just code to convert an URL into a QR code. Or a good, short URL that can easily be typed, e.g. "microsoft.com/errors/1234"
