Re: Wishlist for oGnus

Re: Wishlist for oGnus

[Kai Großjohann]

* Allow article editing in groups which do not support it, but
  emulating it via deleting the old article and entering the new one
  into the group.  This would be very useful to support `T ^' (say) in
  nnimap groups.

* Allow user to specify which kinds of groups should be displayed.
  For example, I want to display all the groups that are displayed
  now, plus those which have cached messages in them.  (Gnus does
  display those with ticked messages but not those with
  cached-but-unticked ones.)  This would become even more important
  when we allow labels.

* Go through the todo list and remove items already done.

* Create new data type `article identifier' and use that instead of
  article numbers.  A first implementation could offer something like
  (num . 4711) but this could be extended.  This would be useful for
  using servers with *really* large numbers -- there we could have a
  bignum type.  It might also be useful for the nnweb and nnultimate
  thingies where article identifiers are not really numbers.

* Allow use of digests to keep related articles.  Normally, you use
  groups to group together articles which are thematically related.
  But sometimes, you have so many themes that this becomes
  impractical.  WIBNI I could have digests in a group, and there was a
  way to add a new article to one of the digests in that group?

  Or maybe what I really want is a way to tell Gnus that a specific
  thread should always be hidden (as in `T h') by default, while most
  other threads are not hidden by default.  Hm.

* New backend between nnfolder and nnml: have more than one article
  per file, but more than one file per group.  With .overview files.

* .overview files for nnfolder?

* New backend nnbabylfolder.  There is also nnbabyl which is like
  nnmbox but uses babyl format, but there is no babyl format
  equivalent of nnfolder.

* Make movement commands in summary buffer independent of `move after
  mark' behavior when marking articles.  Currently, if you don't want
  `E' to move to the next unread article, you have to set
  gnus-summary-goto-unread to nil, and then there is no way to move to
  the next or previous unread article.

  This one has two sub-tasks.  Providing the commands is one thing,
  finding out useful key bindings for them is another.  I think we
  could provide the commands first while not changing the behavior of
  the key bindings; then different people can experiment with
  different key binding schemes until we find something which suits
  many people.

* `Move to next/previous/first article' is a misnomer, since ticked
  articles are also unread but not moved to by these commands.  Should
  the terminology be fixed or the documentation, or what?

* Allow sorting of threads by newest article rather than by root of
  thread.  Consider the following thread structure:

    root1       Jan 1
      leaf1     Jan 4
    root2       Jan 2
      leaf2     Jan 3

  These two threads are sorted this way because root1 is older than
  root2.  I want an option to sort them the other way round because
  leaf1 is newer than leaf2.

* Improve editing of MIME messages.  I would like to use html-mode to
  edit the body of a text/html message, and enriched-mode for
  text/enriched messages, and so on.  This should go for multipart
  messages as well.  This is probably a hard one since Emacs currently
  does not allow several major modes per buffer.  But maybe it would
  be nice to hack Emacs to provide this infrastructure so that Gnus
  can make use of it?  This would also make it possible to provide
  nifty commands for editing the headers, for example, rather than
  relying on commands which do the same thing everywhere.
  message-x.el is really just a half-assed attempt at doing it, and
  while it is useful, that's not the way it should be done.

  I think Francisco Potortì already did something like this?

* Provide commands for editing MML tags.  For example, there could be
  a command mml-add-tag-attribute which prompts me for an attribute
  name (with completion, from the set filename, type, ...), and then
  for a value.  (This is like `C-c +' in psgml.)  Or there could be a
  command which showed me all the attributes in an MML tag and allows
  me to use TAB to move between them, and then to edit each attribute
  value.  (This is like `C-c C-a' in psgml.)

So much to do...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Wishlist for oGnus

[Robert Epprecht]

* A better interface to the agent download scoring rules, like the one
  for the other scoring rules.

* Editing of messages in the agents cache.

* More article marks (like '!' or '?').
  Maybe user defined marks that can be displayed as any choosen charakter,
  so one could do things like limiting on, to do whatever one likes with
  these articles.

* A possibility to add notes to messages. If thouse could include links
  to other (stored) messages this would be very practical.

* A nnfolder like backend with .overview files.
  This would not only speed up things, but also allow nnir to work on it.

Robert Epprecht

Re: Wishlist for oGnus

[john s jacobs anderson]

* nnsql backend, which would allow messages or folders to be imported
  in a local (My|Postgre|?)SQL RDBMS.

* "posting profiles" ideally accessible from a popup menu; allowing
  choice between predefined profiles of
  from,name,organization,etc. Example: I'm at home, but need to reply
  to a work mail; i can hit 'R', then use this command to switch to my
  'work' profile for purposes of this one reply. (This might already
  be possible with current Gnus, but I don't think so.)




-- 
------------------------------------------------------------------------
John S Jacobs Anderson                               jacobs@genehack.org
                  /* Genehack: Not your daddy's weblog *\
                        <URL:http://genehack.org>

Editing articles in read-only backends (was: Wishlist for oGnus)

[Toby Speight]

Kai> Kai Großjohann <URL:mailto:Kai.Grossjohann@CS.Uni-Dortmund.DE>

0> In article <vafvh4nmvmv.fsf@lucy.cs.uni-dortmund.de>, Kai wrote:

Kai> * Allow article editing in groups which do not support it, but
Kai>   emulating it via deleting the old article and entering the new
Kai>   one into the group.  This would be very useful to support `T ^'
Kai>   (say) in nnimap groups.

Alternatively, support it using the cache, and edit the cached copy,
hiding the original.

Ideally, implement both, and provide a variable (which can be made
group local) to choose the article-edit-function.

Re: Wishlist for oGnus

[David Z. Maze]

* Have Gnus automagically set group parameters for mailing list
  groups.  For example, if I have a splitting rule that automatically
  sorts ding@gnus.org into mail.ding, then Gnus should clue in, set
  the to-list parameter to 'ding@gnus.org', and set total-expire.
  (This is probably Hard (TM).  And of course the user should be able
  to configure what parameters exactly get set.)

* Along the same lines, automagically detect broken reply-to's.  (But
  don't auto-detect users legitimately setting a reply-to header that
  points back to the list.)

* Make it easier to change parameters on a set of groups,
  e.g. set/clear gcc-self on process-marked groups.

* Make it easier/possible to migrate between primary select-methods,
  if that concept is going to be kept.  Right now I have only one
  group on my primary server, and I'd kind of like to change from nntp
  to nnml, but apparently this doesn't work well.

* Make it possible to refer to uniquely-named groups without
  select-method prefix (e.g. mail.misc instead of nnml:mail.misc).

* Allow a user-defined picons directory for personal groups.

-- 
David Maze             dmaze@mit.edu          http://donut.mit.edu/dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
	-- Abra Mitchell

MML editing improvements (was: Wishlist for oGnus)

[Toby Speight]

Kai> Kai Großjohann <URL:mailto:Kai.Grossjohann@CS.Uni-Dortmund.DE>

0> In article <vafvh4nmvmv.fsf@lucy.cs.uni-dortmund.de>, Kai wrote:

Kai> * Improve editing of MIME messages.  I would like to use html-mode
Kai>   to edit the body of a text/html message, and enriched-mode
Kai>   for text/enriched messages, and so on.  This should go for
Kai>   multipart messages as well.  This is probably a hard one
Kai>   since Emacs currently does not allow several major modes per
Kai>   buffer.

One buffer per part?  Perhaps not ideal for all, but good enough for me.

Kai> * Provide commands for editing MML tags.  For example, there
Kai>   could be a command mml-add-tag-attribute which prompts me for
Kai>   an attribute name (with completion, from the set filename,
Kai>   type, ...), and then for a value.  (This is like `C-c +' in
Kai>   psgml.)  Or there could be a command which showed me all the
Kai>   attributes in an MML tag and allows me to use TAB to move
Kai>   between them, and then to edit each attribute value.  (This is
Kai>   like `C-c C-a' in psgml.)

That would be good.  A suggested interface: make the MML tag read-only
(and perhaps give it some other text property so that we can write
tag-like things in messages without confusing Message - don't know if
we can get this saved in drafts, though) and give it a local keymap so
that, say, RET gives a Customize buffer to edit the attributes.  Not
everyone thinks Customize is the greatest, but it does have the
advantage of making the user-interface consistent across packages.

Posting profiles

[David Kagedal]

john s jacobs anderson <jacobs@genehack.org> writes:

> * "posting profiles" ideally accessible from a popup menu; allowing
>   choice between predefined profiles of
>   from,name,organization,etc. Example: I'm at home, but need to reply
>   to a work mail; i can hit 'R', then use this command to switch to my
>   'work' profile for purposes of this one reply. (This might already
>   be possible with current Gnus, but I don't think so.)

I use the following.  I read mail at work using to IMAP servers and
constantly send mail from different addresses.  When replying it
guesses the profile, but otherwise it asks who who I want to be this
time.

(defconst message-profiles
  '((idasys
     (user-mail-address . "david.kagedal@idasys.se")
     (message-signature . "David Kågedal, Ida Systems\n"))
    (lysator
     (user-mail-address . "davidk@lysator.liu.se")
     (message-signature . "David Kågedal"))))

(defvar message-profile nil)
    
(defun set-message-profile (profile)
  (let ((profile (cdr (assq profile message-profiles))))
    (if profile
	(progn
	  (mapcar (function (lambda (v)
			      (let ((var (car v))
				    (val (cdr v)))
				(make-local-variable var)
				(set var val))))
		  profile)
	  (make-local-variable 'message-profile)
	  (setq message-profile profile))
      (error "unknown profile: %S" profile))))

(defun read-message-profile (prompt &optional default)
  (let ((table (mapcar (function (lambda (x)
				   (list (symbol-name (car x)))))
		       message-profiles)))
    (intern (completing-read prompt table nil t default))))
					 

(defun dk-select-message-profile ()
  (unless message-profile
    (let ((to (message-fetch-reply-field "to"))
	  profile)
      (set-message-profile (cond ((null to)
				  (read-message-profile "Profile: "))
				 ((string-match "@idasys.se" to)
				  'idasys)
				 ((string-match "@lysator.liu.se" to)
				  'lysator)
				 (t
				  (read-message-profile "Profile: ")))))))

(add-hook 'message-signature-setup-hook 'dk-select-message-profile)


I also use this to add a BCC:

(defun dk-add-bcc ()
  (goto-char (point-max))
  (insert "Bcc: " user-mail-address "\n"))

(add-hook 'message-header-setup-hook 'dk-add-bcc)


-- 
David Kågedal

Re: Posting profiles

[john s jacobs anderson]

>>>>> "David" == David Kagedal <davidk@lysator.liu.se> writes:

  David> john s jacobs anderson <jacobs@genehack.org> writes:
  >> * "posting profiles" ideally accessible from a popup menu;
  >>   allowing
  >> choice between predefined profiles of
  >> from,name,organization,etc. Example: I'm at home, but need to
  >> reply to a work mail; i can hit 'R', then use this command to
  >> switch to my 'work' profile for purposes of this one reply. (This
  >> might already be possible with current Gnus, but I don't think
  >> so.)

  David> I use the following.  I read mail at work using to IMAP
  David> servers and constantly send mail from different addresses.
  David> When replying it guesses the profile, but otherwise it asks
  David> who who I want to be this time.
(snip of lisp)

Chris D.Halverson replied privately to point me to
<URL:http://www.comsecmilnavpac.net/elisp/>, where (among other
goodies), I found gnus-pers.el, which appears to be exactly what the
doctor ordered (being as I'm an XEmacs user, and it works via the
Customize buffer).

thanks,
john.

-- 
------------------------------------------------------------------------
John S Jacobs Anderson                               jacobs@genehack.org
                  /* Genehack: Not your daddy's weblog *\
                        <URL:http://genehack.org>

Re: Wishlist for oGnus

[Alan Shutko]

john s jacobs anderson <jacobs@genehack.org> writes:

>   from,name,organization,etc. Example: I'm at home, but need to reply
>   to a work mail; i can hit 'R', then use this command to switch to my
>   'work' profile for purposes of this one reply. (This might already
>   be possible with current Gnus, but I don't think so.)

I split work mail to different groups, so I use existing
gnus-posting-styles.  If I need to write a new mail, I C-u a over a
work mail group.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
A dead comic is at his wit's end...

Re: Wishlist for oGnus

[Didier Verna]

* Better handling of the mail retrieving / splitting feature:
  - the variables <backend>-get-new-mail should not exist anymore. Mail
    retrieving should be a separate matter.
  - we should be able to split mails to groups AND backends at the same time.
  - meanwhile, we should still be able to associate certain mail sources with
    certain backends.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /        EPITA / LRDE            mailto:didier@epita.fr
/_/ / /_/ / /__ /      14-16 rue Voltaire       Tel.   +33 (1) 44 08 01 77
                   94276 Kremlin-Bicêtre cedex  Fax.   +33 (1) 44 08 01 99

Re: Wishlist for oGnus

[Karl Kleinpaste]

Most of what I want is mail-specific.

* Additional article marking, and an ability to affect marks placed
  during e.g. mail acquisition.  I want to be able to notice the
  subject "fast money" or "web traffic", automatically mark it with a
  `$', and score it into oblivion.  (But I fear that wanting to change
  marks with mail-source-* and nnmail-* functions will represent a
  philosophical conflict with the rest of Gnus' management of article
  marks.  mail-source-* and nnmail-* currently hack around with files
  under ~/Mail and leave traces in ~/Mail/active, but don't affect
  things stored in .newsrc.eld.)

* A much better interface to nnmail-split-methods.  I don't know how
  I'd like this done, but I know that the current method of manually
  hacking regexps is pretty untenable for new users.  My boss, who is
  tenured faculty at CMU and CEO & CTO at JPRC, and whose research
  work has involved Lisp for the last 25 years, is trying to implant
  himself in a Gnus mail environment, and this is a big sticking point
  even for him.

* PGP-supported encryption of entire nnml & nnmh groups.  There are
  people with whom I exchange mail routinely who don't send w/PGP, but
  I'd really rather that the content not be left lying around
  unencrypted.  Hook into article acquisition the way jka-compr
  supposedly does, to auto-decrypt every message read.

* Baby's First Mail In Gnus.  Some set of functions that the
  new-to-mail-in-Gnus user can invoke which will query the user
  appropriately for the basic information required to establish mail
  handling, leaving the appropriate traces in .gnus.  Perhaps a
  customize buffer would be appropriate.
  - Where does your mail come from?
  - If some server, what is your POP/IMAP protocol identity?
  - What is your identity when sending mail, as opposed to posting to
    Usenet?
  - Here are some basic concepts of mail groups (list a few:
    personal mail, company-wide mail, mailing lists, garbage dumps,
    receptacles for outbound copies of what one sends; which ones do
    you want to instantiate, and what mail should land in each?
    [/viz./ problem of nnmail-split-methods interface.]

* Full integration of nnir into Gnus.  Generic hooks for adding new
  external nnir sources.  I use a couple experimental, in-house tools
  (JPRC is a research lab, occupied with document analysis and machine
  learning) and adding new search engines to nnir by hacking the main
  nnir.el module is rather clunky.

Re: Wishlist for oGnus

[Alan Shutko]

Karl Kleinpaste <karl@justresearch.com> writes:

> * A much better interface to nnmail-split-methods.  I don't know how
>   I'd like this done, but I know that the current method of manually
>   hacking regexps is pretty untenable for new users.

Have you looked at the new (gnus)Group Mail Splitting yet?  It's
great... G c on a group, tell it what addresses it's related to, and
you're simultaneously splitting _and_ setting the address to use when
posting!

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Silent gratitude isn't much use to anyone.

Re: Wishlist for oGnus

[Michael Cook]

* Manual ordering of articles in an nnml folder.

  That is, keystrokes to move articles (or whole threads) up or down
  in the *Summary* buffer relative to the other articles.  The order
  would be persistent (e.g., across gnus sessions).

  With this ability, an nnml folder would make for a good to-do list.

M.

Re: Wishlist for oGnus

[Kai Großjohann]

Robert Epprecht <epprecht@sunweb.ch> writes:

> * A nnfolder like backend with .overview files.
>   This would not only speed up things, but also allow nnir to work on it.

Say what?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Wishlist for oGnus

[Kai Großjohann]

Karl Kleinpaste <karl@justresearch.com> writes:

> * Full integration of nnir into Gnus.  Generic hooks for adding new
>   external nnir sources.  I use a couple experimental, in-house tools
>   (JPRC is a research lab, occupied with document analysis and machine
>   learning) and adding new search engines to nnir by hacking the main
>   nnir.el module is rather clunky.

If you need to do more than (add-to-list 'nnir-engines '(...)), please
tell me.  I might have done something wrong which I'm not aware of.
The idea behind the current implementation was that this is sufficient
to add a new search engine.

But then, there are several nnir todo items on my list which have been
there too long already :-|

nnir.el should really grok more than one backend.  Argh.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Wishlist for oGnus

[Stainless Steel Rat]

Relatively simple, I hope:

  * gnus-uu-decode should complain if one or more parts of a series post
    (ie, "part N of X") is missing, and optionally tick what parts are
    there for decoding in a later session.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not taunt Happy Fun Ball.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Wishlist for oGnus

[Doug Bagley]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> Relatively simple, I hope:
> 
>   * gnus-uu-decode should complain if one or more parts of a series post
>     (ie, "part N of X") is missing, and optionally tick what parts are
>     there for decoding in a later session.

I was annoyed by that too.  Why does it try to assemble incomplete
series?  So I wrote the following.  I would use it to mark all the
*complete* series I want, and then I download them all at once.  Then
I got tired of that and wrote a perl script which does it even better,
so I don't really use this code any more.

;; only mark a series if it isn't missing any articles
(define-key gnus-summary-mode-map [f1] 'kof:gnus-uu-mark-complete-series)
(require 'gnus-uu)
(defun kof:gnus-uu-mark-complete-series ()
  "Mark the current series with the process mark if it contains all parts."
  (interactive)
  (if current-prefix-arg
      (let ((articles (gnus-uu-find-articles-matching)))
	(while articles
	  (gnus-summary-remove-process-mark (car articles))
	  (setq articles (cdr articles))))
    (let* ((articles (gnus-uu-find-articles-matching))
	   (actual-count (list-length articles))
	   (expected-count (kof:max-series-from-subject (gnus-summary-article-subject))))
      (if (>= actual-count expected-count)
	  (progn
	    (while articles
	    (gnus-summary-set-process-mark (car articles))
	    (setq articles (cdr articles)))
	    (forward-line))
	(message (format "Series is not continuous.  Expected: %s  Actual: %s"
			 expected-count actual-count)))
      (gnus-summary-position-point))))
(defun kof:max-series-from-subject (subject)
  "according to subject, return the total count of articles in series."
  (let ((string (gnus-uu-reginize-string subject)))
    (if (string-match "\\[0-9\\]\\+[^0-9]*\\([0-9]+\\)" string)
	(string-to-number (substring string (match-beginning 1) (match-end 1)))
      0)))

Cheers,
Doug

Re: Wishlist for oGnus

[Alexandre Oliva]

On Jan 21, 2000, "David Z. Maze" <dmaze@mit.edu> wrote:

> * Have Gnus automagically set group parameters for mailing list
>   groups.  For example, if I have a splitting rule that automatically
>   sorts ding@gnus.org into mail.ding, then Gnus should clue in, set
>   the to-list parameter to 'ding@gnus.org', and set total-expire.

How about the contrary: when you set to-list, it automatically adds
that to the mail splitting rules?  That's what you get with
gnus-group-split.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Group parameters and splitting (Was: Re: Wishlist for oGnus)

[David Z. Maze]

Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:
AO> On Jan 21, 2000, "David Z. Maze" <dmaze@mit.edu> wrote:
 DZM> * Have Gnus automagically set group parameters for mailing list
 DZM> groups.  For example, if I have a splitting rule that automatically
 DZM> sorts ding@gnus.org into mail.ding, then Gnus should clue in, set
 DZM> the to-list parameter to 'ding@gnus.org', and set total-expire.
AO> 
AO> How about the contrary: when you set to-list, it automatically adds
AO> that to the mail splitting rules?  That's what you get with
AO> gnus-group-split.

For example, my nnmail-split-fancy contains
(any "debian-\\(\\w*\\)@lists\\.debian\\.org" "mail.lists.debian.\\1")
which causes groups like mail.lists.debian.devel,
mail.lists.debian.user, etc. to be automagically created.  I don't
want to create all of the relevant groups by hand, and I'd prefer not
to set group parameters by hand either.

-- 
David Maze             dmaze@mit.edu          http://donut.mit.edu/dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
	-- Abra Mitchell

Re: Wishlist for oGnus

[John Prevost]

On 21 Jan 2000, Stainless Steel Rat wrote:

> Relatively simple, I hope:
> 
>   * gnus-uu-decode should complain if one or more parts of a series post
>     (ie, "part N of X") is missing, and optionally tick what parts are
>     there for decoding in a later session.

Something related I'd find even more useful (though it really wants the
above):

  * Either the ability to suspend downloading mid-stream and continue it
    again later.  (Either because I want to read some other news or
    because I'm about to unplug the network.)

  * Or the ability to add things for downloading to a sort of queue, which
    is handled automatically by the demon stuff.  This way, not only could
    processing of big multiparts be done automatically behind my back, but
    the system could even potentially watch for the appearance of missing
    articles, and finish if they appear (or give a warning if they don't)
    over a week or so.

Pie in the sky.  :)

John.

Re: Wishlist for oGnus

[Raja R Harinath]

* Support message/partial MIME "envelope".

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Wishlist for oGnus

[Justin Sheehy]

Jonas Steverud <d4jonas@dtek.chalmers.se> writes:

> * Update the FAQ! From (gnus)Installation FAQ:
>    * Q1.1  What is the latest version of Gnus?
> 
>      The latest (and greatest) version is 5.0.10.  

The copy of the FAQ that is currently packaged alonside Gnus is
certainly way out of date.  This is because the FAQ is currently
maintained in HTML, and I haven't texinfo'ed it.

I have been planning on doing so for a while, and sort-of planning on
changing the markup language that the FAQ is maintained in.  But I
haven't managed to get around to it yet.

In any case, this one is my fault, and I should do something about
it.  But there is also the fact that the real FAQ is generally pretty
up-to-date.  It is posted on usenet every month and also can be found at
http://www.ccs.neu.edu/software/contrib/gnus/

-Justin

 

Re: Wishlist for oGnus

[Steinar Bang]

* Delayed downloading of attachments with nnimap.  What message parts
  not to download except by explicit command should be configurable
  (MIME type and size)

* Agent and nnimap delayed downloading of attachments.  When used with
  agent, nnimap should be able to have MIME message parts marked for
  download the next time Gnus is online and plugged, in the same way
  as today whole articles are marked

Re: Wishlist for oGnus

[Andrew J Cosgriff]

Steinar Bang wrote :

> * Delayed downloading of attachments with nnimap.  What message parts
>   not to download except by explicit command should be configurable
>   (MIME type and size)

Mmm, yes please.

-- 
Andrew J Cosgriff <ajc@polydistortion.net> shaken and stirred

Re: Wishlist for oGnus

[Andi Hechtbauer]

Steinar Bang <sb@metis.no> writes:

> * Delayed downloading of attachments with nnimap.  What message parts
>   not to download except by explicit command should be configurable
>   (MIME type and size)
> 
> * Agent and nnimap delayed downloading of attachments.  When used with
>   agent, nnimap should be able to have MIME message parts marked for
>   download the next time Gnus is online and plugged, in the same way
>   as today whole articles are marked

Yes Pu-leeese :-) 

This is one of the top features of IMAP for me. It would be so great,
I even considered learning elisp just to implement _that_. But then...

regards,

-- 
Andi Hechtbauer                                           anti@spin.de 
System Administration                         voice: +49 941 94 65 937
SPiN GmbH               http://www.spin.de/     fax: +49 941 94 65 938  
------- web design - java chats - guestbooks - java/cgi coding -------

Re: Wishlist for oGnus

[Rob Browning]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> * Create new data type `article identifier' and use that instead of
>   article numbers.  A first implementation could offer something like
>   (num . 4711) but this could be extended.  This would be useful for
>   using servers with *really* large numbers -- there we could have a
>   bignum type.  It might also be useful for the nnweb and nnultimate
>   thingies where article identifiers are not really numbers.

It would be really nice (if this is done) to go one step further and
move to totally unique (within a server?) message ID's.  That way you
don't have problems with article renumbering, and you can use the ID's
like pointers in other files to refer to messages, etc.  This might
also allow the nnml backend to be more easily modified to handle
directory hashing to deal with really large groups without slowing
down so dramatically.

I also agree with those that want to generalize the idea of marking to
support more than just a few useful ones.

> * Allow sorting of threads by newest article rather than by root of
>   thread.

This would be great.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: Wishlist for oGnus

[lconrad]

>>>>> "Karl" == Karl Kleinpaste <karl@justresearch.com> writes:

    Karl> Most of what I want is mail-specific.

    Karl> * Baby's First Mail In Gnus.  

(lots of good ideas snipped)

Another aspect of starting to use mail in gnus that intimidates
first-time users is how to find the groups once you've started
splitting them.  The manual says:

    manual> Getting Started Reading Mail 
    manual> ----------------------------

    manual>    It's quite easy to use Gnus to read your new mail.  You
    manual>    just plonk
    manual> the mail backend of your choice into
    manual> `gnus-secondary-select-methods', and things will happen
    manual> automatically.  ...
    manual>    You will probably want to split the mail into several
    manual>    groups, though:

    manual>      (setq nnmail-split-methods
    manual>            '(("junk" "^From:.*Lars Ingebrigtsen")
    manual>              ("crazy"
    manual>              "^Subject:.*die\\|^Organization:.*flabby")
    manual>              ("other" "")))

    manual>    This will result in three new `nnml' mail groups being
    manual>    created:
    manual> `nnml:junk', `nnml:crazy', and `nnml:other'.  All the mail
    manual> that doesn't fit into the first two groups will be placed
    manual> in the last group.

    manual>    This should be sufficient for reading mail with Gnus.

Let me quote from a recent gnu.emacs.gnus posting:

    newbie> I am sorry if this has been asked. I tried reading the
    newbie> manual, but haven't found a solution. The problem, I am
    newbie> having is with reading mail from my ISP using "nnml"
    newbie> backend.  Gnus on startup connects to my ISP, ans gathers
    newbie> the mail, but does not display it in the group buffer. I
    newbie> tried the command, "A z" to display zombies and I get the
    newbie> response saying, No zombies.

    kai> The following should be tried in this order: `F', `A k', `A
    kai> z', `A A'.  Type `u' on a group to subscribe to it.  In the
    kai> long lists, you may wish to use `C-s nnml' to search for this
    kai> string.

I think the right thing is to change the behavior of gnus so that the
example in the manual "just works", and people don't have to try
several undocumented key sequences in the right order to find their
mail.  I don't know what the best way to do this would be -- maybe
changing the default level for a newly created nnml group?

If we don't do that, I think adding documentation about how to find
the groups created by nnmail-split-methods to the Getting Started
Reading Mail  section of the manual would be a good idea.  

-- 
Laura (mailto:lconrad@world.std.com , http://www.world.std.com/~lconrad/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: Wishlist for oGnus

[Andreas Fuchs]

* in Novice mode, warn if Forwarding Messages with ^Re: CfV.* in the
  Subject to a newsgroup and not to poster; warning when replying to
  a RfD would not be good beahvior, IMO.

  (i.e. "This is a call for vote. Really Follow up to Group?")

Regards,
-- 
Andreas Stefan Fuchs                             in Real Life aka
asf@ycom.at, asf@acm.org                         in NNTP and SMTP,
antifuchs@#debian.de, #linux.de and #unix        in IRC and
Relf Herbstfresser, Male 1/2 Elf Priest          in AD&D

Re: Wishlist for oGnus

[Steinar Bang]

* make it possible to set a directory prefix for each IMAP server.
  This will make mail group names shorter when using the UoW imapd

* make it possible to list all available folders of an IMAP server.
  This command should use the directory prefix for the servers where
  this has been set

Re: Wishlist for oGnus

[David Kagedal]

Steinar Bang <sb@metis.no> writes:

> * make it possible to set a directory prefix for each IMAP server.
>   This will make mail group names shorter when using the UoW imapd

Even better:

* Make it possible to duplicate the IMAP folder hierarchy with Gnus
  topics, and only showing the last part of the group names, since the
  full folder name (minus the root prefix) is available as the topic
  path.

-- 
David Kågedal

Re: Wishlist for oGnus

[Simon Josefsson]

David Kagedal <davidk@lysator.liu.se> writes:

> Steinar Bang <sb@metis.no> writes:
> 
> > * make it possible to set a directory prefix for each IMAP server.
> >   This will make mail group names shorter when using the UoW imapd
> 
> Even better:
> 
> * Make it possible to duplicate the IMAP folder hierarchy with Gnus
>   topics, and only showing the last part of the group names, since the
>   full folder name (minus the root prefix) is available as the topic
>   path.

I agree this would be useful, it was debated a while ago on the nnimap
list (now unavailable due to the infinite wisdom of networksolutions),
but it was noted that something similar already exist on the todo
list:

@item
 a way to say that all groups within a specific topic comes
from a particular server?  Hm.

IMAP server hierarchy as topics

[Steinar Bang]

>>>>> David Kagedal <davidk@lysator.liu.se>:

> Steinar Bang <sb@metis.no> writes:
>> * make it possible to set a directory prefix for each IMAP server.
>> This will make mail group names shorter when using the UoW imapd

> Even better:

> * Make it possible to duplicate the IMAP folder hierarchy with Gnus
>   topics, and only showing the last part of the group names, since the
>   full folder name (minus the root prefix) is available as the topic
>   path.

Hm... but I use topics as a logical grouping, grouping news groups and 
mail groups about the same things.  Won't this approach conflict with
that? 

Re: IMAP server hierarchy as topics

[David Kagedal]

Steinar Bang <sb@metis.no> writes:

> >>>>> David Kagedal <davidk@lysator.liu.se>:
> 
> > Steinar Bang <sb@metis.no> writes:
> >> * make it possible to set a directory prefix for each IMAP server.
> >> This will make mail group names shorter when using the UoW imapd
> 
> > Even better:
> 
> > * Make it possible to duplicate the IMAP folder hierarchy with Gnus
> >   topics, and only showing the last part of the group names, since the
> >   full folder name (minus the root prefix) is available as the topic
> >   path.
> 
> Hm... but I use topics as a logical grouping, grouping news groups and 
> mail groups about the same things.  Won't this approach conflict with
> that? 

Yes it would, and I wouldn't want to force it on you.  I previously
used topics like you do, but since I switched to IMAP, and started
reading mail from several IMAP sources, and no NNTP, I prefer to group
them by server, because that is logical to me; one topic for work, and
one of private stuff.

-- 
David Kågedal

Re: IMAP server hierarchy as topics

[John Prevost]

David Kagedal <davidk@lysator.liu.se> writes:

> Steinar Bang <sb@metis.no> writes:
> 
> > >>>>> David Kagedal <davidk@lysator.liu.se>:
> > 
> > > Steinar Bang <sb@metis.no> writes:
> > >> * make it possible to set a directory prefix for each IMAP server.
> > >> This will make mail group names shorter when using the UoW imapd
> > 
> > > Even better:
> > 
> > > * Make it possible to duplicate the IMAP folder hierarchy with Gnus
> > >   topics, and only showing the last part of the group names, since the
> > >   full folder name (minus the root prefix) is available as the topic
> > >   path.

Hmm.  If this could be made to do lookups in a "nice" way when
browsing the active file hierarchically (A T?  Is that it?) this would
be especially good.  (i.e. do a LIST "" "%" to get the top level, then
LIST "" "something.%" when you open one of the sublevels, and so on.)
This would provide a good way to deal with very large servers, since
getting the active file on a 30000 group server is a bit, um,
prohibitive at the moment.  (I haven't let it finish--30 minutes and
all the VM on my machine is sufficient to put me off.)

> > Hm... but I use topics as a logical grouping, grouping news groups and 
> > mail groups about the same things.  Won't this approach conflict with
> > that? 

No forcing of this on people, yeah.  Also note the ability of groups
to be in more than one topic, though.  That could help this issue.

John.

Re: Wishlist for oGnus

[Alf-Ivar Holm]

lconrad@world.std.com writes:

> I think the right thing is to change the behavior of gnus so that the
> example in the manual "just works", and people don't have to try
> several undocumented key sequences in the right order to find their
> mail.  I don't know what the best way to do this would be -- maybe
> changing the default level for a newly created nnml group?

Yes, or at least some option to set it.  It's fine by me that new
news-groups are zombies, but mail I usually don't want to miss, on the
contrary, I would like my new mail groups to show up with "l" as soon
as some mail is being splitted to them.  

        Affi

Re: Wishlist for oGnus

[Anders Melchiorsen]

Not having followed this thread, I may be duplicating. But it just
occurred to me that what I really miss in Gnus when comparing to more
graphical clients is the ability to open several views at the same
time.

That is, have two frames showing different summaries/messages, for
example. Or showing several messages from the same group at the same
time, in a couple of different frames.

I do belive that this is not possible, or at least not pretty, with
current Gnus. Please tell me that I wrong? :)
-- 
Regards, Anders
(address is valid)

Re: Wishlist for oGnus

[Kai Großjohann]

Anders Melchiorsen <postmaster@and.nospam.kampsax.k-net.dk> writes:

> That is, have two frames showing different summaries/messages, for
> example. Or showing several messages from the same group at the same
> time, in a couple of different frames.

There is the variable gnus-single-article-buffer, which might help.
And there is gnus-kill-summary-on-exit, which also might help.  I'm
not sure if it does, though.

You could try M-x rename-uniquely RET to have two summary buffers for
the same group -- does that work?

kai
-- 
~/.signature: No such file or directory

Multiple view interface (Re: Wishlist for oGnus)

[Anders Melchiorsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> Anders Melchiorsen <postmaster@and.nospam.kampsax.k-net.dk> writes:
> 
> > That is, have two frames showing different summaries/messages, for
> > example. Or showing several messages from the same group at the same
> > time, in a couple of different frames.
> 
> There is the variable gnus-single-article-buffer, which might help.

That does indeed seem to help a bit. Thanks.

> And there is gnus-kill-summary-on-exit, which also might help.  I'm
> not sure if it does, though.

I have gnus-kill-summary-on-exit set to t and I like the way it works.

> You could try M-x rename-uniquely RET to have two summary buffers for
> the same group -- does that work?

No, I seem to still get problems. I cannot figure out a useful setup
where I can look at several messages in the same group; the buffers
seem to come and go in strange and wonderful ways when I select a new
message in the summary buffer.

It is not a major concern, though. Usually it is sufficient to read
one message at a time.

-- 
Regards, Anders
(address is valid)

IMAP server hierarchy as topics

[Steinar Bang]

>>>>> David Kagedal <davidk@lysator.liu.se>:

> Steinar Bang <sb@metis.no> writes:
>> * make it possible to set a directory prefix for each IMAP server.
>> This will make mail group names shorter when using the UoW imapd

> Even better:

> * Make it possible to duplicate the IMAP folder hierarchy with Gnus
>   topics, and only showing the last part of the group names, since the
>   full folder name (minus the root prefix) is available as the topic
>   path.

On closer thought, the two requirements are separate.

My requirment is to make nnimap work better with UoW imapd, running on 
a machine where the users' home directories are used for other things
than mail.

You would wish to set the directory prefix for a UoW imapd, even when
you're presenting the IMAP folder hierarchy as topics (unless you wish 
to browse your entire home directory as mail folders... which I guess
is possible, however I don't)

Re: IMAP server hierarchy as topics

[David Kagedal]

Steinar Bang <sb@metis.no> writes:

> >>>>> David Kagedal <davidk@lysator.liu.se>:
> 
> > Steinar Bang <sb@metis.no> writes:
> >> * make it possible to set a directory prefix for each IMAP server.
> >> This will make mail group names shorter when using the UoW imapd
> 
> > Even better:
> 
> > * Make it possible to duplicate the IMAP folder hierarchy with Gnus
> >   topics, and only showing the last part of the group names, since the
> >   full folder name (minus the root prefix) is available as the topic
> >   path.
> 
> On closer thought, the two requirements are separate.

Separate, but related.

On a related note, working with UoW poses problems if you want to
create mail folder from Gnus, since Gnus does not allow / in group
names.

I have applied this patch to my local copy.  It is probably not a good
idea to do this in the general case.

--- gnus.el	2000/01/31 22:08:08	5.127
+++ gnus.el	2000/02/15 10:27:39
@@ -2782,7 +2782,7 @@
 	group)
     (while (not group)
       (when (string-match
-	     "[: `'\"/]\\|^$"
+	     "[: `'\"]\\|^$"
 	     (setq group (read-string (concat prefix prompt)
 				      (cons (or default "") 0)
 				      'gnus-group-history)))


-- 
David Kågedal

Re: IMAP server hierarchy as topics

[David Kagedal]

Steinar Bang <sb@metis.no> writes:

> >>>>> David Kagedal <davidk@lysator.liu.se>:
> 
> > Steinar Bang <sb@metis.no> writes:
> >> * make it possible to set a directory prefix for each IMAP server.
> >> This will make mail group names shorter when using the UoW imapd
> 
> > Even better:
> 
> > * Make it possible to duplicate the IMAP folder hierarchy with Gnus
> >   topics, and only showing the last part of the group names, since the
> >   full folder name (minus the root prefix) is available as the topic
> >   path.
> 
> On closer thought, the two requirements are separate.
> 
> My requirment is to make nnimap work better with UoW imapd, running on 
> a machine where the users' home directories are used for other things
> than mail.
> 
> You would wish to set the directory prefix for a UoW imapd, even when
> you're presenting the IMAP folder hierarchy as topics (unless you wish 
> to browse your entire home directory as mail folders... which I guess
> is possible, however I don't)

In a flash of inspiration, I decided to implement your first idea,
remove a prefix from the group names.

I have used %G in gnus-group-line-format, which would make all my
group names, exept for INBOX, start with "mail/".

An nnimap method does not really specify a prefix, but a list
pattern.  So I decided that I needed to add the prefix to strip to the
method information.  This is what I use:

    (defconst lysator-imap-method
      '(nnimap "lysator"
               (nnimap-address "imap.lysator.liu.se")
               (nnimap-list-pattern ("INBOX" "mail/*"))
               (prefix "mail/")))  

I implemented a user format function, and use %uG instead of %G.

    (setq gnus-group-line-format "%m%M%S%p%5y: %(%uG%)\n")

The function does one more trick; if the group parameters contains a
'name parameter, its value is used instead.

    (defun gnus-user-format-function-G (arg)
      (let ((name (gnus-group-find-parameter gnus-tmp-group 'name)))
        (if name
            name
          (let ((prefix (assq 'prefix (cddr gnus-tmp-method))))
            (if (and prefix
                     (string-match (concat "^\\("
                                           (regexp-quote (cadr prefix))
                                           "\\)")
                                   gnus-tmp-qualified-group))
                (substring gnus-tmp-qualified-group (match-end 1))
              gnus-tmp-qualified-group))))))

-- 
David Kågedal

Re: IMAP server hierarchy as topics

[David Kagedal]

David Kagedal <davidk@lysator.liu.se> writes:

> The function does one more trick; if the group parameters contains a
> 'name parameter, its value is used instead.

This, I admit, is a dubious feature, and has absolutely nothing to do
with what I was really trying to solve.

-- 
David Kågedal

Re: IMAP server hierarchy as topics

[Chris Richards]

Steinar Bang <sb@metis.no> writes:
> My requirment is to make nnimap work better with UoW imapd, running on 
> a machine where the users' home directories are used for other things
> than mail.

And along those lines, it would be nice if nnimap used many of the
same features that the nnfolder backend uses.  In other words, you
should be able to read local IMAP folders stored under ~/Mail with
nnfolder.  From my cursory glance, it doesn't seem that the IMAP
messages have X-Gnus-* and Xref.

Cheers,
cjr

IMAP extra headers (was: IMAP server hierarchy as topics)

[Toby Speight]

Chris> Chris J. Richards <URL:mailto:cjr@netpliance.net>

0> In article <6e66vq4hcb.fsf@sloth.netpliance.net>, Chris wrote:

Chris> From my cursory glance, it doesn't seem that the IMAP messages
Chris> have X-Gnus-* and Xref.

ISTR this is because you can't edit articles on IMAP backends.  Perhaps
it's possible to store these extra headers as IMAP properties, and
insert them into the article buffer at retrieval time?

This approach would be helpful in reading MS Exchange's calendar/contact
items, as was requested recently - without having to imbue Gnus with
knowledge of IMAP's annotations.  Simply have the fetch function write
these properties into X-headers, then user code can operate on them
(and they work even when the article is copied to other backends!).

Re: IMAP server hierarchy as topics

[Arnd Kohrs]

>>>>> "David" == David Kagedal <davidk@lysator.liu.se> writes:


    David>     (defconst lysator-imap-method '(nnimap "lysator"
    David> (nnimap-address "imap.lysator.liu.se") (nnimap-list-pattern
    David> ("INBOX" "mail/*")) (prefix "mail/")))

    David> I implemented a user format function, and use %uG instead of
    David> %G.

    David>     (setq gnus-group-line-format "%m%M%S%p%5y: %(%uG%)\n")

    David> The function does one more trick; if the group parameters
    David> contains a 'name parameter, its value is used instead.

Hi David,

NAME:
I tried and liked your code. However, when I do a ¨G c¨ (to customize
a group) Gnus chokes on the new 'name' attribute.  
 
Signaling: (wrong-type-argument listp "Ding")
  widget-match-inline((sexp :tag "Value" :value "nil") "Ding")
  widget-group-match-inline((list :format "%v" :value (nil nil) :args ((symbol :tag "Variable" :value "nil") (sexp :tag "Value" :value "nil"))) (name . "Ding"))
  widget-group-match((list :format "%v" :value (nil nil) :args ((symbol :tag "Variable" :value "nil") (sexp :tag "Value" :value "nil"))) (name . "Ding"))
[...]

Also, I would suggest a more explicative name for the parameter, for
example display-name or preferred-display-name.

PREFIX MASKING:

Even though Your solution provides some a cosmetical cover-up to the
previously described problem, the prefix-masking should be applied on a
lower level, so that the existence of a prefix is transparent for the
user.

Example: When I want to copy a message to group, which prefix has been
masked, I still need to know the prefix.

Again, I suggest a better name which captures more the nature of the
parameter (for example prefix-to-mask or remove-prefix )

CU
Arnd.

-- 
Arnd Kohrs   -   kohrs@acm.org  -  http://www.eurecom.fr/~kohrs
              
The Active WebMuseum: Your personalized access to art paintings.
 Visit now ->  http://www.eurecom.fr/~kohrs/museum.html

Re: IMAP server hierarchy as topics

[David Kågedal]

Arnd Kohrs <kohrs@acm.org> writes:

> NAME:
> I tried and liked your code. However, when I do a ¨G c¨ (to customize
> a group) Gnus chokes on the new 'name' attribute.  
>  
> Signaling: (wrong-type-argument listp "Ding")
>   widget-match-inline((sexp :tag "Value" :value "nil") "Ding")
>   widget-group-match-inline((list :format "%v" :value (nil nil) :args ((symbol :tag "Variable" :value "nil") (sexp :tag "Value" :value "nil"))) (name . "Ding"))
>   widget-group-match((list :format "%v" :value (nil nil) :args ((symbol :tag "Variable" :value "nil") (sexp :tag "Value" :value "nil"))) (name . "Ding"))
> [...]

This I get with all nnimap groups, caused by the uidvalidity
parameter.  I thoung Per wrote that it was a widget.el bug or
something.

> Also, I would suggest a more explicative name for the parameter, for
> example display-name or preferred-display-name.

I would go for display-name.

> PREFIX MASKING:
> 
> Even though Your solution provides some a cosmetical cover-up to the
> previously described problem, the prefix-masking should be applied on a
> lower level, so that the existence of a prefix is transparent for the
> user.
> 
> Example: When I want to copy a message to group, which prefix has been
> masked, I still need to know the prefix.

If possible, this might be true.  But it should should probably not go
in at the lowest level, since the groups needs a uniquie identifying
name which shouldne be so easily changed.

> Again, I suggest a better name which captures more the nature of the
> parameter (for example prefix-to-mask or remove-prefix )

This is an updated version:

    (defun gnus-user-format-function-G (arg)
      (or (gnus-group-find-parameter gnus-tmp-group 'display-name)
          (let ((prefix (assq 'remove-prefix (cddr gnus-tmp-method))))
            (if (and prefix
                     (string-match (concat "^\\("
                                           (regexp-quote (cadr prefix))
                                           "\\)")
                                   gnus-tmp-qualified-group))
                (substring gnus-tmp-qualified-group (match-end 1))
              gnus-tmp-qualified-group))))

This is how I currently use it:

    (setq gnus-group-line-format "%m%M%S%p%P%(%uG - %y%)\n")
    (defalias 'gnus-group-position-point 'beginning-of-line)

-- 
David Kågedal

Re: IMAP server hierarchy as topics

[Steinar Bang]

>>>>> David Kagedal <davidk@lysator.liu.se>:

>     (defconst lysator-imap-method
>       '(nnimap "lysator"
>                (nnimap-address "imap.lysator.liu.se")
>                (nnimap-list-pattern ("INBOX" "mail/*"))
>                (prefix "mail/")))  

Hm... shouldn't the setting be something like this to be more logical?
     (defconst lysator-imap-method
       '(nnimap "lysator"
                (nnimap-address "imap.lysator.liu.se")
                (nnimap-list-pattern ("INBOX" "*"))
                (prefix "mail/")))  

Alternatively the prefix could be calculated from the entry in the
nnimap-list-pattern, if there is only one (though I prefer an explicit 
prefix).

Re: IMAP server hierarchy as topics

[David Kågedal]

Steinar Bang <sb@metis.no> writes:

> >>>>> David Kagedal <davidk@lysator.liu.se>:
> 
> >     (defconst lysator-imap-method
> >       '(nnimap "lysator"
> >                (nnimap-address "imap.lysator.liu.se")
> >                (nnimap-list-pattern ("INBOX" "mail/*"))
> >                (prefix "mail/")))  
> 
> Hm... shouldn't the setting be something like this to be more logical?
>      (defconst lysator-imap-method
>        '(nnimap "lysator"
>                 (nnimap-address "imap.lysator.liu.se")
>                 (nnimap-list-pattern ("INBOX" "*"))
>                 (prefix "mail/")))  
> 
> Alternatively the prefix could be calculated from the entry in the
> nnimap-list-pattern, if there is only one (though I prefer an explicit 
> prefix).

I think it would be ugly to give nnimap-list-pattern different
meanings depending on whether there exists another parameter.  Then
I'd rather have a paramter to use *instead* of nnimap-list-pattern.

-- 
David Kågedal

Re: IMAP server hierarchy as topics

[Justin Sheehy]

Chris Richards <cjr@netpliance.net> writes:

> And along those lines, it would be nice if nnimap used many of the
> same features that the nnfolder backend uses.  In other words, you
> should be able to read local IMAP folders stored under ~/Mail with
> nnfolder. 

I must be misunderstanding what you are asking for.  In the general
case, you certainly can't read IMAP mailboxes with nnfolder.

IMAP is a mail access network protocol that quite intentionally does
not specify the storage format of mailboxes.  It is entirely
implementation-dependent.  One IMAP server might store folders in mbox 
format, one might store them in an mh-like format, and another might
store them in a database.

It is quite clear and essential that the end-user never needs to know
what format the server uses for storage.  

Thus, while users of one specific IMAP server implementation might be
able to get at their mailboxes with nnfolder, nnmh, or whatever, this
is not a feature that can be generalized.

-Justin

 

Re: IMAP server hierarchy as topics

[Chris Richards]

You are not misunderstanding.

I realize that the file format is server dependent.  With that said,
however, most of the Unix varients that I have dealt with interact
directly with /var/spool/mail (reads and writes to it) as well as
read/write in mbox format to the users' home directories for
sub-folders.

Majority rules.

I have no wishes that the feature be generalized.  In fact, if it
maintained the Xref and X-Gnus* tags, I would be happy.  It would then
be up to the user to determine what other backend (if any) could
read/write locally stored files.

Cheers,
cjr

Justin Sheehy <dworkin@ccs.neu.edu> writes:
> Chris Richards <cjr@netpliance.net> writes:
> 
> > And along those lines, it would be nice if nnimap used many of the
> > same features that the nnfolder backend uses.  In other words, you
> > should be able to read local IMAP folders stored under ~/Mail with
> > nnfolder. 
> 
> I must be misunderstanding what you are asking for.  In the general
> case, you certainly can't read IMAP mailboxes with nnfolder.
> 
> IMAP is a mail access network protocol that quite intentionally does
> not specify the storage format of mailboxes.  It is entirely
> implementation-dependent.  One IMAP server might store folders in mbox 
> format, one might store them in an mh-like format, and another might
> store them in a database.
> 
> It is quite clear and essential that the end-user never needs to know
> what format the server uses for storage.  
> 
> Thus, while users of one specific IMAP server implementation might be
> able to get at their mailboxes with nnfolder, nnmh, or whatever, this
> is not a feature that can be generalized.
> 
> -Justin
> 
>  

Re: IMAP server hierarchy as topics

[Simon Josefsson]

Chris Richards <cjr@netpliance.net> writes:

> I have no wishes that the feature be generalized.  In fact, if it
> maintained the Xref and X-Gnus* tags, I would be happy.  It would then
> be up to the user to determine what other backend (if any) could
> read/write locally stored files.

Would `it' mean nnimap?  If so, it can't maintain Xref and X-Gnus
header since articles can't be edited via IMAP (not without changing
the article ID anyway, and then I wouldn't call it "editing" but
rather "replacing").

Re: Wishlist for oGnus

[Kim-Minh Kaplan]

Anders Melchiorsen writes:

> what I really miss in Gnus when comparing to more graphical clients
> is the ability to open several views at the same time.
> 
> That is, have two frames showing different summaries/messages, for
> example. Or showing several messages from the same group at the same
> time, in a couple of different frames.
> 
> I do belive that this is not possible, or at least not pretty, with
> current Gnus. Please tell me that I wrong? :)

You're only partly wrong: if you set `gnus-single-article-buffer' to
nil then each group gets its own article buffer.

To view multiple articles from the same newsgroup, you can go to the
*Article* buffer and invoke `rename-uniquely' then go to the other
article you want to see.  Not pretty though.

Kim-Minh.

nnfolder NOV (was: Wishlist for oGnus)

[ShengHuo ZHU]

Robert Epprecht <epprecht@sunweb.ch> writes:

> * A nnfolder like backend with .overview files.
>   This would not only speed up things, but also allow nnir to work on it.

Done, but unstable.

(setq nnfolder-nov-is-evil t) disables the feature.

ShengHuo

Re: nnfolder NOV (was: Wishlist for oGnus)

[Dan Christensen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> Robert Epprecht <epprecht@sunweb.ch> writes:
> 
> > * A nnfolder like backend with .overview files.
> >   This would not only speed up things, but also allow nnir to work on it.
> 
> Done, but unstable.
> 
> (setq nnfolder-nov-is-evil t) disables the feature.
> 
> ShengHuo

When I run nnfolder-generate-active-file, I get the backtrace below.
I am using Gnu emacs 20.7.2 and the latest version of Gnus from cvs.

Dan

Signaling: (wrong-type-argument stringp nil)
  mm-encode-coding-string(nil binary)
  (setq group (mm-encode-coding-string group nnmail-pathname-coding-system))
  nnfolder-group-pathname(nil)
  (concat (nnfolder-group-pathname group) nnfolder-nov-file-suffix)
  (let ((nnfolder-directory ...)) (concat (nnfolder-group-pathname group) nnfolder-nov-file-suffix))
  nnfolder-group-nov-pathname(nil)
  (set (make-local-variable (quote nnfolder-nov-buffer-file-name)) (nnfolder-group-nov-pathname nnfolder-current-group))
  (save-excursion (set-buffer buffer) (set (make-local-variable ...) (nnfolder-group-nov-pathname nnfolder-current-group)) (erase-buffer) (when (file-exists-p nnfolder-nov-buffer-file-name) (nnheader-insert-file-contents nnfolder-nov-buffer-file-name)))
  (let ((buffer ...)) (save-excursion (set-buffer buffer) (set ... ...) (erase-buffer) (when ... ...)) (push (cons group buffer) nnfolder-nov-buffer-alist) buffer)
  (or (cdr (assoc group nnfolder-nov-buffer-alist)) (let (...) (save-excursion ... ... ... ...) (push ... nnfolder-nov-buffer-alist) buffer))
  nnfolder-open-nov("1year")
  (setq novbuf (nnfolder-open-nov group))
  (set-buffer (setq novbuf (nnfolder-open-nov group)))
  (save-current-buffer (set-buffer (setq novbuf ...)) (goto-char (point-min)) (while (not ...) (push ... articles) (forward-line 1)) (setq articles (nreverse articles)))
  (with-current-buffer (setq novbuf (nnfolder-open-nov group)) (goto-char (point-min)) (while (not ...) (push ... articles) (forward-line 1)) (setq articles (nreverse articles)))
  (if (or gnus-nov-is-evil nnfolder-nov-is-evil (and ... ...)) nil (unless (file-exists-p nov) (gnus-make-directory ...)) (with-current-buffer (setq novbuf ...) (goto-char ...) (while ... ... ...) (setq articles ...)))
  (unless (or gnus-nov-is-evil nnfolder-nov-is-evil (and ... ...)) (unless (file-exists-p nov) (gnus-make-directory ...)) (with-current-buffer (setq novbuf ...) (goto-char ...) (while ... ... ...) (setq articles ...)))
  (let ((delim "^From ") (marker ...) (number "[0-9]+") (active ...) (scantime ...) (minid ...) maxid start end newscantime novbuf articles newnum buffer-read-only) (buffer-disable-undo) (setq maxid (cdr active)) (unless (or gnus-nov-is-evil nnfolder-nov-is-evil ...) (unless ... ...) (with-current-buffer ... ... ... ...)) (goto-char (point-min)) (when (or nnfolder-ignore-active-file novbuf ...) (while ... ... ...) (when ... ...) (setcar active ...) (setcdr active ...) (goto-char ...)) (when (not ...) (goto-char ...) (unless ... ...)) (unless (nnmail-search-unix-mail-delim) (goto-char ...)) (setq end (point-marker)) (while (not ...) (setq start ...) (goto-char end) (while ... ...) (set-marker end ...) (goto-char start) (when ... ... ... ... ... ...)) (set-marker end nil) (nnfolder-save-active nnfolder-group-alist nnfolder-active-file) (setq newscantime (visited-file-modtime)) (if scantime (setcdr scantime ...) (push ... nnfolder-scantime-alist)) (when novbuf (nnfolder-save-no!
 
v)) (current-buffer))
  (save-excursion (goto-char (point-min)) (while (eq ... 10) (delete-char 1)) (nnmail-activate (quote nnfolder)) (let (... ... ... ... ... ... maxid start end newscantime novbuf articles newnum buffer-read-only) (buffer-disable-undo) (setq maxid ...) (unless ... ... ...) (goto-char ...) (when ... ... ... ... ... ...) (when ... ... ...) (unless ... ...) (setq end ...) (while ... ... ... ... ... ... ...) (set-marker end nil) (nnfolder-save-active nnfolder-group-alist nnfolder-active-file) (setq newscantime ...) (if scantime ... ...) (when novbuf ...) (current-buffer)))
  (if (equal (cadr ...) (nth 5 ...)) (if (file-exists-p file) buffer (push ... nnfolder-buffer-alist) (set-buffer-modified-p t) (nnfolder-save-buffer)) (save-excursion (goto-char ...) (while ... ...) (nnmail-activate ...) (let ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...)))
  (let* ((file ...) (nov ...) (buffer ...)) (if (equal ... ...) (if ... buffer ... ... ...) (save-excursion ... ... ... ...)))
  nnfolder-read-folder("1year")
  (list group (nnfolder-read-folder group))
  (cons (list group (nnfolder-read-folder group)) nnfolder-buffer-alist)
  (setq nnfolder-buffer-alist (cons (list group ...) nnfolder-buffer-alist))
  (push (list group (nnfolder-read-folder group)) nnfolder-buffer-alist)
  (if (and inf (gnus-buffer-live-p ...)) (set-buffer (cadr inf)) (when inf (setq nnfolder-buffer-alist ...)) (when nnfolder-group-alist (nnfolder-save-active nnfolder-group-alist nnfolder-active-file)) (push (list group ...) nnfolder-buffer-alist))
  (let ((inf ...)) (if (and inf ...) (set-buffer ...) (when inf ...) (when nnfolder-group-alist ...) (push ... nnfolder-buffer-alist)))
  nnfolder-possibly-change-folder("1year")
  (let ((oldgroup ...)) (if oldgroup (nnheader-message 5 "Refreshing group %s..." file) (nnheader-message 5 "Adding group %s..." file)) (if oldgroup (setq nnfolder-group-alist ...)) (push (list file ...) nnfolder-group-alist) (nnfolder-possibly-change-folder file) (nnfolder-possibly-change-group file) (nnfolder-close-group file))
  (progn (let (...) (if oldgroup ... ...) (if oldgroup ...) (push ... nnfolder-group-alist) (nnfolder-possibly-change-folder file) (nnfolder-possibly-change-group file) (nnfolder-close-group file)))
  (if (and (not ...) (message-mail-file-mbox-p ...)) (progn (let ... ... ... ... ... ... ...)))
  (when (and (not ...) (message-mail-file-mbox-p ...)) (let (...) (if oldgroup ... ...) (if oldgroup ...) (push ... nnfolder-group-alist) (nnfolder-possibly-change-folder file) (nnfolder-possibly-change-group file) (nnfolder-close-group file)))
  (while (setq file (pop files)) (when (and ... ...) (let ... ... ... ... ... ... ...)))
  (let ((files ...) file) (while (setq file ...) (when ... ...)) (nnheader-message 5 ""))
  nnfolder-generate-active-file()
  call-interactively(nnfolder-generate-active-file)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Re: nnfolder NOV (was: Wishlist for oGnus)

[ShengHuo ZHU]

Dan Christensen <jdc@julian.uwo.ca> writes:

> When I run nnfolder-generate-active-file, I get the backtrace below.
> I am using Gnu emacs 20.7.2 and the latest version of Gnus from cvs.

Fixed.

ShengHuo

Re: nnfolder NOV (was: Wishlist for oGnus)

[Dan Christensen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> Dan Christensen <jdc@julian.uwo.ca> writes:
> 
> > When I run nnfolder-generate-active-file, I get the backtrace below.
> > I am using Gnu emacs 20.7.2 and the latest version of Gnus from cvs.
> 
> Fixed.

Works fine now.  Thanks so much!  I've wanted this for ages.

Dan