Mercurial > emacs
view admin/notes/commits @ 108656:0b28d05fa415
Initial reimplementation of calculating line edge positions in bidi lines.
dispextern.h (struct glyph_row): New members minpos and maxpos.
(MATRIX_ROW_START_CHARPOS, MATRIX_ROW_START_BYTEPOS)
(MATRIX_ROW_END_CHARPOS, MATRIX_ROW_END_BYTEPOS): Reference minpos
and maxpos members instead of start.pos and end.pos, respectively.
xdisp.c (display_line): Compare IT_CHARPOS with the position in
row->start.pos, rather than with MATRIX_ROW_START_CHARPOS.
(cursor_row_p): Use row->end.pos rather than MATRIX_ROW_END_CHARPOS.
(try_window_reusing_current_matrix, try_window_id): Use
ROW->minpos rather than ROW->start.pos.
(init_from_display_pos, init_iterator): Use EMACS_INT for
character and byte positions.
(find_row_edges): Renamed from find_row_end. Accept additional
arguments for minimum and maximum buffer positions seen by
display_line for this row. Don't use iterator to find the
position following the maximum one; instead, increment the
position found by display_line directly.
(display_line): Record minimum and maximum buffer positions for
glyphs in this row. Record the position of the newline that
terminates the line.
dispnew.c (increment_row_positions, check_matrix_invariants):
Increment and check row->start.pos and row->end.pos, in addition
to MATRIX_ROW_START_CHARPOS and MATRIX_ROW_END_CHARPOS.
author | Eli Zaretskii <eliz@gnu.org> |
---|---|
date | Tue, 18 May 2010 18:22:15 +0300 |
parents | 36d0fedf13ca |
children | 4e1df9366cdd a5eeeb631d8a |
line wrap: on
line source
HOW TO COMMIT CHANGES TO EMACS Most of these points are from: http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00555.html From: Miles Bader Subject: commit style redux Date: Tue, 31 Mar 2009 12:21:20 +0900 (0) Each commit should correspond to a single change (whether spread over multiple files or not). Do not mix different changes in the same commit (eg adding a feature in one file, fixing a bug in another should be two commits, not one). (1) Commit all changed files at once with a single log message (which in CVS will result in an identical log message for all committed files), not one-by-one. This is pretty easy using vc-dir now. (2) Make the log message describe the entire changeset, perhaps including relevant changelog entiries (I often don't bother with the latter if it's a trivial sort of change). Many modern source-control systems vaguely distinguish the first line of the log message to use as a short summary for abbreviated history listing (in arch this was explicitly called the summary, but many other systems have a similar concept). So it's nice if you can format the log entry like: SHORTISH ONE-LINE SUMMARY MULTIPLE-LINE DETAILED DESCRIPTION POSSIBLY INCLUDING (OR CONSISTING OF) CHANGELOG ENTRIES [Even with CVS this style is useful, because web CVS browsing interfaces often include the first N words of the log message of the most recent commit as a short "most recent change" description.] (3) Don't phrase log messages assuming the filename is known, because in non-file-oriented systems (everything modern other than CVS), the log listing tends to be treated as global information, and the connection with specific files is less explicit. For instance, currently I often see log messages like "Regenerate"; for modern source-control systems with a global log, it's better to have something like "Regenerate configure". Followup discussion: http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00401.html PREVIOUS GUIDELINES FOR CVS For historical interest only, here is the old-style advice for CVS logs: http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html From: Eli Zaretskii Subject: Re: Log messages in CVS Date: Sat, 29 Dec 2007 16:06:29 +0200