June 2007 - XEmacs-Patches - XEmacs Mailing List Archives

[AC general-docs] draft XEmacs Developer's Guide 7 years, 3 months

Stephen J. Turnbull

APPROVE COMMIT general-docs With this patch the XEmacs Developer's Guide is a fairly self-contained and internally consistent guide to best current practices of the XEmacs Project. I hope it will turn into a policy document, but that would require the Review Board to show some interest in policy.... It remains rather incomplete; contributions welcome. Once again many thanks to Bill Wohler whose MH-E Developer's Guide formed the framework for this document, and for his permission to publish it under the GPL. Also to the XEmacs reviewers and developers who have built the procedures and discussed the policies over the years. Index: ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/ChangeLog,v retrieving revision 1.16 diff -u -r1.16 ChangeLog --- ChangeLog 2005/05/07 12:23:53 1.16 +++ ChangeLog 2007/05/12 08:32:10 ＠＠ -0,0 +1,51 ＠＠ +2007-05-13 Stephen J. Turnbull <stephen(a)xemacs.org> + + Publish xemacs-devguide. + + * Makefile (EXPLICIT_DOCS): Add xemacs-devguide.texi. + +2007-05-13 Stephen J. Turnbull <stephen(a)xemacs.org> + + * texi/xemacs/xemacs-devguide.texi: + (Philosophy): Rewrite to look like XEmacs current practice. + +2007-02-17 Stephen J. Turnbull <stephen(a)xemacs.org> + + Fix up xemacs-devguide. + + * texi/xemacs/xemacs-devguide.texi: + Remove all the silly Edited: and Written: tags. + Implicit self-approval: This is decided, we just need to fix + the commit trigger. + Guide variables: Update dates and add DEVGUIDE. Use it. + xemacs-design: Update references to note it's inactive. + Copyrights: Update mine, improve formatting slightly. + Fix typos. + + (Nodes borrowed from other projects not adapted to XEmacs): + New appendix. Update menus. + (Philosophy): Revise desiderata. Deprecate GFDL. + (Committer): Clarify usage. + (Committer Welcome Message): Update package tree size estimate. + (Release Engineer): Clarify "ex oficio". + (The Work Flow): Clarify absence of binary packages. + (About Copyright Assignment): Clarify FSF policy on XEmacs. + (ChangeLogs): Clarify syntax of log entries. + (Copying): Moved whole node. + + (The Package Maintainer Role): + (Getting Started as a Package Maintainer): + (Advice to Package Maintainers): + New subnodes of XEmacs Package Maintainer. + + (Support Requests): + (Bugs): + (Feature Requests): + (Patch Queue): + (File Releases): + (News): + (Surveys): + (Free Software Directories): + Move these nodes and subnodes into new Appendix, update pointers. + A few desultory fixups. + Index: Makefile =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/Makefile,v retrieving revision 1.13 diff -u -r1.13 Makefile --- Makefile 2005/05/07 12:23:54 1.13 +++ Makefile 2007/05/12 08:32:10 ＠＠ -27,6 +27,7 ＠＠ # We'll need something like this. #EXPLICIT_DOCS = texi/*.texi texi/xemacs/*.texi texi/packages/*.texi -EXPLICIT_DOCS = texi/xemacs/fontconfig.texi +EXPLICIT_DOCS = texi/xemacs/fontconfig.texi \ + texi/xemacs/xemacs-devguide.texi include ../../XEmacs.rules Index: texi/xemacs/xemacs-devguide.texi =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/general-docs/texi/xemacs/xemacs-devguide.texi,v retrieving revision 1.1 diff -u -r1.1 xemacs-devguide.texi --- texi/xemacs/xemacs-devguide.texi 2005/02/01 16:08:35 1.1 +++ texi/xemacs/xemacs-devguide.texi 2007/05/12 08:32:12 ＠＠ -3,16 +3,16 ＠＠＠c Generate HTML with: ＠c (shell-command "texi2html -number -monolithic xemacs-devguide.texi" nil) ＠c -＠c Preamble edited: stephen 2005-01-20 ＠c %**start of header ＠setfilename ../../info/xemacs-devguide.info ＠settitle xemacs-devguide ＠c %**end of header -＠c Version variables. -＠set EDITION 0.5 -＠set UPDATED 2005-01-20 -＠set UPDATE-MONTH January, 2005 +＠c Developer's Guide variables. +＠set DEVGUIDE ＠cite{XEmacs Developer's Guide} +＠set EDITION 0.6 +＠set UPDATED 2007-02-17 +＠set UPDATE-MONTH February, 2007 ＠c Other variables. ＠set XEMACSORG XEmacs.ORG ＠＠ -22,6 +22,7 ＠＠＠set C-E-X the ＠i{comp.emacs.xemacs} Usenet newsgroup ＠set ANNOUNCE-LIST the ＠email{xemacs-announce＠(a)xemacs.org,XEmacs Announcements} mailing list ＠set BETA-LIST the ＠email{xemacs-beta＠(a)xemacs.org,XEmacs Beta} mailing list +＠c xemacs-design is currently not operative; substitute xemacs-beta ＠set DESIGN-LIST the ＠email{xemacs-design＠(a)xemacs.org,XEmacs Design} mailing list ＠set REVIEW-LIST the ＠email{xemacs-review＠(a)xemacs.org,XEmacs Review} mailing list ＠set PATCHES-LIST the ＠email{xemacs-patches＠(a)xemacs.org,XEmacs Patches} mailing list ＠＠ -29,19 +30,20 ＠＠＠set BUILDREPORTS-LIST the ＠email{xemacs-buildreports＠(a)xemacs.org,XEmacs Build Reports} mailing list ＠copying -This is Edition ＠value{EDITION} of the ＠cite{XEmacs Developers Guide}, +This is Edition ＠value{EDITION} of the ＠value{DEVGUIDE}, last updated ＠value{UPDATED}. -Copyright ＠copyright{} 2000, 01, 02, 03, 2004 Bill Wohler -Copyright ＠copyright{} 2005 Free Software Foundation +Copyright ＠copyright{} 2000, 2001, 2002, 2003, 2004 Bill Wohler +Copyright ＠copyright{} 2005, 2007 Free Software Foundation + ＠quotation -The ＠cite{XEmacs Developers Guide} is free documentation; you can +The ＠value{DEVGUIDE} is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. -The ＠cite{XEmacs Developers Guide} is distributed in the hope that it +The ＠value{DEVGUIDE} is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. ＠＠ -57,11 +59,11 ＠＠＠dircategory XEmacs Editor ＠direntry -* XEmacs Developers Guide: (xemacs-devguide). UNOFFICIAL EARLY DRAFT. +* XEmacs Developer's Guide: (xemacs-devguide). DRAFT. ＠end direntry ＠titlepage -＠title The XEmacs Developers Guide +＠title The XEmacs Developer's Guide ＠subtitle Edition ＠value{EDITION} ＠subtitle ＠value{UPDATE-MONTH} ＠author Stephen J. Turnbull ＠＠ -97,18 +99,7 ＠＠ * The Work Roles:: * The Work Flow:: * XEmacs Resources on the Internet:: - -Nodes borrowed from other projects, not adapted to XEmacs: - -* Support Requests:: -* Bugs:: -* Feature Requests:: -* Patch Queue:: -* File Releases:: -* News:: -* Surveys:: -* Free Software Directories:: -* Copying:: +* Nodes borrowed from other projects not adapted to XEmacs:: * Index:: ＠detailmenu ＠＠ -129,6 +120,11 ＠＠ * Commit Access:: * Committer Welcome Message:: +XEmacs Package Maintainer + +* The Package Maintainer Role:: +* Advice to Package Maintainers:: + XEmacs Reviewer * Appointing New Reviewers:: ＠＠ -155,7 +151,7 ＠＠ Submit the Patch -* Proposed Optional Alternate Procedure for Reviewers:: +* Optional Alternate Procedure for Reviewers:: Patch Review ＠＠ -178,6 +174,16 ＠＠ Nodes borrowed from other projects, not adapted to XEmacs +* Support Requests:: +* Bugs:: +* Feature Requests:: +* Patch Queue:: +* File Releases:: +* News:: +* Surveys:: +* Free Software Directories:: +* Copying:: + Bugs * Category:: ＠＠ -211,8 +217,6 ＠＠＠node Acknowledgments, Introduction, Top, Top ＠chapter Acknowledgments -＠c Edited: stephen 2005-01-18 - Special thanks go to Bill Wohler, whose ＠emph{MH-E Developers Guide} formed the framework for this document, and contributed a lot of text as well, for permission to redistribute the derived work under the GNU ＠＠ -227,8 +231,6 ＠＠＠node Introduction, Philosophy, Acknowledgments, Top ＠chapter Introduction -＠c Edited: stephen 2005-01-18 - ＠cindex Introduction ＠cindex ＠value{XEMACSORG} ＠＠ -250,7 +252,7 ＠＠＠cindex xemacs-design And remember, this is your document. If you think something is bogus, -start a movement on ＠value{DESIGN-LIST}. One of the tenets of the +start a movement on ＠value{BETA-LIST}. One of the tenets of the philosophy is rough consensus. If you can get a rough consensus to agree with your point of view, then the document shall be changed accordingly. ＠＠ -265,19 +267,7 ＠＠ Feel free to submit patches to ＠value{PATCHES-LIST}. Please try to review and edit a whole node at a time. They're short; it's not that -great a burden. XEmacs Reviewers: If you review and approve of a node -as is, please add a comment just below the ＠samp{＠＠node} and sectioning -commands in the node like - -＠example -＠＠c Reviewed: ＠var{name} ＠var{date} -＠end example - -Otherwise, edit the node and add a comment - -＠example -＠＠c Edited: ＠var{name} ＠var{date} -＠end example +great a burden. ＠end cartouche ＠＠ -286,14 +276,12 ＠＠＠node Philosophy, The Work Roles, Introduction, Top ＠chapter Philosophy -＠c Edited: stephen 2005-01-18 - ＠cindex Philosophy -＠strong{Currently pretty much everything in this node is hardly -representative of the ＠value{PROJECT}. Sometimes stephen thinks much of -this would be a good statement of values, other times he doesn't. What -do you think? Submit a patch!} +＠strong{This node is hardly +changed from the ＠emph{MH-E Developers Guide}, and is not +representative of the ＠value{PROJECT}. However, everything here has +been espoused by XEmacs developers at one time or another.} This chapter discusses the philosophy and principles of the XEmacs project. The first section covers our coding philosophy, while the ＠＠ -306,51 +294,52 ＠＠ follows: ＠enumerate - ＠item -Keep the code small and fast +Keep the C code fast. ＠item -Refrain from adding lots of code to the codebase that would be better -served with hooks. +Refrain from adding lots of code to the C codebase that would be better +served with Lisp. ＠item -In order to provide maximum compatibility with other MH interfaces and -MH itself, XEmacs should use MH itself as much as possible. XEmacs is, -after all, a interface to MH and therefore should not implement MH. +XEmacs is a cross-platform application. Features should work on all +platforms. ＠item XEmacs should be easy to use out-of-the-box for new users. - ＠end enumerate -That last priority struggles mightily with the other priorities. For -example, the user ＠i{could} write his own hooks for many features. -However, the average user is not going to do so. Indeed, the -customization buffer may be too intimidating and providing radio -buttons and checkboxes in the menu may be the way to go in some cases. - ＠cindex customize +We should get as much mileage out of ＠code{customize} as we can to +reduce the amount of code that users have to write. + +XEmacs at any time has a ＠emph{stable} branch and uses the ＠emph{trunk} +for development. We do not freeze the trunk, except for the short +period of time needed to create a consistent release branch. The +release branch in principle should only be changed for bug fixes. (In +the past this principle has been honored as much in the breach as in the +observance; nevertheless, it's a good starting point.) + +A change in the major version number indicates a pervasive change +affecting all users. For example, the introduction of Mule in version +20, the extensive user of the package system in 21, and Unicode support +in 22. A change in the minor version number reflects addition of +features, and accompanies an initial public release. A change in the +patchlevel reflects bugfix releases of the stable branch, while on the +trunk patchlevels are fairly arbitrary, reflecting regular beta +releases. + +The stable branch has a single gatekeeper, the listed maintainer. +Changes are made only by the maintainer, or at his convenience with +explicit authorization. Any XEmacs reviewer may make or authorize +changes to the trunk. Having commit privileges does ＠emph{not} +authorize changes; commit privileges are for the convenience of the +project and of regular contributors, but do not imply a direct say in +decisions. Conversely, we are always looking for new reviewers; the +review board is self-maintaining, but not closed. -In a less contentious way, making XEmacs easier to use may mean better -integration with other software packages (such as ＠code{tm} or -＠code{goto-addr}). Or pre-written hook functions could be provided. We -should get as much mileage out of ＠code{customize} as we can to reduce -the amount of code that users have to write. - -One other subject related to philosophy is to what constitutes a major -release. Major releases signal to the user that the new version may -not work as it did before and that reading of the release notes is -mandatory. Major releases occur when incompatible changes are made -that are visible to the user. Types of changes include changing the -name of or deleting functions, key bindings, and customization -variables. The converse is true; these sorts of changes should not be -applied to minor releases. - -By itself, merely adding a new feature does not just justify a major -release. On the other hand, a major release is called for if the code -is completely rewritten, even if the user cannot notice any -difference. +Individual packages, like the stable branch, may have a listed +maintainer. In those cases, the listed maintainer is the gatekeeper. ＠heading Guiding Principles ＠＠ -358,9 +347,8 ＠＠＠enumerate 1 ＠item -While we all are scratching an itch on this project, we also have very -few users and a great desire to have more. Our users are sacrosanct; -we will go the extra distance to please our users. +We all are scratching an itch on this project. We respect each others' +goals, which are quite varies. ＠item Using vulgar language towards our users and/or developers is ＠＠ -370,10 +358,8 ＠＠ The team makes decisions by consensus through articulated arguments. If one wants to express an opinion, they do it by presenting evidence to support their claim in a respectful way, and not by insulting -others' points of view. While it takes some time and effort to -articulate the reasons behind one's point of view, we enjoy the -process and often gain a better understanding of the issues by the -end. +others' points of view. Where consensus seems hard to achieve, what we +try first may be decided by a vote in the Review Board. ＠item We are all committed to a high-quality product. We have no artificial ＠＠ -417,9 +403,16 ＠＠＠end ifhtml ＠strong{Please ensure that the copyright notice of every file accurately -reflects your contribution, whether you have assigned your copyright or -not. This will aid future project admins greatly if there ever is a -merger.} +reflects your contribution, whether you have assigned your copyright to +the FSF or not. This will aid future project admins greatly if there +ever is a merger of XEmacs with Emacs.} ``Accurately reflects'' means +that if you have not assigned your contribution, ＠emph{your name} should +appear in a copyright notice, along with an accurate list of the years +in which your contributions were made. If you have assigned your +contribution, you should list the FSF (or other assignee) as copyright +holder, and make sure that the list of years is appropriately updated. +In both cases, an accurate ChangeLog detailing your changes (file and +function) should accompany the patch. You ＠strong{must} reference the GPL correctly in every file. ＠＠ -427,17 +420,24 ＠＠ they have various different licenses. ＠emph{Be careful}: it is typically ＠strong{not} permissible to mix excerpts from different documents with each other, or with XEmacs code, unless they have -＠emph{identical} licenses. +＠emph{identical} licenses. In particular, the XEmacs Texinfo manuals +(the ＠emph{XEmacs User's Guide}, the ＠emph{XEmacs Lisp Reference}, and +the ＠emph{XEmacs Internals Manual}) have a unique license which is not +the GPL or the GFDL, and is incompatible with both. All code and data files must be licensed under the GPL (or a compatible license) so that they can be added to XEmacs, and others may modify them. Documentation files must be licensed under an approved free license or an OSI-approved open source license. Where possible, GPL-compatible -licenses are preferred. +licenses are preferred. If at all possible, avoid the GNU Free +Documentation License, because it ＠emph{is incompatible with the GPL}, +implying that text cannot be copied freely between docstrings and the +Texinfo manual, except by the copyright holder. The ＠uref{http://www.gnu.org/prep/standards.html, GNU -Coding Conventions} is required reading. +Coding Conventions} is required reading. Note that XEmacs has its own +slightly different, version. ＠xref{Top, Coding Standards, ,standards}. Before checking in files, load ＠file{lisp-mnt} into Emacs, and run ＠code{lm-verify} within the lisp file you are editing to ensure that ＠＠ -463,8 +463,6 ＠＠＠node The Work Roles, The Work Flow, Philosophy, Top ＠chapter The Work Roles -＠c Created: stephen 2005-01-20 - On the one hand, ``open source'' means that you are free to take the existing program, make it into whatever you want, and nobody will stop you. On the other hand, ``open source'' means that you are free to ＠＠ -475,7 +473,7 ＠＠ Allowing people to fill roles that suit them, and creating a work flow that lets them share the products of their work without getting in each -other's ways, are the foundations of the project. +others' way, are the foundations of the project. ＠heading People and the Project ＠＠ -533,24 +531,25 ＠＠＠item Reviewer A developer who may authorize developers, including himself, to write to the XEmacs CVS repository. ＠xref{XEmacs Reviewer}. Should participate -in ＠value{BETA-LIST} ＠ref{xemacs-beta}, ＠value{DESIGN-LIST} -＠ref{xemacs-design}, and ＠value{PATCHES-LIST} ＠ref{xemacs-patches}. +in ＠value{BETA-LIST} ＠ref{xemacs-beta}, ＠value{PATCHES-LIST} +＠ref{xemacs-patches}, and ＠value{REVIEW-LIST} +＠ref{xemacs-review}. ＠item XEmacs Review Board The reviewers as a group, responsible for delegating access to ＠value{PROJECT} resources to developers. A self-selecting cabal. The current members are noted on the -＠uref{http://www.xemacs.org/Develop/jobs.html,＠emph{Job List}}. +＠uref{http://www.xemacs.org/Develop/jobs.html,＠emph{Jobs List}}. ＠xref{Jobs List}. ＠item Chairman of the Board -＠item CEO -＠item Maintainer -＠item Benevolent Dictator for Life +＠itemx CEO +＠itemx Maintainer +＠itemx Benevolent Dictator for Life Call it what you like, we don't have one any more, by deliberate choice. ＠item Meta-maintainer -＠item Mr. XEmacs +＠itemx Mr. XEmacs The reviewer responsible for trying to keep track of what isn't getting done, and finding someone to do it. The latter title allows him to tell his mother how important he is. More seriously, the meta-maintainer ＠＠ -559,8 +558,8 ＠＠＠value{BETA-LIST} ＠ref{xemacs-beta}. ＠item Release engineer -＠item Stable release engineer -＠item Package release engineer +＠itemx Stable release engineer +＠itemx Package release engineer Responsible for the quality control and adminstrative details of distributing some coherent package of functionality. The ＠dfn{stable release engineer} manages the core distribution, including the build ＠＠ -573,8 +572,8 ＠＠＠c #### Write nodes for these posts! ＠item Postmaster -＠item Webmaster -＠item CVS Manager +＠itemx Webmaster +＠itemx CVS Manager Administrators of the various Internet-based services important to XEmacs users and developers. ＠c #### Write nodes for these posts! ＠＠ -620,10 +619,10 ＠＠ give the community information about the variety of platforms and features XEmacs is being configured for. Bug reports are submitted to ＠value{BETA-LIST}, preferably via ＠kbd{M-x report-xemacs-bug RET}. +＠value{BETA-LIST} is also the channel to lobby for their favorite new +features. Build reports are submitted to ＠value{BUILDREPORTS-LIST} -via the ＠kbd{M-x build-report RET} utility. Testers may -also wish to subscribe to ＠value{DESIGN-LIST}, to lobby for -their favorite new features. +via the ＠kbd{M-x build-report RET} utility. However, for those who do wish to make contributions to the collection of bytes that we call ``XEmacs'', there are a number of formal roles, ＠＠ -637,10 +636,14 ＠＠＠cindex committer ＠c MH-E says that committers may be _assigned_ bugs + A ＠dfn{committer} is one who is authorized to check in approved changes into the CVS repository, including changes to private branches they may -maintain. Developers who do not have CVS access contribute by -submitting patches to ＠value{PATCHES-LIST}. +maintain. Note that, in contrast to the use of this term on many +projects, being a committer is simply an administrative convenience; +committers must wait for approval to check in changes. +Developers who do not have CVS access contribute by submitting patches +to ＠value{PATCHES-LIST}. Commit access is generally given to those who have submitted several good patches, to ``well-known'' developers on request, and to XEmacs ＠＠ -656,8 +659,6 ＠＠＠node Commit Access, Committer Welcome Message, Committer, Committer ＠subsection Commit Access -＠c Edited: stephen 2005-01-18 - ＠cindex commit access ＠cindex cvs.xemacs.org committer accounts ＠＠ -771,8 +772,8 ＠＠ Which will get just the redtape package. You can get all the packages with the module name "packages". I'd strongly suggest that you get the whole packages tree as usually packages require some functionality from -other packages. But be warned, the packages tree is quite big (80+ MB -as of 11/2002). +other packages. But be warned, the packages tree is quite big (120+ MB +as of 2007/02). Committing patches to CVS: ------------------------- ＠＠ -913,6 +914,271 ＠＠ Of course the package maintainer does have control over the decision to release. +＠menu +* The Package Maintainer Role:: +* Getting Started as a Package Maintainer:: +* Advice to Package Maintainers:: +＠end menu + + + +＠node The Package Maintainer Role, Advice to Package Maintainers, , XEmacs Package Maintainer +＠subsection The Package Maintainer Role + +The ＠dfn{package maintainer} is basically a liaison between two +communities: the XEmacs developers, and the users of the package, who +will typically not be Lisp programmers, and perhaps not programmers at +all. Because the package maintainer represents the interest of a +community which often is not otherwise active in XEmacs development, he +is the ultimate authority on what goes into the package. Probably he +will extremely rarely wish to oppose changes made by members of the +Review Board (who have the authority to review and approve changes to +any part of XEmacs). However, he should feel free to make any changes +he thinks useful for his package; he does not need to ask anyone's +permission, and may approve or veto submissions by other users, and +incorporate them in -modesthe package as he sees fit. + +The responsibility accepted is simply to pay attention to the package. +The package maintainer should stay on top of progress in the upstream +versions of the libraries in the package, and should subscribe to the +XEmacs Beta and XEmacs Patches mailing lists to watch for bug reports +and patches relevant to it. + +We also hope and expect that the package maintainer will take part in +updating and improving the package, but we don't expect him to be a +coding wizard. It's possible to be a package maintainer even with +very little knowledge of the code. One can always ask for advice on +XEmacs Beta, or directly of experts on whatever the problem area is. +The roles of the package maintainer and of the core team are +complementary: the package maintainer stays in contact with his +community and finds out what the needs are; the core team provides +advice, information about how XEmacs works, and often patches and +documentation. + + + +＠node Getting Started as a Package Maintainer, Advice to Package Maintainers, The Package Maintainer Role, XEmacs Package Maintainer +＠subsection Getting Started as a Package Maintainer + +The first step is to check out the package from CVS in +read-write mode. This is done as follows: + +＠example +export CVSROOT=:ext:xemacs＠cvs.xemacs.org:/pack/xemacscvs +export CVS_RSH=/usr/bin/ssh +cvs checkout packages +＠end example + +This will take a while, and about 120MB of space. It's possible to do +without most of the packages (for example, most modes can delete all of +the mule-packages subtree), but the Lisp programming language makes it +very easy to call functions in one package from another, and +interdependencies are frequent. Unless one is really really tight for +space, it's best to start by just checking out the whole thing, and +prune it back later. + +The package developer is welcome to change anything in the subtree that +contains the package. However, there are a couple of administrative +files that are conceptually the "property" of the package system. These +are ＠file{package-info.in} and the ＠file{Makefile}. There is almost +surely no need to change either at this time, except to change the +＠samp{MAINTAINER} variable in the ＠file{Makefile} to contain the +maintainer's name and email address. The package maintainer should +never change the ＠samp{VERSION} variable; that is automatically +maintained by the package release engineer (currently Norbert Koch) who +does the releases of new versions of packages. You should keep the +＠samp{AUTHOR_VERSION} variable in sync with upstream, if that makes +sense. It may be possible and convenient to have ＠code{AUTHOR_VERSION +== VERSION}; ask the package release engineer about it if that seems +attractive. + +So now you can (with the above environment settings) + +＠example +cd packages/xemacs-packages/＠var{package_name} +xemacs Makefile +# change MAINTAINER to your name and address +# make a patch with cvs diff > my.patch and send it to XEmacs Patches +cvs commit -m "Update MAINTAINER name and address." Makefile +＠end example + +which is a good test that everything is working. You can find out +more about CVS and the XEmacs repository at ＠url{http://cvs.xemacs.org}. + +Many maintainers who have a separate repository for the upstream project +do not send patches, but simply announce a synch to upstream. However, +at least at first it is advisable to send patches, so that other +developers can give you advice. + +The next step is to copy the ＠file{packages/Local.rules.template} file +to ＠file{packages/Local.rules}, and edit it to fit your environment. +The main things are to make sure that the ＠samp{XEMACS} variable points +to the appropriate XEmacs binary, and that the ＠samp{STAGING} directory +is set to something useful. Now you can build a test package by simply +typing ＠kbd{make bindist}. + +Then copy the updated upstream files over the existing ones. Try +making a package with make bindist. Use the new code, too, to see if +you find any bugs. If not, you can commit the new files to CVS. + +When you make a commit, you should notify the package release engineer, +currently ＠email{viteno＠(a)xemacs.org,Norbert Koch}, about your +intentions. Norbert is pretty aggressive about making new packages and +putting them up for download. If you don't want that after a given +change, you should tell him so. (This advice may or may not apply to +the next release engineer.) + +For internal communication purposes, we make aliases for the maintainer +and the package ＠samp{＠(a)xemacs.org}. The package maintainer addresses are + +＠example +＠var{firstname.lastname}＠(a)xemacs.org +＠var{cvsuser}＠(a)xemacs.org +＠end example + +You can use these publically as you see fit, or not. The package +addresses are + +＠example +＠var{package}-bugs＠(a)xemacs.org +＠var{package}-discuss＠(a)xemacs.org +＠var{package}-patches＠(a)xemacs.org +＠var{package}-maintainer＠(a)xemacs.org +＠end example + +The last alias is set to the maintainer address. The ＠samp{bugs-} and +＠samp{discuss-} aliases are redirected to XEmacs Beta, and the +＠samp{patches-} address to the XEmacs Patch forum. You can ask that +these be changed at any time, for example if you prefer to get mail +about the XEmacs package in upstream project channels rather than XEmacs +channels. + + + +＠node Advice to Package Maintainers, , Getting Started as a Package Maintainer, XEmacs Package Maintainer +＠subsection Advice to Package Maintainers + +This section contains some as yet unorganized advice to package +maintainers, especially those who are coming from a community which uses +XEmacs but normally develops in a language other than Lisp. +(a)emph{I.e.}, the maintainer of an editor mode. + +＠heading Setting Up to Build Your Package + +Building a package almost always requires the presence of the +＠emph{source code} for other packages. Almost all packages depend on +the ＠file{xemacs-base} package, for example. Therefore the recommended +procedure is to check out the whole package tree, configure +(a)file{Local.rules}, and do a full build with ＠kbd{make} from the top. +(After that you should keep the tree up-to-date with ＠kbd{cvs update +-dP} and occasionally do a ＠kbd{make} to keep things in order.) Having +done this once, you can thereafter normally simply do ＠kbd{make} and +＠kbd{make bindist} in your package's top directory. + +We know this is annoying, but disk space is cheap, and the requirement +for a full build is a one-time thing. After that, you can just do make +bindist in your package's directory. Suggestions for improvement of the +process ＠emph{are} welcome, but they must account for the need to +provide macro definitions and autoloads. + +＠heading Lisp macros and autoloads + +Lisp provides ＠dfn{macros}, which involve ＠dfn{expansion}, which means +evaluating a Lisp expression which constructs a new Lisp expression. +When a macro is invoked by the interpreter, the second expression is +then ＠dfn{applied} to the actual arguments to give the actual result. + +This separation of expansion from application means that expansion can +take place without knowing the actual arguments. The most important +example is at compile time. As a design principle, ＠emph{compiled code +cannot expand macros} (because it's unnecessary and inefficient), so you +must have all definitions of macros used available at compile time. The +somewhat similar ＠dfn{defsubst} is like C ＠samp{inline}; it's advice to +the compiler, but the function can be called in the usual way. So +although it's not strictly necessary, it's desirable for efficiency that +defsubst definitions be available to the compiler. + +Since Lisp is very dynamic, it's possible to for code to call functions +that haven't been defined yet, as long as the call isn't evaluated until +after the function definition is loaded. The ＠dfn{autoload} facility +allows definitions to be loaded the first time they are used. + +＠heading Application to the XEmacs package infrastructure + +When a package is built, of course its Lisp libraries are compiled. To +ensure that necessary definitions are available, the libraries of the +packages named in the ＠samp{REQUIRES} Make variable are required, and +the autoload definitions are loaded from generated libraries called +＠file{auto-autoloads} in each package. + +So you should at least do ＠kbd{make autoloads} from the top of the +package tree. (It should be possible to do a more minimal set of +auto-autoloads, just the ones that your package and packages it depends +on use, but there's no automatic way to compute that set.) + +Since the compile process involves expanding macros, which is executing +package code, it will speed up the build process for your package to do +a full "make" from the top. The speedup may or may not be measurable, +since make itself and simply starting XEmacs to do the compilation are +pretty time-consuming. + +＠heading For the future + +Some attempts have been made to track the dependencies on macros and +autoloads, but the problem turns out to be fairly hard because it's +possible to dynamically compute the names of functions to call, and +things like that. Thus a program to analyze dependencies must +actually understand Lisp semantics. We've found it most reliable to +just build the packages, and set up dependencies when errors +occur. + +＠heading Getting Help with Your Package + +If you want advice on the code itself, just post it to XEmacs Patches, +which is basically designed to put new code that is believed to be ready +to be committed in front of the reviewers. Since you're the maintainer, +you should mention explicitly that you want review. Otherwise people +will assume you know what you're doing, even though you know you +don't. + +If you're more interested in whether it's a good idea or people will use +it, then post to XEmacs Beta, where a lot more people will see it. +Alternatively you may want to post to package-specific channels, either +an upstream project or the channels devoted to the language it +manipulates. To the extent that fixes have been submitted by the +community, this fits into the latter case, and you only need to consult +XEmacs channels if they don't work as expected. + +Finally, if it's a little of both, you can cross-post. This is useful +in cases where you know you want to commit this patch but you want +advice on what needs to be done next. + +＠heading Learning About Emacs Lisp + +In this case posting to XEmacs Beta and/or comp.emacs.xemacs is best, +because there are many competent Lisp hackers who are not core +developers. In many cases, for example, font lock and indentation, this +is probably not so much "learning Lisp" as "learning how Emacsen do font +lock and indentation". Still, these are skills that are quite common +outside of the core developer group. + +Many of the editor features are (unfortunately) relatively +fork-specific. Emacs and XEmacs do them somewhat differently, +especially font-lock. Nevertheless, you may also get some help on +channels like comp.emacs and gnu.emacs.help. (Not +＠samp{emacs-devel＠(a)gnu.org}, please; XEmacs-specific stuff is off-topic +there, and even individual gurus won't be able to help much, since +XEmacs code has diverged substantially. + +For Emacs Lisp itself, there's some tutorial material in +＠ref{Top,the XEmacs Lisp Reference manual, , lispref}, and GNU +distributes an Emacs Lisp tutorial. However, the GNU tutorial is really +more of a generic Lisp tutorial, with a few examples drawn from the +Emacs domain. The Lisp Reference is pretty well organized; if you have +trouble finding references to what you need to do, or don't understand +what it says, feel free to report it as a bug. It's not always possible +to improve it, but it's always worth trying! + ＠node XEmacs Reviewer, Meta-Maintainer, XEmacs Package Maintainer, The Work Roles ＠＠ -962,7 +1228,6 ＠＠＠node Appointing New Reviewers, Welcoming New Reviewers, XEmacs Reviewer, XEmacs Reviewer ＠subsection Appointing New Reviewers -＠c Created: stephen 2005-01-19 ＠strong{This node needs improvement!!} ＠cindex ＠value{BOARD} ＠＠ -1176,7 +1441,10 ＠＠ including such things as ensuring that generated files are committed to CVS, tagging CVS, updating release documentation, creating and uploading tarballs, and making announcements. Release engineers are ＠emph{ex -oficio} members of the XEmacs Review Board. +oficio} members of the XEmacs Review Board. That is, if you are willing +to accept the responsibility of release engineering, and the Board is +willing to accept you, you will be appointed as Reviewer if you aren't +already. ＠c #### MAKE A SEPARATE NODE CORRESPONDING TO jobs.html, AND FIGURE OUT ＠c HOW TO AUTOMAGICALLY UPDATE AND PUBLISH IT AS jobs.html. ＠＠ -1203,7 +1471,6 ＠＠＠node The Work Flow, XEmacs Resources on the Internet, The Work Roles, Top ＠chapter The Work Flow -＠c Created: stephen 2005-01-20 This section is a description of current best practices, rather than an attempt to define a standard. ＠＠ -1215,8 +1482,10 ＠＠＠table ＠emph ＠item Get the sources. -XEmacs is distributed with source, but CVS simplifies management of your -improvements. +＠value{PROJECT} tarballs are always distributed as source (except in +the case of the Windows installer), but CVS simplifies management of +your improvements. (Third-party vendors such as *nix distributions and +Cygwin may distribute binary packages, but XEmacs no longer does.) ＠item Write low-profile code. Don't distract your users or colleagues from their work. Just make it ＠＠ -1230,11 +1499,14 ＠＠＠item Create the patch. Dot the i's, cross the t's. Make sure that it's easy to add to the code -base. +base. The best way is by using ＠code{cvs diff -uN} against the tip of +the branch or trunk you intend to have the patch applied to. The +exception is ChangeLog patches, which may be generated using ＠code{cvs +diff -U 0 ChangeLog}, or submitted as plain test. ＠item Submit the patch. -Compose the message so it's easy to find, easy to identify, easy to -review, and easy to apply. +Compose the message, especially the Subject: header, so it's easy to +find, easy to identify, easy to review, and easy to apply. ＠item Review the patch. The primary function of the ＠value{BOARD} is to help you improve your ＠＠ -1281,17 +1553,19 ＠＠ the FSF (or other free software trust), which is required by its covenants of incorporation to actively defend free software it holds. You may also wish to respect the wishes of Richard Stallman, the first -author and still major contributor to the development of Emacs. +author and current maintainer of Emacs. Finally, you may wish to support the FSF's advocacy of free software by assigning your copyright to the FSF. At the present time, the ＠value{PROJECT} neither advocates nor discourages this action; it's up to you. -Also, be aware that at the time of writing, January 2005, -Richard Stallman had recently denied that such assignments would +Also, be aware that in January 2005 +Richard Stallman explicitly denied that such assignments would facilitate adoption of XEmacs code by GNU Emacs; if you want your code to be used in GNU Emacs, you will have to resubmit it directly to the -GNU Emacs project. +GNU Emacs project. (The assignment is acceptable for use in Emacs, but +Emacs developers are not allowed to port others' code from XEmacs to GNU +Emacs, even if it's assigned; the original developer must do that.) Get more information about procedures from the ＠email{emacs-devel＠(a)gnu.org,GNU Emacs developers' mailing list} or from ＠＠ -1305,7 +1579,6 ＠＠＠node Scratching That Itch, Get the Sources, About Copyright Assignment, The Work Flow ＠section Scratching That Itch -＠c Edited: stephen 2005-01-18 ＠c #### needs revision As always in free software, a patch starts life when some developer ＠＠ -1319,7 +1592,8 ＠＠＠node Get the Sources, Write Low-Profile Code, Scratching That Itch, The Work Flow ＠section Get the Sources -Maybe he's never worked on XEmacs before. In that case, he'll need to +Maybe the developer has never worked on XEmacs before. In that case, +he'll need to check out the ＠samp{xemacs} module from the CVS repository ＠ref{CVS Repository}. True, he may already have the whole package because he built from source after downloading a tarball. However, tarballs often ＠＠ -1327,7 +1601,7 ＠＠ maintainer off like a patch that doesn't apply because it was generated against an old version. Furthermore, the developer needs to keep track of the original file in order to generate a correct patch, which can be -quite difficult if you go through several iterations woring on a complex +quite difficult if you go through several iterations working on a complex issue. It's true that CVS has problems in advanced usage, but for these simple housekeeping tasks it works very well. Use CVS. ＠＠ -1407,8 +1681,7 ＠＠＠node Add a ChangeLog Entry, Create the Patch, Test Your Changes, The Work Flow ＠section Add a ChangeLog Entry -＠c Created: stephen 2005-01-21 -＠strong{Needs revision!!} +＠strong{Needs review!!} Add a log entry to ＠file{ChangeLog} file in the ancestor directory closest to each changed file. ＠＠ -1421,8 +1694,6 ＠＠＠node ChangeLogs, Log Messages, Add a ChangeLog Entry, Add a ChangeLog Entry ＠subsection ChangeLogs -＠c Edited: stephen 2005-01-18 - ＠strong{This section is pretty close to correct for XEmacs. Needs review.} ＠cindex ChangeLog ＠＠ -1472,6 +1743,12 ＠＠ 4 a} (＠code{add-change-log-entry-other-window}) which inserts this text for you (even from a diff!), please do follow its conventions. +Note that the date, the full name, and the email address are separated +by pairs of ASCII spaces, the date is in YYYY-MM-DD format, and the +email address enclosed in angle brackets. The leading space in the log +entries is encoded as an ASCII TAB, not as 8 spaces. These formatting +rules are mandatory, because ChangeLog modes depend on these heuristics. + Multiple targets with the same text may appear in the same entry. ＠cindex Debian ＠＠ -1498,8 +1775,6 ＠＠＠node Log Messages, , ChangeLogs, Add a ChangeLog Entry ＠subsection Log Messages -＠c Edited: stephen 2005-01-18 - ＠strong{This section, written by Bill Wohler for MH-E and lightly edited to substitute ``XEmacs'' for ``MH-E'', is pretty close to correct for XEmacs, at least in the case of implicit self-approval. Needs review.} ＠＠ -1554,7 +1829,7 ＠＠ (The following lines describe the current patch creation standard for developers without commit access, committers, and reviewers alike. An -optional alternative procedure for ＠emph{reviewers only} is likely to be +optional alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005.) Patches should be created using a standard diff(1) such as provided by ＠＠ -1593,7 +1868,7 ＠＠ (The following lines describe the current patch submission procedure for developers without commit access, committers, and reviewers alike. An -optional alternative procedure for ＠emph{reviewers only} is likely to be +optional alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005.) Send the patch by email to ＠value{PATCHES-LIST}. The subject line ＠＠ -1654,13 +1929,13 ＠＠ commit the changes to CVS as appropriate. ＠menu -* Proposed Optional Alternate Procedure for Reviewers:: +* Optional Alternate Procedure for Reviewers:: ＠end menu -＠node Proposed Optional Alternate Procedure for Reviewers, , Submit the Patch, Submit the Patch -＠subsection Proposed Optional Alternate Procedure for Reviewers +＠node Optional Alternate Procedure for Reviewers, , Submit the Patch, Submit the Patch +＠subsection Optional Alternate Procedure for Reviewers Patches that are self-approved by a reviewer, and are either expected to be non-controversial or are part of a project that has the general ＠＠ -1670,8 +1945,9 ＠＠＠value{PATCHES-LIST}. This may be referred to as ＠dfn{implicit self-approval}. -＠strong{This procedure is not yet in effect, and the commit-trigger has -not yet been implemented at the time of writing. (2005-01-20)} +＠strong{The commit-trigger has +not yet been implemented at the time of writing. For this reason +implicit self-approvals should still be avoided. (2007-05-13)} ＠＠ -1684,7 +1960,7 ＠＠ (The following lines describe the current patch submission procedure for developers without commit access and committers. Reviewers may optionally use ``commit-and-review,'' described later. Another optional -alternative procedure for ＠emph{reviewers only} is likely to be adopted +alternative procedure for ＠emph{reviewers only} was adopted in first quarter 2005. Called ``implicit self-approval,'' it was described in the previous section.) ＠＠ -1712,7 +1988,7 ＠＠＠item REVISE The reviewer is demanding certain revisions, or the patch will be -vetoed. May be obsolete; current practice seems to favor use of +vetoed. May be obsolete; current practice strongly favors use of ＠strong{QUERY} both for required revisions and for further discussion, and there seems to be little need to distinguish these cases. ＠＠ -1898,10 +2174,9 ＠＠ -＠node XEmacs Resources on the Internet, Support Requests, The Work Flow, Top +＠node XEmacs Resources on the Internet, Copying, The Work Flow, Top ＠chapter XEmacs Resources on the Internet -＠c Edited: stephen 2005-01-18 ＠strong{Write this node! Get mailing list and newsgroup information from the ＠uref{http://www.xemacs.org/Lists/, mailing list page}, available as the module ＠emph{xemacsweb} ＠ref{CVS Repository}. ＠＠ -1926,8 +2201,6 ＠＠＠node Project Website, CVS Repository, XEmacs Resources on the Internet, XEmacs Resources on the Internet ＠section Project Website -＠c Edited: stephen 2005-01-18 - ＠strong{Needs review. Adrian?} ＠cindex Project Website ＠＠ -1949,8 +2222,6 ＠＠＠node CVS Repository, comp.emacs.xemacs, Project Website, XEmacs Resources on the Internet ＠section CVS Repository -＠c Edited: stephen 2005-01-18 - ＠cindex CVS Repository ＠c #### update the specific links for convenience!! ＠＠ -1978,10 +2249,13 ＠＠＠node xemacs-design, xemacs-patches, xemacs-beta, XEmacs Resources on the Internet ＠section The xemacs-design Mailing List -＠strong{Write me!} +This list is currently inactive. Traffic that used to go to +＠value{DESIGN-LIST} should be directed to ＠value{BETA-LIST} instead. +＠strong{Concerning content, write me!} + ＠node xemacs-patches, xemacs-mule, xemacs-design, XEmacs Resources on the Internet ＠section The xemacs-patches Mailing List ＠＠ -2003,203 +2277,613 ＠＠ -＠c ########################################################################## -＠c #### I haven't seriously worked on the following material. -- stephen #### -＠c ########################################################################## +＠node Copying, Nodes borrowed from other projects not adapted to XEmacs, XEmacs Resources on the Internet, Top +＠appendix GNU GENERAL PUBLIC LICENSE +＠center Version 2, June 1991 -＠node Support Requests, Bugs, XEmacs Resources on the Internet, Top -＠chapter Support Requests +＠display +Copyright ＠copyright{} 1989, 1991 Free Software Foundation, Inc. +59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -＠cindex Support Requests +Everyone is permitted to copy and distribute verbatim copies +of this license document, but changing it is not allowed. +＠end display -Support requests are made to ＠value{BETA-LIST}. Developers should read -the mailing list frequently, and after a period of inactivity, browse -the ＠uref{http://list-archive.xemacs.org/xemacs-beta/,recent archives}. +＠appendixsec Preamble + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software---to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. -＠node Bugs, Feature Requests, Support Requests, Top -＠chapter Bugs + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. -＠c Edited: stephen 2005-01-18 + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. -＠strong{We don't have a tracker. We should. Describe what it should -look like here.} + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. -＠cindex Bugs -＠cindex priority -＠cindex bugs, priority + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. -Bug reports, feature requests, and discussions that are expected to lead -to bug reports or feature requests are created in -＠uref{https://sourceforge.net/bugs/?group_id=13357, Bugs}. Most -bugs should be set to a priority of 5. + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. -＠cindex bug-gnu-emacs -＠cindex Debian + The precise terms and conditions for copying, distribution and +modification follow. -Developers should follow the ＠i{bug-gnu-emacs} mailing lists/newsgroup -and move bug reports into Bugs if it has not been done already. -Similarly, XEmacs bugs reported in other systems should be transfered to -＠value{XEMACSORG}. The bug may be cut and pasted into a new bug report, or a -URL to the source of the original bug report may be all that appears -in the bug report. +＠iftex +＠appendixsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +＠end iftex +＠ifinfo +＠center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +＠end ifinfo -A brief lifecycle of a bug proceeds something like this. A bug is -entered. A developer ensures that the Category, Priority and Group are -correct. The Group for an Open bug should be set to the version of -software in which the bug was found, or CVS if it was found in the -latest and greatest. +＠enumerate 0 +＠item +This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The ``Program,'' below, +refers to any such program or work, and a ``work based on the Program'' +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term ``modification.'') Each licensee is addressed as ``you.'' -The assignment of bugs in Bugs follows the honor system. If you see an -open bug that you think you could handle, assign the bug to yourself. -Bugs that remain open should be reviewed by a member of the -＠value{BOARD}, who should try to find a developer to work on the bug. +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. -If you fix a bug, set the resolution to Fixed and group to CVS. Please -also assign the bug to yourself if you have not done so already, so -you get credit in the -＠uref{https://sourceforge.net/tracker/reporting/?atid=113357&what=tech&span=&period=lifespan&group_id=13357#b, -reports}. If a documentation change is not required, set the status to -Closed. If a documentation change is required, set the category to -Documentation, and assign the bug to the documentation tsar, -leave the status Open, and set the priority to 3 to set it -aside in listings sorted by priority. +＠item +You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. -See ＠ref{File Releases} for a motivation of why this process is useful. +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. -The rest of this section describes the categories and groups that have -been set up for the XEmacs project. +＠item +You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: -＠menu -* Category:: -* Status:: -* Group:: -* Resolution:: -＠end menu +＠enumerate a +＠item +You must cause the modified files to carry prominent notices +stating that you changed the files and the date of any change. -＠node Category, Status, Bugs, Bugs -＠section Category +＠item +You must cause any work that you distribute or publish, that in +whole or in part contains or is derived from the Program or any +part thereof, to be licensed as a whole at no charge to all third +parties under the terms of this License. -＠cindex category -＠cindex bug category +＠item +If the modified program normally reads commands interactively +when run, you must cause it, when started running for such +interactive use in the most ordinary way, to print or display an +announcement including an appropriate copyright notice and a +notice that there is no warranty (or else, saying that you provide +a warranty) and that users may redistribute the program under +these conditions, and telling the user how to view a copy of this +License. (Exception: if the Program itself is interactive but +does not normally print such an announcement, your work based on +the Program is not required to print an announcement.) +＠end enumerate -Several categories have been created for the XEmacs project organized by -function. They include ＠i{General}, ＠i{UI}, ＠i{MIME}, ＠i{Security}, -＠i{Documentation}, and ＠i{Contrib} +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. -＠table ＠b +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. -＠item General +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. -＠cindex general bug category -＠cindex bug categories, general +＠item +You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: -The ＠dfn{General} category is used for bugs that do not belong in any of -the other categories. +＠enumerate a +＠item +Accompany it with the complete corresponding machine-readable +source code, which must be distributed under the terms of Sections +1 and 2 above on a medium customarily used for software interchange; or, -＠item UI - -＠cindex UI bug category -＠cindex bug categories, UI +＠item +Accompany it with a written offer, valid for at least three +years, to give any third party, for a charge no more than your +cost of physically performing source distribution, a complete +machine-readable copy of the corresponding source code, to be +distributed under the terms of Sections 1 and 2 above on a medium +customarily used for software interchange; or, -The ＠dfn{UI} category is used for bugs in the software that the user sees -such as font-lock, key definitions, menus, and customization. +＠item +Accompany it with the information you received as to the offer +to distribute corresponding source code. (This alternative is +allowed only for noncommercial distribution and only if you +received the program in object code or executable form with such +an offer, in accord with Subsection b above.) +＠end enumerate -＠item MIME +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. -＠cindex MIME bug category -＠cindex bug categories, MIME +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. -The ＠dfn{MIME} category is used for bugs that pertain to MIME. +＠item +You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. -＠item Security +＠item +You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. -＠cindex security bug category -＠cindex bug categories, security +＠item +Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. -The ＠dfn{Security} category is used for bugs in the security arena. At -present, XEmacs does not include any security code, so this category might -be used for PGP interaction. +＠item +If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. -＠item Documentation +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. -＠cindex documentation bug category -＠cindex bug categories, documentation +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. -The ＠dfn{Documentation} category is used for bugs in the documentation -arena. In addition, if there are any code changes made as a result of a -bug report or feature request that require changes to the documentation, -the category of that issue should be set to Documentation after the bug -has been fixed or the feature implemented. Assign the issue to -＠i{wohler} for editing and/or writing of the documentation, and set -the priority to 3 to set the issue aside in listings sorted by priority. +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. -＠item Contrib +＠item +If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. -＠cindex contrib bug category -＠cindex bug categories, contrib +＠item +The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. -The ＠dfn{Contrib} category is used for all bugs in the contributed -software. +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and ``any +later version,'' you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. -＠end table +＠item +If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. -＠node Status, Group, Category, Bugs -＠section Status +＠iftex +＠heading NO WARRANTY +＠end iftex +＠ifinfo +＠center NO WARRANTY +＠end ifinfo -＠cindex status -＠cindex bug status +＠item +BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW＠. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE＠. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU＠. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. -The bug ＠dfn{status} is divided into four sections: ＠i{Open}, -＠i{Closed}, ＠i{Deleted} and ＠i{Pending}. +＠item +IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. +＠end enumerate -＠table ＠b +＠iftex +＠heading END OF TERMS AND CONDITIONS +＠end iftex +＠ifinfo +＠center END OF TERMS AND CONDITIONS +＠end ifinfo -＠item Open +＠page +＠appendixsec How to Apply These Terms to Your New Programs -＠cindex open bug status -＠cindex bug status, open + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. -When bugs are initially created, they are marked ＠dfn{Open}. + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the ``copyright'' line and a pointer to where the full notice is found. -＠cindex discussing bugs -＠cindex bugs, discussing -＠cindex features, discussing +＠smallexample +＠var{one line to give the program's name and an idea of what it does.} +Copyright (C) 19＠var{yy} ＠var{name of author} -The Bugs and Feature Requests sections are also used as a method to -get the ball rolling among developers. They are used to register what -we feel we should work on. For example, a developer may have questions -about the way XEmacs handles MIME that we should discuss before we -attempt to fix it: What do other people do? How should we attack this? -That developer opens a bug report in the MIME category and a -discussion ensues. Once the disposition of the issue is resolved, the -bug is assigned to a developer. Later, when the bug is fixed, the bug -can be closed. +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. -Discussion about entirely new features should be opened in the Feature -Requests section (＠pxref{Feature Requests}) but otherwise handled in -the same way. +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE＠. See the +GNU General Public License for more details. -＠item Closed +You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., +59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. +＠end smallexample -＠cindex closed bug status -＠cindex bug status, closed +Also add information on how to contact you by electronic and paper mail. -When all aspects of a bug have been fixed, including code and -documentation, the bug is marked ＠dfn{Closed}. +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: -When setting the status to Closed, the group should be set to Fixed, -Works For Me, Invalid, or Rejected. +＠smallexample +Gnomovision version 69, Copyright (C) 20＠var{yy} ＠var{name of author} +Gnomovision comes with ABSOLUTELY NO WARRANTY; for details +type `show w'. This is free software, and you are welcome +to redistribute it under certain conditions; type `show c' +for details. +＠end smallexample -＠item Pending +The hypothetical commands ＠samp{show w} and ＠samp{show c} should show +the appropriate parts of the General Public License. Of course, the +commands you use may be called something other than ＠samp{show w} and +＠samp{show c}; they could even be mouse-clicks or menu items---whatever +suits your program. -＠cindex pending bug status -＠cindex bug status, pending +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a ``copyright disclaimer'' for the program, if +necessary. Here is a sample; alter the names: -You can set the status to ＠dfn{Pending} if you are waiting for a -response from the tracker item author. When the author responds, the -status is automatically reset to that of Open. Otherwise, if the +＠smallexample +＠group +Yoyodyne, Inc., hereby disclaims all copyright +interest in the program `Gnomovision' +(which makes passes at compilers) written +by James Hacker. + +＠var{signature of Ty Coon}, 1 April 1989 +Ty Coon, President of Vice +＠end group +＠end smallexample + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. + + +＠node Nodes borrowed from other projects not adapted to XEmacs, Index, Copying, Top +＠appendix Nodes borrowed from other projects not adapted to XEmacs + +＠c ######################################################################### +＠c #### I haven't seriously worked on the included material. -- stephen #### +＠c ######################################################################### + +＠menu +* Support Requests:: +* Bugs:: +* Feature Requests:: +* Patch Queue:: +* File Releases:: +* News:: +* Surveys:: +* Free Software Directories:: +＠end menu + + +＠node Support Requests, Bugs, , Top +＠chapter Support Requests + +＠cindex Support Requests + +Support requests are made to ＠value{BETA-LIST}. Developers should read +the mailing list frequently, and after a period of inactivity, browse +the ＠uref{http://list-archive.xemacs.org/xemacs-beta/,recent archives}. + + + +＠node Bugs, Feature Requests, Support Requests, Top +＠chapter Bugs + +＠strong{We don't have a tracker. We should. Describe what it should +look like here.} + +＠cindex Bugs +＠cindex priority +＠cindex bugs, priority + +Bug reports, feature requests, and discussions that are expected to lead +to bug reports or feature requests are created in +＠uref{https://sourceforge.net/bugs/?group_id=13357, Bugs}. Most +bugs should be set to a priority of 5. + +＠cindex bug-gnu-emacs +＠cindex Debian + +Developers should follow the ＠i{bug-gnu-emacs} mailing lists/newsgroup +and move bug reports into Bugs if it has not been done already. +Similarly, XEmacs bugs reported in other systems should be transfered to +＠value{XEMACSORG}. The bug may be cut and pasted into a new bug report, or a +URL to the source of the original bug report may be all that appears +in the bug report. + +A brief lifecycle of a bug proceeds something like this. A bug is +entered. A developer ensures that the Category, Priority and Group are +correct. The Group for an Open bug should be set to the version of +software in which the bug was found, or CVS if it was found in the +latest and greatest. + +The assignment of bugs in Bugs follows the honor system. If you see an +open bug that you think you could handle, assign the bug to yourself. +Bugs that remain open should be reviewed by a member of the +＠value{BOARD}, who should try to find a developer to work on the bug. + +If you fix a bug, set the resolution to Fixed and group to CVS. Please +also assign the bug to yourself if you have not done so already, so +you get credit in the +＠uref{https://sourceforge.net/tracker/reporting/?atid=113357&what=tech&span=&period=lifespan&group_id=13357#b, +reports}. If a documentation change is not required, set the status to +Closed. If a documentation change is required, set the category to +Documentation, and assign the bug to the documentation tsar, +leave the status Open, and set the priority to 3 to set it +aside in listings sorted by priority. + +See ＠ref{File Releases} for a motivation of why this process is useful. + +The rest of this section describes the categories and groups that have +been set up for the XEmacs project. + +＠menu +* Category:: +* Status:: +* Group:: +* Resolution:: +＠end menu + +＠node Category, Status, Bugs, Bugs +＠section Category + +＠cindex category +＠cindex bug category + +Several categories have been created for the XEmacs project organized by +function. They include ＠i{General}, ＠i{UI}, ＠i{MIME}, ＠i{Security}, +＠i{Documentation}, and ＠i{Contrib} + +＠table ＠b + +＠item General + +＠cindex general bug category +＠cindex bug categories, general + +The ＠dfn{General} category is used for bugs that do not belong in any of +the other categories. + +＠item UI + +＠cindex UI bug category +＠cindex bug categories, UI + +The ＠dfn{UI} category is used for bugs in the software that the user sees +such as font-lock, key definitions, menus, and customization. + +＠item MIME + +＠cindex MIME bug category +＠cindex bug categories, MIME + +The ＠dfn{MIME} category is used for bugs that pertain to MIME. + +＠item Security + +＠cindex security bug category +＠cindex bug categories, security + +The ＠dfn{Security} category is used for bugs in the security arena. At +present, XEmacs does not include any security code, so this category might +be used for PGP interaction. + +＠item Documentation + +＠cindex documentation bug category +＠cindex bug categories, documentation + +The ＠dfn{Documentation} category is used for bugs in the documentation +arena. In addition, if there are any code changes made as a result of a +bug report or feature request that require changes to the documentation, +the category of that issue should be set to Documentation after the bug +has been fixed or the feature implemented. Assign the issue to +＠i{wohler} for editing and/or writing of the documentation, and set +the priority to 3 to set the issue aside in listings sorted by priority. + +＠item Contrib + +＠cindex contrib bug category +＠cindex bug categories, contrib + +The ＠dfn{Contrib} category is used for all bugs in the contributed +software. + +＠end table + +＠node Status, Group, Category, Bugs +＠section Status + +＠cindex status +＠cindex bug status + +The bug ＠dfn{status} is divided into four sections: ＠i{Open}, +＠i{Closed}, ＠i{Deleted} and ＠i{Pending}. + +＠table ＠b + +＠item Open + +＠cindex open bug status +＠cindex bug status, open + +When bugs are initially created, they are marked ＠dfn{Open}. + +＠cindex discussing bugs +＠cindex bugs, discussing +＠cindex features, discussing + +The Bugs and Feature Requests sections are also used as a method to +get the ball rolling among developers. They are used to register what +we feel we should work on. For example, a developer may have questions +about the way XEmacs handles MIME that we should discuss before we +attempt to fix it: What do other people do? How should we attack this? +That developer opens a bug report in the MIME category and a +discussion ensues. Once the disposition of the issue is resolved, the +bug is assigned to a developer. Later, when the bug is fixed, the bug +can be closed. + +Discussion about entirely new features should be opened in the Feature +Requests section (＠pxref{Feature Requests}) but otherwise handled in +the same way. + +＠item Closed + +＠cindex closed bug status +＠cindex bug status, closed + +When all aspects of a bug have been fixed, including code and +documentation, the bug is marked ＠dfn{Closed}. + +When setting the status to Closed, the group should be set to Fixed, +Works For Me, Invalid, or Rejected. + +＠item Pending + +＠cindex pending bug status +＠cindex bug status, pending + +You can set the status to ＠dfn{Pending} if you are waiting for a +response from the tracker item author. When the author responds, the +status is automatically reset to that of Open. Otherwise, if the author doesn't respond within 14 days, then the item is given a status of Deleted. ＠＠ -2238,9 +2922,9 ＠＠ release. Just be sure to mention the issue number in the ChangeLog so that it can be noted in the next release announcement. -＠item mh-e* +＠item XE* -Bugs in groups starting with mh-e have either been found in the given +Bugs in groups starting with XE have either been found in the given version if the Status is Open, or fixed in the given version if the Status is Closed. ＠＠ -2362,12 +3046,10 ＠＠＠node Feature Requests, Patch Queue, Bugs, Top ＠chapter Feature Requests -＠c Edited: stephen 2005-01-18 - ＠cindex Feature Requests Developers should check the -＠uref{https://sourceforge.net/patch/?group_id=13357, Feature Requests} +Feature Requests occasionally for new feature requests and comment on the feature's usefulness and integrity. Unless a positive comment has ＠c #### define "reasonable" ＠＠ -2387,8 +3069,6 ＠＠＠node Patch Queue, File Releases, Feature Requests, Top ＠chapter Patch Queue -＠c Edited: stephen 2005-01-18 - ＠cindex Patch Queue Developers should check ＠value{PATCHES-LIST} ＠＠ -2408,8 +3088,6 ＠＠＠node File Releases, News, Patch Queue, Top ＠chapter File Releases -＠c Edited: stephen 2005-01-18 - ＠strong{This node and all of its children need to be reviewed and adapted to the XEmacs process. One topic that ＠emph{must} be addressed is regenerating and checking in generated files.} ＠＠ -2444,8 +3122,6 ＠＠＠node Release Schedule, Release Prerequisites, File Releases, File Releases ＠section Release Schedule -＠c Edited: stephen 2005-01-18 - ＠strong{Totally bogus for XEmacs historical practice, probably totally unrealistic as future policy.} ＠＠ -2508,8 +3184,6 ＠＠＠node Release Prerequisites, Updating NEWS, Release Schedule, File Releases ＠section Release Prerequisites -＠c Edited: stephen 2005-01-18 only to fix a makeinfo error - ＠cindex Release Prerequisites ＠cindex Coding Conventions ＠cindex Emacs Lisp Coding Conventions ＠＠ -2576,12 +3250,12 ＠＠＠end enumerate The previous steps usually catch most items. To use a finer sieve, use -the following commands. These assume that the last version of the XEmacs -package was 6.0. +the following commands. These assume that the last version of XEmacs +was 21.4.20. ＠example - cvs log -rmh-e-6_0 - cvs diff -rmh-e-6_0 + cvs log -rr21-4-20 + cvs diff -rr21-4-20 ＠end example See section ＠ref{Updating ChangeLogs} before checking in this file. ＠＠ -2710,15 +3384,21 ＠＠＠item ＠strong{Module} ＠tab ＠strong{Tarball} -＠item src -＠tab mh-e-M.N.tgz +＠item Full distro +＠tab xemacs-X.Y.Z.tar.gz -＠item doc -＠tab mh-e-doc-M.N.tgz +＠item Patch +＠tab xemacs-X.Y.Z-X.Y.(++Z).patch.gz -＠item contrib -＠tab mh-e-contrib-M.N.tgz +＠item Sources only +＠tab xemacs-X.Y.Z-src.tar.gz +＠item Compiled Lisp +＠tab xemacs-X.Y.Z-elc.tar.gz + +＠item Formatted Info +＠tab xemacs-X.Y.Z-info.tar.gz + ＠end multitable ＠end quotation ＠＠ -2730,40 +3410,8 ＠＠＠cindex version numbers The tarballs listed in the table above are built as follows: - -＠itemize - -＠cindex CVS, co - -＠item If ＠var{module} has not been checked out -already, check it out: - -＠example -export CVS_RSH=ssh -cvs -d -z3 $USER＠＠cvs.mh-e.sourceforge.net:/cvsroot/mh-e co -r ＠var{release} ＠var{module} -＠end example - -＠item If ＠var{module} has been checked out -already, set the sticky tag for the release: - -＠example -cvs update -r ＠var{release} -＠end example - -＠item Build the tarball. - -＠example -cd ＠var{module} -make dist -＠end example - -＠end itemize -The ＠code{make dist} command ensures that the tarball is named correctly -and that the tar extracts in a subdirectory that has the same name as -the tarball's prefix. For example, if ＠var{release} was mh-e-5_2, then -the tarball would be named mh-e-5.2.tgz and would extract into the -directory named mh-e-5.2. +＠strong{Write me!} ＠node Creating ＠value{XEMACSORG} Releases, Updating the Tracker, Creating Tarballs, File Releases ＠section Creating ＠value{XEMACSORG} Releases ＠＠ -2772,61 +3420,16 ＠＠＠cindex releases ＠cindex tarballs, making -First, create the tarballs (＠pxref{Creating Tarballs}). Then -＠uref{https://sourceforge.net/project/admin/editpackages.php?group_id=13357, -add the release} per the instructions in -＠uref{https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1#filereleasesteps, -The File Release System}. Be sure to check the box labeled -＠code{Preserve my pre-formatted text}. Use the entire ＠file{README} -file for the release notes and the appropriate section of the -＠file{NEWS} file for the Change Log. - -If there were any beta releases leading up to this release, -＠uref{https://sourceforge.net/project/admin/editreleases.php?package_id=11309&group_id=13357, -edit the release} and set the Status to Hidden. +＠strong{Write me!} ＠node Updating the Tracker, Announce the Release, Creating ＠value{XEMACSORG} Releases, File Releases ＠section Updating the Tracker ＠cindex Updating the Tracker -After XEmacs is released, update the tracker. First, change the group to -mh-e-doc-(a)var{m.n} (for example, mh-e-doc-1.3) for all open -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=113357, -bugs} and -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=363357&, -features} with a category of Documentation and a group of CVS. The -list is restricted to open issues since it is possible that an issue -was given a category of Documention for inclusion in the release -notes and then closed. Such an issue would not force a manual update. - -Then change the name of the group CVS to mh-e-(a)var{m.n} for both -＠uref{https://sourceforge.net/tracker/admin/index.php?group_id=13357&atid=113357&add_group=1, -bugs} and -＠uref{https://sourceforge.net/tracker/admin/index.php?group_id=13357&atid=363357&add_group=1, -features}. For example, when XEmacs version 6.0 is released, rename the -CVS group to mh-e-6.0. Then create a new CVS group. This should be -done for doc and contrib releases too. - -An exception to this occurs when releasing beta releases. The group -name in the series of beta releases leading up to the actual release -is reused. That way, in the end all the existing issues are left -pointing to the actual release rather than a beta. For example, CVS -would first be renamed to mh-e-6.1.90 which would in turn be renamed -to mh-e-6.1.91 which would in turn be renamed to mh-e-7.0. - -Another oddity occurs when you make a patch release. When you change -the name of the group from CVS to mh-e-(a)var{m.n.p}, you will probably -effect mainline work. So go back to -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=113357, -bugs} and -＠uref{https://sourceforge.net/tracker/?group_id=13357&atid=363357, -features}, and browse all issues with the new mh-e-(a)var{m.n.p} group -name. Perform a mass group name change from mh-e-(a)var{m.n.p} to CVS -for all issues that do not appear in the patch release. It may also be -easier to add a new group name of mh-e-(a)var{m.n.p} and set the group -of the items in the patch release to it. +＠strong{Write me! (and install a Tracker!)} + ＠node Announce the Release, Updating the Emacs Repository, Updating the Tracker, File Releases ＠section Announce the Release ＠＠ -2838,8 +3441,6 ＠＠＠node Updating the Emacs Repository, Updating the Debian Package, Announce the Release, File Releases ＠section Updating the Emacs Repository -＠c Edited: stephen 2005-01-19 - ＠strong{Needs review. Although on the face of it this obviously has nothing to do with XEmacs, in fact there are probably hints here for XEmacs release engineers.} ＠＠ -3018,6 +3619,7 ＠＠ time to put the new code on the Emacs branch. This makes it possible to detect changes to XEmacs that an Emacs developer may make later. + ＠node Updating the Debian Package, Updating the XEmacs Package, Updating the Emacs Repository, File Releases ＠section Updating the Debian Package ＠＠ -3025,9 +3627,9 ＠＠＠cindex Debian Package, Updating ＠cindex Debian -This task is the duty of Peter Galbraith <＠i{psg＠(a)debian.org}>. It may -be useful to others to want to make an unofficial package of the CVS -tree. +＠strong{Edit me! Or maybe not: currently the various distros have +their own maintainers. It might be useful for Debian/Ubuntu because of +the complex Debian Emacs policy.} To build a Debian package, you'll need to have installed the Debian package ＠code{build-essential} as well as those listed in the ＠＠ -3085,7 +3687,6 ＠＠＠node Updating the Online Documentation, Updating the Free Software Directories, Updating the XEmacs Package, File Releases ＠section Updating the Online Documentation -＠c Edited: stephen 2005-01-19 ＠strong{Adrian, please review.} ＠cindex Updating the Online Documentation ＠＠ -3135,7 +3736,6 ＠＠＠node Updating the Free Software Directories, After the Release, Updating the Online Documentation, File Releases ＠section Updating the Free Software Directories -＠c Edited: stephen 2005-01-18 ＠strong{Add FreshMeat, at least.} Update the ＠i{source-tarball} and ＠i{version} fields in the FSF/UNESCO ＠＠ -3181,8 +3781,6 ＠＠＠node News, Surveys, File Releases, Top ＠chapter News -＠c Edited: stephen 2005-01-18 - ＠strong{Needs review.} ＠cindex News ＠＠ -3214,8 +3812,7 ＠＠ As only the first paragraph is shown on the ＠value{XEMACSORG} front page, it should be written wisely. Emulate the look and feel of previous news postings. The first sentence should be the same as the first sentence -in the description on the -＠uref{https://sourceforge.net/projects/mh-e/, Summary} page. The +in the description on the home page. The following sentences are typically copied from the first paragraph of the release notes and should briefly describe the benefit of the release or otherwise entice the reader to read further. The contrib ＠＠ -3227,12 +3824,6 ＠＠ Read on for more details. ＠end example -Use the following for the second paragraph: - -＠example - Project home page at: http://mh-e.sourceforge.net/. -＠end example - Finally, include the release notes from ＠file{NEWS}. Because the introductory paragraph was already used, include the release notes starting with the ``New Features'' item. To avoid ugly wrapping, first ＠＠ -3265,18 +3856,17 ＠＠＠node Surveys, Free Software Directories, News, Top ＠chapter Surveys -＠c Edited: stephen 2005-01-18 - ＠strong{Interesting. Should we do this, maybe?} ＠cindex Surveys The project admin may create -＠uref{https://sourceforge.net/survey/?group_id=13357, Surveys}. The +＠c #### need to fix the group_id +＠uref{https://sourceforge.net/survey/?group_id=, Surveys}. The interface is backwards. First you create questions and note the question IDs. Then you create a survey and list the question IDs. -＠node Free Software Directories, Copying, Surveys, Top +＠node Free Software Directories, , Surveys, Top ＠chapter Free Software Directories ＠cindex FSF/UNESCO Free Software Directory ＠＠ -3340,404 +3930,8 ＠＠＠c * Public Forums:: ＠c * Anonymous FTP Space:: ＠c ＠end menu - -＠node Copying, Index, Free Software Directories, Top -＠appendix GNU GENERAL PUBLIC LICENSE -＠center Version 2, June 1991 - -＠display -Copyright ＠copyright{} 1989, 1991 Free Software Foundation, Inc. -59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - -Everyone is permitted to copy and distribute verbatim copies -of this license document, but changing it is not allowed. -＠end display - -＠appendixsec Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software---to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - -＠iftex -＠appendixsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION -＠end iftex -＠ifinfo -＠center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION -＠end ifinfo - -＠enumerate 0 -＠item -This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The ``Program,'' below, -refers to any such program or work, and a ``work based on the Program'' -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term ``modification.'') Each licensee is addressed as ``you.'' - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - -＠item -You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - -＠item -You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - -＠enumerate a -＠item -You must cause the modified files to carry prominent notices -stating that you changed the files and the date of any change. - -＠item -You must cause any work that you distribute or publish, that in -whole or in part contains or is derived from the Program or any -part thereof, to be licensed as a whole at no charge to all third -parties under the terms of this License. - -＠item -If the modified program normally reads commands interactively -when run, you must cause it, when started running for such -interactive use in the most ordinary way, to print or display an -announcement including an appropriate copyright notice and a -notice that there is no warranty (or else, saying that you provide -a warranty) and that users may redistribute the program under -these conditions, and telling the user how to view a copy of this -License. (Exception: if the Program itself is interactive but -does not normally print such an announcement, your work based on -the Program is not required to print an announcement.) -＠end enumerate - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - -＠item -You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - -＠enumerate a -＠item -Accompany it with the complete corresponding machine-readable -source code, which must be distributed under the terms of Sections -1 and 2 above on a medium customarily used for software interchange; or, - -＠item -Accompany it with a written offer, valid for at least three -years, to give any third party, for a charge no more than your -cost of physically performing source distribution, a complete -machine-readable copy of the corresponding source code, to be -distributed under the terms of Sections 1 and 2 above on a medium -customarily used for software interchange; or, - -＠item -Accompany it with the information you received as to the offer -to distribute corresponding source code. (This alternative is -allowed only for noncommercial distribution and only if you -received the program in object code or executable form with such -an offer, in accord with Subsection b above.) -＠end enumerate - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - -＠item -You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - -＠item -You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - -＠item -Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - -＠item -If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - -＠item -If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - -＠item -The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and ``any -later version,'' you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - -＠item -If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - -＠iftex -＠heading NO WARRANTY -＠end iftex -＠ifinfo -＠center NO WARRANTY -＠end ifinfo - -＠item -BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW＠. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE＠. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU＠. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - -＠item -IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. -＠end enumerate - -＠iftex -＠heading END OF TERMS AND CONDITIONS -＠end iftex -＠ifinfo -＠center END OF TERMS AND CONDITIONS -＠end ifinfo - -＠page -＠appendixsec How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest -possible use to the public, the best way to achieve this is to make it -free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest -to attach them to the start of each source file to most effectively -convey the exclusion of warranty; and each file should have at least -the ``copyright'' line and a pointer to where the full notice is found. - -＠smallexample -＠var{one line to give the program's name and an idea of what it does.} -Copyright (C) 19＠var{yy} ＠var{name of author} - -This program is free software; you can redistribute it and/or -modify it under the terms of the GNU General Public License -as published by the Free Software Foundation; either version 2 -of the License, or (at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE＠. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License along -with this program; if not, write to the Free Software Foundation, Inc., -59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. -＠end smallexample - -Also add information on how to contact you by electronic and paper mail. - -If the program is interactive, make it output a short notice like this -when it starts in an interactive mode: - -＠smallexample -Gnomovision version 69, Copyright (C) 20＠var{yy} ＠var{name of author} -Gnomovision comes with ABSOLUTELY NO WARRANTY; for details -type `show w'. This is free software, and you are welcome -to redistribute it under certain conditions; type `show c' -for details. -＠end smallexample - -The hypothetical commands ＠samp{show w} and ＠samp{show c} should show -the appropriate parts of the General Public License. Of course, the -commands you use may be called something other than ＠samp{show w} and -＠samp{show c}; they could even be mouse-clicks or menu items---whatever -suits your program. - -You should also get your employer (if you work as a programmer) or your -school, if any, to sign a ``copyright disclaimer'' for the program, if -necessary. Here is a sample; alter the names: - -＠smallexample -＠group -Yoyodyne, Inc., hereby disclaims all copyright -interest in the program `Gnomovision' -(which makes passes at compilers) written -by James Hacker. - -＠var{signature of Ty Coon}, 1 April 1989 -Ty Coon, President of Vice -＠end group -＠end smallexample - -This General Public License does not permit incorporating your program into -proprietary programs. If your program is a subroutine library, you may -consider it more useful to permit linking proprietary applications with the -library. If this is what you want to do, use the GNU Library General -Public License instead of this License. -＠node Index, , Copying, Top +＠node Index, , Nodes borrowed from other projects not adapted to XEmacs, Top ＠unnumbered Index ＠printindex cp _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

