I read mails with mutt and a lot of people send mail with both plain and html version.
I prefer to see html version with elinks in some cases so I had to set text/html as my preferred alternative.
However, when replying, the quote is infamous (a lot of ugly characters) so I'd like to use the text/plain version in the quote.
Two linked questions emerge:
is it possible to have alternative_order option set depending on the folder
is it possible to quote the text version of the email even if the mail was seen in html
This question has also bee asked on http://www.debian-administration.org/articles/75#comment_28 without reply.
Using the result from another question related to mutt configuration, I can think of a solution to set the alternative_order:
Suppose, I prefer to see plain text on folder1, html elsewhere:
#this reset all conf when changing folder
set my_reset_source=`~/.dotfiles/mutt/reset.sh ~/.dotfiles/mutt/*.config > /tmp/mutt-reset`
folder-hook . source /tmp/mutt-reset
folder-hook . source ~/.dotfiles/mutt/html_prefered
folder-hook folder1 source ~/.dotfiles/mutt/plain_prefered
with ~/.dotfiles/mutt/plain_prefered, being:
alternative_order text/plain
This solution, however does not answer the other part of the question: how to always quote the plain text version.
Related
I'd like to have .po-file without path-comments (location). Our team has because of them a lot of trouble during git-merge.
I can get the file without comment using command:
$ xgettext --no-location -o input.po output.po
BUT! It removes headlines in the file beginning as well. Without those headlines PoEdit does not work correctly.
How can i remove all path-comments but store headlines in *.po file?
You answered your own question: use --no-location.
--no-location does not remove the gettext header (which you probably mean by "headlines"). It would make no sense for it to do it and Poedit itself uses it for its own PO(T) file(s).
Your problem is in your command — read xgettext manpage, it is for extraction from source code, not manipulating existing PO files (that's what msgcat is for).
I am copying a bunch of log output to a github issue and I want to indent it so that it is distinguishable as code/output from the rest of the issue.
How do I do this?
I tried:
CTRL+Tab
CTRL+[
CTRL+]
CTRL+Spacebar
but none seem to work? I really don't want to do every single line individually..
Wrap your code inside ```.
You can also specify language name after if your log file is analogus to any programming language's syntax.
e.g.
```yaml
You can refer Gihub Flavored Markdown for more info.
This question is increasingly esoteric, as we generally migrate away from text-based email reading. But often, I read and send email using mutt. When I copy something from a web page (usually encoded as utf-8), and then paste it into mutt, I get weird character encodings. Like, \xe2\x80\x9cWhen push .. (for a double quote).
I am using Mutt 1.4.2.3i (2007-05-26);
My shell is GNU bash, version 4.0.10(2)-release (i386-portbld-freebsd7.2);
My .bashrc file has export LANG=en_CA.UTF-8;
In my .muttrc, I specify set charset = "en_ca.UTF-8";
Indeed, in mutt itself, if I type :set &charset ?charset I get back charset="utf-8".
But I still don't get the result I'm looking for: when pasting text into an email, I get incorrect characters. Thanks!
Keep in mind that mutt uses vi as its editor...
I have link generating web app. I'd like to make it easy for users to email the links they create to others using gmail, yahoo mail, etc. Yahoo mail has a particular quirk that I need a workaround for.
If you have a Yahoo mail account, please follow this link:
http://compose.mail.yahoo.com/?body=http%3A%2F%2Flocalhost%3A8000%2Fpath%23anchor
Notice that yahoo redirects to a specific mail server (e.g. http://us.mc431.mail.yahoo.com/mc/compose). As it does, it decodes the hex codes. One of them, %23, is a hash symbol which is not legal in a query string parameter value. All info after %23 is lost.
All my links are broken, and just using another character is not an option.
Calling us.mc431.yahoo.com directly works for me, but probably not for all users, depending on their location.
I've tried setting html=true|false, putting the URL in a html tag. Nothing works. Anyone got a reliable workaround for this particular quirk?
Note: any server-based workaround is a non-starter for me. This has to be a link that's just between Yahoo and the end-user.
Thanks
Here is how i do it:
run a window.escape on those chars: & ' " # > < \
run a encodeURIComponent on the full string
it works for most of my case. though newline (\n) is still an issue, but I replace \n with space in my case and it worked fine.
I have been dealing with the same problem the last couple of hours and I found a workaround!
If you double-encode the anchor it will be interpreted correctly by Yahoo. That means change %23 to %2523 (the percent-sign is %25 encoded).
So your URI will be:
http://compose.mail.yahoo.com/?body=http%3A%2F%2Flocalhost%3A8000%2Fpath%2523anchor
The same workaround can be used for ampersand. If you only encode that as %26, then Yahoo will convert that to "&" which will discard the rest of message. Same procedure as above - change %26 to %2526.
I still haven't found a solution to the newline-problem though (%0D and %0A).
For the newline, add the newline as < BR > and double encode it also, it is interpreted successfully as new line in the new message
I think you're at the mercy of what Yahoo's server does when it issues the HTTP redirect. It seems like it should preserve the URL escaping on the redirect, but isn't. However, without knowledge of their underlying application, it's hard to say why it wouldn't. Perhaps, it's just an unintended side effect (or bug), or perhaps some of the Javascript features on that page require them to do some finagling with the hash tag.
When downloading a file with Response.Write spaces in the file name are replaced with underscores, and when the associated application opens, a number in square brackets is appended:
Response.AppendHeader("Content-disposition", "attachment; filename=this is the file.xml");
Response.Write(dr["InfopathDoc"]);
This results in this file name in the associated application:
this_is_the_file[1].xml
How can I get rid of the underscores and why do I get the [1] ?
Thanks
Found the solution for this problem here
http://dotnetslackers.com/Community/blogs/kaushalparik/archive/2009/05/06/file-download-problem-filename-with-spaces-truncated-in-ff-and-replaced-by-underscore-in-ie.aspx
To solve problem for FF, add quotes around the filename as
Response.AddHeader("Content-Disposition",
"attachment; filename=\"" + filename +
"\"");
And for IE, replace spaces with '%20'
filename = toDownload.Name.Replace(" ", "%20");
On the net there are some solutions suggested to this kind of problem. Not all solutions work everywhere and for all browsers, but some solutions at least guarantee "save results" although they cannot keep the originally "suggested" filename for all clients:
First sight:
Content-Disposition: attachment; filename=My New Document.pdf;
FF36: Presents for download the file "My" :-(
IE6: Presents "My New Document.pdf", but on opening it may appear as "My New Document[1].pdf".
IE8: Presents "My_New_Document.pdf", but may also append "[1]" as IE6.
ATTN: On saving the document, IE keeps the presented name, regardless of what it hands out to the selected application on direct opening!
First improvement:
Content-Disposition: attachment; filename="My New Document.pdf";
FF36: Works as supposed, i. e. presents "My New Document.pdf".
IE6+IE8: No change, just as before.
Second change:
Content-Disposition: attachment; filename="My%20New%20Document.pdf";
(replace blanks by %20, as in URL encoding, and keep double quotes.)
FF36: Presents what was sent back, which is "My%20New%20Document.pdf". Not nice.
IE6+IE8: Presents "My New Document.pdf", but hands out "My%20New%20Document.pdf".
Third variation:
Content-Disposition: attachment; filename=My%20New%20Document.pdf;
(Remove double quotes, but keep %20.)
FF36: As above -- not nice.
IE6+IE8: As above -- not that nice also.
Conclusion:
It seems that at least the presented methods do not solve the problem all and forever: Neither do they cover all situations for 1 browser, nor do they cover all browsers for the any same one selected situation.
For me, the best result seems to be possible with surrounding double quotes: For FF36 and IE6 that works, and for IE8 (and probably for IE7) it is at least stable with the underscores, i. e. download & save render the same file name as download & open, except the "[1]" which we cannot prevent anyway.
Final remarks
Some people go with the little king of Saint-Exupérys "The Little Prince" which said that an emperor cannot really expect that his people follows when he demands what is simply not possible, causing him to command the sun to rise and set just when it naturally happens to do so. Like this king gets in trouble when his small planet accelerates its rotation more and more, these people have given up and simply add underscores on the server side already. :-)
But the RFCs on this topic and what browser implementors offer is quite hard to overcome sometimes.
If anyone is still interested:
This kind of file name rewriting is done by the browser only as you can see when inspecting the received HTTP response with an appropriate tool, independent of the browser used. IE first downloads the requested file into its "Temporary Internet Files" folder system (which is not just one, but this is another topic), and for this purpose the file receives a new name, making best match to the "Content-Disposition" suggestion from the HTTP response. But if an equally named file is already present in the actual "Temporary Internet Files" folder actually used for this file, its name is extended by a sequenced number in brackets, like "[2]". Because every new HTTP request causes the IE cache mechanism to newly compute the actual cache folder, and the next cache folder chosen may not yet contain a file with that name, the number may seem to vanish at the next download of a file or resource with the same name.
If a downloaded file is stored somewhere, the originally suggested file name is used again usually, depending on the IE version. Some versions and patch levels seem to use the cache folder file name instead :-(
The problem starts to become annoying when the browser hands out a downloaded file to a chosen or automatically selected application. In this case the application is called to open the file directly from the cache, which is bad for at least 2 reasons:
(1) The file name will be the name of the file in the cache folder, not the suggested name. This may even strip the extension, which will confuse some applications even if they have been chosen for handling the file correctly.
(2) If an internet newbie user downloads and opens a file for editing and then simply presses the "Save" button of the application, the file is simply saved into the IE cache folder, and no user of this kind will ever find this file again. These are things which can turn people really angry and desperate...
Shouldn't you be using Response.Output.Write() instead, after HTMLEncoding the output? :
Response.Output.Write(Server.HtmlEncode(Convert.ToString(dr["InfopathDoc"])));
Edit: The underscores and the [1] appended to the filename suggest that it is being loaded from the Temporary internet files folder. There is insufficient information to deduce why this may be happening, but maybe this information will provide you a clue.
Did you try replacing spaces with "%20" (without double qoutes) like in urls?
But you should consider to avoid spaces in filenames (in urls).
Apparently this is an issue with IE7 and requires a hotfix:
http://support.microsoft.com/kb/952730/en-us
Still don't know about the number being appended though - I thought maybe it is because a file of the same name already exists in the IE temporary download folder, but that's not the case.