| From: ac via talk <talk@gtalug.org> | I practiced with my first top post in 2006, before it became | fashionable :) It has been gauche for a lot longer than that :-) It can make sense in business correspondence where a precise record of what you are responding to is important. This was not such a case. It can make sense when you are dealing with folks who only know how to do mail on smartphones. This was not such a case. It can make sense when your time is more valuable than the readers' time. This was not such a case. It is almost never the case on a mailing list. | From: ac via talk <talk@gtalug.org> | It was one fine spring day, at least over 180? (it may be 280 or even | more) something full moons ago that i realized that Mutt simply sucks at | threading, so I disabled it. Since then, I also thought that some/ALL | Linux console users probably also battle and struggle with threads (and | the worth/value which the unwashed places in threads) I congratulate | you on the fine prowess of your "mail reader" but it is probably not | console based? (or maybe it could be? is it Pine? not looked at Pine | in decades...hmm, maybe?) | | As you said "almost all others" it certainly is not any? console users, | unless Pine or something else has turned me into an ignorant dino... I don't understand this. But I'll respond to a couple of things that I think I've gleaned from it. I use ALPINE (PINE is dead). It can do threading. It works on a terminal. What am I missing? I actually use procmail to sort GTALUG mail into a "folder". It turns out that all the messages in this thread are lined up appropriately by being sorted in arrival order. I don't often use thread-order. I use it often enough that I don't have to look it up. I guess I might use it more if I didn't demultiplex my incoming mail. How do you handle/avoid the deluge of email? I ask in all humility since it is a burden as well as a blessing. If Mutt is broken, fix it. It's open source. Or, more likely, you'll come to understand why it does what it does. Anecdote: The second assembly language I learned was PDP-8 PAL. I was offended by the opcode mnemonics chosen by DEC. For example, the only add instruction was "TAD" (for Two's complement ADd). Would ADD not be better? But by the time I learned enough to attempt the task, I had started to think of the operation as TAD. This is an example of starting out intending to change a tool and ending up changing me. Sub-anecdote: The PDP-8 was a single-accumulator machine. And there was no instruction to load a word from memory into the accumulator! Instead you arranged for the accumulator to be 0 and than "TAD memory" to add the content of the memory word that 0, leaving the sum in the accumulator. So TAD was a heavily used instruction. There were only eight opcodes, but two of them had modifier bits. The PDP-8 machine language was incredibly easy to learn even if it wasn't very powerful. Much simpler than any micro people use now.