>
In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?I don't see how CLI programs avoid this. "One thing" is a human idea, subject to interpretation. Should grep and sed be consolidated? Does find do too much? Why do we have both echo and printf?
> Is "reading an email" one thing? And "writing an email" another thing?
Mutt says so. You read and sort emails in Mutt, you write emails in $EDITOR and then you can add attachments and such back in mutt.
> What about "spellchecking the email"?
Well since mutt outsources writing the email, I can't really comment on what mutt does. But if you don't want to do spellchecking within your editor for whatever reason, mutt lets you pipe the contents of anything to an external program, so you could write your email, then select the message from the attachments list and type "|aspell -a" and you'll get a basic spellcheck.
> What about "managing all my email contacts"?
I think that's pretty clearly a seperate program's duty, since contacts are used by other applications as well. Not only does mutt agree with me, so do Google and Apple. Mutt makes it simple to integrate with external contact lists to provide autocomplete for known email addresses.
> What about "back up my emails"?
That should be taken care of by both your email provider and your personal backup solution. I don't see why an email client would care about backups.
> What about "sign email with GPG"?
Well that's a job for GPG isn't it? That again can be accomplished by just piping the message into an external command. If you use it frequently you'd write some config and scripts to automate it. I saddly rarely uses PGP for email so I don't have hands on experience with this, but it looks like mutt has built in support for this kind of automation. A more unix-aligned approach would be to ship an /usr/share/mutt/examples/auto-gpg.muttrc or something like that that users can just source in their config files.
> but there is just now way you could make GIMP follow the unix principle.
No? Represent layers as a bunch of image files in a directory. Have one program check when they change and composite them in realtime. Have another program render the output of that one to the screen. Have a third integrate with the rendering program and manage the creation of selections (represented as a selection mask, so it supports everything from rectangular selection to brush selection). Drawing tools and filters become programs that take an image and a selection and some (interactive) options and output a new image. Then you have a UI program that brings all these programs together.
If this isn't as performant as Gimp, you can optimize it, for example, by replacing pipelines between parts of the standard toolchain with some kind of shared memory IPC or something similar.
It's not that the ideas behind unix don't apply to modern software; people just don't give a fuck.