Disabling threading on a per-group basis
Is is possible to disable threading on a per-group basis? C-M-t seems to disable/enable threading globally. Thanks ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: nnimap and other clients
On Sat, 22 Jan 2011 21:13:30 +0100, Lars Ingebrigtsen wrote: Hi everyone. I noticed that if I move a message among folders (via another imap client) Gnus doesn't pick up the change (and doesn't seem to notice the different article count anyway). Does `M-g' on the nnimap groups do anything? No, I can't say it does any difference. Is there anything more radical I can run on a group to completely purge/refresh/rescan it? Anyway, nnimap has been rewritten for Emacs 24, so this problem is probably gone by now. (And new ones have been created. :-) New bugs, mhh yummy. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
nnimap and other clients
Hi everyone. I noticed that if I move a message among folders (via another imap client) Gnus doesn't pick up the change (and doesn't seem to notice the different article count anyway). Is there a way to regenerate such caches? Is there a way to make this automatic (in case other clients modify imap folders)? Thanks ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: nnimap and other clients
On Mon, 17 Jan 2011 22:14:10 +0100, Richard Riley wrote: Hi everyone. I noticed that if I move a message among folders (via another imap client) Gnus doesn't pick up the change (and doesn't seem to notice the different article count anyway). Is there a way to regenerate such caches? Is there a way to make this automatic (in case other clients modify imap folders)? How is your gnus accessing your mail? If its imap it'll see the correct folders and articles : in my case I sync using offliniemap between about 5 machines with no issues. If I move on one, offlineimap syncs my local dovecot with remote gmail and the other clients, in turn, sync gmail to their local dovecot. My setup is Gnus connecting via nnimap to a dovecot server. My other client is usually Sylpheed, connecting again via imap directly. If I move a message to the trash using Sylpheed, for instance, I can still see the message in the summary buffer when I use Gnus later, but trying to display it will cause the line to be marked as deleted. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Managing groups added from within gnus
On Thu, 06 Jan 2011 12:28:39 +0100, Philipp Haselwarter wrote: Hi, I'm having some trouble with gnus blocking when some servers aren't avalable. I just tried to start gnus (Gnus v5.13) at my uni's library where port 119 (nntp) is blocked. gnus just sat there for ages and blocked, as it obviously couldn't connect to news.gmane.org. I tried `gnus-unplugged' but that wasn't any different. Eventually I had to C-g out, resulting in gnus not connecting at all (imaps connection would have been possible but gnus just aborted all together). I also have the same problems. If a connection is dropped while performing some network activity, Gnus becomes totally unresponsive. A single C-g doesn't do anything, but if you insist, eventually, you return to a broken *Groups* buffer (nothing works basically). In the end I always have to kill emacs and restart. Since I'm on a flaky WiFi network, connection timeouts and hangs happen very often, not just because of server issues. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: message-alternative-emails
On Sun, 02 Jan 2011 08:37:17 +0100, Lars Magne Ingebrigtsen wrote: In my .gnus file I have the following: (setq message-alternative-emails (concat \\(email\\)\\| ... \\(email\\)\\| ... )) (setq message-dont-reply-to-names (concat \\( (regexp-quote user-mail-address) \\)\\| message-alternative-emails)) (setq gnus-ignored-from-addresses message-dont-reply-to-names) It sounds like there should be a way to avoid all that repetition. Why aren't these variables derived from each-other automatically by default? The last variable is derived from `user-mail-address'. The first second wouldn't make sense to derive from the first, I think. Except that user-mail-address can only accept a single address. Currently: message-alternative-emails: defaults to nil message-dont-reply-to-names: defaults to nil (which means to strip user-mail-address) gnus-ignored-from-addresses defaults to user-mail-address Wouldn't it make more sense to derive message-dont-reply-to-names and gnus-ignored-from-addresses from a combination of user-mail-address and message-alternative-emails? It seems to me that the purpose of such variables is to easily recognize yourself from your different email aliases (except maybe from message-dont-reply-to-names which may be a superset), and such the defaults are a bit unsatisfactory. To be more precise: message-dont-reply-to-names defaulting to: (when message-alternative-emails (concat \\( (regexp-quote user-mail-address) \\)\\|\\( message-alternative-emails \\))) it makes more sense to avoid replying to one of your many identities. then default gnus-ignored-from-addresses from message-dont-reply-to-names? If message-dont-reply-to-names is really supposed to be a superset, then I would prefer gnus-ignored-from-addresses to default of the combination of user-mail-address and message-alternative-emails as above. I still do believe that message-dont-reply-to-names is mostly used as a way to filter out yourself though, and using it as a default for gnus-ignored-from-addresses should be fine. The opposite should be always true however: message-dont-reply-to-names is probably always a subset of gnus-ignored-from-addresses, though it's probably defined too late to be used as a default. Any comment? I could supply a patch for this. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: format=flowed
On Sun, 02 Jan 2011 08:53:25 +0100, Lars Magne Ingebrigtsen wrote: Yuri D'Elia wav...@users.sf.net writes: (use-hard-newlines) looks a relic from the past (emacs 22), when word-wrap didn't exist and long-lines-mode was required. `use-hard-newlines' hasn't been obsoleted, so I'm not sure why you thing it's a relic... `longlines-mode' hasn't either, but you can now use a combination of `truncate-lines' and `word-wrap' to avoid both (though I agree that use-hard-newlines is *still* useful when editing pre-formatted content). ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Sun, 02 Jan 2011 12:32:31 +0100, Yuri D'Elia wrote: After reading the sources, I was able to achieve flowed zenity with the following: (setq fill-flowed-display-column nil) (add-hook 'message-mode-hook (lambda () (turn-off-auto-fill) (setq truncate-lines nil) (use-hard-newlines))) (add-hook gnus-article-mode-hook (lambda () (setq truncate-lines nil))) My only complaint is that `use-hard-newlines' shouldn't be necessary. Any line longer than `fill-flowed-encode-column' should trigger a format=flowed message automatically instead of generating a warning. Herm, it doesn't seem to work at all with NNTP :/ I though gmane did some exceptions, but it doesn't. Oh well.. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Sun, 02 Jan 2011 12:51:03 +0100, David Kastrup wrote: (setq fill-flowed-display-column nil) (add-hook 'message-mode-hook (lambda () (turn-off-auto-fill) (setq truncate-lines nil) (use-hard-newlines))) (add-hook 'gnus-article-mode-hook (lambda () (setq truncate-lines nil))) My only complaint is that use-hard-newlines' shouldn't be necessary. Any line longer than `fill-flowed-encode-column' should trigger a format=flowed message automatically instead of generating a warning. That's the worst comb quoting and unreadable run-in garbage I've seen in a long time. Impressive that you managed to create it using gnus. I'm impressed, too :P This is caused by (use-hard-newlines) actually. Since quoted and pasted text has no 'hard' newlines, it gets unwrapped. This makes replies to not-flowed messages substantially impossible. I don't think that's really expected. I was thinking of manually adding 'hard' properties to newlines in `message-mode-hook', but I don't think that would actually be sufficient. A safer approach could be replacing all newlines with 'hard' newlines in `message-send-hook' then setting `use-hard-newlines' manually to trick Gnus into sending a flowed message. Not fun. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: More on format=flowed
On Sun, 02 Jan 2011 20:32:31 +0100, Lars Magne Ingebrigtsen wrote: (defun harden-newlines () (save-excursion (goto-char (point-min)) (while (search-forward \n nil t) (put-text-property (1- (point)) (point) 'hard t So, basically, you make all the newlines hard. Isn't the point of `use-hard-newlines' that you can mix and match hard and soft newlines? I guess the point of `use-hard-newlines' is to preserve the concept of soft and hard newlines when the text is being automatically manipulated by auto-fill. Just as a note, `longlines-mode' is a twist on the concept that performs word wrapping with soft newlines, but stores hard newlines only (simulating the effect of word-wrap). Is this mode still needed at all? The point of format=flowed is to have flowed text however, when reading *and* writing if the user so desires. For instance, when a flowed message is decoded in flow-fill.el, hard newlines aren't restored. This means that you can't actually make *use* of the distinction (a cheap hack would have been turning on `longlines-mode' in the article buffer with mixed hard/soft newlines). At least with `fill-flowed-display-column' I can force the unquoting so that I can still use word-wrap, but that's sub-optimal. Either fully support soft newlines, or use word-wrap and be done. word-wrap t use-hard-newlines t You're mixing `use-hard-newlines' with `word-wrap', and the two don't really mix that well. I think. Turning `use-hard-newlines' on is just a hack to force Gnus into generating a flowed message. Internally `fill-flowed-encode' unwraps all soft newlines and then rewraps then using `fill-region'. That's completely unnecessary with word-wrap (there are no more soft newlines). I simply skip the first step by marking all lines as hard. When lines longer than `message-fill-column' are seen, the body should be encoded automatically with format=flowed, or quoted-printable. But I can't see any variable that can regulate the final message encoding. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Gnus and new mail notification
On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote: As soon as you use splitting or virtual groups, an external process becomes useless (for instance, I have several rules that split messages into groups that I ignore). Not if you dont use the demon and then split when you hit g. In other words you only fetch your mail when gnubiff or something similar tells you that you have new mail. Concrete example: if splitting includes spam rules, gnubiff will notify you of spam too. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Gnus and new mail notification
gnus-notify.el is available at: http://www.thregr.org/~wavexx/hacks/gnus-notify.el I've updated the library: http://www.thregr.org/~wavexx/hacks/gnus-desktop-notify/ as suggested. So many configurable options, so little time! ;) ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Gnus and new mail notification
On Sat, 25 Dec 2010 14:10:11 +0100, Philipp Haselwarter wrote: Please try harder, there are already at least two with that name: http://www.mail-archive.com/gnu-emacs-sources@gnu.org/msg01615.html http://www.emacswiki.org/emacs/gnus-notify.el and you do something different (*desktop notification* instead of *mode line* stuff)! gnus-desktop-notify? gnus-ext-notify? While I was testing you lib, I discovered that `gnus-newsrc-alist'-elements `g' can contain 3 different type elements at (nth 2 g) (ie `gnus-info-read'): - `nil' - a list, like '(1 . 140) - a list of lists, like '((1 . 9)) Obviously, a cdar on a list (eg. (cdar '(1 . 140))) is invalid, which can result in problems in `gnus-notify-check'. I noticed that, though by reading the source I don't understand how the list of list is actually used. It's also weird how the unread count is stored (in a text-property instead of using newsrc-alist), requiring you to perform an additional lookup using gnus-group-unread. http://www.gnu.org/software/emacs/elisp/html_node/Coding-Conventions.html , | Simply loading a package should not change Emacs's editing | behavior. Include a command or commands to enable and disable the | feature, or to invoke it. | | This convention is mandatory for any file that includes custom | definitions. If fixing such a file to follow this convention requires an | incompatible change, go ahead and make the incompatible change; don't | postpone it. ` You can simply wrap a function around the adding/removal of the hooks: ... How about making it a global minor mode? Any pointer in how to do that? I don't do elisp very often. And I noticed that you put spaces around the enclosing parentheses of your let-assignments, which I found a bit weird, so here's a whitespace patch :p I like the fact that assignments line-up this way: (let ( (...) (...) ) ...) I don't remember where I first saw this style. (don't take this one too seriously ;) Shouldn't I? ;) ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Gnus and new mail notification
On Sat, 25 Dec 2010 21:31:43 +0100, Richard Riley wrote: I'm interested how this helps - I think I'm missing something. Since this can only work in Gnus when Gnus sees new mail what purpose does it server since Gnus has already fetched the mail : isnt a third party imap/maildir asynchronous monitor a better solution for this external notification process? As soon as you use splitting or virtual groups, an external process becomes useless (for instance, I have several rules that split messages into groups that I ignore). Of course, this only makes sense if you fetch mail/news regularly with gnus-demon and leave gnus running. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: format=flowed
On Wed, 22 Dec 2010 21:46:16 +0100, Ralf Soergel wrote: but it doesn't. Is there a reason as of why use-hard-newlines is required? Wouldn't be enough to check if there's any line longer than 80 and use format=flowed automatically? I've the fill-adapt-minor-mode in effect. The help says, the fill functions insert soft linebreaks only if use-hard-newlines is in effect. But I find out the fill functions had inserted hard linebreaks, in result the sended message has only hard newlines in it. Because of this for the recipient's system was every linebreak a new paragraph, displayed with an empty line before. Ok, I was able to make it work, when sending a message, by doing: (add-hook 'message-mode-hook (lambda () (auto-fill-mode -1) ;; turn off auto-fill if enabled (setq truncate-lines nil word-wrap t) (use-hard-newlines))) Then, when decoding a flowed message, soft-newlines aren't restored. Again, I would like to use truncate-lines/word-wrap here (new in emacs 23 if I remember correctly). Are you sure, the flowed message is encoded correctly? You should verify the raw text. It is... Is it possible? I've give up this mode ... (use-hard-newlines) looks a relic from the past (emacs 22), when word-wrap didn't exist and long-lines-mode was required. Maybe some Gnus developer is reading this? Should I submit a bug/feature request somewhere? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Wed, 22 Dec 2010 23:13:02 +0100, Adam Sjøgren wrote: On Wed, 22 Dec 2010 22:46:45 +0100, Yuri wrote: (_real_ format=flowed support anyone? it's supported since 199? in outlook) What doesn't work? And what is format=flowed? Why would you want it? format=flowed encodes hard-newlines in the message, while still wrapping the source of the message to 80 columns. This allow compliant readers to either show the wrapped text or flow the content to the window's margins. For the composer, it means no more auto-fill required, no wrap achtung!s required for long URLs, and (with some message-mode magic) easier quoting since you would only have one quotation mark per paragraph. For the reader, it means customizable wrapping behavior. Claws-Mail has good support for format=flowed that works exactly like this. I'm all for format=flowed. Even if you don't know it yet, you want it too ;) ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Gnus and new mail notification
I wasn't happy with the existing new mail notification scripts that I've found on emacswiki. I've put together a new script, called gnus-notify[1], that can call any arbitrary program when new messages are received. The default uses the 'notify-send' program (part of libnotify's library) which creates little popup messages. This is especially useful if you have virtual desktops and leave Gnus running with gnus-demon. The result (showing Gnus + awesomewm + libnotify-bin on Debian) is shown here: http://www.thregr.org/~wavexx/hacks/gnus-notify.png You can also do arbitrary stuff by either setting a different executable, or supplying an entirely new notification function. Simply read the commentary in the source. gnus-notify.el is available at: http://www.thregr.org/~wavexx/hacks/gnus-notify.el Merry christmas :) [1] I know there's already a gnus-notify.el script, but I wasn't able to come up with a better name. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Multiple sources and accounts with GNUS
On Tue, 21 Dec 2010 20:49:21 +0100 Tassilo Horn tass...@member.fsf.org wrote: Yuri D'Elia wav...@users.sf.net writes: msmtp is a nice solution, but I don't really want to store the password on disk (typing at every message is not a nice solution either). You can save it encrypted in ~/.authinfo.gpg. Just to clarify, my understanding is that msmtp wouldn't read an encrypted authinfo file. I tried to go with the smtpmail route, but failed quickly. I have an SMTP server that requires encryption via STARTTLS on port 25. Looking at the trace buffer of my last SMTP session, that uses STARTTLS, too. I have the credentials for the server in ~/.authinfo.gpg and didn't setup anything special about how to use STARTTLS... In my case, LOGIN is only advertised after STARTTLS, maybe that makes some difference? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Reply to self behavior
Still tweaking GNUS in the spare time here. I'm trying to replicate an useful feature of mutt (and some other mailers): if you reply to yourself (in the sent mail folder at least), mutt would actually create a followup of your message with the original recipients instead of actually creating an email for yourself (mostly, I use this feature to correct or clarify myself on some points exactly 0.01 seconds I sent the message - of course). Ideas? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Multiple sources and accounts with GNUS
On Wed, 22 Dec 2010 13:21:37 +0100, Tassilo Horn wrote: Looking at the trace buffer of my last SMTP session, that uses STARTTLS, too. I have the credentials for the server in ~/.authinfo.gpg and didn't setup anything special about how to use STARTTLS... In my case, LOGIN is only advertised after STARTTLS, maybe that makes some difference? Hm, dunno. I have to admit, that I don't really have a clue about the SMTP protocol an STARTTLS, but that's a snippet from my SMTP trace buffer. 220 deliver.uni-koblenz.de ESMTP Postfix EHLO thinkpad 250-deliver.uni-koblenz.de 250-PIPELINING 250-SIZE 7000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN After trying some more, it seems that smtpmail is *not* making a secured connection with STARTTLS at all. (setq send-mail-function 'smtpmail-send-it message-send-mail-function 'smtpmail-send-it smtpmail-debug-info t smtpmail-debug-verb t smtpmail-auth-credentials '((smtp.x 25 x nil)) smtpmail-starttls-credentials '((smtp.x, 25, nil, nil)) smtpmail-smtp-server smtp.x) Anything missing? (yes, gnutls-cli is present and working). ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
message-alternative-emails
In my .gnus file I have the following: (setq message-alternative-emails (concat \\(email\\)\\| ... \\(email\\)\\| ... )) (setq message-dont-reply-to-names (concat \\( (regexp-quote user-mail-address) \\)\\| message-alternative-emails)) (setq gnus-ignored-from-addresses message-dont-reply-to-names) It sounds like there should be a way to avoid all that repetition. Why aren't these variables derived from each-other automatically by default? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Wed, 22 Dec 2010 18:59:15 +0100, Adam Sjøgren wrote: That is what happens when I follow up (f/F) to my own emails in Gnus. If I reply (r/R), I send email to myself. Ha! I never actually tried to follow-up myself, I unconsciously restricted that to news. It works as intended. | message-dont-reply-to-names is a variable defined in `message.el'. | Its value is | \\(asjo\\|adsj\\)@\\(koldfront.dk\\|asjo.org\\) | Original value was nil | | Documentation: | *Addresses to prune when doing wide replies. | This can be a regexp or a list of regexps. Also, a value of nil means | exclude your own user name only. I posted another thread about this variable. Try F on one of your own emails and see if it doesn't work out-of-the-box? Thanks again, it sounds obvious in retrospect :) ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Wed, 22 Dec 2010 13:24:41 -0600, Tommy Kelly wrote: Yuri writes: ... it sounds obvious in retrospect Can I propose this as the new motto for Gnus :-) You know, I went away from Gnus around 4-5 years ago because my .gnus reached 10k. I was fairly proficient back then but figured there *had* to be a mail client with those 10k as defaults. Also, I wanted something that had GUI written all over it. I'm now back, disillusioned and begging for mercy. There is no such client[*]. Be patient while I rebuild those 10k of pure elisp bliss. Aaand, while I'm at it: is there a hook that is called whenever a backend receives new mail? I'm trying to integrate emacs with the awesome window manager. gnus-biff and gnus-notify seem to check every group manually - I was looking for something more straightforward. Bests [*] I should really gave wanderlust a longer try, but I tried several times to configure imap over ssl and failed. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
On Wed, 22 Dec 2010 15:18:55 -0600, Tommy Kelly wrote: You know, I went away from Gnus around 4-5 years ago because my .gnus reached 10k. I was fairly proficient back then but figured there *had* to be a mail client with those 10k as defaults. Also, I wanted something that had GUI written all over it. That's a lot of .gnus. It sounds like you were a bit of a ninja. Why give that up simply for a GUI? Not just for the GUI of course, I tried all sorts of clients. I'm particularly fond of mutt and slrn. It's just that there seems no end to customizing Gnus. At some point I was wondering whether, just maybe, there was a better way to read mail (as in 'mail as news', emacs interface, groups, hooks, etc), and whether this way would require less customization overall. If you fire up mutt, it's email-1-2-3! And the defaults are quite good. Learning Gnus requires quite some effort. Customizing Gnus even more. After investing so much time you become entrenched. How many Gnus users actually gave wanderlust a try, for example? (and vice-versa?) I had the impression that Gnus was a sealed world in need of some fresh air. After taking a look around, I'd say there is room for improvement in some areas (_real_ format=flowed support anyone? it's supported since 199? in outlook), but overall the flexibility you have pays off. But if you are an average user with average needs, finding an existing client which works almost the way you want is waaay faster (and there is a lot to choose from). My theory as to why I should try it now when I gave up in the past is that now I'm more determined to push through this initial learning phase to get (I hope) to a level of competency where I can at least do *slightly* better than the other clients I've used, before developing enough ability to be able to do a *lot* better. Honestly, it's quite easy to do better than thunderbird, gmail (and most GTK linux client anyway). And that's unfortunate, because a GUI *should* give you more in the same space. A serious contender, in my opinion, would be mutt and maybe some other console-based clients. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Multiple sources and accounts with GNUS
On Mon, 20 Dec 2010 17:42:25 +0100 Richard Riley rile...@googlemail.com wrote: My code above selects the msmtp profile to use based on the From address which, im turn, is set by gnus-posting-styles but hopefully you can adjust as appropriate. Googling up the key vars above and msmtp should provide the info you need. msmtp is a nice solution, but I don't really want to store the password on disk (typing at every message is not a nice solution either). I tried to go with the smtpmail route, but failed quickly. I have an SMTP server that requires encryption via STARTTLS on port 25. The following minimal configuration: smtpmail-debug-info t smtpmail-debug-verb t smtpmail-auth-credentials '((smtp.server 25 me nil)) smtpmail-starttls-credentials '((smtp.server, 25, nil, nil)) smtpmail-smtp-server smtp.server) asks for my credentials, but it doesn't actually call STARTTLS (I can verify it from the SMTP trace). Ideas? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Multiple sources and accounts with GNUS
Hi everyone. After a long period with mutt (which indeed sucks less but doesn't do news) and sylpheed/claws (which just sucks), I'm back to GNUS. I'm a sadist underneath - I know. So far I was able to setup all the receiving accounts successfully (a couple of nnimap accounts, gmane via nntp, nnmaildir for local spools, etc), but I'm having trouble to send outgoing e-mails to different accounts depending on the current group. I'm fine with the default of using sendmail, but for a couple of IMAP groups I need to use a specific SMTP server with credentials. Could I use 'gnus-parameters' for that, and change 'message-send-mail-function' depending on the group? Any pointer or small example in how to do this? Thanks. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
format=flowed
I'm trying to make use of the format=flowed support in GNUS, but it's not working the way I intend it to. I was hoping that setting the message buffer with the native word-wrap support would work: (setq truncate-lines t word-wrap t) but it doesn't. Is there a reason as of why use-hard-newlines is required? Wouldn't be enough to check if there's any line longer than 80 and use format=flowed automatically? Then, when decoding a flowed message, soft-newlines aren't restored. Again, I would like to use truncate-lines/word-wrap here (new in emacs 23 if I remember correctly). Is it possible? Thanks ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
