Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jcompost/mu 1.12 support with backward compatibility #184

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jeremy-compostella
Copy link
Owner

No description provided.

This addresses Issue #177.

Signed-off-by: Jeremy Compostella <[email protected]>
@jeremy-compostella jeremy-compostella force-pushed the jcompost/mu-1.12-support-with-backward-compatibility branch 2 times, most recently from 704856a to 466f816 Compare February 27, 2024 17:28
mu keeps changing the prefix of their function breaking org-msg in the
process. This should address issues #182 and #176.

This commit introduces helper functions looking for the right function
names as an attempt to support mu 1.12 while offering backward
compatibility.

Signed-off-by: Jeremy Compostella <[email protected]>
@jeremy-compostella jeremy-compostella force-pushed the jcompost/mu-1.12-support-with-backward-compatibility branch from 466f816 to cc25647 Compare February 27, 2024 17:36
@danielfleischer
Copy link
Contributor

danielfleischer commented Feb 28, 2024

Testing this; after sending an email I get message-do-fcc: Text is read-only and buffer shows the draft email although the email was sent. Also, the signature is duplicated.

@emacsomancer
Copy link

I think a number of bits of functionality have been shifted to use Gnus's message mode, which is why some old mu4e functions seem to have disappeared without replacements.

@gajama
Copy link
Contributor

gajama commented Mar 6, 2024

I have a work-around for the "Text is read-only" error, but haven't yet identified the best plave to fix the problem in the code itself.

The cause is that mu4e--message-separator is propertized with read-only.

As this problem doesn't occur when using mu4e without org-msg, there must be somewhere where the removal of this property happens with plain mu4e but not when using org-msg. I haven't been able to pinpoint that yet, though.

The workaround is to add some advice around message-send to remove the read-only property. For example:

(defun `my--ensure-text-not-read-only` (orig &rest args)
  (let ((inhibit-read-only t))
  (remove-text-properties (point-min) (point-max) '(read-only nil))
  (apply orig args)))

(advice-add 'message-send :around #'my--ensure-text-not-read-only)

EDIT: Oh - I also had to comment out a line in org-msg-edit-mode which adds undo to message-sent-hook, as this was barfing on the undo being to a non-visible part of the buffer. I'm not sure what this undo does (or undoes, I suppose), but things seem to be working without it. Probably removing undo from the hook in some advice on org-msg-edit-mode would be better. The buffer gets destroyed anyway, so I can't figure out why the undo is needed.

Once I've done some more testing to check that things are working correctly (for me, at least), I'll try and figure out a patch that does the same couple of fixes, without interfering with any code shared with the other MUAs.

@gajama
Copy link
Contributor

gajama commented Mar 6, 2024

Also, it seems that org-msg-edit-mode-mu4e no longer needs the message-send-hook or meesage-sent-hook additions with this version of mu4e, as the actions preformed by those pieces of code are taken care of by mu4e itself via mu4e--compose-before-send and mu4e--compose-after-send which are added to those hooks while org-msg is active.

@danielfleischer
Copy link
Contributor

@gajama it's here isn't it?

@gajama
Copy link
Contributor

gajama commented Mar 6, 2024

Yes - I meant that the read-only property must get over-ridden when using vanilla mu4e - because the "text is read-only" error doesn't happen then - but that doesn't happen when using org-msg. I've not yet been able to find where the critical difference is.

@danielfleischer
Copy link
Contributor

danielfleischer commented Mar 6, 2024

I see this delimit/undelimit function is added to before/after-save hooks, maybe it's related.

@gajama
Copy link
Contributor

gajama commented Mar 6, 2024

I'll have to look at it again, but I think that still gets called when using org-msg, although maybe not, as it's on the save hook. But you're likely right and that is the function that stops the error with plain mu4e.

I guess adding that function to the before-save-hook in org-msg could work then.

@gajama
Copy link
Contributor

gajama commented Mar 6, 2024

I couldn't work out how to get that delimit/undelimit function to fix the read-only error. I guess it's probably possible, and I didn't try very hard - I'm pretty tired this evening.

Instead, I went back to my sledgehammer of simply removing all read-only text properties from the buffer.

And, I couldn't figure out what was causing the undo in message-sent-hook to fail. So, I just added a remove-hook in org-msg-edit-mode-mu4e to get rid of the undo.

I guess both of these decisions could cause problems if, for example, the message aborts before sending. I'm not sure how I can best simulate that. But, I just wanted things to work. I'm going to test some more tomorrow, to see that things are working. Then I'll create a PR, over the weekend possibly.

It's just occured to me that the undo might be failing because mu4e--compose-after-send gets in the way, so I'll see what happens if the undo is called first. And the hook order could also be the cause of the other problems... I wonder. Maybe it is just that the org-msg bits need to fire first in the hooks?

@emacsomancer
Copy link

with mu4e shifting more and more functionality to re-use Gnus' Message-mode, to what extent can org-msg's current Message mode support be leverage?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants