Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 10:23, John Doherty via mailmate wrote: > On Sun 2023-01-22 04:15 PM MST -0700, wrote: > >> My need, and I expect this is shared by many, is to give attachments a >> useful name before saving to their proper home. > > I noticed today (as a result of reading this thread) that if you hold the > option key down when you click on the "Save" button for the attachment, you > are presented with a normal "Save As..." dialog and can put the attachment > anywhere you want with whatever name you want. > > I just guessed that this was likely to work this way and lo and behold, it > did. > I like it ✅ Confirming this also works via “Quick Look Attachment” where pressing the option key while clicking on “Open With Preview” lets you rename and/or move the opened document. Regards Gavan ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
Apologies for miscasting… to the extent that makes sense, read Malcolm where I have written Robert, otherwise the names are meant as placeholders for generic roles and, are in no way to be interpreted as applying to any real person past or present. ;) On 23 Jan 2023, at 10:15, Gavan Schneider wrote: On 23 Jan 2023, at 8:05, Malcolm Fitzgerald wrote: On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: Keep read-only flag to reduce my productivity Well, it is, reading the notes helps: New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. Thank you for reading the notes a lot better than myself, and now I will head into the “Hidden Preferences” zone for the first time. Let’s see… Hmmm MailMate Help gives an example: gavan@Rosebud ~> defaults read com.freron.MailMate MmDefaultBccHeader 2023-01-23 09:08:54.144 defaults[35710:3326831] The domain/default pair of (com.freron.MailMate, MmDefaultBccHeader) does not exist Not a good start, and likely to produce many serious problems if dabbling continues. Recipe anyone? My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. The name change is needed for those companies who think they are so important in my life that only they would have an attachment called “Statement”, and that I will only ever need one! Another case is for when an invoice attachment has been entered in “the books” and saved in the relevant folder — I preface the file name with the accounts reference number. Many other use cases are easy enough to imagine. This is not risky behaviour and no-one needs to be protected from it. And, while Robert makes the case that users are not always happy when they have made some changes to attachments, there may be good reasons why they attempted a change. Basically, in some cases, help will be needed to repair an error in an otherwise necessary process. Which likely means, down the track, Robert and others, will be asked to remove this barrier to normal processes, and, given humans are involved, occasionally have to help when the user makes a mistake while doing what they were meant to do. Anyway the default setting is now in what could be considered “least change == least harm” which sounds good for what is, as far as I am concerned, a , and is only getting in the way. Propose: == This setting becomes the first to be alterable via the UI under a new tab “Advanced” in the “MailMate>Settings…” interface Or, maybe better: = When an enclosure is opened with the “Quick Look Attachment” process, and then “Open with Preview” is selected I get a *copy* of the attachment which is not locked. The original attachment can stay in place and be there for any salvage operations as needed. And, instead of the “filename (copy).pdf” name, may I suggest “filename.3456.pdf”, where 3456 is the number given to the message .eml file. This is so Spotlight can help me find the relevant email unless it has already been deleted. Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920 ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On Sun 2023-01-22 04:15 PM MST -0700, wrote: My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. I noticed today (as a result of reading this thread) that if you hold the option key down when you click on the "Save" button for the attachment, you are presented with a normal "Save As..." dialog and can put the attachment anywhere you want with whatever name you want. I just guessed that this was likely to work this way and lo and behold, it did. ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 8:05, Malcolm Fitzgerald wrote: On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: Keep read-only flag to reduce my productivity Well, it is, reading the notes helps: New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. Thank you for reading the notes a lot better than myself, and now I will head into the “Hidden Preferences” zone for the first time. Let’s see… Hmmm MailMate Help gives an example: gavan@Rosebud ~> defaults read com.freron.MailMate MmDefaultBccHeader 2023-01-23 09:08:54.144 defaults[35710:3326831] The domain/default pair of (com.freron.MailMate, MmDefaultBccHeader) does not exist Not a good start, and likely to produce many serious problems if dabbling continues. Recipe anyone? My need, and I expect this is shared by many, is to give attachments a useful name before saving to their proper home. The name change is needed for those companies who think they are so important in my life that only they would have an attachment called “Statement”, and that I will only ever need one! Another case is for when an invoice attachment has been entered in “the books” and saved in the relevant folder — I preface the file name with the accounts reference number. Many other use cases are easy enough to imagine. This is not risky behaviour and no-one needs to be protected from it. And, while Robert makes the case that users are not always happy when they have made some changes to attachments, there may be good reasons why they attempted a change. Basically, in some cases, help will be needed to repair an error in an otherwise necessary process. Which likely means, down the track, Robert and others, will be asked to remove this barrier to normal processes, and, given humans are involved, occasionally have to help when the user makes a mistake while doing what they were meant to do. Anyway the default setting is now in what could be considered “least change == least harm” which sounds good for what is, as far as I am concerned, a , and is only getting in the way. Propose: == This setting becomes the first to be alterable via the UI under a new tab “Advanced” in the “MailMate>Settings…” interface Or, maybe better: = When an enclosure is opened with the “Quick Look Attachment” process, and then “Open with Preview” is selected I get a *copy* of the attachment which is not locked. The original attachment can stay in place and be there for any salvage operations as needed. And, instead of the “filename (copy).pdf” name, may I suggest “filename.3456.pdf”, where 3456 is the number given to the message .eml file. This is so Spotlight can help me find the relevant email unless it has already been deleted. Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920 ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 23 Jan 2023, at 9:15, Robert M. Münch wrote: On 20 Jan 2023, at 9:06, Robert M. Münch wrote: At least, this super annoying feature should be an option, like: *Keep read-only flag to reduce my productivity* Well, it is, reading the notes helps: *New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled* As someone who is regularly asked to assist when an email attachment has been modified this default makes so much sense. Knowledgable users can modify their settings to suit themselves, everyone else gets the benefits of a safe setting. thank you, Malcolm ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] 5933: Dragging files into a folder => files are locked (immutable set)
On 20 Jan 2023, at 9:06, Robert M. Münch wrote: > At least, this super annoying feature should be an option, like: *Keep > read-only flag to reduce my productivity* Well, it is, reading the notes helps: *New: Attachments in the cache are now always saved in a locked state. This can be disabled at your own risk: MmAttachmentsCacheImmutableStateDisabled* I take the risk! Viele Grüsse. Robert signature.asc Description: OpenPGP digital signature ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Pasting text results in image - how to fix?
Scott 2023-01-22 0:42 wrote: > For a while now (over a year, possibly more), I've found that when I paste > text into a compose window on MailMate, instead of just getting the text, it > is turned into a Pasted Image (PNG, I think). I have experienced this as well. Anything that is not pure plain text will result in an attached image. A workaround is to use the command "Paste as Plain Text" in the Edit menu. Hold down Shift + Option to see it. Keyboard shortcut: Shift + Option + Command + V You can remap this to plain Command + V with Apples Keyboard system settings. Fredrik ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Pasting text results in image - how to fix?
I agree, this is frustrating. I do the same -- cmd-tab into BBEdit then cmd-N, cmd-A, cmd-C, cmd-W, click "delete", cmd-tab to MailMate, cmd-P. --Randall On 21 Jan 2023, at 15:42, Scott wrote: Hello, For a while now (over a year, possibly more), I've found that when I paste text into a compose window on MailMate, instead of just getting the text, it is turned into a Pasted Image (PNG, I think). This is somewhat infuriating, as I end up taking the same text from the Clipboard, pasting it into Sublime Text, select-all, copy, and THEN pasting it into MailMate. Is it just me? Is there a workaround? The source text is often from various web-apps I use for work, but, no other application besides MailMate seems to have an issue with it. I can take the same Clipboard and paste into a Terminal session, vim, any text editor, DevonThink, doesn't matter...always works. But MailMate will almost always turn pasted text into an image. I'm guessing there's extraneous information in the copied data which is making MailMate assume I'm trying to paste binary content, perhaps. Would be great if someone knows a way around this! Regards, Scott ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Pasting text results in image - how to fix?
I just tried (Mailmate 5898, Big Sur) and it works OK, I just get the text. Not very helpful, I admit. Alain On 22 Jan 2023, at 0:42, Scott wrote: Hello, For a while now (over a year, possibly more), I've found that when I paste text into a compose window on MailMate, instead of just getting the text, it is turned into a Pasted Image (PNG, I think). This is somewhat infuriating, as I end up taking the same text from the Clipboard, pasting it into Sublime Text, select-all, copy, and THEN pasting it into MailMate. Is it just me? Is there a workaround? The source text is often from various web-apps I use for work, but, no other application besides MailMate seems to have an issue with it. I can take the same Clipboard and paste into a Terminal session, vim, any text editor, DevonThink, doesn't matter...always works. But MailMate will almost always turn pasted text into an image. I'm guessing there's extraneous information in the copied data which is making MailMate assume I'm trying to paste binary content, perhaps. Would be great if someone knows a way around this! Regards, Scott ___ mailmate mailing list mailmate@lists.freron.com https://urldefense.com/v3/__https://lists.freron.com/listinfo/mailmate__;!!JFdNOqOXpB6UZW0!pFSFgxwR-8z4t2xum4_wWZFfM3o3NTAA0hZhba5kiptXSjIcVxkr6IX_-krTCaPEhEMPrwCUhsnNvCF5yhYuqQ$___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