10 participants
10 comments

[AC21.5] Improve resizing of echo area 7 years, 5 months

Stephen J. Turnbull

APPROVE COMMIT 21.5 This patch causes Adrian's patch of 2006-10-28 for resizing the echo area to respect resize-minibuffer-mode. I'm of two minds about that, but I think that these two facilities are so closely related that we should try to keep their behavior as similar as possible. Also, I've experienced a bit of annoyance (things like debug backtraces will max out the echo area, which won't return to normal size until you force a message), so I think it's important to have a way to turn it off. It also respects the defcustoms of resize-minibuffer-mode. I added a new defcustom, `resize-minibuffer-idle-height', which is the target height of the echo area/minibuffer window when it is idle. (Only partially unimplemented.) As with resize-minibuffer, there are two modes: adjust height exactly, and reduce only when too big. I'm reverting behavior to that of 21.5.27: those who do not enable resize-minibuffer mode won't get echo area resizing any more. If nobody objects, I'll enable resize-minibuffer-mode by default later. (This takes a little work since it was designed as a minor mode.) I've also added a function to use as an undisplay-echo-area-function, which reverts the echo area/minibuffer to small size when it's idle. Unfortunately, it seems really easy to get an uninterruptible infloop if that function signals or produces any output. Therefore it is disabled by default, and has lots of warnings in the code and documentation until I have more experience with it. Feel free to try it ... I *think* I've got all angles (except deliberate sabotage :-) covered in the current version. lisp/ChangeLog addition: 2007-04-30 Stephen J. Turnbull <stephen(a)xemacs.org> * simple.el (raw-append-message): Improve resizing of echo area --- now obeys resize-minibuffer conventions. * resize-minibuffer.el (resize-minibuffer-idle-height): New. * simple.el (undisplay-echo-area-resize-window-allowed): New. * simple.el (undisplay-echo-area-resize-window): New. Add function to shrink echo area when idle. (incomplete) * simple.el (log-message-ignore-regexps): * simple.el (undisplay-echo-area-function): * simple.el (clear-message): * simple.el (append-message): * simple.el (display-message): Improve docstrings. 21.5 source patch: Diff command: cvs -q diff -u Index: lisp/resize-minibuffer.el =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/resize-minibuffer.el,v retrieving revision 1.4 diff -u -u -r1.4 resize-minibuffer.el --- lisp/resize-minibuffer.el 15 Mar 2002 07:43:21 -0000 1.4 +++ lisp/resize-minibuffer.el 30 Apr 2007 13:48:01 -0000 ＠＠ -88,6 +88,15 ＠＠ :type '(choice (const nil) integer) :group 'resize-minibuffer) +;; #### Yeah, I know. The relation between the echo area and the +;; minibuffer needs rethinking. It's not really possible to unify them at +;; present. -- sjt +(defcustom resize-minibuffer-idle-height nil + "When minibuffer is idle, crop its window to this height. +Must be a positive integer or nil. nil indicates no limit. +Effective only when `undisplay-echo-area-function' respects it. One such +function is `undisplay-echo-area-resize-window'.") + (defcustom resize-minibuffer-window-exactly t "*If non-`nil', make minibuffer exactly the size needed to display all its contents. Otherwise, the minibuffer window can temporarily increase in size but Index: lisp/simple.el =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/simple.el,v retrieving revision 1.58 diff -u -u -r1.58 simple.el --- lisp/simple.el 29 Dec 2006 18:09:43 -0000 1.58 +++ lisp/simple.el 30 Apr 2007 13:48:03 -0000 ＠＠ -4127,9 +4127,10 ＠＠ "List of regular expressions matching messages which shouldn't be logged. See `log-message'. -Ideally, packages which generate messages which might need to be ignored -should label them with 'progress, 'prompt, or 'no-log, so they can be -filtered by the log-message-ignore-labels." +Adding entries to this list slows down messaging significantly. Wherever +possible, messages which might need to be ignored should be labeled with +'progress, 'prompt, or 'no-log, so they can be filtered by +log-message-ignore-labels." :type '(repeat regexp) :group 'log-message) ＠＠ -4146,9 +4147,39 ＠＠ :group 'log-message) (defcustom undisplay-echo-area-function nil - "The function to call to undisplay echo area buffer." -:type 'function -:group 'log-message) + "The function to call to undisplay echo area buffer. +WARNING: any problem with your function is likely to result in an +uninterruptible infinite loop. Use of custom functions is therefore not +recommended." +:type '(choice (const nil) + function) +:group 'log-message) + +(defvar undisplay-echo-area-resize-window-allowed t + "INTERNAL USE ONLY. +Guards against `undisplay-echo-area-resize-window' infloops. +Touch this at your own risk.") + +(defun undisplay-echo-area-resize-window () + "Resize idle echo area window to `resize-minibuffer-idle-height'. +If either `resize-minibuffer-idle-height' or `resize-minibuffer-mode' is nil, +does nothing. If `resize-minibuffer-window-exactly' is non-nil, always resize +to this height exactly, otherwise if current height is no larger than this, +leave it as is." + (when (default-value undisplay-echo-area-resize-window-allowed) + (setq-default undisplay-echo-area-resize-window-allowed nil) + (let* ((mbw (minibuffer-window)) + (height (window-height mbw))) + (with-boundp '(resize-minibuffer-idle-height) + (and resize-minibuffer-mode + (numberp resize-minibuffer-idle-height) + (> resize-minibuffer-idle-height 0) + (unless (if resize-minibuffer-window-exactly + (= resize-minibuffer-idle-height height) + (<= resize-minibuffer-idle-height height)) + (enlarge-window (- resize-minibuffer-idle-height height) + nil mbw)))) + (setq-default undisplay-echo-area-resize-window-allowed t)))) ;;Subsumed by view-lossage ;; Not really, I'm adding it back by popular demand. -slb ＠＠ -4235,6 +4266,9 ＠＠ is nil, it will be displayed. The string which remains in the echo area will be returned, or nil if the message-stack is now empty. If LABEL is nil, the entire message-stack is cleared. +STDOUT-P is ignored, except for output to stream devices. For streams, +STDOUT-P non-nil directs output to stdout, otherwise to stderr. \(This is +used only in case of restoring an earlier message from the stack.) Unless you need the return value or you need to specify a label, you should just use (message nil)." ＠＠ -4293,13 +4327,19 ＠＠ (setq log (cdr log))))) (defun append-message (label message &optional frame stdout-p) + "Add MESSAGE to the message-stack, or append it to the existing text. +LABEL is the class of the message. If it is the same as that of the top of +the message stack, MESSAGE is appended to the existing message, otherwise +it is pushed on the stack. +FRAME determines the minibuffer window to send the message to. +STDOUT-P is ignored, except for output to stream devices. For streams, +STDOUT-P non-nil directs output to stdout, otherwise to stderr." (or frame (setq frame (selected-frame))) ;; If outputting to the terminal, make sure output from anyone else clears ;; the left side first, but don't do it ourselves, otherwise we won't be ;; able to append to an existing message. (if (eq 'stream (frame-type frame)) (set-device-clear-left-side (frame-device frame) nil)) - ;; Add a new entry to the message-stack, or modify an existing one (let ((top (car message-stack))) (if (eq label (car top)) (setcdr top (concat (cdr top) message)) ＠＠ -4308,31 +4348,60 ＠＠ (if (eq 'stream (frame-type frame)) (set-device-clear-left-side (frame-device frame) t))) -;; Really append the message to the echo area. no fiddling with +;; Really append the message to the echo area. No fiddling with ;; message-stack. (defun raw-append-message (message &optional frame stdout-p) (unless (equal message "") (let ((inhibit-read-only t)) (with-current-buffer " *Echo Area*" (insert-string message) - ;; (fill-region (point-min) (point-max)) - (enlarge-window - (- - (ceiling - (/ (- (point-max) (point-min)) - (- (window-width (minibuffer-window)) 1.0))) - (window-height (minibuffer-window))) - nil (minibuffer-window))) - ;; Conditionalizing on the device type in this way is not that clean, - ;; but neither is having a device method, as I originally implemented - ;; it: all non-stream devices behave in the same way. Perhaps - ;; the cleanest way is to make the concept of a "redisplayable" - ;; device, which stream devices are not. Look into this more if - ;; we ever create another non-redisplayable device type (e.g. - ;; processes? printers?). + ;; #### This needs to be conditional; cf discussion by Stefan Monnier + ;; et al on emacs-devel in mid-to-late April 2007. One problem is + ;; there is no known good way to guess whether the user wants to have + ;; the echo area height changed on him asynchronously, especially + ;; after message display. + ;; There is also a problem where Lisp backtraces get sent to the echo + ;; area, thus maxing out the window height. Unfortunately, it doesn't + ;; return to a reasonable size very quickly. + ;; It is not clear that echo area and minibuffer behavior should be + ;; linked as we do here. It's OK for now; at least this obeys the + ;; minibuffer resizing conventions which seem a pretty good guess + ;; at user preference. + (when resize-minibuffer-mode + ;; #### interesting idea, unbearable implementation + ;; (fill-region (point-min) (point-max)) + ;; + ;; #### We'd like to be able to do something like + ;; + ;; (save-window-excursion + ;; (select-window (minibuffer-window frame)) + ;; (resize-minibuffer-window)))) + ;; + ;; but that can't work, because the echo area isn't a real window! + ;; We should fix that, but this is an approximation, duplicating the + ;; resize-minibuffer code. + (let* ((mbw (minibuffer-window frame)) + (height (window-height mbw)) + (lines (ceiling (/ (- (point-max) (point-min)) + (- (window-width mbw) 1.0))))) + (and (numberp resize-minibuffer-window-max-height) + (> resize-minibuffer-window-max-height 0) + (setq lines (min lines + resize-minibuffer-window-max-height))) + (or (if resize-minibuffer-window-exactly + (= lines height) + (<= lines height)) + (enlarge-window (- lines height) nil mbw))))) ;; Don't redisplay the echo area if we are executing a macro. (if (not executing-kbd-macro) + ;; Conditionalizing on the device type in this way isn't clean, but + ;; neither is having a device method, as I originally implemented + ;; it: all non-stream devices behave in the same way. Perhaps + ;; the cleanest way is to make the concept of a "redisplayable" + ;; device, which stream devices are not. Look into this more if + ;; we ever create another non-redisplayable device type (e.g. + ;; processes? printers?). (if (eq 'stream (frame-type frame)) (send-string-to-terminal message stdout-p (frame-device frame)) (funcall redisplay-echo-area-function)))))) ＠＠ -4341,6 +4410,8 ＠＠ "Print a one-line message at the bottom of the frame. First argument LABEL is an identifier for this message. MESSAGE is the string to display. Use `clear-message' to remove a labelled message. +STDOUT-P is ignored, except for output to stream devices. For streams, +STDOUT-P non-nil directs output to stdout, otherwise to stderr. Here are some standard labels (those marked with `*' are not logged by default--see the `log-message-ignore-labels' variable): ---------------- end of patch ---------------- _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
1 comments

