Start trying out better support for composing email

[matsl]

What

Start trying out better support for composing email. Implement the mail reader functionality for gnus and add a way to override the mail composer function.

Why

The mail reader support provides slightly different functionality for gnus. So could be seen as an alternative to using the Hyperbole news support. If providing this support is valuable is another question.

Users need to be able to setup their favorite mail client and have it configured for editing with as little effort as possible. This is also a start in exploring this for ideas and feedback. The variable hmail:compose-mail-other-window is the way for the user to specify how the mail composer should be started.

Discussion

This adds a new function to the email interface. A function that opens up the mail composer. The idea being that the user selects the preferred emailer and by that gets the proper setup for using email address buttons etc.

Not sure though if that fits in there. Maybe it should be its own abstraction just for this purpose? The later would maybe make it easier for users with a strange setup to customize just the function that brings up the composer!? Decided to go forward with this implementation thinking that even if the Gnus-mail-init is not called the composer can still use the hmail:compose-mail-other-window

There can still be details with composing and reading email with embedded buttons that is missing in this PR. This can be added later.

With current email standards, to not klick on something someone sent you, maybe suggests that this part of Hyperbole is not the most important to implement, or would need some redesign? I leave that discussion to later.

Would not the email interface be a good candidate to refactor to use the object oriented support, similar to the registry code? Also leaving this idea to later as the current implementation is good enough.

[rswgnu]

I'm always up for adding in good abstractions and certainly welcome improved email handling when it's ready.

[rswgnu]

We were deferring the above in case the user never used mail/messaging. Then we didn't need to load any of this or potentially overload default messaging functions.

[matsl]

This code initialized the mail reader functionality if a user tries to use a mail link. Is not that rather subtle since the user experience is change under the hood for the user? In the gnus case the gnus news functionality will be used before using the link and gnus email functionality after.

[matsl]

What do you think of on Hyperbole activation giving a warning if the user has customized the email support but not initialized it?

[rswgnu]

If it is a customization option, then you can force the initialization function to run when the value is changed. Would that solve this issue?

[rswgnu]

I am in favor of having a full abstraction for the email composer, as exists for other elements of the messaging interface.

…

On Sat, Dec 17, 2022 at 6:09 PM Mats Lidell ***@***.***> wrote: What Start trying out better support for composing email. Why Users need to be able to setup their favorite mail client and have it configured for editing with as little effort as possible. This is a start in exploring this for ideas and feedback. Discussion This adds a new function to the email interface. A function that opens up the mail composer. The idea being that the user selects the preferred emailer and by that gets the proper setup for using email address buttons etc. Not sure though if that fits in there. Maybe it should be its own abstraction just for this purpose? The later would maybe make it easier for users with a strange setup to customize just the function that brings up the composer!? Would not the email interface be a good candidate to refactor to use the object oriented support, similar to the registry code? ------------------------------ You can view, comment on, or merge this pull request online at: #290 Commit Summary - 899a79e <899a79e> Start trying out better support for composing email File Changes (5 files <https://github.com/rswgnu/hyperbole/pull/290/files>) - *M* ChangeLog <https://github.com/rswgnu/hyperbole/pull/290/files#diff-91c5b46dc84a94604a4e4d0caed9bf85590a2eddbb12d2e8dc80badf324a9dfb> (11) - *M* Makefile <https://github.com/rswgnu/hyperbole/pull/290/files#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52> (6) - *A* hgnus-mail.el <https://github.com/rswgnu/hyperbole/pull/290/files#diff-ad2ca1b79e18ca3c0354ee75ff4c72c9814e45f738fd0471cc9b40141926f8ed> (78) - *M* hibtypes.el <https://github.com/rswgnu/hyperbole/pull/290/files#diff-b85e78cb71213fb6c7d5429ec4e2322ae8a0f0cf0faef812533f1a1c99ceb1e2> (16) - *M* hmail.el <https://github.com/rswgnu/hyperbole/pull/290/files#diff-9d8e82ca693af05f71e9a353fa87423bc881286a95b292ad4302280e2bb94dd9> (9) Patch Links: - https://github.com/rswgnu/hyperbole/pull/290.patch - https://github.com/rswgnu/hyperbole/pull/290.diff — Reply to this email directly, view it on GitHub <#290>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE5WPD6KEEP2LNM4PODOFGTWNZBY7ANCNFSM6AAAAAATCF2YNM> . You are receiving this because your review was requested.Message ID: ***@***.***>

[rswgnu]

We need to finish this if it is to go in the next release.

[matsl]

@rswgnu Rebased to bring this on top of current master to make further development easier. I think for setting up mail sending for Gnus users this could be OK as is, but I have not thought through if the combined consequences are acceptable. Since gnus is both a mail reader and news reader we might be over complicating things supporting both in different ways. What I mean is that if the user is used to reading news with Hyperbole and than decides to activate the mail support the reading behavior will change!? We need to think about how to resolve that I think.

Note:

This needs further testing and development. The rmail:msg-narrow (and possibly other rmail abstract functions) is not properly configured. Marked as WIP.

[rswgnu]

@matsl, just pointing out this is still out here if you want to finish this for this release. Maybe the next one would be better.

[matsl]

@rswgnu Was thinking of starting all over with this in a new PR but for now just rebased it to bring it close to master so easier to work with. Labeled with WIP to highlight it is not ready for review.

In fact I think I need to take a step back and rethink this. Not sure we should add a mail interface to GNUS. The current news interface works well so could just keep that. Or put it this way, the reading and composing interface need to be possible to use both with GNUS and with one of the mail readers for those that don't use GNUS as their mail client.

[matsl]

Starting over again on this in another PR possibly using the built in support for different email composers better.