1 ;; Also know as the "wish list". Some are done. For the others, no
2 ;; promise when to be implemented.
4 * Use a new custom type (`define-widget') for posting-style in `gnus-cus.el'
5 (G c) and for `gnus-posting-styles'. Maybe some allowed types are still
8 * Add proper doc strings to functions and variables explained in the manual
9 (info "(gnus)Gnus Utility Functions")
11 * Add Message-IDs or URLs refering to relevant discussions on lists and
14 * Use nicer tool bar icons from GNOME
16 Done for Emacs (The GNOME icons won't fit into standard XEmacs icons,
17 IMHO. -- rsteib) in group, summary and message mode.
19 Some modes might also deserve improved tool bars:
25 . zap most buttons; except print, customize (?) and help
27 . "exit" should just kill the buffer
29 - gnus-server-mode: Add some commands from the Connections and Server
32 - gnus-browse-mode (could borrow some icons from gnus-group-mode)
34 (See http://article.gmane.org/gmane.emacs.gnus.general/62147).
36 * Maybe Gnus should support the LIST SUBSCRIPTIONS, see RFC 2980.
38 * Merge `message-extra-wide-headers' and ` message-header-synonyms'?
40 * Maybe texi/emacs-mime.texi could be divided into user-visible stuff and
41 reference manual for the MIME library.
43 Related: Bill Wohler's article on mh-e-user.
44 http://thread.gmane.org/29067.1138078896@olgas.newt.com
46 * Fix `change servers' command, see David Kastrup's message.
47 http://thread.gmane.org/x54qewqxz4.fsf@lola.goethe.zz
49 * texi/gnus-coding.texi should be fixed.
51 * gnus-topic-kill-region
52 From Colin Marquardt <colin.marquardt@usa.alcatel.com>
54 I noticed that when re-arranging topics, C-k yanks a topic just fine
55 (runs gnus-topic-kill-group).
57 However, my habit is to do marking and the yanking the region, so I
58 would run C-w on the marked topic. But C-w runs
59 gnus-group-kill-region and doesn't yank the topic (for groups it
62 So could we have a gnus-topic-kill-region, or a
63 gnus-group-kill-region which handles topics as well?
65 * Speed up sorting in summary buffer if there is a limit.
67 Suggested by Daniel Ortmann <ortmann@isl.net>.
69 * Investigate the memory usage of Gnus.
71 But it does seem strange that Gnus would use some 15meg for this. I
72 think that is worth investigating. I suspect that bugs or bad
73 design are causing waste; they could be in Gnus, or in Emacs. -- RMS
77 The result of Google group search return a thread. Is it a digest
82 Implement NOV caching with Gnus Agent.
84 * Allow specification of server in Newsgroups header
88 WIBNI I could put `Newsgroups: nntp+quimby:bla' into a message and
89 Gnus would know to post this message on my server `nntp:quimby' into
90 the group bla? I think this would be way cool.
92 But Gnus would have to rewrite the Newsgroups header before actually
95 Thanks for Micha Wiedenmann for this suggestion.
97 * Parsing of the subscription notice to stash away details like what
98 address you're subscribed to the list under (and automatically send
99 mail to the list using that address, when you send mail inside the list
100 group), what address to mail to unsubscribe, and the list info message
101 if available. Hitting the "get FAQ" command inside a mailing list
102 group should display that stashed copy of the info message.
104 * Some help in coming up with good split rules for mailing lists, as
105 automated as possible. Splitting on To and Cc is almost always not
106 what I want, since it can misfile messages and since if I'm cc'd on
107 list mail I want to get both copies, one in my personal mailbox and one
108 in the list mailbox. I know other people handle it other ways, but I
109 prefer it that way. Accordingly, some way to semi-automatically
110 generate split rules based on Sender, Mailing-List, Return-Path,
111 X-Loop, and all of the other random headers that often work would be
116 * A better interface to the agent download scoring rules, like the one
117 for the other scoring rules.
119 * Editing of messages in the agents cache.
121 * Support for encrypted folders. Even if the mail arrives unencrypted
122 Gnus should be able to encrypt the *folder* for added safety. This
123 should go for both Gnus' own folders and the folders Gnus reads from
124 (e.g. /var/spool/mail/${USER}). All backends this makes sense for.
126 [John Wiegley's article <200011030445.VAA08277@localhost.dynodns.net>,
127 posted on gnu.emacs.gnus does this.
128 Also, gnus-article-encrypt `K E' encrypts the article body.]
130 * Splitting .newsrc.eld so the history is in one file and the
131 configuration is in another. To help those that reads at two
132 locations (e.g. work and home) and want to have the same
135 * Additional article marking, and an ability to affect marks placed
136 during e.g. mail acquisition. I want to be able to notice the
137 subject "fast money" or "web traffic", automatically mark it with a
138 `$', and score it into oblivion. (But I fear that wanting to change
139 marks with mail-source-* and nnmail-* functions will represent a
140 philosophical conflict with the rest of Gnus' management of article
141 marks. mail-source-* and nnmail-* currently hack around with files
142 under ~/Mail and leave traces in ~/Mail/active, but don't affect
143 things stored in .newsrc.eld.)
145 * A much better interface to nnmail-split-methods. I don't know how
146 I'd like this done, but I know that the current method of manually
147 hacking regexps is pretty untenable for new users. My boss, who is
148 tenured faculty at CMU and CEO & CTO at JPRC, and whose research
149 work has involved Lisp for the last 25 years, is trying to implant
150 himself in a Gnus mail environment, and this is a big sticking point
153 * PGP-supported encryption of entire nnml & nnmh groups. There are
154 people with whom I exchange mail routinely who don't send w/PGP, but
155 I'd really rather that the content not be left lying around
156 unencrypted. Hook into article acquisition the way jka-compr
157 supposedly does, to auto-decrypt every message read.
159 [See Support for encrypted folders.]
161 * Baby's First Mail In Gnus. Some set of functions that the
162 new-to-mail-in-Gnus user can invoke which will query the user
163 appropriately for the basic information required to establish mail
164 handling, leaving the appropriate traces in .gnus. Perhaps a
165 customize buffer would be appropriate.
166 - Where does your mail come from?
167 - If some server, what is your POP/IMAP protocol identity?
168 - What is your identity when sending mail, as opposed to posting to
170 - Here are some basic concepts of mail groups (list a few:
171 personal mail, company-wide mail, mailing lists, garbage dumps,
172 receptacles for outbound copies of what one sends; which ones do
173 you want to instantiate, and what mail should land in each?
174 [/viz./ problem of nnmail-split-methods interface.]
176 [Probably `assistant.el' will provide this. But it's development is
179 * Manual ordering of articles in an nnml folder.
181 That is, keystrokes to move articles (or whole threads) up or down
182 in the *Summary* buffer relative to the other articles. The order
183 would be persistent (e.g., across gnus sessions).
185 With this ability, an nnml folder would make for a good to-do list.
187 * Since many uses Gnus to store to do lists I think it is time for an
188 nntodo. (I know Kai already written one, maybe use that for a start?)
190 * nnsql backend, which would allow messages or folders to be imported
191 in a local (My|Postgre|?)SQL RDBMS.
193 * "posting profiles" ideally accessible from a popup menu; allowing
194 choice between predefined profiles of
195 from,name,organization,etc. Example: I'm at home, but need to reply
196 to a work mail; i can hit 'R', then use this command to switch to my
197 'work' profile for purposes of this one reply. (This might already
198 be possible with current Gnus, but I don't think so.)
200 * Better handling of the mail retrieving / splitting feature:
201 - the variables <backend>-get-new-mail should not exist anymore. Mail
202 retrieving should be a separate matter.
203 - we should be able to split mails to groups AND backends at the same time.
204 - meanwhile, we should still be able to associate certain mail sources with
207 * More article marks (like '!' or '?').
208 Maybe user defined marks that can be displayed as any choosen charakter,
209 so one could do things like limiting on, to do whatever one likes with
212 * Allow article editing in groups which do not support it, but
213 emulating it via deleting the old article and entering the new one
214 into the group. This would be very useful to support `T ^' (say) in
217 * Allow user to specify which kinds of groups should be displayed.
218 For example, I want to display all the groups that are displayed
219 now, plus those which have cached messages in them. (Gnus does
220 display those with ticked messages but not those with
221 cached-but-unticked ones.) This would become even more important
222 when we allow labels.
224 * Create new data type `article identifier' and use that instead of
225 article numbers. A first implementation could offer something like
226 (num . 4711) but this could be extended. This would be useful for
227 using servers with *really* large numbers -- there we could have a
228 bignum type. It might also be useful for the nnweb and nnultimate
229 thingies where article identifiers are not really numbers.
231 * Allow use of digests to keep related articles. Normally, you use
232 groups to group together articles which are thematically related.
233 But sometimes, you have so many themes that this becomes
234 impractical. WIBNI I could have digests in a group, and there was a
235 way to add a new article to one of the digests in that group?
237 Or maybe what I really want is a way to tell Gnus that a specific
238 thread should always be hidden (as in `T h') by default, while most
239 other threads are not hidden by default. Hm.
241 * New backend nnbabylfolder. There is also nnbabyl which is like
242 nnmbox but uses babyl format, but there is no babyl format
243 equivalent of nnfolder.
245 * Make movement commands in summary buffer independent of `move after
246 mark' behavior when marking articles. Currently, if you don't want
247 `E' to move to the next unread article, you have to set
248 gnus-summary-goto-unread to nil, and then there is no way to move to
249 the next or previous unread article.
251 This one has two sub-tasks. Providing the commands is one thing,
252 finding out useful key bindings for them is another. I think we
253 could provide the commands first while not changing the behavior of
254 the key bindings; then different people can experiment with
255 different key binding schemes until we find something which suits
258 * `Move to next/previous/first article' is a misnomer, since ticked
259 articles are also unread but not moved to by these commands. Should
260 the terminology be fixed or the documentation, or what?
262 * Allow sorting of threads by newest article rather than by root of
263 thread. Consider the following thread structure:
270 These two threads are sorted this way because root1 is older than
271 root2. I want an option to sort them the other way round because
272 leaf1 is newer than leaf2.
274 * Improve editing of MIME messages. I would like to use html-mode to
275 edit the body of a text/html message, and enriched-mode for
276 text/enriched messages, and so on. This should go for multipart
277 messages as well. This is probably a hard one since Emacs currently
278 does not allow several major modes per buffer. But maybe it would
279 be nice to hack Emacs to provide this infrastructure so that Gnus
280 can make use of it? This would also make it possible to provide
281 nifty commands for editing the headers, for example, rather than
282 relying on commands which do the same thing everywhere.
283 message-x.el is really just a half-assed attempt at doing it, and
284 while it is useful, that's not the way it should be done.
286 I think Francisco Potort
\e,Al
\e(B already did something like this?
288 * Provide commands for editing MML tags. For example, there could be
289 a command mml-add-tag-attribute which prompts me for an attribute
290 name (with completion, from the set filename, type, ...), and then
291 for a value. (This is like `C-c +' in psgml.) Or there could be a
292 command which showed me all the attributes in an MML tag and allows
293 me to use TAB to move between them, and then to edit each attribute
294 value. (This is like `C-c C-a' in psgml.)
296 * Have Gnus automagically set group parameters for mailing list
297 groups. For example, if I have a splitting rule that automatically
298 sorts ding@gnus.org into mail.ding, then Gnus should clue in, set
299 the to-list parameter to 'ding@gnus.org', and set total-expire.
300 (This is probably Hard (TM). And of course the user should be able
301 to configure what parameters exactly get set.)
303 * Along the same lines, automagically detect broken reply-to's. (But
304 don't auto-detect users legitimately setting a reply-to header that