Mercurial > emacs
view admin/notes/years @ 63781:99d460dc50ca
Require 'tree-widget instead of 'wid-edit.
(recentf-filename-handler): Fix widget :type.
(recentf-cancel-dialog, recentf-open-more-files)
(recentf-open-files-action): Doc fix.
(recentf-dialog-goto-first): New function.
(recentf-dialog-mode-map): Set parent keymap first.
(recentf-dialog-mode): Define with define-derived-mode. Don't
display continuation lines in dialogs.
(recentf-edit-list): Rename from recentf-edit-selected-items.
(recentf-edit-list-select): Rename from recentf-edit-list-action.
Simplify.
(recentf-edit-list-validate): New function.
(recentf-edit-list): Update accordingly.
(recentf-open-files-item-shift): Remove.
(recentf-open-files-item): Convert menu elements into tree and
link widgets. Don't create the widgets.
(recentf-open-files): Update accordingly.
(recentf-save-list): Untabify.
author | David Ponce <david@dponce.com> |
---|---|
date | Sun, 26 Jun 2005 07:42:38 +0000 |
parents | 344e02ca2730 |
children | 32b32ccdedc0 |
line wrap: on
line source
THIS DOCUMENT IS UNDER REVIEW. DO NOT FOLLOW THESE INSTRUCTIONS -- THEY ARE NOT CORRECT. How to Maintain Copyright Years for GNU Emacs Principle: Individual files need to have the year of the release in the copyright notice if there is significant change. Practice: - individual files - each must be examined, along w/ its history, by a human - automated tools facilitate but can never replace this process - year of the release - may be different from year of file introduction, or year of last significant change - sometimes the release year slips, leaving a file w/ prematurely marked release year => need update (e.g., s/2004/2005/ for Emacs 22) - intervening years (between releases) are not valid and may cause embarrassment later in case of dispute => remove (however, see next) - years for new files (merged, contributed) that have been separately published are valid even if between releases => leave alone - significant change - insignificant - whitespace - copyright notice - version control tags - simple var/func renaming - in-file reorganization/reordering - typos - small bugfixes - small docfixes - filename renaming - most everything else is significant - change to interface - change in functionality - new file - many small changes may be significant in aggregate - when in doubt, ask (and update these guidelines -- thanks!) - sometimes people make mistakes - if they have not read these guidelines, point them here - if the guidelines are not helpful, improve the guidelines