diff options
Diffstat (limited to 'admin/notes')
| -rw-r--r-- | admin/notes/BRANCH | 40 | ||||
| -rw-r--r-- | admin/notes/bugtracker | 29 | ||||
| -rw-r--r-- | admin/notes/bzr | 40 | ||||
| -rw-r--r-- | admin/notes/copyright | 14 | ||||
| -rw-r--r-- | admin/notes/cpp | 18 | ||||
| -rw-r--r-- | admin/notes/elpa | 42 | ||||
| -rw-r--r-- | admin/notes/font-backend | 9 | ||||
| -rw-r--r-- | admin/notes/newfile | 2 | ||||
| -rw-r--r-- | admin/notes/nextstep | 159 |
9 files changed, 300 insertions, 53 deletions
diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH index 258fcd95566..53f3d9603ca 100644 --- a/admin/notes/BRANCH +++ b/admin/notes/BRANCH @@ -1,29 +1,25 @@ -This file describes the bzr branch in which it is maintained. -Everything below the line is branch-specific. -________________________________________________________________________ +You can view the available Emacs branches at + +http://bzr.savannah.gnu.org/r/emacs/ -This is the trunk (sometimes mistakenly called "HEAD"). -When people say "use the development version of Emacs" or the -"bzr version of Emacs", this is the branch they are talking about. +Development normally takes places on the trunk. +Sometimes specialized features are developed on separate branches +before possibly being merged to the trunk. -Emacs development takes place on the trunk. Most of the time, Emacs -hackers add to it relatively free of constraint (aside from proper -legal / accounting practices), although sometimes there is related -discussion on the emacs-devel mailing list. +Development is discussed on the emacs-devel mailing list. -Sometime before the release of a new major version of Emacs (eg 22.1), +Sometime before the release of a new major version of Emacs (eg 23.2), a "feature freeze" is imposed on the trunk. No new features may be -added after this point. This is usually many months before the release. -During this time, there is no official place for development of new features. +added after this point. This is usually some months before the release. -Shortly before the release, a release branch is created. For example, -EMACS_22_BASE or EMACS_21_1_RC for Emacs 22.x and 21.x, respectively. -(Unfortunately the naming scheme has not always been consistent.) +Shortly before the release, a release branch is created, and the +trunk is then free for development. +For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for +23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x. -The release branch is used to make the release (22.1), and all later -members of the series (22.2, 22.3, etc). Generally, only bug-fixes have -been allowed in the minor releases, although in 22.x, self-contained -new features were allowed on a case-by-case basis. +Consult emacs-devel for exactly what kinds of changes are allowed +on what branch at any time. -From the point that a release branch is created, the trunk is free for -development for the next major version. +If you are looking at this file in a branch other than the trunk, +there may be some branch-specific documentation below this line. +________________________________________________________________________ diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker index ca71214cdcc..7c6c0ff4272 100644 --- a/admin/notes/bugtracker +++ b/admin/notes/bugtracker @@ -149,6 +149,23 @@ Discard mails matching: ^X-GNU-PR-Message: (transcript|closed) +** Not receiving messages in response to your control commands? +The messages debbugs sends out in response to control-server commands +always have headers To: your@email, and Cc: tracker@debbugs.gnu.org +(the latter is an alias for the emacs-bug-tracker mailing list). +These are also the addresses to which a copy of the response is sent. +(In general, there need not be any relation between the To: and Cc: +headers visible in a message and where debbugs actually sends it.) +If you used an X-Debbugs-No-Ack header, however, a copy is _not_ sent +to you, but the To: header is unchanged. If you are subscribed to the +emacs-bug-tracker mailing list and have duplicate suppression turned +on, the presence of your address in the To: header will cause Mailman +to not send you a list copy, because it thinks you have received a +direct copy. If you used X-Debbugs-No-Ack, this is not the case, and +you won't get any copy at all. If this bothers you, don't use both +X-Debbugs-No-Ack and Mailman duplicate suppression for the +emacs-bug-tracker mailing list, just pick one or the other. + ** How to avoid multiple copies of mails. If you reply to reports in the normal way, this should work fine. Basically, reply only to the numbered bug address (and any individual @@ -367,6 +384,14 @@ fixed 123 23.0.60 *** To remove a "fixed" mark: notfixed 123 23.0.60 +*** To make a bug as present in a particular version: +found 123 23.2 +NB if there is no specified "fixed" version, or if there is one and it +is earlier than the found version, this reopens a closed bug. + +The leading "23.1;" that M-x report-emacs-bug adds to bug subjects +automatically sets a found version (if none is explicitly specified). + *** To assign or reassign a bug to a package or list of packages: reassign 1234 emacs @@ -578,9 +603,13 @@ All discarded messages are stored in /var/lib/mailman/spam. If a non-spam message accidentally gets discarded, just do: cat /var/lib/mailman/spam/not-really-spam.msg | /usr/lib/debbugs/receive +chown Debian-debbugs:Debian-debbugs /var/lib/debbugs/spool/incoming/* ... check it works ... mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/ +Also check that the sender was not added to the auto-discard/reject list +in the debbugs-submit Mailman interface. + ** Administrivia The debbugs-submit list should have the administrivia option off, diff --git a/admin/notes/bzr b/admin/notes/bzr new file mode 100644 index 00000000000..c66cdd98a3c --- /dev/null +++ b/admin/notes/bzr @@ -0,0 +1,40 @@ +NOTES ON COMMITTING TO EMACS'S BAZAAR REPO -*- outline -*- + +* Install changes only on one branch, let them get merged elsewhere if needed. +In particular, install bug-fixes only on the release branch (if there +is one) and let them get synced to the trunk; do not install them by +hand on the trunk as well. E.g. if there is an active "emacs-23" branch +and you have a bug-fix appropriate for the next Emacs-23.x release, +install it only on the emacs-23 branch, not on the trunk as well. + +Installing things manually into more than one branch makes merges more +difficult. + +http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html + +* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23"). +Label the commit as a backport, e.g. by starting the commit message with +"Backport:". This is helpful for the person merging the release branch +to the trunk. + +http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html + +* Installing changes from your personal branches. +If your branch has only a single commit, or many different real +commits, it is fine to do a merge. If your branch has only a very +small number of "real" commits, but several "merge from trunks", it is +preferred that you take your branch's diff, apply it to the trunk, and +commit directly, not merge. This keeps the history cleaner. + +In general, when working on some feature in a separate branch, it is +preferable not to merge from trunk until you are done with the +feature. Unless you really need some change that was done on the +trunk while you were developing on the branch, you don't really need +those merges; just merge once, when you are done with the feature, and +Bazaar will take care of the rest. Bazaar is much better in this than +CVS, so interim merges are unnecessary. + +Or use shelves; or rebase; or do something else. See the thread for +yet another fun excursion into the exciting world of version control. + +http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html diff --git a/admin/notes/copyright b/admin/notes/copyright index 81736e038b6..cb1c4e0b0e8 100644 --- a/admin/notes/copyright +++ b/admin/notes/copyright @@ -132,10 +132,16 @@ Cocoa/Emacs.base/Contents/Resources/English.lproj/InfoPlist.strings GNUstep/Emacs.base/Resources/Info-gnustep.plist `set-copyright' in admin.el will do all the above. -<top-level>/install-sh -lispintro/install-sh +configure + - copyright FSF, with unlimited permission to copy, distribute and modify + +m4/getopt.m4 + - copyright FSF, with MIT-like license + +install-sh - this file is copyright MIT, which is OK. Leave the copyright alone. +mkinstalldirs src/m/news-r6.h public domain, leave alone. @@ -329,6 +335,9 @@ Leave the copyrights alone. Leave the Eli Zaretskii copyright in is_exec.c alone. See the msdos/README file for the legal history of these files. +msdos/sed*.inp - These files are copyright FSF and distributed under +an MIT-like license. + oldXMenu/ Keep the "copyright.h" method used by X11, rather than moving the @@ -611,6 +620,7 @@ of writing) GPL >= 2. rms says may as well leave the licenses of these alone (may import them from Gnulib again). These are: Gnulib: + move-if-change src/getloadavg.c src/gmalloc.c src/md5.c diff --git a/admin/notes/cpp b/admin/notes/cpp deleted file mode 100644 index 275001369d9..00000000000 --- a/admin/notes/cpp +++ /dev/null @@ -1,18 +0,0 @@ -ttn 2003-04-09 - -we use a C preprocesor not only in the normal compilation of .c files -into object files, but also for creating - - src/Makefile - lib-src/Makefile - -(delimited by comment "start of cpp stuff"). some cpp implementations -insert whitespace in between tokens. - -during makefile creation, the preprocessor symbol NOT_C_CODE is defined. -this should not be defined for normal .c file compilation. - -there has been discussion on eliminating this use of cpp and relying -solely on autoconf processing. rms says to leave it be. - -;;; arch-tag: d654291e-9fc8-41b7-ab0c-d3cde842a8e0 diff --git a/admin/notes/elpa b/admin/notes/elpa new file mode 100644 index 00000000000..e28d81e6d6e --- /dev/null +++ b/admin/notes/elpa @@ -0,0 +1,42 @@ +NOTES ON THE EMACS PACKAGE ARCHIVE + +Here are instructions on uploading files to the package archive at +elpa.gnu.org, for Emacs maintainers. (If you are not a maintainer, +contact us if you want to submit a package.) + +1. You will need login access to elpa.gnu.org. You will also need to + get the FSF sysadmins to allow ssh access through the FSF firewall + for your local machine. Ensure that your uid, USER, is in the + `elpa' group on elpa.gnu.org; this gives you write access to the + bzr repository from which the packages are managed. + +2. Go to your bzr repository on your local machine. Of, if you don't + have one (you should, if you're tracking Emacs bzr), make one: + + cd $DEVHOME + bzr init-repo elpa/ + cd elpa + + Create a branch for elpa: + + bzr branch bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo package-repo + + Bind the branch: + + cd package-repo/ + echo "public_branch = bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo" >> .bzr/branch/branch.conf + bzr bind bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo + + Now you should be able to do `bzr up' and `bzr commit'. + +3. Changes in bzr do not immediately propagate to the user-facing tree + (i.e., what users see when they do `M-x list-packages'). That tree + is created by a (daily) cron job that does "bzr export". If for + some reason you need to refresh the user-facing tree immediately, + run /home/elpa/bin/package-update.sh as the "elpa" user. + + The Org mode dailies are not part of the repository. After the + package-update.sh script creates the user-facing tree, it copies + the daily tarfile hosted on orgmode.org directly into that tree. + +4. FIXME: How to actually upload a package file. diff --git a/admin/notes/font-backend b/admin/notes/font-backend index d35102d681e..be35693fc6e 100644 --- a/admin/notes/font-backend +++ b/admin/notes/font-backend @@ -6,11 +6,6 @@ See the end of the file for license conditions. New font handling mechanism with font backend method ---------------------------------------------------- -The configure script, if invoked with "--enable-font-backend", checks -if libraries freetype and fontconfig exist. If they are both -available, macro "USE_FONT_BACKEND" is defined in src/config.h. In -that case, the existence of Xft library is checked too. - The new files are: font.h -- header providing font-backend related structures (most important ones are "struct font" and "struct @@ -44,10 +39,6 @@ Fontconfig are also available on w32, what we need may be: ftw32font.c -- font-driver on w32 directly using FreeType fonts utilizing methods provided by ftfont.c. -And, for those to work, macterm.c and macfns.c must be changed by the -similar way as xterm.c and xfns.c (the parts "#ifdef USE_FONT_BACKEND" -... "#endif" should be checked). - It may be interesting if Emacs supports a frame buffer directly and has these font driver. ftfbfont.c -- font-driver on FB for FreeType fonts. diff --git a/admin/notes/newfile b/admin/notes/newfile index acba327072b..0b66b8054bb 100644 --- a/admin/notes/newfile +++ b/admin/notes/newfile @@ -17,8 +17,6 @@ not include any files that end up in the release tarball. ** Make the ChangeLog entry in the name of the author(s), not your own name. -** If appropriate, add an entry to lisp/Makefile.in ELCFILES. - ** If appropriate, check that the file compiles OK and that Emacs builds fine with it. Address any compilation warnings. diff --git a/admin/notes/nextstep b/admin/notes/nextstep new file mode 100644 index 00000000000..462101f9abf --- /dev/null +++ b/admin/notes/nextstep @@ -0,0 +1,159 @@ +This file summarizes primary aspects of the NS port architecture. If +possible, it should be updated for changes. + +Currently it summarizes the state as of: + + summer 2008 shortly after merging to trunk + + + +Startup +------- + +Init sequence: + emacs.c: ns_alloc_autorelease_pool() nsterm.m + emacs.c: ns_init_paths() nsterm.m + - override EMACSLOADPATH, etc. so resources can be found in-bundle + emacs.c: init_display() dispnew.c + - sets Vwindow_system (window-system) to 'ns + emacs.c: loadup.el -> startup.el -> ns-initialize-window-system + -> x-open-connection (nsfns.m) + - ns-list-services + -> nsterm.m: ns_term_init() + - EmacsApp sharedApplication + - read NS defaults (org.gnu.Emacs.plist) + - init X-style color list + - ns_create_terminal() + - NSApp run (goes to applicationDidFinishLaunching which terminates + event loop -- see below) + + + +Event Loop +---------- + +In an NS application, the event loop is normally managed by system and all +user code is event-driven. [NSApp run] is called by user and never returns. + +In Emacs, the event loop is managed by emacs itself. + +The NS port mediates between these two styles by intercepting the NS event +dispatch at [NSApp sendEvent]. If a special event is detected, the event loop +is broken, and control returned to Emacs. This special event is sent by +ns_send_appdefined, which is called under these circumstances: + + - if a user input event is received + - when a timeout fires + +NS event processing is instigated from Emacs through ns_select() and +ns_read_socket() in nsterm.m. Parts of the codepaths leading to these +functions are: + + + keyboard.c:read_avail_input() + -> ns_read_socket (ns_send_appdefined) -> [NSApp run] + + process.c:wait_reading_process_output() + -> ns_select -> gobble_input (global inNsSelect=1) + -> ns_read_socket (ns_send_appdefined if !expected) -> [NSApp run] + + sysdep.c:sys_select() -> read_input_waiting() + -> ns_read_socket (send_appdefined) -> [NSApp run] + [this codepath may not be used] + + +Currently ctrl-g is not detected in as many circumstances as other emacsen. +It is not certain whether this is due to the means of event loop integration, +or errors of omission in the NS code. This is an area for improvement. +Also, see the article here and its containing thread: + +http://article.gmane.org/gmane.emacs.devel/92021/match=handling%5fsignal + + + + +Text Rendering and Font Handling +-------------------------------- + +nsfont.m implements the font driver, responsible for managing fonts and +rendering text. Fonts are obtained through NSFontManager. Rendering must be +done at a low level due to emacs' fine control over this process, therefore +there are different approachs under Cocoa and GNUstep. Under GNUstep, the +original NeXT Display PostScript (DPS) APIs are available and used. Under +Cocoa, these were removed and Quartz drawing functions replaced them. + +In both cases, font glyphs are accessed through UTF8 character +representations. It would be preferable to use unicode indices, but prior +attempts at this have failed. + +Multi-script fontsets are auto-created in nsfont_make_fontset_for_font() using +the facilities of NSTextStorage and NSLayoutManager. + + +Object Architecture +------------------- + +Unlike the other GUIs, the NS interface is based on a high-level and +object-oriented API. This creates some tension in the code because emacs +itself has been architected around the low-level Xlib and Xt APIs. The NS +port tries to strike a balance between simplifying code on its side using OO +features, and keeping code as similar as possible to other ports to ease +maintenance. The following are the main classes (see nsterm.h): + +EmacsApp : NSApplication + - event loop integration, interapp comms point for Finder (NSWorkspace) msgs, + Services + - one global instance (NSApp) + - nsterm.m + +EmacsView : NSView <TextInput> + - handles rendering of text and fringe, interapp comms for drag/drop + - instance for each frame + - child of window's content view + - nsterm.m + +EmacsWindow : NSWindow + - utility override for resize handling + +EmacsScroller : NSScroller + - instance for each emacs window, renders scrollbar + - child of window's content view + - nsterm.m + +EmacsImage : NSImage + - image rendering, toolbar icons, stippling, fringe bitmaps + - instance for each image + - nsimage.m + +EmacsMenu : NSMenu + - menu management + - one tree of instances for menubar, one instance for each popup menu + - nsmenu.m + +EmacsToolbar : NSToolbar + - toolbar management, one instance for each frame + - nsmenu.m + + +EmacsDialogPanel : NSPanel + - popup dialogs, one instance for each + - nsmenu.m + +EmacsTooltip : NSObject + - tooltip popups, one instance for each + - nsmenu.m + +EmacsGlyphStorage : NSObject <NSGlyphStorage> + - utility for text rendering + - nsfont.m + +EmacsPrefsController : NSObject + - utility for preferences panel management, one global instance + - nsterm.m + - nextstep/Cocoa/Emacs.base/Contents/Resources/preferences.nib + - nextstep/GNUstep/Emacs.base/Resources/preferences.gorm + +EmacsSavePanel : NSSavePanel +EmacsOpenPanel : NSOpenPanel + - utility override for panel notifications + |