Re: [Mutt] Hide a message?
Mihai Lazarescu wrote: On Wednesday, December 12, 2018 at 19:39:25 +0700, Victor Sudakov wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Limit to negated pattern does not work? E.g., to see all messages *except* those with 'mutt' in subject: ! ~s mutt It does work, but as I said in another mail, I use limiting interactively, so as soon as I limit the messages by some other criterion, the undesirable message will show. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [Mutt] Hide a message?
On Wednesday, December 12, 2018 at 19:39:25 +0700, Victor Sudakov wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Limit to negated pattern does not work? E.g., to see all messages *except* those with 'mutt' in subject: ! ~s mutt Mihai
Re: Hide a message?
Claus Assmann wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Maybe this works: show only messages matching a pattern Details can be found in the documentation. Well, I often use limiting to show only useful messages in a mailbox (e.g. ~f from a certain person only, or ~s by subject). But it has never occured to me to use it for showing all messages but one. Can scoring be used for hiding messages? I think not :-( -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On Wed, Dec 12, 2018, Victor Sudakov wrote: > Is there a way to hide a message (e.g. with a certain subject) from view in > a mailbox, without actually deleting it? Maybe this works: show only messages matching a pattern Details can be found in the documentation.
Hide a message?
Dear Colleagues, Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? The dovecot IMAP server keeps its folder (mailbox) metadata as a pseudo-message. When I access those mboxes locally with mutt, I see this pseudo-message but I don't want to. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [Mutt] Re: [Mutt] Re: Group reply To-vs-Cc recipients
On Tuesday, December 11, 2018 at 18:23:11 -0600, Derek Martin wrote: On Tue, Dec 11, 2018 at 09:51:08AM -0800, Kevin J. McCarthy wrote: > On Mon, Dec 10, 2018 at 05:29:01PM -0600, Derek Martin wrote: > > [...]since these are normally secondary recipients of the reply. > > > >It recomments Mutt's current behavior, for precisely the reasons I > >gave in support of it. > > Okay, that's a good argument for keeping the default behavior as-is. > > But the "reason" supplied by the RFC, which I snipped to emphasize, > is a bit weak. I'm not sure why you think that. You, just now, responded to something I said. Without the thing I said you have no purpose in replying to the message. Therefore principally, inherently, it is me that you are responding to... no one else said the thing you're responding to, only me. I am the only principle recipient of your message. Everyone else who is a recipient, inherently, you are just keeping in the loop, because they may be interested in your follow-up to my message. That's exactly the stated purpose of the Cc: line. That is a fact, and it's a fact your mailer can easily deal with. Both behaviours are useful, for distinct use cases. An example: 1. Incoming: manager-to-team members, with team members in To: + some recipients from aux services in Cc:. Replies from team members very likely should have only the manager in To: and the rest in Cc:. 2. Incoming: manager-to-managers all at same level and all in To: + some aux recipients in Cc: (e.g., secretaries) Replies from other managers should preserve the incoming To:/Cc: distribution. Technically, To: and Cc: deliver the message the same way. So the RFC could have discarded Cc: altogether. However, Cc: is there exactly because of the carbon-copy era distinction between primary and secondary recipients, which matters in some use cases. If and when the Cc:/To: distinction matters and how the recipients should be distributed between these fields is only environment- and user-specific. The RFC or other static rules cannot determine it universally. That's why the RFC and other MUAs allow both behaviours. Mihai
