Emacs plugin

[soywod]

I don't know that much about Emacs Lisp, so any kind of help is welcomed!

[dantecatalfamo]

I can offer a hand if you need any help :slightly_smiling_face:

[soywod]

Definitely @dantecatalfamo!! It is not a big priority but if someone could initiate the plugin it could be awsome

[dantecatalfamo]

I started working on it a little bit here https://github.com/dantecatalfamo/himalaya-emacs 😄 I'm working on it in a separate repo so I don't have to pollute your repo with branches and PRs but I'd be happy to add it to the tree here once it's in a good state if you want

[soywod]

Awesome :heart: with great pleasure!!

[gkmngrgn]

Hey @dantecatalfamo, do you have a roadmap? I'm an Emacs user, and I'm pretty happy using himalaya as a default email client. So I can be a tester for the plugin, or if you need any help, please let me know.

[dantecatalfamo]

@gkmngrgn I don't have an explicit roadmap, but it's in a pretty good state and I'm making decent progress. As of right now I can display the contents of mailboxes, paginate them, change mailboxes, read messages, etc. The features I haven't worked on yet are ones that modify or send mail

[dantecatalfamo]

@gkmngrgn I've gotten most of the basic features working! Check it out if you have a chance and let me know what you think :slightly_smiling_face:

[soywod]

Awesome, I will check it out whenever I can!

[gkmngrgn]

@gkmngrgn I've gotten most of the basic features working! Check it out if you have a chance and let me know what you think 🙂

hi @dantecatalfamo, first of all, congratulations! I want to give you some feedback about my tests. My default account Gmail is not what I wanted to see in Emacs inside, and I tried to customize the default account and configured it as Hotmail (for example).

However, it tries to change my mailbox instead of my account:

Error: cannot select mailbox "Hotmail"

Caused by:
    No Response: [NONEXISTENT] Unknown Mailbox: Hotmail (Failure)

Second thing, is it possible to add a new section to README.md about the installation? I think you can let the users install with straight, use-package or something else, even it's not completed yet.

Maybe I can continue to write my feedback opening a new issue on your project. Which is better for you?

[dantecatalfamo]

Thanks for the quick feedback @gkmngrgn! I found a typo that led to the error you're talking about. :grinning:

I've only ever tested it with a single account configured so I never would have caught it. https://github.com/dantecatalfamo/himalaya-emacs/commit/fe3d4d85940e4ef26012aa8330e966f7ef539979

I can make some instructions for adding the extension by git cloning it and adding the load path with use-package it for now. I'll try to get the package into MELPA as soon as it's somewhat stable.

I think feedback would be better in issues so to not pollute this issue too much. It'll also make it easier to keep track of.

Thanks a lot!

[soywod]

@dantecatalfamo I also tried the plugin and you did an awesome job! Thanks a lot. I recently switched from vim to emacs and I'm gonna use it a lot.

The only remark I have for now is about the table. When I built the table system in rust I encountered a lot of issues I did not expect: unicode chars shifting all columns, table bigger than the terminal, shrunk content etc. I took me a while to have sth stable enough. I can say now that this part of the code is one of the cleanest part of himalaya (and it is well tested). Any feedback is welcomed btw https://github.com/soywod/himalaya/blob/master/src/ui/table.rs. When I built the vim plugin, I encountered the same issues. I realized that those issues will be shared across all UIs. Every UI will need to build a table. So I updated the API in order to export this table logic. Here the commit https://github.com/soywod/himalaya/commit/43785b3c1ed15b9e726661cd17da8a68358bed9b where I made the vim plugin use the new API. I can summarize it by adding a --max-width argument (which is the size of the current buffer) and remove the --json argument (since the response will be just a string).

I realize that this information could have save you some time (sorry :disappointed:). I need to document this part for those who wants to build TUIs over himalaya.

[soywod]