[PATCH] Update man page for init file, one nroff format error 17 years, 2 months

Shyamal Prasad

etc/ChangeLog addition: 2004-12-03 Shyamal Prasad <shyamal(a)member.fsf.org> * xemacs.1: Now describe $HOME/.xemacs/init.el as the preferred init file. Fixed excessive space insertion in the description of the '-vanilla' option XEmacs source patch: Diff command: cvs -q diff -u Files affected: etc/xemacs.1 Index: etc/xemacs.1 =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/etc/xemacs.1,v retrieving revision 1.13 diff -u -r1.13 xemacs.1 --- etc/xemacs.1 2001/04/12 18:20:52 1.13 +++ etc/xemacs.1 2004/12/04 01:33:45 ＠＠ -147,12 +147,7 ＠＠ .TP .B \-vanilla Load no extra files at startup. Equivalent to the combination of -.B \-q -, -.B \-no-site-file -, and -.B \-no-early-packages -\. +.BR \-q ", " \-no-site-file ", and " \-no-early-packages . .TP .BI \-u " user, " \-user " user" Load ＠＠ -628,7 +623,8 ＠＠ META-left Make a rectangular selection. .SH FILES Lisp code is read at startup from the user's init file, -\fB$HOME/.emacs\fP. +\fB$HOME/.xemacs/init.el\fP. If this file does not exist then +\fB$HOME/.emacs\fP will be read if it is present. /usr/local/info - files for the Info documentation browser (a subsystem of

