This has been around for ages and ages, and I have put up with it enough... HOW does one stop the send message disappearing completely (aka, turning into a blank text) if one accidentally includes a non-ascii character in the message, as composed by the external editor (vim, in an xterm, via xterm -e vim)? There is no backup made. It does not go into Drafts. It looks like the issue is with the pipe to the send/composition window from the editor. If I remember, I save the text while still in vim. Then if it disappears (nonascii characters can be too subtle to spot by eye), I can copy it into the send/composition window later directly from the file I made. Otherwise it is Goodbye and Bless You to the text I just laboriously composed. The editor terminates OK so there is no recovery text made. Is there some configuration option that is responsible? I have searched and searched without seeing anything that looks applicable. Please figure some way to stop this - or at least TELL me about it! PTB Running debian unstable on i386: ii claws-mail 3.17.8-1+b1 i386 Fast, lightweight> ii claws-mail-acpi-notifier:i386 3.17.8-1+b1 i386 Laptop's Mail LED> ii claws-mail-address-keeper:i386 3.17.8-1+b1 i386 Address keeper pl> ii claws-mail-archiver-plugin:i386 3.17.8-1+b1 i386 Archiver plugin f> ii claws-mail-attach-remover:i386 3.17.8-1+b1 i386 Mail attachment r> un claws-mail-doc <none> <none> (no description a> un claws-mail-extra-plugins <none> <none> (no description a> un claws-mail-i18n <none> <none> (no description a> ii claws-mail-pdf-viewer:i386 3.17.8-1+b1 i386 PDF and PostScrip> un claws-mail-tools <none> <none> (no description a> un claws-mail-vcalendar-plugin <none> <none> (no description a>
Your description sounds like you should have sent it to the users' mailing list, (info here: https://www.claws-mail.org/MLs.php), as it is asking for help rather than providing details and examples so that the issue can be reproduced. If I understand correctly, you use an external editor in claws-mail, and that editor is vim. You enter a non-ascii character - any particular character? Non-ascii characters are not normally a problem, of course.
My description sounds like a BUG to me, because I have pointed out what is wrong (in my opinion), describing the circumstances (debian linux i386, versions as given) and the (unwanted) result (blank send/compose message window), as well as a way of reproducing it (run vim in eterm -e as your editor, put any old nonascii character in your wonderfully composed text, anywhere, and finish the edit normally). So I don't know why you think that it sounds like a user problem! Do you perhaps know of a user setting that cures it that would lead you to think so and that you are not telling me/us about? I'm open to the possibility that there is a user error between keyboard and chair here, but in that case the error would be that the mailer doesn't tell ME. the user, about it. Do you think that a blank compose/send window is an acceptable outcome of editing away carefully at a text for half an hour or so? Perhaps you're OK with that in a GUI, but I'm not. "Destroy your data" is not a menu item, for randomly obscure reasons ... Believe me, I am plenty frustrated and would like to have a cure for my texts being thrown away without a by-your-leave or any warning, not goofy responses. This problem has been around forever, and I am talking years and years. I've just gathered up the time and energy to REPORT it to you, who ought to have noticed it in those years and fixed it by now. You haven't. Instead of just "giving up" (on it and you both!), I am giving you the information you may need, and am willing to do such experiments as you may ask me to in order to refine that information and investigate further. I can compile fine. I can debug fine. I don't like GUIs, but as a long-time (decades!) kernel programmer, I am pretty good at debugging, Zen or otherwise, so this may be YOUR opportunity to get it fixed as much as mine. It seems to me that the problem IS at the claws end, because vim exits normally. Have you somehow magicked a 7-bit unix pipe in some compleely unimaginable way? Pipes are just socket pairs, and sockets don't care what data flows across them! Impossible! So it's in claws. Should I be using a utf-accepting version of claws? No, the send window accepts those same characters that I pasted into vim just fine when I paste them into the window directly. The problem has to be located at what you do with data coming out of the pipe from the external editor, not those going into the send window. Would "claws-mail-i18n" be expected to deal with utf characters out of ascii range? I'm happy to try and will tell you if it succeeds, if you tell me it should. But what happens right now is a BUG, provided the user has not failed by ticking a "destroy my data with no warning" box somewhere in the configuration options ... and I would really like to be told that it is so. Regards and thanks in advance for further information and hints PTB.
Ok, Peter. You misunderstand me in some ways, e.g. that you think that I think it "sounds like a user problem", which is not what I said. You've written far too much in comment #2 to make it a useful comment in a bug report. There's just far too much that doesn't need to be said in this context. Please, no more "attitude". I'll see if I can reproduce it.
I can reproduce it, if I force gvim to write the file in non-utf8 encoding. I.e. in gvim, do ":set fenc=latin1" when the text contains non-ascii (>= 127) characters. Then, after saving and quitting, the text in claws will be empty. To get around it, have gvim use utf-8 fileencoding. You can do this either globally in vimrc or just change the ext.editor command to e.g. "gvim -f -c 'set fenc=utf-8' '%s'". (See ":help enc" and ":help fenc" in vim)