There is another point: attachments. The vim plugin has an open issue about it (#47). Commands save and send take a raw message in parameter (which should include mime parts and so attachments), and this is a problem (#259). Any suggestion?

In Emacs Gnus, when we add an attachment, a line is inserted inside the body:

<#part type="application/octet-stream" filename="/path/to/file" disposition=attachment description=desc>
<#/part>

I like the concept because it is easy to add/edit/delete, but it requires some work to transform those lines into real mime parts.

[soywod]

I have a working prototype where I separated the fact to save/send a raw message and the fact save/send a message from a template:

• himalaya save/send allow us to send raw messages, without any treatment. Raw messages are composed of headers and parts, so there should be no attachment issue
• himalaya tpl save/send allow us to send messages based on template. A template is just a more user friendly version of a message (it is what users interact with when writing/replying/forwarding messages). It only contains few headers and the text/plain body. Attachments can be added with the argument -a|--attachment. It is these commands UIs will need to use. UIs will also need to manage attachments prompt.

I will update the vim plugin to see how it can be implemented, maybe it will help you doing the same with the emacs plugin!

[soywod]

Here so far what I got: https://github.com/soywod/himalaya/compare/development...attachments-save-send

For now you can only add an attachment. I think what misses is the ability to manage added attachments. I was thinking about opening a horizontal bottom split in edition mode that contains the list of attachments. We can add, edit, delete them easily and we can provide a helper prompt to add easily an attachment (with file completion). What do you think? Is it doable within the emacs plugin?

[dantecatalfamo]

@dantecatalfamo I also tried the plugin and you did an awesome job! Thanks a lot. I recently switched from vim to emacs and I'm gonna use it a lot.

The only remark I have for now is about the table. When I built the table system in rust I encountered a lot of issues I did not expect: unicode chars shifting all columns, table bigger than the terminal, shrunk content etc. I took me a while to have sth stable enough. I can say now that this part of the code is one of the cleanest part of himalaya (and it is well tested). Any feedback is welcomed btw https://github.com/soywod/himalaya/blob/master/src/ui/table.rs. When I built the vim plugin, I encountered the same issues. I realized that those issues will be shared across all UIs. Every UI will need to build a table. So I updated the API in order to export this table logic. Here the commit 43785b3 where I made the vim plugin use the new API. I can summarize it by adding a --max-width argument (which is the size of the current buffer) and remove the --json argument (since the response will be just a string).

I realize that this information could have save you some time (sorry disappointed). I need to document this part for those who wants to build TUIs over himalaya.

Thanks!

I actually rebuild the table from the JSON output using a table mode that's built into Emacs by default called tabulated-list-mode, so the column width shouldn't be an issue (hopefully).

For the Emails, I use part of GNUS called message-mode for the write and reply actions and just replace the default send function with one that I wrote that sends the contents of the buffer to himalaya send. In theory everything that already works in GNUS and mml-mode should continue to work, like MIME settings, encryption, file attachments, etc. I haven't tested them out myself yet though.

[soywod]

I actually rebuild the table from the JSON output using a table mode that's built into Emacs by default called tabulated-list-mode, so the column width shouldn't be an issue (hopefully).

So great, I did not know about this mode! Good news :slightly_smiling_face:

For the Emails, I use part of GNUS called message-mode for the write and reply actions and just replace the default send function with one that I wrote that sends the contents of the buffer to himalaya send. In theory everything that already works in GNUS and mml-mode should continue to work, like MIME settings, encryption, file attachments, etc. I haven't tested them out myself yet though.

I tried to set up an attachment and send an email, but I receive it like this:

<#part type="application/octet-stream" filename="/path/to/file" disposition=attachment description=desc>
<#/part>

Is there a way with mml to display the raw version of a message (I mean, with all parts built correctly)? If not then I'm afraid we will have to parse <#part ...> tags before sending :disappointed:

[soywod]

I found a tiny request: do you think it could be possible to add reply and forward actions to the list view?

[soywod]

Is there a way with mml to display the raw version of a message (I mean, with all parts built correctly)? If not then I'm afraid we will have to parse <#part ...> tags before sending

In fact this does not make sense. Emacs should process messages before sending them because Emacs is the one setting up this special tags <#part ...>. Sth is wrong with the integration I guess.

[dantecatalfamo]

Ah yeah it's very possible the intergations won't work too well yet, I had to do quite a bit of digging in the code to figure out which functions could be substituted and it's very possible I removed part that deals with attachments.

I can totally add reply and forward to list view! I'll try to get around to it soon :slightly_smiling_face:

[soywod]

@dantecatalfamo 8 months ago you said that you would be happy to continue maintaining the plugin. I opened 2 PRs (https://github.com/dantecatalfamo/himalaya-emacs/pull/8 https://github.com/dantecatalfamo/himalaya-emacs/pull/10) on your repository 7 months ago, you never replied. 3 months ago I received some financial support and I proposed you to be part of it, you never replied. I thought you abandoned the plugin, so I decided to fork it because I have time and money to support it right now.

But 2 days ago you pushed 2 commits on your repository and 1 commit on the melpa repository that contains the recipe for himalaya pointing to dantecatalfamo/himalaya-emacs.

I am a bit confused about the situation. I mean, you cannot be the melpa maintainer of the plugin AND not having time for replying to issues, pull requests and messages. Do you still plan to maintain it?

(PS: Do not take it personally, I can understand that you were busy for all this time. I really appreciate the work you did, and I would love to bring the plugin ta a production-ready stage. I really need to know your position, I hope you understand.)

[dantecatalfamo]

Hey @soywod, sorry about the lack of communication! I've had a lot going on in my personal life with my family and only recently began having enough free time to work on the plugin again.

My work place uses SSO on github and it seems to have a nasty bug where it hides my personal github notifications if there's a page of work-related notifications in front of them when you aren't authenticated with SSO. With all the dependabot PRs I get every day stacking up I never saw your notifications on my personal computer :slightly_frowning_face:.

I think you taking over the plugin makes sense currently since you seem to have the bandwidth to support it and I'm not sure I will in the near future. If you can figure out how to make a PR to change the fork that MELPA points to I'd be happy to give it the 👍.

If you could add your fork back to github I'd be happy to contribute when I get a chance!

[soywod]

@dantecatalfamo thank you for your reply, I really started to worry.

I've had a lot going on in my personal life with my family and only recently began having enough free time to work on the plugin again.

I'm sorry to hear that :disappointed: I hope you the best!

If you could add your fork back to github I'd be happy to contribute when I get a chance!

What about inviting me on your repo as collaborator?

1. You still own the repo
2. We do not need to change the melpa recipe
3. I can continue maintaining the plugin and you can participate whenever you can

[dantecatalfamo]

Sounds good! I'll look into that right away 🙂

[soywod]

Thank you :slightly_smiling_face: I will propose soon a PR with all the changes I did on my fork (there is few features + some rewording like mbox -> folder and msg -> email to match the lib, the CLI and the Vim plugin), then I will be able to delete the fork. I close this issue since the Emacs plugin has its own repo and is stable enough!