2 participants
1 comments

[PATCH] Synch up format-time-string % specifiers with Emacs 21.3.1 17 years, 2 months

Shyamal Prasad

This patch adds % specifiers to format-time-string that are missing in XEmacs but supported by Emacs 21.3.1 src/ChangeLog addition: 2004-12-08 Shyamal Prasad <shyamal(a)member.fsf.org> * editfns.c: * editfns.c (Fformat_time_string): Added documentation for %z, %g, %G and %V specifiers. This synchs up the set of % specifiers for format-time-string with Emacs 21.3.1. Make copy of static buffer returned by localtime(). * strftime.c: * strftime.c (strftime): Implemented %z, %g, %G and %V in a style similar to existing implementation of other specifiers. XEmacs source patch: Diff command: cvs -q diff -u Files affected: src/strftime.c src/editfns.c Index: src/editfns.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/editfns.c,v retrieving revision 1.51 diff -u -r1.51 editfns.c --- src/editfns.c 2004/12/06 03:52:03 1.51 +++ src/editfns.c 2004/12/09 02:40:17 ＠＠ -1015,6 +1015,8 ＠＠ %d is replaced by the day of month, zero-padded. %D is a synonym for "%m/%d/%y". %e is replaced by the day of month, blank-padded. +%G is replaced by the year containing the ISO 8601 week +%g is replaced by the year of the ISO 8601 week within the century (00-99) %h is a synonym for "%b". %H is replaced by the hour (00-23). %I is replaced by the hour (00-12). ＠＠ -1033,12 +1035,14 ＠＠ %t is a synonym for "\\t". %T is a synonym for "%H:%M:%S". %U is replaced by the week of the year (00-53), first day of week is Sunday. +%V is replaced by the ISO 8601 week number %w is replaced by the day of week (0-6), Sunday is day 0. %W is replaced by the week of the year (00-53), first day of week is Monday. %x is a locale-specific synonym, which defaults to "%D" in the C locale. %X is a locale-specific synonym, which defaults to "%T" in the C locale. %y is replaced by the year without century (00-99). %Y is replaced by the year with century. +%z is replaced by the time zone as a numeric offset (e.g +0530, -0800 etc.) %Z is replaced by the time zone abbreviation. The number of options reflects the `strftime' function. ＠＠ -1063,13 +1067,15 ＠＠ { Extbyte *buf = alloca_extbytes (size); Extbyte *formext; + /* make a copy of the static buffer returned by localtime() */ + struct tm tm = * localtime(&value); + *buf = 1; /* !!#### this use of external here is not totally safe, and potentially data lossy. */ LISP_STRING_TO_EXTERNAL (format_string, formext, Qnative); - if (emacs_strftime (buf, size, formext, - localtime (&value)) + if (emacs_strftime (buf, size, formext, &tm) || !*buf) return build_ext_string (buf, Qnative); /* If buffer was too small, make it bigger. */ Index: src/strftime.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/strftime.c,v retrieving revision 1.6 diff -u -r1.6 strftime.c --- src/strftime.c 2002/03/29 04:48:37 1.6 +++ src/strftime.c 2004/12/09 02:40:18 ＠＠ -58,6 +58,7 ＠＠ %S second (00..61) %T time, 24-hour (hh:mm:ss) %X locale's time representation (%H:%M:%S) + %z time zone offset (e.g. +0530, -0800 etc) %Z time zone (EDT), or nothing if no time zone is determinable Date fields: ＠＠ -70,10 +71,13 ＠＠ %d day of month (01..31) %e day of month ( 1..31) %D date (mm/dd/yy) + %G year corresponding to the ISO 8601 week + %g Year of the ISO 8601 week within century (00 - 99) %h same as %b %j day of year (001..366) %m month (01..12) %U week number of year with Sunday as first day of week (00..53) + %V ISO 8601 week number (first week is the earliest one with Thu) %w day of week (0..6) %W week number of year with Monday as first day of week (00..53) %x locale's date representation (mm/dd/yy) ＠＠ -235,6 +239,30 ＠＠ return dl <= 0 ? 0 : dl / 7 + (dl % 7 != 0); } +#ifndef __isleap +/* Nonzero if YEAR is a leap year (every 4 years, + except every 100th isn't, and every 400th is). */ +# define __isleap(year) \ + ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0)) +#endif + +/* The number of days from the first day of the first ISO week of this + year to the year day YDAY with week day WDAY. ISO weeks start on + Monday; the first ISO week has the year's first Thursday. YDAY may + be as small as YDAY_MINIMUM. */ +#define ISO_WEEK_START_WDAY 1 /* Monday */ +#define ISO_WEEK1_WDAY 4 /* Thursday */ +#define YDAY_MINIMUM (-366) +static int +iso_week_days (int yday, int wday) +{ + /* Add enough to the first operand of % to make it nonnegative. */ + int big_enough_multiple_of_7 = (-YDAY_MINIMUM / 7 + 2) * 7; + return (yday + - (yday - wday + ISO_WEEK1_WDAY + big_enough_multiple_of_7) % 7 + + ISO_WEEK1_WDAY - ISO_WEEK_START_WDAY); +} + #if !defined(HAVE_TM_ZONE) && !defined(HAVE_TZNAME) char *zone_name (const struct tm *tp); char * ＠＠ -362,10 +390,125 ＠＠ length += strftime (&string[length], max - length, "%H:%M:%S", tm); break; + + case 'V': + case 'g': + case 'G': + { + int year = tm->tm_year + 1900; + int days = iso_week_days (tm->tm_yday, tm->tm_wday); + + if (days < 0) + { + /* This ISO week belongs to the previous year. */ + year--; + days = + iso_week_days (tm->tm_yday + (365 + __isleap (year)), + tm->tm_wday); + } + else + { + int d = + iso_week_days (tm->tm_yday - (365 + __isleap (year)), + tm->tm_wday); + if (0 <= d) + { + /* This ISO week belongs to the next year. */ + year++; + days = d; + } + } + + switch (*format) + { + /* + #### FIXME + We really can't assume 1000 <= year <= 9999 + once time_t gets beyond 32 bits, but it's true + of the rest of the code here so get with the + program + */ + case 'g': + length += + add_num2 (&string[length], year % 100, + max - length, pad); + break; + + case 'G': + add_char (year / 1000 + '0'); + length += add_num3 (&string[length], year % 1000, + max - length, zero); + break; + + default: + length += + add_num2 (&string[length], days / 7 + 1, + max - length, pad); + break; + } + } + break; case 'X': length += strftime (&string[length], max - length, "%H:%M:%S", tm); break; + case 'z': + { + /* + #### FIXME: could use tm->tm_gmtoff if present. Since + the other code in xemacs does not do so we follow the + leaders (and don't add a autoconf macro to detect + its presence). + */ + long int offset; + long int minutes; + struct tm lt, *ut; + time_t utc; + + lt = *tm; + utc = mktime(&lt); + ut = gmtime(&utc); + /* assume that tm is valid so the others will be too! */ + assert( utc != (time_t) -1 && ut != NULL ); + + /* tm diff code below is based on mktime.c, glibc 2.3.2 */ + { + int lt4, ut4, lt100, ut100, lt400, ut400; + int intervening_leap_days, years, days; + + lt4 = (lt.tm_year >> 2) + (1900 >> 2) - + ! (lt.tm_year & 3); + ut4 = (ut->tm_year >> 2) + (1900 >> 2) - + ! (ut->tm_year & 3); + lt100 = lt4 / 25 - (lt4 % 25 < 0); + ut100 = ut4 / 25 - (ut4 % 25 < 0); + lt400 = lt100 >> 2; + ut400 = ut100 >> 2; + intervening_leap_days = + (lt4 - ut4) - (lt100 - ut100) + (lt400 - ut400); + years = lt.tm_year - ut->tm_year; + days = (365 * years + intervening_leap_days + + (lt.tm_yday - ut->tm_yday)); + offset = (60 * (60 * (24 * days + (lt.tm_hour - ut->tm_hour)) + + (lt.tm_min - ut->tm_min)) + + (lt.tm_sec - ut->tm_sec)); + } + + minutes = offset / ( offset < 0 ? -60 : 60 ); + + add_char ((offset < 0 ? '-' : '+')); + + if ( minutes / 600 != 0 ) + add_char (minutes / 600 + '0'); + else if ( pad != none ) + add_char ((pad == zero ? '0' : ' ')); + + length += + add_num3 (&string[length], + ((minutes / 60 ) % 10) * 100 + (minutes % 60), + max - length, pad); + break; + } case 'Z': #ifdef HAVE_TM_ZONE length += add_str (&string[length], tm->tm_zone, max - length);

2 participants
1 comments

[PATCH] Eliminate a crash when profiling. 17 years, 3 months

Aidan Kehoe

This follows discussion with Adrian, and I’ll commit it later today. src/ChangeLog addition: 2006-11-26 Aidan Kehoe <kehoea(a)parhasard.net> * eval.c (Fcommand_execute): * eval.c (Feval): * eval.c (Ffuncall): Use the PROFILE_DECLARE macro instead of declaring `struct backtrace backtrace' by hand. * profile.h: * profile.h (PROFILE_EXIT_FUNCTION): * profile.h (PROFILE_ENTER_FUNCTION): Check do_backtrace before passing the backtrace structure to profile_record_about_to_call, profile_record_just_called. XEmacs Trunk source patch: Diff command: cvs -q diff -Nu Files affected: src/profile.h =================================================================== RCS src/eval.c =================================================================== RCS Index: src/eval.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/eval.c,v retrieving revision 1.93 diff -u -u -r1.93 eval.c --- src/eval.c 2006/08/29 14:10:54 1.93 +++ src/eval.c 2006/11/26 10:05:42 ＠＠ -3078,7 +3078,7 ＠＠ /* This function can GC */ Lisp_Object prefixarg; Lisp_Object final = cmd; - struct backtrace backtrace; + PROFILE_DECLARE(); struct console *con = XCONSOLE (Vselected_console); prefixarg = con->prefix_arg; ＠＠ -3511,7 +3511,7 ＠＠ /* This function can GC */ Lisp_Object fun, val, original_fun, original_args; int nargs; - struct backtrace backtrace; + PROFILE_DECLARE(); #ifdef ERROR_CHECK_TRAPPING_PROBLEMS check_proper_critical_section_lisp_protection (); ＠＠ -3806,7 +3806,7 ＠＠ /* This function can GC */ Lisp_Object fun; Lisp_Object val; - struct backtrace backtrace; + PROFILE_DECLARE(); int fun_nargs = nargs - 1; Lisp_Object *fun_args = args + 1; Index: src/profile.h =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/profile.h,v retrieving revision 1.4 diff -u -u -r1.4 profile.h --- src/profile.h 2006/03/14 19:31:43 1.4 +++ src/profile.h 2006/11/26 10:05:42 ＠＠ -47,11 +47,18 ＠＠ This ensures correct behavior (e.g. we never modify the profiling info when profiling is not active) because we seed and reap all functions currently on the stack when starting and stopping. See - `start-profiling'. */ + `start-profiling'. + + We check do_backtrace to make sure that the backtrace structure is + initialised. If it isn't, we can enter a function with profiling turned + off, and exit it with it turned on, with the consequence that an + unitialised backtrace structure is passed to + profile_record_just_called. Since do_backtrace is function-local (apart + from in the garbage collector) this avoids that. */ #define PROFILE_ENTER_FUNCTION() \ do \ { \ - if (profiling_active) \ + if (profiling_active && do_backtrace) \ profile_record_about_to_call (&backtrace); \ } \ while (0) ＠＠ -59,7 +66,7 ＠＠ #define PROFILE_EXIT_FUNCTION() \ do \ { \ - if (profiling_active) \ + if (profiling_active && do_backtrace) \ profile_record_just_called (&backtrace); \ } \ while (0) -- Santa Maradona, priez pour moi! _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

1 participants
1 comments

[C] [R21.4] xemacs-21.5-clean: Sync font-lock-add-keywords and font-lock-remove-keywords from GNU Emacs 17 years, 4 months

Adrian Aichner

Hi Vin, here is the patch again. I was able to find it quickly by use of M-x gnus-article-refer-article on the message-id I quoted in my followup mail. Let me know if this works for you. Best regards! Adrian COMMIT RECOMMEND 21.4 Many unbundled lisp libraries don't work out-of-the-box due to these missing functions. I've had these locally added to my 21.4 build for years. It's time we close this compatibility gap. oddmuse.el works out of the box for me with this patch. Adrian xemacs-21.5-clean ChangeLog patch: Diff command: cvs -q diff -U 0 Files affected: lisp/ChangeLog Index: lisp/ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/ChangeLog,v retrieving revision 1.766 diff -u -U0 -r1.766 ChangeLog --- lisp/ChangeLog 1 Nov 2006 21:35:35 -0000 1.766 +++ lisp/ChangeLog 1 Nov 2006 23:13:52 -0000 ＠＠ -0,0 +1,10 ＠＠ +2006-11-02 Adrian Aichner <adrian(a)xemacs.org> + + * font-lock.el: Sync font-lock-add-keywords and + font-lock-remove-keywords from GNU Emacs. + * font-lock.el (font-lock-keywords-alist): New. + * font-lock.el (font-lock-removed-keywords-alist): New. + * font-lock.el (font-lock-add-keywords): New. + * font-lock.el (font-lock-update-removed-keyword-alist): New. + * font-lock.el (font-lock-remove-keywords): New. + xemacs-21.5-clean source patch: Diff command: cvs -f -z3 -q diff -u -w -N Files affected: lisp/font-lock.el Index: lisp/font-lock.el =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/font-lock.el,v retrieving revision 1.30 diff -u -w -r1.30 font-lock.el --- lisp/font-lock.el 4 Feb 2006 01:56:06 -0000 1.30 +++ lisp/font-lock.el 1 Nov 2006 23:10:11 -0000 ＠＠ -449,6 +449,32 ＠＠ Be very careful composing regexps for this list; the wrong pattern can dramatically slow things down! ") + +(defvar font-lock-keywords-alist nil + "Alist of additional `font-lock-keywords' elements for major modes. + +Each element has the form (MODE KEYWORDS . HOW). +`font-lock-set-defaults' adds the elements in the list KEYWORDS to +`font-lock-keywords' when Font Lock is turned on in major mode MODE. + +If HOW is nil, KEYWORDS are added at the beginning of +`font-lock-keywords'. If it is `set', they are used to replace the +value of `font-lock-keywords'. If HOW is any other non-nil value, +they are added at the end. + +This is normally set via `font-lock-add-keywords' and +`font-lock-remove-keywords'.") + +(defvar font-lock-removed-keywords-alist nil + "Alist of `font-lock-keywords' elements to be removed for major modes. + +Each element has the form (MODE . KEYWORDS). `font-lock-set-defaults' +removes the elements in the list KEYWORDS from `font-lock-keywords' +when Font Lock is turned on in major mode MODE. + +This is normally set via `font-lock-add-keywords' and +`font-lock-remove-keywords'.") + ;;;###autoload (make-variable-buffer-local 'font-lock-keywords) ＠＠ -868,6 +894,188 ＠＠ (setq font-lock-maximum-decoration t) (font-lock-recompute-variables))) +(defun font-lock-add-keywords (mode keywords &optional how) + "Add highlighting KEYWORDS for MODE. + +MODE should be a symbol, the major mode command name, such as `c-mode' +or nil. If nil, highlighting keywords are added for the current buffer. +KEYWORDS should be a list; see the variable `font-lock-keywords'. +By default they are added at the beginning of the current highlighting list. +If optional argument HOW is `set', they are used to replace the current +highlighting list. If HOW is any other non-nil value, they are added at the +end of the current highlighting list. + +For example: + + (font-lock-add-keywords 'c-mode + '((\"\\\\\\=<\\\$FIXME\\\$:\" 1 font-lock-warning-face prepend) + (\"\\\\\\=<\\\$and\\\\|or\\\\|not\\\$\\\\\\=>\" . font-lock-keyword-face))) + +adds two fontification patterns for C mode, to fontify `FIXME:' words, even in +comments, and to fontify `and', `or' and `not' words as keywords. + +The above procedure will only add the keywords for C mode, not +for modes derived from C mode. To add them for derived modes too, +pass nil for MODE and add the call to c-mode-hook. + +For example: + + (add-hook 'c-mode-hook + (lambda () + (font-lock-add-keywords nil + '((\"\\\\\\=<\\\$FIXME\\\$:\" 1 font-lock-warning-face prepend) + (\"\\\\\\=<\\\$and\\\\|or\\\\|not\\\$\\\\\\=>\" . + font-lock-keyword-face))))) + +The above procedure may fail to add keywords to derived modes if +some involved major mode does not follow the standard conventions. +File a bug report if this happens, so the major mode can be corrected. + +Note that some modes have specialized support for additional patterns, e.g., +see the variables `c-font-lock-extra-types', `c++-font-lock-extra-types', +`objc-font-lock-extra-types' and `java-font-lock-extra-types'." + (cond (mode + ;; If MODE is non-nil, add the KEYWORDS and HOW spec to + ;; `font-lock-keywords-alist' so `font-lock-set-defaults' uses them. + (let ((spec (cons keywords how)) cell) + (if (setq cell (assq mode font-lock-keywords-alist)) + (if (eq how 'set) + (setcdr cell (list spec)) + (setcdr cell (append (cdr cell) (list spec)))) + (push (list mode spec) font-lock-keywords-alist))) + ;; Make sure that `font-lock-removed-keywords-alist' does not + ;; contain the new keywords. + (font-lock-update-removed-keyword-alist mode keywords how)) + (t + ;; Otherwise set or add the keywords now. + ;; This is a no-op if it has been done already in this buffer + ;; for the correct major mode. + (font-lock-set-defaults) + (let ((was-compiled (eq (car font-lock-keywords) t))) + ;; Bring back the user-level (uncompiled) keywords. + (if was-compiled + (setq font-lock-keywords (cadr font-lock-keywords))) + ;; Now modify or replace them. + (if (eq how 'set) + (setq font-lock-keywords keywords) + (font-lock-remove-keywords nil keywords) ;to avoid duplicates + (let ((old (if (eq (car-safe font-lock-keywords) t) + (cdr font-lock-keywords) + font-lock-keywords))) + (setq font-lock-keywords (if how + (append old keywords) + (append keywords old))))) + ;; If the keywords were compiled before, compile them again. + (if was-compiled + (setq font-lock-keywords + (font-lock-compile-keywords font-lock-keywords))))))) + +(defun font-lock-update-removed-keyword-alist (mode keywords how) + "Update `font-lock-removed-keywords-alist' when adding new KEYWORDS to MODE." + ;; When font-lock is enabled first all keywords in the list + ;; `font-lock-keywords-alist' are added, then all keywords in the + ;; list `font-lock-removed-keywords-alist' are removed. If a + ;; keyword was once added, removed, and then added again it must be + ;; removed from the removed-keywords list. Otherwise the second add + ;; will not take effect. + (let ((cell (assq mode font-lock-removed-keywords-alist))) + (if cell + (if (eq how 'set) + ;; A new set of keywords is defined. Forget all about + ;; our old keywords that should be removed. + (setq font-lock-removed-keywords-alist + (delq cell font-lock-removed-keywords-alist)) + ;; Delete all previously removed keywords. + (dolist (kword keywords) + (setcdr cell (delete kword (cdr cell)))) + ;; Delete the mode cell if empty. + (if (null (cdr cell)) + (setq font-lock-removed-keywords-alist + (delq cell font-lock-removed-keywords-alist))))))) + +;; Written by Anders Lindgren <andersl(a)andersl.com>. +;; +;; Case study: +;; (I) The keywords are removed from a major mode. +;; In this case the keyword could be local (i.e. added earlier by +;; `font-lock-add-keywords'), global, or both. +;; +;; (a) In the local case we remove the keywords from the variable +;; `font-lock-keywords-alist'. +;; +;; (b) The actual global keywords are not known at this time. +;; All keywords are added to `font-lock-removed-keywords-alist', +;; when font-lock is enabled those keywords are removed. +;; +;; Note that added keywords are taken out of the list of removed +;; keywords. This ensure correct operation when the same keyword +;; is added and removed several times. +;; +;; (II) The keywords are removed from the current buffer. +(defun font-lock-remove-keywords (mode keywords) + "Remove highlighting KEYWORDS for MODE. + +MODE should be a symbol, the major mode command name, such as `c-mode' +or nil. If nil, highlighting keywords are removed for the current buffer. + +To make the removal apply to modes derived from MODE as well, +pass nil for MODE and add the call to MODE-hook. This may fail +for some derived modes if some involved major mode does not +follow the standard conventions. File a bug report if this +happens, so the major mode can be corrected." + (cond (mode + ;; Remove one keyword at the time. + (dolist (keyword keywords) + (let ((top-cell (assq mode font-lock-keywords-alist))) + ;; If MODE is non-nil, remove the KEYWORD from + ;; `font-lock-keywords-alist'. + (when top-cell + (dolist (keyword-list-how-pair (cdr top-cell)) + ;; `keywords-list-how-pair' is a cons with a list of + ;; keywords in the car top-cell and the original how + ;; argument in the cdr top-cell. + (setcar keyword-list-how-pair + (delete keyword (car keyword-list-how-pair)))) + ;; Remove keyword list/how pair when the keyword list + ;; is empty and how doesn't specify `set'. (If it + ;; should be deleted then previously deleted keywords + ;; would appear again.) + (let ((cell top-cell)) + (while (cdr cell) + (if (and (null (car (car (cdr cell)))) + (not (eq (cdr (car (cdr cell))) 'set))) + (setcdr cell (cdr (cdr cell))) + (setq cell (cdr cell))))) + ;; Final cleanup, remove major mode cell if last keyword + ;; was deleted. + (if (null (cdr top-cell)) + (setq font-lock-keywords-alist + (delq top-cell font-lock-keywords-alist)))) + ;; Remember the keyword in case it is not local. + (let ((cell (assq mode font-lock-removed-keywords-alist))) + (if cell + (unless (member keyword (cdr cell)) + (nconc cell (list keyword))) + (push (cons mode (list keyword)) + font-lock-removed-keywords-alist)))))) + (t + ;; Otherwise remove it immediately. + (font-lock-set-defaults) + (let ((was-compiled (eq (car font-lock-keywords) t))) + ;; Bring back the user-level (uncompiled) keywords. + (if was-compiled + (setq font-lock-keywords (cadr font-lock-keywords))) + + ;; Edit them. + (setq font-lock-keywords (copy-sequence font-lock-keywords)) + (dolist (keyword keywords) + (setq font-lock-keywords + (delete keyword font-lock-keywords))) + + ;; If the keywords were compiled before, compile them again. + (if was-compiled + (setq font-lock-keywords + (font-lock-compile-keywords font-lock-keywords))))))) ;;;;;;;;;;;;;;;;;;;;;; actual code ;;;;;;;;;;;;;;;;;;;;;; -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/ _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
2 comments

