1 ;; Also know as the "wish list". Some are done. For the others, no
2 ;; promise when to be implemented.
4 * gnus-topic-kill-region
5 From Colin Marquardt <colin.marquardt@usa.alcatel.com>
7 I noticed that when re-arranging topics, C-k yanks a topic just fine
8 (runs gnus-topic-kill-group).
10 However, my habit is to do marking and the yanking the region, so I
11 would run C-w on the marked topic. But C-w runs
12 gnus-group-kill-region and doesn't yank the topic (for groups it
15 So could we have a gnus-topic-kill-region, or a
16 gnus-group-kill-region which handles topics as well?
18 * Speed up sorting in summary buffer if there is a limit.
20 Suggested by Daniel Ortmann <ortmann@isl.net>.
22 * Investigate the memory usage of Gnus.
24 But it does seem strange that Gnus would use some 15meg for this. I
25 think that is worth investigating. I suspect that bugs or bad
26 design are causing waste; they could be in Gnus, or in Emacs. -- RMS
30 The result of Google group search return a thread. Is it a digest
35 Implement NOV caching with Gnus Agent.
37 * Multiple charsets for topic names.
41 * Allow specification of server in Newsgroups header
45 WIBNI I could put `Newsgroups: nntp+quimby:bla' into a message and
46 Gnus would know to post this message on my server `nntp:quimby' into
47 the group bla? I think this would be way cool.
49 But Gnus would have to rewrite the Newsgroups header before actually
52 Thanks for Micha Wiedenmann for this suggestion.
54 * Understand mail-user-agent. Maybe gnus-mail-user-agent.
58 * Emphasis delimiters show when `W W c'.
62 * Parsing of the common list confirmation requests so that Gnus can
63 prepare the response with a single command. Including LISTSERV
64 periodic ping messages and the like.
66 * Parsing of the various List-* headers to enable automatic commands
67 like "send help message," "send unsubscribe message," and the like.
69 [done, see gnus-ml.el]
71 * Parsing of the subscription notice to stash away details like what
72 address you're subscribed to the list under (and automatically send
73 mail to the list using that address, when you send mail inside the list
74 group), what address to mail to unsubscribe, and the list info message
75 if available. Hitting the "get FAQ" command inside a mailing list
76 group should display that stashed copy of the info message.
78 * Some help in coming up with good split rules for mailing lists, as
79 automated as possible. Splitting on To and Cc is almost always not
80 what I want, since it can misfile messages and since if I'm cc'd on
81 list mail I want to get both copies, one in my personal mailbox and one
82 in the list mailbox. I know other people handle it other ways, but I
83 prefer it that way. Accordingly, some way to semi-automatically
84 generate split rules based on Sender, Mailing-List, Return-Path,
85 X-Loop, and all of the other random headers that often work would be
88 * Support for zipped folders for all backends this makes sense for.
89 Most likely using jka-compr. (It has been suggested that this do
90 work but I think it should be verified for all backends.)
92 * Support for RFC2015, PGP-MIME. Probably has to involve the people in
93 the Mailcrypt project.
97 * Agent (Can someone write some subtopics here? I don't use it myself
98 so I don't know what is lacking.)
100 * Support for encrypted folders. Even if the mail arrives unencrypted
101 Gnus should be able to encrypt the *folder* for added safety. This
102 should go for both Gnus' own folders and the folders Gnus reads from
103 (e.g. /var/spool/mail/${USER}). All backends this makes sense for.
105 [John Wiegley's article <200011030445.VAA08277@localhost.dynodns.net>,
106 posted on gnu.emacs.gnus does this.
107 Also, gnus-article-encrypt `K E' encrypts the article body.]
109 * The stuff on "Newest Features" in the manual should be implemented
110 and the node updated (it maybe is?).
112 * Splitting .newsrc.eld so the history is in one file and the
113 configuration is in another. To help those that reads at two
114 locations (e.g. work and home) and want to have the same
117 * gnus-uu-decode should complain if one or more parts of a series post
118 (ie, "part N of X") is missing, and optionally tick what parts are
119 there for decoding in a later session.
121 * Additional article marking, and an ability to affect marks placed
122 during e.g. mail acquisition. I want to be able to notice the
123 subject "fast money" or "web traffic", automatically mark it with a
124 `$', and score it into oblivion. (But I fear that wanting to change
125 marks with mail-source-* and nnmail-* functions will represent a
126 philosophical conflict with the rest of Gnus' management of article
127 marks. mail-source-* and nnmail-* currently hack around with files
128 under ~/Mail and leave traces in ~/Mail/active, but don't affect
129 things stored in .newsrc.eld.)
131 * A much better interface to nnmail-split-methods. I don't know how
132 I'd like this done, but I know that the current method of manually
133 hacking regexps is pretty untenable for new users. My boss, who is
134 tenured faculty at CMU and CEO & CTO at JPRC, and whose research
135 work has involved Lisp for the last 25 years, is trying to implant
136 himself in a Gnus mail environment, and this is a big sticking point
139 * PGP-supported encryption of entire nnml & nnmh groups. There are
140 people with whom I exchange mail routinely who don't send w/PGP, but
141 I'd really rather that the content not be left lying around
142 unencrypted. Hook into article acquisition the way jka-compr
143 supposedly does, to auto-decrypt every message read.
145 [See Support for encrypted folders.]
147 * Baby's First Mail In Gnus. Some set of functions that the
148 new-to-mail-in-Gnus user can invoke which will query the user
149 appropriately for the basic information required to establish mail
150 handling, leaving the appropriate traces in .gnus. Perhaps a
151 customize buffer would be appropriate.
152 - Where does your mail come from?
153 - If some server, what is your POP/IMAP protocol identity?
154 - What is your identity when sending mail, as opposed to posting to
156 - Here are some basic concepts of mail groups (list a few:
157 personal mail, company-wide mail, mailing lists, garbage dumps,
158 receptacles for outbound copies of what one sends; which ones do
159 you want to instantiate, and what mail should land in each?
160 [/viz./ problem of nnmail-split-methods interface.]
162 * Full integration of nnir into Gnus. Generic hooks for adding new
163 external nnir sources. I use a couple experimental, in-house tools
164 (JPRC is a research lab, occupied with document analysis and machine
165 learning) and adding new search engines to nnir by hacking the main
166 nnir.el module is rather clunky.
168 * Manual ordering of articles in an nnml folder.
170 That is, keystrokes to move articles (or whole threads) up or down
171 in the *Summary* buffer relative to the other articles. The order
172 would be persistent (e.g., across gnus sessions).
174 With this ability, an nnml folder would make for a good to-do list.
176 * Since many uses Gnus to store to do lists I think it is time for an
177 nntodo. (I know Kai already written one, maybe use that for a start?)
179 * nnsql backend, which would allow messages or folders to be imported
180 in a local (My|Postgre|?)SQL RDBMS.
182 * "posting profiles" ideally accessible from a popup menu; allowing
183 choice between predefined profiles of
184 from,name,organization,etc. Example: I'm at home, but need to reply
185 to a work mail; i can hit 'R', then use this command to switch to my
186 'work' profile for purposes of this one reply. (This might already
187 be possible with current Gnus, but I don't think so.)
189 * Better handling of the mail retrieving / splitting feature:
190 - the variables <backend>-get-new-mail should not exist anymore. Mail
191 retrieving should be a separate matter.
192 - we should be able to split mails to groups AND backends at the same time.
193 - meanwhile, we should still be able to associate certain mail sources with
196 * A better interface to the agent download scoring rules, like the one
197 for the other scoring rules.
199 * Editing of messages in the agents cache.
201 * More article marks (like '!' or '?').
202 Maybe user defined marks that can be displayed as any choosen charakter,
203 so one could do things like limiting on, to do whatever one likes with
206 * A possibility to add notes to messages. If thouse could include links
207 to other (stored) messages this would be very practical.
209 * A nnfolder like backend with .overview files.
210 This would not only speed up things, but also allow nnir to work on it.
214 * Allow article editing in groups which do not support it, but
215 emulating it via deleting the old article and entering the new one
216 into the group. This would be very useful to support `T ^' (say) in
219 * Allow user to specify which kinds of groups should be displayed.
220 For example, I want to display all the groups that are displayed
221 now, plus those which have cached messages in them. (Gnus does
222 display those with ticked messages but not those with
223 cached-but-unticked ones.) This would become even more important
224 when we allow labels.
226 * Go through the todo list and remove items already done.
228 * Create new data type `article identifier' and use that instead of
229 article numbers. A first implementation could offer something like
230 (num . 4711) but this could be extended. This would be useful for
231 using servers with *really* large numbers -- there we could have a
232 bignum type. It might also be useful for the nnweb and nnultimate
233 thingies where article identifiers are not really numbers.
235 * Allow use of digests to keep related articles. Normally, you use
236 groups to group together articles which are thematically related.
237 But sometimes, you have so many themes that this becomes
238 impractical. WIBNI I could have digests in a group, and there was a
239 way to add a new article to one of the digests in that group?
241 Or maybe what I really want is a way to tell Gnus that a specific
242 thread should always be hidden (as in `T h') by default, while most
243 other threads are not hidden by default. Hm.
245 * New backend between nnfolder and nnml: have more than one article
246 per file, but more than one file per group. With .overview files.
248 [done. nnfolder has .overview. Backward- and forward-compatible
249 between 1.0 and 2.0. (setq nnfolder-nov-is-evil t) disables the
252 * .overview files for nnfolder?
256 * New backend nnbabylfolder. There is also nnbabyl which is like
257 nnmbox but uses babyl format, but there is no babyl format
258 equivalent of nnfolder.
260 * Make movement commands in summary buffer independent of `move after
261 mark' behavior when marking articles. Currently, if you don't want
262 `E' to move to the next unread article, you have to set
263 gnus-summary-goto-unread to nil, and then there is no way to move to
264 the next or previous unread article.
266 This one has two sub-tasks. Providing the commands is one thing,
267 finding out useful key bindings for them is another. I think we
268 could provide the commands first while not changing the behavior of
269 the key bindings; then different people can experiment with
270 different key binding schemes until we find something which suits
273 * `Move to next/previous/first article' is a misnomer, since ticked
274 articles are also unread but not moved to by these commands. Should
275 the terminology be fixed or the documentation, or what?
277 * Allow sorting of threads by newest article rather than by root of
278 thread. Consider the following thread structure:
285 These two threads are sorted this way because root1 is older than
286 root2. I want an option to sort them the other way round because
287 leaf1 is newer than leaf2.
289 * Improve editing of MIME messages. I would like to use html-mode to
290 edit the body of a text/html message, and enriched-mode for
291 text/enriched messages, and so on. This should go for multipart
292 messages as well. This is probably a hard one since Emacs currently
293 does not allow several major modes per buffer. But maybe it would
294 be nice to hack Emacs to provide this infrastructure so that Gnus
295 can make use of it? This would also make it possible to provide
296 nifty commands for editing the headers, for example, rather than
297 relying on commands which do the same thing everywhere.
298 message-x.el is really just a half-assed attempt at doing it, and
299 while it is useful, that's not the way it should be done.
301 I think Francisco Potort
\e,Al
\e(B already did something like this?
303 * Provide commands for editing MML tags. For example, there could be
304 a command mml-add-tag-attribute which prompts me for an attribute
305 name (with completion, from the set filename, type, ...), and then