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

replying to html #28

Closed
sa5bke opened this issue Nov 23, 2017 · 11 comments
Closed

replying to html #28

sa5bke opened this issue Nov 23, 2017 · 11 comments

Comments

@sa5bke
Copy link

sa5bke commented Nov 23, 2017

I really like bower but I have one problem. I can view HTML mails ok with

html_dump = w3m -dump -T text/html

but when replying to them the HTML text is not quoted. Any solution to that?

@wangp
Copy link
Owner

wangp commented Nov 23, 2017

Not yet. I think we would need to generate the reply template using the result of notmuch reply --format=json, which would allow us to (conditionally) quote any inline text attachments as well.

@xunam
Copy link

xunam commented Apr 22, 2020

Hi, I just want to reactivate this issue. Replying to HTML-only messages is inconvenient.
Currently I either copy-paste the text in the editor, or I switch back to mutt for replying…

@wangp
Copy link
Owner

wangp commented Apr 25, 2020

I was wondering if we can respond to HTML messages "in kind" (not replying only with text/plain).

Ideally there would exist a suitable program that we can pass the HTML body to, then read back in when it is done editing, e.g. a wysiwyg HTML editor. I experimented with using pandoc to convert a few HTML emails to markdown, for editing in a text editor then converting back to HTML. The results were not promising. It seems like HTML emails in the wild use far too many tables for layout, so everything ends up in tables.

You would not be able to edit headers except at the compose screen, and bower could not automatically insert quote markers or wrap the reply body in a blockquote or whatever is customary.

Other ideas welcome.

@xunam
Copy link

xunam commented Apr 27, 2020

This seems a bit too complicated and it would probably add many opportunities to break. As you point out, HTML emails are way too variable in their structure (or lack thereof) to be treated in a uniform way using converters. I tried using Pandoc already as HTML-to-text converter and got to the conclusion that it is not the right tool in this context, because it tries too hard to keep structure (and is really good at that), while the main thing needed in a mail reader is to extract text and remove cruft. Tools like lynx of w3m are way better at this task.

My opinion is that the first thing needed is to be able to reply to HTML-only messages in plain text, using the same converter as the one used for displaying. For instance, when the original message has no plain text content, replace the (empty) body generated by notmuch reply with one built using the displayed content.

Regarding a switch to HTML composition when replying to a message in HTML, I think it is an orthogonal issue. Calling an editor for HTML could be useful on occasion (either edit HTML using an appropriate tool or for instance compose a message in markdown and have Pandoc convert it to HTML, whatever), but it does not have to be tied to message formats when replying.

wangp added a commit that referenced this issue May 24, 2020
…ger.

In particular, this allows replying to HTML-only emails by converting
HTML parts to plain text.

Closes #28
@wangp
Copy link
Owner

wangp commented May 24, 2020

You can test the reply-json branch now if you like. I will test it more and probably improve the code before merging onto the master branch.

@xunam
Copy link

xunam commented May 26, 2020

Somehow I can't manage to compile the code from this branch. The symptom I get is this:

$ make
make[1]: Entering directory '/home/manu/soft/source/bower/src'
Making Mercury/cs/compose.c
compose.m:441: In clause for predicate `prepare_reply'/4:
compose.m:441:   error: undefined symbol `maybe_default/2'.
compose.m:442: In clause for predicate `prepare_reply'/4:
compose.m:442:   error: undefined symbol `maybe_default/2'.
compose.m:443: In clause for predicate `prepare_reply'/4:
compose.m:443:   error: undefined symbol `maybe_default/2'.
** Error making `Mercury/cs/compose.c'.
make[1]: *** [Makefile:9: bower] Error 1
make[1]: Leaving directory '/home/manu/soft/source/bower/src'
make: *** [Makefile:5: bower] Error 2

This appears with commit abcb194.

The NEWS file stats that I need Mercury 14.01 or above so the one I use (from Nixos version 19.09, if that matters) matches the requirement:

$ mmc --version
Mercury Compiler, version 14.01.1, configured for x86_64-unknown-linux-gnu
Copyright (C) 1993-2014 The University of Melbourne

How can I diagnose this further ?

@wangp
Copy link
Owner

wangp commented May 27, 2020

It will compile with 14.01 now.

@xunam
Copy link

xunam commented May 27, 2020

Indeed. I just compiled it and successfully replied to a HTML-only message. So it works, as far as I am concerned…

Thanks !

@xunam
Copy link

xunam commented May 28, 2020

Actually the initial issue for replies also applies to forwarding: when pressing W while on a HTML-only message, one gets a template message with nothing else than headers between the lines Forwarded message and End forwarded message. I feel that the work already done for replies can also solve this (hence I included in the same issue).

@wangp
Copy link
Owner

wangp commented May 31, 2020

I've updated forward and edit-as-new functionality to match.

@xunam
Copy link

xunam commented Jun 3, 2020

It works for me, as far as I can see.

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

No branches or pull requests

3 participants