[AC21.5R21.4] Workaround for LDAP API lag 17 years, 4 months

Stephen J. Turnbull

APPROVE COMMIT 21.5 RECOMMEND 21.4 Vin, AFAIK 21.5's LDAP support is the same as 21.4's so you'll probably run into the same problem. Index: modules/ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/modules/ChangeLog,v retrieving revision 1.62 diff -u -r1.62 ChangeLog --- modules/ChangeLog 21 May 2007 05:01:52 -0000 1.62 +++ modules/ChangeLog 22 Jun 2007 16:52:51 -0000 ＠＠ -0,0 +1,6 ＠＠ +2007-06-23 Stephen J. Turnbull <stephen(a)xemacs.org> + + * ldap/eldap.h: Declare that we use deprecated API. + Thanks to Mats Lidell <matsl(a)xemacs.org> for the report & patch: + <871wgnqunm.fsf(a)spencer.lidell.homelinux.net>. + Index: modules/ldap/eldap.h =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/modules/ldap/eldap.h,v retrieving revision 1.4 diff -u -r1.4 eldap.h --- modules/ldap/eldap.h 25 Oct 2005 08:32:42 -0000 1.4 +++ modules/ldap/eldap.h 22 Jun 2007 16:52:51 -0000 ＠＠ -22,6 +22,13 ＠＠ #define INCLUDED_eldap_h_ #include <lber.h> +/* #### NEEDS REWRITE! + Thanks to Mats Lidell <matsl(a)xemacs.org> for the report & patch: + <871wgnqunm.fsf(a)spencer.lidell.homelinux.net> + "See http://www.openldap.org/faq/data/cache/1278.html. + Temporary workaround would be use the deprecated interface. Long term + solution is a rewrite." */ +#define LDAP_DEPRECATED 1 #include <ldap.h> /* _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
1 comments

