view admin/notes/commits @ 110410:f2e111723c3a

Merge changes made in Gnus trunk. Reimplement nnimap, and do tweaks to the rest of the code to support that. * gnus-int.el (gnus-finish-retrieve-group-infos) (gnus-retrieve-group-data-early): New functions. * gnus-range.el (gnus-range-nconcat): New function. * gnus-start.el (gnus-get-unread-articles): Support early retrieval of data. (gnus-read-active-for-groups): Support finishing the early retrieval of data. * gnus-sum.el (gnus-summary-move-article): Pass the move-to group name if the move is internal, so that nnimap can do fast internal moves. * gnus.el (gnus-article-special-mark-lists): Add uid/active tuples, for nnimap usage. * nnimap.el: Rewritten. * nnmail.el (nnmail-inhibit-default-split-group): New internal variable to allow the mail splitting to not return a default group. This is useful for nnimap, which will leave unmatched mail in the inbox. * utf7.el (utf7-encode): Autoload. Implement shell connection. * nnimap.el (nnimap-open-shell-stream): New function. (nnimap-open-connection): Use it. Get the number of lines by using BODYSTRUCTURE. (nnimap-transform-headers): Get the number of lines in each message. (nnimap-retrieve-headers): Query for BODYSTRUCTURE so that we get the number of lines. Not all servers return UIDNEXT. Work past this problem. Remove junk from end of file. Fix typo in "bogus" section. Make capabilties be case-insensitive. Require cl when compiling. Don't bug out if the LIST command doesn't have any parameters. 2010-09-17 Knut Anders Hatlen <[e-mail]> (tiny change) * nnimap.el (nnimap-get-groups): Don't bug out if the LIST command doesn't have any parameters. (mm-text-html-renderer): Document gnus-article-html. 2010-09-17 Julien Danjou <[e-mail]> (tiny fix) * mm-decode.el (mm-text-html-renderer): Document gnus-article-html. * dgnushack.el: Define netrc-credentials. If the user doesn't have a /etc/services, supply some sensible port defaults. Have `unseen-or-unread' select an unread unseen article first. (nntp-open-server): Return whether the open was successful or not. Throughout all files, replace (save-excursion (set-buffer ...)) with (with-current-buffer ... ). Save result so that it doesn't say "failed" all the time. Add ~/.authinfo to the default, since that's probably most useful for users. Don't use the "finish" method when we're reading from the agent. Add some more nnimap-relevant agent stuff to nnagent.el. * nnimap.el (nnimap-with-process-buffer): Removed. Revert one line that was changed by mistake in the last checkin. (nnimap-open-connection): Don't error out when we can't make a connection nnimap-related changes to avoid bugging out if we can't contact a server. * gnus-start.el (gnus-get-unread-articles): Don't try to scan groups from methods that are denied. * nnimap.el (nnimap-possibly-change-group): Return nil if we can't log in. (nnimap-finish-retrieve-group-infos): Make sure we're not waiting for nothing. * gnus-sum.el (gnus-select-newsgroup): Indent.

HOW TO COMMIT CHANGES TO EMACS

Most of these points are from:

http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00555.html
From: 	 Miles Bader
Subject: commit style redux
Date: 	 Tue, 31 Mar 2009 12:21:20 +0900

(0) Each commit should correspond to a single change (whether spread
    over multiple files or not).  Do not mix different changes in the
    same commit (eg adding a feature in one file, fixing a bug in
    another should be two commits, not one).

(1) Commit all changed files at once with a single log message (which
    in CVS will result in an identical log message for all committed
    files), not one-by-one.  This is pretty easy using vc-dir now.

(2) Make the log message describe the entire changeset, perhaps
    including relevant changelog entiries (I often don't bother with
    the latter if it's a trivial sort of change).

    Many modern source-control systems vaguely distinguish the first
    line of the log message to use as a short summary for abbreviated
    history listing (in arch this was explicitly called the summary,
    but many other systems have a similar concept).  So it's nice if
    you can format the log entry like:

        SHORTISH ONE-LINE SUMMARY

        MULTIPLE-LINE DETAILED DESCRIPTION POSSIBLY INCLUDING (OR
        CONSISTING OF) CHANGELOG ENTRIES

    [Even with CVS this style is useful, because web CVS browsing
    interfaces often include the first N words of the log message of
    the most recent commit as a short "most recent change"
    description.]

(3) Don't phrase log messages assuming the filename is known, because
    in non-file-oriented systems (everything modern other than CVS),
    the log listing tends to be treated as global information, and the
    connection with specific files is less explicit.

    For instance, currently I often see log messages like "Regenerate";
    for modern source-control systems with a global log, it's better to
    have something like "Regenerate configure".


Followup discussion:
http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00401.html


PREVIOUS GUIDELINES FOR CVS

For historical interest only, here is the old-style advice for CVS logs:
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html

From: Eli Zaretskii
Subject: Re: Log messages in CVS
Date: Sat, 29 Dec 2007 16:06:29 +0200