annotate admin/notes/bzr @ 111566:b4dbe6c4111e

Cleanup of window coordinate positioning code. Now, text area click input events measure Y from the top of the text area, excluding the header line if any. * src/dispnew.c (buffer_posn_from_coords): Assume that X counts from the start of the text area. * src/keyboard.c (make_lispy_position): For text area clicks, record Y pixel position relative to the text area, excluding header line. Also change X and Y to Lisp_Objects, not pointers; don't return coordinate values via pointers. Pass ON_TEXT_AREA coordinate to buffer_posn_from_coords counting from the start of the text area. (Fposn_at_x_y, make_lispy_event): Callers changed. * src/w32term.c (w32_read_socket): * src/msdos.c (dos_rawgetc): * src/xterm.c (handle_one_xevent): Likewise. * src/window.c (coordinates_in_window): Change X and Y to ints rather than pointers; don't return coordinates via pointers. (struct check_window_data): Change X and Y from pointers to ints. (window_from_coordinates): Remove args WX and WY; don't return coordinates via pointers. (Fcoordinates_in_window_p, window_from_coordinates): (check_window_containing, Fwindow_at): Callers changed. (window_relative_x_coord): New function. * src/window.h (window_from_coordinates, window_relative_x_coord): Update prototypes. * src/xdisp.c (remember_mouse_glyph): Change window_from_coordinates call. Use window_relative_x_coord. (note_mouse_highlight): Change window_from_coordinates call.

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