[AC21.5] Test for 'revert-buffer doesn't reset modiff' bug 17 years, 4 months

Stephen J. Turnbull

APPROVE COMMIT 21.5 RECOMMEND 21.4 Vin -- consider this for 21.4. I haven't tested in 21.4, will do so on request. Should work, though. The bug it's testing for was never in 21.4, but considering the delicacy of revert-buffer, it's imaginable that a regression could occur. This test fails on XEmacs 21.5 before Aidan's patch of yesterday, passes post patch. So I'm pretty sure the bug Ville and I reported is fixed. Thanks Aidan! Index: tests/ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/tests/ChangeLog,v retrieving revision 1.93 diff -u -r1.93 ChangeLog --- tests/ChangeLog 21 Jun 2007 13:39:32 -0000 1.93 +++ tests/ChangeLog 22 Jun 2007 16:31:15 -0000 ＠＠ -0,0 +1,4 ＠＠ +2007-06-22 Stephen J. Turnbull <stephen(a)xemacs.org> + + * automated/mule-tests.el (buffer-modified-p): Test after revert. + Index: tests/automated/mule-tests.el =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/tests/automated/mule-tests.el,v retrieving revision 1.18 diff -u -r1.18 mule-tests.el --- tests/automated/mule-tests.el 21 May 2007 08:11:37 -0000 1.18 +++ tests/automated/mule-tests.el 22 Jun 2007 16:31:15 -0000 ＠＠ -112,6 +112,35 ＠＠ ;; ochars[3] = 0x80 | input & ~(0xFFFFFFC0); (logior #x80 (logand code-point #x3f)))))))) +;;---------------------------------------------------------------- +;; Test that revert-buffer resets the modiff +;; Bug reported 2007-06-20 <200706201902.32191.scop(a)xemacs.org>. +;; Fixed 2007-06-22 <18043.2793.611745.734215(a)parhasard.net>. +;;---------------------------------------------------------------- + +;; #### need a temp file name but this will do for now +(let ((test-file-name (expand-file-name "~/test-revert-buffer-resets-modiff")) + revert-buffer-function + kill-buffer-hook) ; paranoia + (find-file test-file-name) + (erase-buffer) + (insert "a string\n") + (save-buffer 0) + (insert "more text\n") + (revert-buffer t t) + ;; Just "find-file" with autodetect coding didn't fail for me, but it does + ;; fail under test harness. Still we'll redo the test with an explicit + ;; coding system just in case. + (Assert (not (buffer-modified-p))) + (kill-buffer nil) + (when (find-coding-system 'utf-8) + (find-file test-file-name 'utf-8) + (insert "more text\n") + (revert-buffer t t) + (Assert (not (buffer-modified-p))) + (kill-buffer nil)) + (delete-file test-file-name)) + ;;----------------------------------------------------------------- ;; Test string modification functions that modify the length of a char. ;;----------------------------------------------------------------- _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
1 comments

[AC21.5R21.4] Sync etags to v. 17.33 17 years, 4 months

Stephen J. Turnbull

APPROVE COMMIT 21.5 RECOMMEND 21.4 Vin, to sync 21.4 you should just copy lib-src/etags.c and etc/ETAGS.README to the appropriate places. The latter is a permissions file that Francesco says is required by other authors' licenses. (Even though it's duplicated in the header of etags.c.) Basically untested; the patch looks OK, and I trust Francesco. This patch updates etags.c to pot revision 17.33, and syncs it 100% with upstream. Only the version information (which by Francesco's design is tied to the XEmacs release) will vary from a standalone build. At Francesco's request, I am reverting the change that Steve Youngs contributed to include the "pot revision" in the version output, but I have already changed the Makefile so that the +CVS-`date` string will appear for beta versions. That should be precise enough. (Vin: the Makefile change is irrelevant to 21.4, as the complete 21.4.x version is already included AFAIK. Only 21.5 CVS has the extra_name stuff.) Index: lib-src/ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lib-src/ChangeLog,v retrieving revision 1.219 diff -u -r1.219 ChangeLog --- lib-src/ChangeLog 24 May 2007 20:18:50 -0000 1.219 +++ lib-src/ChangeLog 29 May 2007 14:00:33 -0000 ＠＠ -0,0 +1,6 ＠＠ +2007-05-29 Stephen J. Turnbull <stephen(a)xemacs.org> + + * etags.c: Sync to pot_etags_version 17.26. + Reverts part of 2007-03-24 patch: no longer displays + pot_etags_version in usage message. + Index: lib-src/etags.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/lib-src/etags.c,v retrieving revision 1.39 diff -u -r1.39 etags.c --- lib-src/etags.c 21 May 2007 03:50:19 -0000 1.39 +++ lib-src/etags.c 29 May 2007 14:00:33 -0000 ＠＠ -80,7 +80,7 ＠＠ * configuration file containing regexp definitions for etags. */ -char pot_etags_version[] = "＠(#) pot revision number is 17.32"; +char pot_etags_version[] = "＠(#) pot revision number is 17.33"; #define TRUE 1 #define FALSE 0 ＠＠ -882,7 +882,7 ＠＠ # define EMACS_NAME "standalone" #endif #ifndef VERSION -# define VERSION "17.32" +# define VERSION "17.33" #endif static void print_version () ＠＠ -894,6 +894,10 ＠＠ exit (EXIT_SUCCESS); } +#ifndef PRINT_UNDOCUMENTED_OPTIONS_HELP +# define PRINT_UNDOCUMENTED_OPTIONS_HELP FALSE +#endif + static void print_help (argbuffer) argument *argbuffer; ＠＠ -976,6 +980,11 ＠＠ puts ("--no-globals\n\ Do not create tag entries for global variables in some\n\ languages. This makes the tags file smaller."); + + if (PRINT_UNDOCUMENTED_OPTIONS_HELP) + puts ("--no-line-directive\n\ + Ignore #line preprocessor directives in C and derived languages."); + if (CTAGS) puts ("--members\n\ Create tag entries for members of structures in some languages."); ＠＠ -996,13 +1005,17 ＠＠ MODS are optional one-letter modifiers: `i' means to ignore case,\n\ `m' means to allow multi-line matches, `s' implies `m' and\n\ causes dot to match any character, including newline."); + puts ("-R, --no-regex\n\ Don't create tags from regexps for the following files."); + puts ("-I, --ignore-indentation\n\ In C and C++ do not assume that a closing brace in the first\n\ column is the final brace of a function or structure definition."); + puts ("-o FILE, --output=FILE\n\ Write the tags to FILE."); + puts ("--parse-stdin=NAME\n\ Read from standard input and record tags as belonging to file NAME."); ＠＠ -1030,13 +1043,16 ＠＠ Print on the standard output an index of items intended for\n\ human consumption, similar to the output of vgrind. The index\n\ is sorted, and gives the page number of each item."); -# if PRINT_UNDOCUMENTED_OPTIONS_HELP - puts ("-w, --no-duplicates\n\ + + if (PRINT_UNDOCUMENTED_OPTIONS_HELP) + puts ("-w, --no-duplicates\n\ Do not create duplicate tag entries, for compatibility with\n\ traditional ctags."); - puts ("-w, --no-warn\n\ + + if (PRINT_UNDOCUMENTED_OPTIONS_HELP) + puts ("-w, --no-warn\n\ Suppress warning messages about duplicate tag entries."); -# endif /* PRINT_UNDOCUMENTED_OPTIONS_HELP */ + puts ("-x, --cxref\n\ Like --vgrind, but in the style of cxref, rather than vgrind.\n\ The output uses line numbers instead of page numbers, but\n\ _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
1 comments

[21.5] Fix crash in PNG initialiation [was: can't move cursor ...] 17 years, 4 months

Stephen J. Turnbull

21.5 Vin, this presumably affects 21.4 too. If you don't recall any related reports (probably only comes up if PNG lib that gets found at runtime differs from build-time link lib), I'll take my time.... Stephen J. Turnbull writes: > Does `configure --with-cppflags="-newflag $CPPFLAGS" ...' work in your > application? I think that having the `--with-whateverflags' options > override the corresponding environment variables is easier to > explain. It's certainly easier to code! [[ This is in my queue but I am working on other stuff. ]] > Ron Isaacson writes: > > #2 is definitely not our problem. :-) I think you need to ensure that > > png_err_stct.setjmp_buffer is set to a valid address BEFORE passing > > png_error_func as a parameter to anything. Otherwise, any runtime > > error from png_create_read_struct will get you into the same boat. OK, yes, this is really ugly. (But then, when isn't a setjmp/longjmp ugly?) I think the attached patch should fix the problem, but I don't yet have a test case and I've never patched code involving setjmp/ longjmp before so a second opinion would be welcome (and a third...). (I think the relevant test case for the original bug can be easily constructed by substituting "You're going down, sucker!" for PNG_LIBPNG_VER_STRING, but I haven't done that yet.) The first hunk is a little suspicious; for some reason png_destroy_read_struct() wants access to the pointer variable containing png_ptr, not just the pointer itself. The only reason I can think why it would want that is to NULL it, and I've done that, so passing &tmp to png_destroy_read_struct() should be OK, I think. The other changes are to first NULL out any unwind pointers to structures that are being destroyed in case the libpng code longjmps, then call libpng's finalizer; to move the setjmp call much earlier; and to stuff the unwind structure with the the necessary data as soon as we get it. I guess I have to assume that none of the libpng functions will implicitly call a finalizer.... I'll run with it a while before committing, but would really appreciate comments. 2007-02-17 Stephen J. Turnbull <stephen(a)xemacs.org> * glyphs-eimage.c (png_instantiate_unwind): Avoid recursion. (png_instantiate): Initialize setjmp_buffer early, and avoid recursive entry to error handler. diff --git a/src/glyphs-eimage.c b/src/glyphs-eimage.c index 49364ca..5184e2c 100644 --- a/src/glyphs-eimage.c +++ b/src/glyphs-eimage.c ＠＠ -849,7 +849,13 ＠＠ png_instantiate_unwind (Lisp_Object unwind_obj) free_opaque_ptr (unwind_obj); if (data->png_ptr) - png_destroy_read_struct (&(data->png_ptr), &(data->info_ptr), (png_infopp)NULL); + { + /* ensure we can't get here again */ + png_structp tmp = data->png_ptr; + data->png_ptr = NULL; + png_destroy_read_struct (&tmp, &(data->info_ptr), (png_infopp)NULL); + } + if (data->instream) retry_fclose (data->instream); ＠＠ -874,24 +880,36 ＠＠ png_instantiate (Lisp_Object image_instance, Lisp_Object instantiator, png_structp png_ptr; png_infop info_ptr; + xzero (unwind); + record_unwind_protect (png_instantiate_unwind, make_opaque_ptr (&unwind)); + + if (setjmp (png_err_stct.setjmp_buffer)) + { + /* Something blew up: + just display the error (cleanup happens in the unwind) */ + signal_image_error_2 ("Error decoding PNG", + build_string(png_err_stct.err_str), + instantiator); + } + /* Initialize all PNG structures */ - png_ptr = png_create_read_struct (PNG_LIBPNG_VER_STRING, (void*)&png_err_stct, + png_ptr = png_create_read_struct (PNG_LIBPNG_VER_STRING, + (void *) &png_err_stct, png_error_func, png_warning_func); if (!png_ptr) signal_image_error ("Error obtaining memory for png_read", instantiator); + unwind.png_ptr = png_ptr; + info_ptr = png_create_info_struct (png_ptr); if (!info_ptr) { + unwind.png_ptr = NULL; /* avoid re-calling png_destroy_read_struct + when unwinding */ png_destroy_read_struct (&png_ptr, (png_infopp)NULL, (png_infopp)NULL); signal_image_error ("Error obtaining memory for png_read", instantiator); } - - xzero (unwind); - unwind.png_ptr = png_ptr; unwind.info_ptr = info_ptr; - record_unwind_protect (png_instantiate_unwind, make_opaque_ptr (&unwind)); - /* This code is a mixture of stuff from Ben's GIF/JPEG stuff from this file, example.c from the libpng 0.81 distribution, and the pngtopnm sources. -WMP- ＠＠ -900,16 +918,6 ＠＠ png_instantiate (Lisp_Object image_instance, Lisp_Object instantiator, and is no longer usable for previous versions. jh */ - /* Set the jmp_buf return context for png_error ... if this returns !0, then - we ran into a problem somewhere, and need to clean up after ourselves. */ - if (setjmp (png_err_stct.setjmp_buffer)) - { - /* Something blew up: just display the error (cleanup happens in the unwind) */ - signal_image_error_2 ("Error decoding PNG", - build_string(png_err_stct.err_str), - instantiator); - } - /* Initialize the IO layer and read in header information */ { Lisp_Object data = find_keyword_in_vector (instantiator, Q_data); _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

2 participants
2 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

XEmacs-Patches June 2007