-
Notifications
You must be signed in to change notification settings - Fork 11
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
Feature: Composing multipart/alternative #58
Comments
+1 for this. I actually already played around with this idea a while ago. As the text editor is configurable, I simply wrapped the call to vi so that it would strip any multipart html on load and add it on save. It didn't work well with bower, though, message preview broke my multipart message. Maybe one could reuse the message view for usual messages for previewing messages to be sent? This would even enable some sort of html preview. |
Cf. wangp#58. This is a first go at the feature and remains rather unfinished. It still misses proper error handling should the filter fail, for instance. Usage is pretty straightforward and has been hinted at in bower.conf.sample.
So I started adding this feature. Here's some further notes on it. Suggestions and feedback are welcome. Edit: Tick some checkboxes in the list below. Notes on alt_html_filterThings that aren't really solved yet
Open wishes
Crazy thoughts
|
That's looking pretty good. |
Thanks. I also gave toggling the filter some thought. I don't really see the use case for toggling it on a per message basis. I. e., at least in my case, there is some sort of structure behind when I want to use the filter. E. g. I have this one sender address I want to send HTML messages from. Or I have that one friend who uses some horribly outdated Smartphone to read my emails, so I want to adjust the style of the alternative so that my emails look nice on that device. In general, I want to be consistent about the application of those rules and not forget to toggle multipart generation on every second email I send. I guess there would be two ways to get such rules working.
The second option would also allow users to make the filter as simple or as complex as they want (or need) it to be. Anything is possible, from just always run it or Additional thoughtsOne additional thought would be that we might want to add a custom use filter/don't use filter header. While I will mostly be matching from and to addresses against regular expressions to determine if I want to use a filter or not, others may find it more convenient to include the following in the header:
Or don't use the filter:
And then simply wrap pandoc in a shell script: #!/bin/sh
if test "$bower_filter"; then
pandoc -f markdown -t html
fi Someone else might actually want to use that same header as such:
#!/bin/sh
$bower_filter (I didn't really check how shell escapes and stuff work for the We could strip the |
Just a quick update on the additional thoughts: I exposed I guess the easiest way to make the filter configurable on a per-message basis is to specify it as:
I didn't strip any headers yet, and I guess that would also be an issue that deserves more thought and broader discussion. |
I was hoping to keep it simple :) If we have two config keys, That might not be convenient enough for your examples. I suggest separating the decision to add a HTML alternative from the filter itself. I don't think the |
I totally agree to keeping it simple ;) And I am well aware that the filter I am using is way over the top. So that is basically why I tried to keep as much of it out of bower itself as I could. About environment variables: I would still like the filter to be (at least potentially) aware of the email it is supposed to convert, without forcing that awareness on it either. That is basically why I used environment variables. It just seemed to be the easiest way of exposing information without changing the call to the filter itself. Note that the proposal works just as well with my over the top filter as it does with a simple invocation of pandoc. Pandoc doesn't know anything about bower, email headers and the like. And why should it. (Also note that plain pandoc doesn't work with the way they implemented the filter in mutt, since they require a somewhat customised output format.) In summary, I would still like to see the environment variable solution in bower. We might talk about which headers to expose, but in a way, simply exposing all of them is the simplest possible solution. I did feel a need to normalise the header names, since Introducing a second command that decides whether or not to use the filter is an option. But the way I see it, that would increase complexity, rather then prevent it. It is one more callout, for instance, and in case the command is meant to reach a decision based on header values, we would still need to find a way to make it aware of those. We could pass them as arguments, sure, but that would mean that users need a customised command that understands those arguments. And then there is still the issue of how to expose them. Email headers are pretty much an arbitrary map from string to string. Do we pass some of them as If you care about it, I could add an option to toggle the filter via Edit: If there was an |
The main issue is with exposing all the headers.
There's not really an issue with exposing a small, fixed set of headers.
I think it's pretty much necessary for manual toggling, see below.
Yes, there must be a way to toggle the option at runtime, otherwise it would be necessary to modify either User who only wants HTML alternative occasionally
At step 6, the User who wants HTML alternative always
User who wants HTML alternatives for specific recipients
We would write an info message "Generated HTML alternative" or "Removed HTML alternative", and combined with the HTML preview, I think it would be hard to miss. What do you think? |
Thanks a lot for the elaborate clarification. Toggling the filterI see we came up with different solutions for how to turn HTML generation on and off. I proposed to delegate that decision to an external program while you want to use a manual toggle (with a customisable default value). I guess both cases have their pros and cons, so I suppose it would be a good idea to offer users a choice between them. As far as the manual toggle is concerned, I do like your proposal. I don't quite like the idea of setting Of course, if I completely delegate the decision to an external command, that command needs to be able to reply to its call in three ways, rather than just with success or failure. The way I see it, there are two ways of achieving this:
Note that I aligned the combinations so that equivalent combinations have corresponding numbers. I guess one could argue that my solution is kind of hackish, since it interprets the data on stdout in two ways:
Of course this overloading means that there is one possible response that the filter simply cannot express: "Please add the empty string as an HTML alternative." I still went ahead with overloading stdout because I didn't consider this to be a response we would want any filter to give. The only case in which this might come up is if the message itself is empty. And I would argue that empty messages simply shouldn't be multipart. There is no point in expressing nothing in two different markups, is there? (We could, of course, still add a warning that the filter returned nothing on stdout, so that users know why they don't see any HTML preview.) Note: Even if the message is empty, the filter could still produce a html representation of nothing that bower would add. As it happens, this is what pandoc does:
For empty input, pandoc produces a single newline. As far as the current implementation of As far as the use cases are concerned, here is how it would look like in my proposal: User only wants HTML alternative occasionally
At step 6, the User wants HTML alternative most of the time
User wants HTML alternative always
User wants something more complicatedOK, if you want something complicated and customised, bower won't do it for you. Bower is meant to be kept simple. But you are free to implement your own solution and tell bower to use that as an external command.
User wants something complicated that still respects the
|
Yes, I think we should treat whitespace-only output as a signal not to generate an HTML part. (The pandoc command should probably pass
That's fine.
That's fine.
I still don't see the need for
That's fine for me. I didn't want anything except the manual option anyway :)
Great, let's forget it then.
I was a bit wary about that part of the design but with the manual override it seemed acceptable.
Agreed, we don't want the tools to have to parse RFC822-style messages (or more correctly, a custom format that superficially looks like RFC822).
Exactly.
I'm undecided how to name the environment variables. Some ideas:
We already have edit: obviously this is just bikeshedding and I don't wish it to distract from the rest of the work. We can always change things later.
Please do. |
Great. I guess the main points are clear then.
I am not quite sure about this one. Running pandoc with
Agreed. I didn't think about consistency with those yet, I have to admit. One more thought on defaultsMaybe we should use the following configuration as our default values:
That way, multipart generation would just work out of the box if pandoc is installed on the system. No configuration needed, everything is just one |
Cf. wangp#58. This is a first go at the feature and remains rather unfinished. It still misses proper error handling should the filter fail, for instance. Usage is pretty straightforward and has been hinted at in bower.conf.sample.
Cf. wangp#58. This is a first go at the feature and remains rather unfinished. It still misses proper error handling should the filter fail, for instance. Usage is pretty straightforward and has been hinted at in bower.conf.sample.
So I started moving parts from
|
Thanks for your work so far!
That's fine. I forgot about that function of
Hmm, I quite like |
Decrypting works. I will test more when closer to merging. The There's an initial blank line in the pager on the compose screen. This doesn't appear in the actual message file. |
Well, not exposing save part seems a bit like cutting corners to me. As one can select part headers in both thread pager and compose now, I would find it rather counterintuitive to have different actions associated with those headers. Maybe we can solve it if we don't
That's true. I wrapped the composed message in a It would be possible to somehow strip that blank line, I suppose. I left it in there for now, however, because I am actually not quite sure yet as to whether this change is a bug or a feature. The blank line is sort of unnecessary for plain text only emails, I guess, but I quite like it for multipart ones, as it separates the |
I don't think so. The message preview on the compose screen was never meant to replicate the functionality of the thread pager, partly because of the inevitable key conflicts. It's fine that you've exposed the open URL/parts functionality on the compose screen but I wouldn't miss it if it wasn't there. On a related note, I noticed that quoted text gets folded now in the message preview. I don't think it was a deliberate change, and I prefer the old behaviour of not hiding anything in the message preview. (You don't need to change it right now.)
You can add
I see. It's a matter of passing
It does look a bit noisy there, but the blank line is too misleading IMHO. |
I see why that wasn't necessary before. Once I could compose multipart/alternative emails, however, I greatly missed the ease with which I can inspect them in thread pager. Especially when I am experimenting with the filter command, open part becomes incredibly valuable. If I didn't have that, I would need to send the email before I could see what the filter output looks like. That really didn't seem right. (There are many other ways of getting some equivalent filter output, of course, but none of those feels particularly convenient and none gives me any guarantees that I am seeing the exact same string bower received.) Similarly, if I embed css into the html part, I really want to have a convenient way to preview that in firefox or some other graphical tool. I guess it comes down to how much one uses multipart/alternative.
Well, that could be seen as a reason to keep things separate. Or it could be seen as a reason to rethink the strategy used for assigning keybindings ;) But I guess that's a matter of taste, somehow.
You're right, of course. Just as the initial blank line, this was no deliberate change either. It came with reusing thread pager functionality in compose. I did notice both changes myself, but I am still undecided about how to handle them. On the one hand, I completely understand why you designed compose the way you did (no folding, no initial blank line). On the other hand, I also think that consistency between compose and thread pager is, generally speaking, a very desirable thing. This is why I went for wrapping plain text only email in
Actually, I don't find the blank line particularly misleading myself. Once I had noticed that it was there, it felt quite natural to me within seconds. I suppose this is why I care more about reducing noise here. Our different experiences might also be related to how much use we make of the multipart/alternative feature. Maybe you should set
Agreed. I'll just make |
OK, the initial blank line just gave me a wtf moment, so I'll have to agree with you. I made a commit that removes it for plain text only while retaining it for multipart/alternative. I hope that's fine. I guess that leaves quote folding as the last open question with this issue, right? |
Yeah, I'll look at the changes again on the weekend and merge. I'm willing to leave the initial blank line and the quote folding as is, for now anyway :) |
Cf. #58. This is a first go at the feature and remains rather unfinished. It still misses proper error handling should the filter fail, for instance. Usage is pretty straightforward and has been hinted at in bower.conf.sample.
I've merged your branch and made a few fixes. Thanks again. There's a couple of issues that I don't know when I'll get around to. Feel free to tackle them if you want :)
|
Here's a first try at the issues: <#75>.
Github didn't resolve the link to this ticket, so that's why I add the
reference manually.
|
I believe that, except for the part of conditionally switching to the HTML alternative, this feature is pretty much done. I have been using it extensively for the last months and am actually not even bothered by the manual switching. Pressing Are there still open issues to be discussed, or could this ticket be closed? |
Let's close it :) |
Regarding the possibility of composing HTML messages (alluded to in another issue:
#28 (comment)), a recent release of Mutt introduced this ability. The approach looks reasonably simple and consistent, it basically consists in piping the plain text content through a configurable external tool that produces the alternative content. That could be a source of inspiration…
The text was updated successfully, but these errors were encountered: