hyperbole icon indicating copy to clipboard operation
hyperbole copied to clipboard

Start trying out better support for composing email

Open matsl opened this issue 2 years ago • 6 comments
trafficstars

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.

matsl avatar Dec 17 '22 23:12 matsl

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

rswgnu avatar Jan 07 '23 23:01 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:

https://github.com/rswgnu/hyperbole/pull/290 Commit Summary

File Changes

(5 files https://github.com/rswgnu/hyperbole/pull/290/files)

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 https://github.com/rswgnu/hyperbole/pull/290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5WPD6KEEP2LNM4PODOFGTWNZBY7ANCNFSM6AAAAAATCF2YNM . You are receiving this because your review was requested.Message ID: @.***>

rswgnu avatar Feb 18 '23 15:02 rswgnu

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

rswgnu avatar Apr 08 '23 02:04 rswgnu

@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.

matsl avatar Oct 31 '23 14:10 matsl

@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.

rswgnu avatar Jan 14 '24 02:01 rswgnu

@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 avatar Apr 05 '24 22:04 matsl

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

matsl avatar Jun 16 '24 13:06 matsl