Re: my vs maildir
On Sun, Jan 2, 2011 at 9:54 PM, Philipp Haselwarter wrote: > > That being said - I also still run dovecot as server: for > offlineimap. Dno if offlineimap could do without a server, guess I'll > have to take a look. It can. Here is an example of IMAP-to-IMAP sync using direct calls instead of server connections. The remote goes through SSH. [Repository LocalIMAP] type = IMAP preauthtunnel = MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap holdconnectionopen = yes [Repository RemoteIMAP] type = IMAP remotehost = localhost #use SSH tunnel remoteuser = USERNAME preauthtunnel = ssh -q REMOTEHOST 'MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap' maxconnections = 3 Adjust as appropriate. -Brett. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
Richard Riley writes:
> Here's an extract from my
> dovecot.conf : this iis the thing that provides the indexing.
>
>
> ,
> | protocol imap {
> | mail_plugins = fts fts_squat
> | listen = *:143
> | ssl_listen = *:993
> | }
> |
> | plugin {
> | fts = squat
> | fts_squat = partial=4 full=10
> | }
> `
>
ok thx for this richard.
i have mairix working now (as per my other thread mairix problems), but
since i was unsuccessful with nnir i think i'll give this a try later. i
would like to see what it offers.
the only thing is it looks like i'll have to set the dovecot server
going again, which is not a problem and look into this fts_squat thing.
i downloaded nnir.el late last night and tried to byte compile it as
they suggested, but that didn't work.
--
in friendship,
prad
___
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
On Sun, 02 Jan 2011 22:10:30 +0100, Richard Riley said: ---8<---[snipped 28 lines]---8<--- RR> other machines can talk to it (if you want) e.g your dev machine on RR> the desk could have the router routing imap to it so you can read RR> your email from anywhere in the word. Just another open port, another socket you're blasting your passwords through. If you set up dovecot properly to use imaps, I guess you should be good. But I think the shell method is preferable to plain auth. For you LAN: wrap ssh around the dovecot command. That being said - I also still run dovecot as server: for offlineimap. Dno if offlineimap could do without a server, guess I'll have to take a look. Anyone? -- Philipp Haselwarter ___ 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: mairix problems - [solved]
prad writes: > so it seems i'm missing a piece somewhere since mairix is doing its job > both out of gnus and in it. what can be done? > the key apparently was to change my base=~/Mail to base=~/Mail/inbox that way instead of creating zz files in both Mail and inbox, everything goes into inbox and it works beautifully! now the issue would be that we have all these zz files cluttering up the inbox which is likely why the manual suggests an alternative for people who don't like this sort of thing: "if you're uncomfortable with nnmairix creating new mail groups alongside your other mail, you can also create e.g. a new nnmaildir server exclusively for mairix." -- in friendship, prad ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
Brett Viren writes: > On Sun, Jan 2, 2011 at 3:02 PM, Richard Riley wrote: > >> Why would you do that? The overhead of Dovecot running is pretty >> low. Doing it that way you incur the overhead of startup. With it being >> a server other programs like offlineimap can then talk to it when >> fetching your email and then storing it locally in dovecot for your >> email client to retrieve using imap. > > I've tried it both ways. The only noticeable difference to me is the > lack of needing to provide authentication when imap is called > directly. After start up I don't notice any speed or functionality > difference compared to talking to it over a socket. > > Running a server when it is not actually needed is frowned upon where > I work so there is that, somewhat intangible, benefit for me. > If its company policy then yes I see. But really, the overhead is about zero. When its not needed it sits there consuming pretty much nothing as all such servers/daemons/services should. And of course the benefits are : offlineimap can talk to it with no special start and connect bootstrap other machines can talk to it (if you want) e.g your dev machine on the desk could have the router routing imap to it so you can read your email from anywhere in the word. That said I wasnt even aware of the reconnect and go shell method so its informative all round;) ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
On Sun, Jan 2, 2011 at 3:02 PM, Richard Riley wrote: > Why would you do that? The overhead of Dovecot running is pretty > low. Doing it that way you incur the overhead of startup. With it being > a server other programs like offlineimap can then talk to it when > fetching your email and then storing it locally in dovecot for your > email client to retrieve using imap. I've tried it both ways. The only noticeable difference to me is the lack of needing to provide authentication when imap is called directly. After start up I don't notice any speed or functionality difference compared to talking to it over a socket. Running a server when it is not actually needed is frowned upon where I work so there is that, somewhat intangible, benefit for me. -Brett. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
prad writes:
> Richard Riley writes:
>
>> Possibly you could post your set up? I am a little confused now. You are
>> running a local Dovecot? (on your machine or on a local server?).
>>
> .emacs:
> (setq imap-shell-program
> '("MAIL=maildir:$HOME/Mail /usr/lib/dovecot/imap"))
>
> .gnus:
> (setq gnus-parameters
> '(("Mail:.*" ;"^nnimap\\+Mail:INBOX"
> (gcc-self . t
> (setq gnus-secondary-select-methods
> '((nnimap "Mail" (nnimap-stream shell
>
> those are the relevant parts to getting in with dovecot. there is no
> dovecot running now which it was doing before and i had access to it
> through .authinfo and my personal login data.
>
>> You then also don't need nnmairix. You can use dovecot's own indexing
>> via nnir.
>>
> i tried that last night, but haven't gotten it to work yet though it
> looks pretty straight-forward to me. i may post questions later if i'm
> not successful. however, i rather like mairix as indicated in my mairix
> problems post and it may be more suitable as my emails grow - just
> haven't gotten that to work fully either.
I doubt it will be since dovecot does the indexing for you as mails are
added. Mairix is then yet another piece in the jigsaw - I used to use it
but if Dovecot can index why not use that? Here's an extract from my
dovecot.conf : this iis the thing that provides the indexing.
,
| protocol imap {
| mail_plugins = fts fts_squat
| listen = *:143
| ssl_listen = *:993
| }
|
| plugin {
| fts = squat
| fts_squat = partial=4 full=10
| }
`
>
>> You saying "imap without running a server" is the bit that throws me.
>>
> ya that's the neat idea brett provided. it seems i can use imap from
> dovecot without having a daemon running.
Why would you do that? The overhead of Dovecot running is pretty
low. Doing it that way you incur the overhead of startup. With it being
a server other programs like offlineimap can then talk to it when
fetching your email and then storing it locally in dovecot for your
email client to retrieve using imap.
Just some other ideas you might consider.
___
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
Yuri D'Elia writes: > 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. No, that's really awful. I know that I've seen other people post with format=flowed (and `use-hard-newlines'), and they don't seem to have this problem. But I don't know the details. Anybody? -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: message-alternative-emails
Yuri D'Elia writes: > message-alternative-emails: defaults to nil > message-dont-reply-to-names: defaults to nil (which means to strip > user-mail-address) Well, it defaults to `rmail-dont-reply-to-names', but that's more for hysterical porpoises... > 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 might, but I would imagine that there are people who don't want any address stripping -- for instance, if they want to Cc a job mail account, but want to use the home account as the From, and so on. -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus and gnupg gives me sometimes bad signature result
Rud1ger Sch1erz writes: >> I don't have that public key (and I have no idea how to acquire one, >> either), so it's a bit difficult to test... anybody? > > http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xCAAD11864B666561 I mean, could someone else debug? :-) -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: More on format=flowed
Yuri D'Elia writes: > (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? That is: [...] > 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. (I've never used either.) -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
Richard Riley writes:
> Possibly you could post your set up? I am a little confused now. You are
> running a local Dovecot? (on your machine or on a local server?).
>
.emacs:
(setq imap-shell-program
'("MAIL=maildir:$HOME/Mail /usr/lib/dovecot/imap"))
.gnus:
(setq gnus-parameters
'(("Mail:.*" ;"^nnimap\\+Mail:INBOX"
(gcc-self . t
(setq gnus-secondary-select-methods
'((nnimap "Mail" (nnimap-stream shell
those are the relevant parts to getting in with dovecot. there is no
dovecot running now which it was doing before and i had access to it
through .authinfo and my personal login data.
> You then also don't need nnmairix. You can use dovecot's own indexing
> via nnir.
>
i tried that last night, but haven't gotten it to work yet though it
looks pretty straight-forward to me. i may post questions later if i'm
not successful. however, i rather like mairix as indicated in my mairix
problems post and it may be more suitable as my emails grow - just
haven't gotten that to work fully either.
> You saying "imap without running a server" is the bit that throws me.
>
ya that's the neat idea brett provided. it seems i can use imap from
dovecot without having a daemon running.
--
in friendship,
prad
___
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english
More on format=flowed
In my quest for format=flowed, I *think* I've come up with a workable solution by using the following: --- (defun harden-newlines () (save-excursion (goto-char (point-min)) (while (search-forward "\n" nil t) (put-text-property (1- (point)) (point) 'hard t (setq fill-flowed-display-column nil) (add-hook 'message-setup-hook (lambda () (when message-this-is-mail (turn-off-auto-fill) (setq truncate-lines nil word-wrap t use-hard-newlines t (add-hook 'message-send-hook (lambda () (when use-hard-newlines (harden-newlines (add-hook 'gnus-article-mode-hook (lambda () (setq truncate-lines nil word-wrap t))) --- The idea behind it: - `fill-flowed-display-column' will unwrap flowed message as expected. Apparently, the current code in flow-fill.el has problems with long quoted text (not all lines are correctly unfolded, but this doesn't affect the usability of the message). - `gnus-article-mode-hook' will wrap flowed messages using word-wrap instead. This works nicely. - In `message-setup-hook' again we turn on the built-in worp-wrap, disable auto-fill and set use-hard-newlines silently. Those are set for mail messages only, though I've verified that flowed messages also work on gmane groups (gmane.test). - The magic is really done i `message-send-hook', where all newlines are replaced with hard newlines. This way the existing message, and more importantly, pasted text lacking 'hard' newlines will be preserved. All long lines will be wrapped at `fill-flowed-encode-column' since `use-hard-newlines' was already turned on earlier. That's *much* harder than calling (use-hard-newlines) to use format=flowed all around. Yet, it seems to work. Maybe. Comments? ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Any way to click article buttons without leaving the summary buffer?
Sean McAfee writes: > When I want to click on a hyperlink embedded in an article, it's kind of > a hassle to switch to the article buffer, navigate to the link, and > press RET, and then return to the summary buffer afterwards. Is there > any convenient built-in way to streamline this process? Ideally I'd > like to be able to just select one of the on-screen buttons and trigger > it without having to leave the summary buffer. I don't see any reason, to keep the focus in the summary buffer. The best would be, to do all commands for summary and article from within the article buffer. Then the navigation (and url selection with TAB) would be more ergonomic. I'm just working on my-alter-summary-map and my-alter-article-map to get this behaviour. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus and gnupg gives me sometimes bad signature result
Lars Magne Ingebrigtsen writes: > Rud1ger Sch1erz writes: >> Message-ID: >> >> [[PGP Signed Part:Bad signature from CAAD11864B666561 David Seppi >> ]] > > I don't have that public key (and I have no idea how to acquire one, > either), so it's a bit difficult to test... anybody? http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xCAAD11864B666561 Cheers, Rudiger ___ 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 said: DK> Yuri D'Elia writes: >> On Sun, 02 Jan 2011 08:40:33 +0100, Lars Magne Ingebrigtsen wrote: >>> Yuri D'Elia writes: > (_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. > > In what way >> doesn't format=flowed work in Gnus? I think that was >>> implemented at least a decade ago, but it may have bitrotted in >> the mean > time... >> >> 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. DK> That's the worst comb quoting and unreadable run-in garbage I've DK> seen in a long time. DK> Impressive that you managed to create it using gnus. DK> -- David Kastrup Remarkable, indeed! Almost better than .newsrc.eld =) -- Philipp Haselwarter ___ 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: Reply to self behavior
Yuri D'Elia writes: > On Sun, 02 Jan 2011 08:40:33 +0100, Lars Magne Ingebrigtsen wrote: >> Yuri D'Elia writes: > (_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. > > In what way > doesn't format=flowed work in Gnus? I think that was >> implemented at least a decade ago, but it may have bitrotted in > the mean > time... > > 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. 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. -- David Kastrup ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Any way to click article buttons without leaving the summary buffer?
Sean Sieger writes: Is there any convenient built-in way to streamline this process? I do, h then C-n; for a URL, h then C-s, ht RET. Shoot, sorry ... then h again to return to the Summary Buffer. ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Any way to click article buttons without leaving the summary buffer?
Is there any convenient built-in way to streamline this process? I do, h then C-n; for a URL, h then C-s, ht RET. ___ 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
I found that , | (gnus-group-unread (car g)) ` sometimes yields nil, resulting in , | let*: Wrong type argument: number-or-marker-p, nil | | Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) | +(3 nil) | (let* ((name (gnus-info-group g)) (unread (gnus-group-unread (car g))) | (count (+ read unread ` Initially I wasn't able to reproduce the behaviour but yesterday and today it reoccurred, I wasn't able to track it down though. Anyways, here's what I did to work around it: --8<---cut here---start->8--- commit 6483c4b075539db1880c5d8a834caf7c9e902b1d (HEAD, refs/heads/check_count) Author: Philipp Haselwarter Date: Thu Dec 30 16:04:36 2010 +0100 [Bugfix] gnus-desktop-notify-check Make `gnus-desktop-notify-check' more robust to another data inconsistency: `(gnus-group-unread (car g))' sometimes yields nil, causing `(count (+ read unread))' to fail. The fix returns 0 instead of nil and uses `name' instead of `(car g)'. Modified gnus-desktop-notify.el diff --git a/gnus-desktop-notify.el b/gnus-desktop-notify.el index 5aef4bb..2ec8cbb 100644 --- a/gnus-desktop-notify.el +++ b/gnus-desktop-notify.el @@ -199,7 +199,7 @@ with the behavior defined by `gnus-desktop-notify-send-mode'." (cdr (gnus-info-read g ) (when read (let* ( (name (gnus-info-group g)) - (unread (gnus-group-unread (car g))) + (unread (or (gnus-group-unread name) 0)) (count (+ read unread)) (old-count (cdr (assoc name gnus-desktop-notify-counts))) (notify (gnus-group-find-parameter name 'group-notify)) ) --8<---cut here---end--->8--- Furthermore, the markup you use in `gnus-desktop-notify-send': , | (format " %d:%s" ` does not work at all with notify-send for me, it just gets displayed literally, which is not-so-pretty.. , | % notify-send -v | notify-send 0.5.2 ` -- Philipp Haselwarter ___ 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 08:40:33 +0100, Lars Magne Ingebrigtsen wrote: Yuri D'Elia writes: > (_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. > > In what way doesn't format=flowed work in Gnus? I think that was implemented at least a decade ago, but it may have bitrotted in the mean > time... 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. ___ 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 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: 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: my vs maildir
Well basically you need a server to open a port providing a socket that your client can talk to. But if all of this is happening on one machine it's a bit of a long way around. Launching the `imap-shell-program' directly provides you with the same interface you'd get if you were talking to your server over telnet but without having to do all the networking fun. This saves you some overhead and has the advantage that you don't have to worry about security issues all that much; either dovecot can read your files or it can not. At least that's my understanding (guess) of what's happening :) While your typical local imap server would look something like --8<---cut here---start->8--- '(nnimap "localhost" (nnimap-stream network) (nnimap-server-port 143)) --8<---cut here---end--->8--- A minimal setup using the shell stream could be: --8<---cut here---start->8--- (setq nnimap-shell-program "MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap") (setq gnus-select-method '(nnimap "localhost" (nnimap-stream shell))) --8<---cut here---end--->8--- NOTICE: `nnimap-shell-program' is a string, not a list -- Philipp Haselwarter ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: my vs maildir
prad writes:
> Brett Viren writes:
>
>> Two more things to consider:
>>
> these ideas worked fantastically well, brett!!
>
> i'm not using procmail yet - have to figure out that one today because i
> want to do spam filtering with it ... right now with my new setup, i
> don't mind receiving spam though. :D
>
> certainly setting the "myserv" ties things together nicely.
>
> i was glad i'd figured out dovecot to be able to get in with minimal
> fuss, but thought it was a bit ironical that i'd need to do all this to
> get into my own files, so your imap without running a server was really
> great!
>
> i'm puzzled though as to why it actually works. i thought the idea was
> to have dovecot listen because a request to imap would come in, but the
> emacs entry:
>
> (setq imap-shell-program '("MAIL=maildir:$HOME/Maildir
> /usr/lib/dovecot/imap"))
>
> would seem to appear to run imap every time you access gnu - which i
> guess is the idea because you need to run it only once to get in.
>
Possibly you could post your set up? I am a little confused now. You are
running a local Dovecot? (on your machine or on a local server?).
If that is so then set your select method to talk to that using nnimap.
You then also don't need nnmairix. You can use dovecot's own indexing
via nnir.
You saying "imap without running a server" is the bit that throws me.
regards
r.
___
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
Yuri D'Elia writes:
> smtpmail-starttls-credentials '(("smtp.x", 25, nil, nil))
I know nothing about smtpmail, but those commas up there look
suspicious...
--
(domestic pets only, the antidote for overdose, milk.)
la...@gnus.org * Lars Magne Ingebrigtsen
___
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Extending the Gnus pyzor example
Christopher Culver writes: > If I try setting it as expirable with gnus-summary-mark-as-expirable > first and then moving it, I get unintended results. The move function > actually ends up moving the next e-mail in the group since setting mail > as expirable automatically selects the next message. If you wrap it in (save-excursion ...), then point won't move. -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Marking down-scored messages as expirable
Vincent Beffara writes: > (Using nnimap,) is it possible to set up scoring in such a way that > messages below a certain score are automatically marked as expirable ? There is no pre-defined functionality in Gnus for doing this. -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Reply to self behavior
Yuri D'Elia writes: >>> (_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. In what way doesn't format=flowed work in Gnus? I think that was implemented at least a decade ago, but it may have bitrotted in the mean time... -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: format=flowed
Yuri D'Elia 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... -- (domestic pets only, the antidote for overdose, milk.) la...@gnus.org * Lars Magne Ingebrigtsen ___ info-gnus-english mailing list info-gnus-english@gnu.org http://lists.gnu.org/mailman/listinfo/info-gnus-english
