view admin/notes/commits @ 107998:531d454c3a99

Implement GUI display of R2L lines, fix TTY display of R2L lines. xdisp.c [HAVE_WINDOW_SYSTEM]: Add prototype for append_stretch_glyph. (set_cursor_from_row) <cursor_x>: Remove unused variable. Fix off-by-one error in computing x at end of text in the row. (append_stretch_glyph): In reversed row, prepend the glyph rather than append it. Set resolved_level and bidi_type of the glyph. (extend_face_to_end_of_line): If the row is reversed, prepend a stretch glyph whose width is such that the rightmost glyph will be drawn at the right margin of the window. Fix off-by-one error on TTY frames in testing whether a line needs face extension. Fix face extension at ZV. If this is the last glyph row, use DEFAULT_FACE_ID, to avoid painting the rest of the window with the region face. (set_cursor_from_row, display_line): Use MATRIX_ROW_CONTINUATION_LINE_P instead of testing value of row->continuation_lines_width. (next_element_from_buffer): Don't call bidi_paragraph_init if we are at ZV. Fixes a crash when reseated to ZV by try_window_reusing_current_matrix. (display_and_set_cursor, erase_phys_cursor): Handle negative HPOS, which happens with R2L glyph rows. Fixes a crash when inserting a character at end of an R2L line. (set_cursor_from_row): Don't be fooled by truncated rows: don't treat them as having zero-width characters. Improve comments. Don't reverse pos_before and pos_after for reversed glyph rows. Set cursor.x to negative value when the cursor might be on the left fringe. (IT_OVERFLOW_NEWLINE_INTO_FRINGE): For R2L lines, consider the left fringe, not the right one. (notice_overwritten_cursor, draw_phys_cursor_glyph) (erase_phys_cursor): For reversed cursor_row, support cursor on the left fringe. fringe.c (update_window_fringes): For R2L rows, swap the bitmaps of continuation indicators on the fringes. (draw_fringe_bitmap): For reversed glyph rows, allow cursor on the left fringe. w32term.c (w32_draw_window_cursor): For reversed glyph rows, draw cursor on the left fringe. xterm.c (x_draw_window_cursor): For reversed glyph rows, draw cursor on the left fringe. dispnew.c (update_text_area): Handle reversed desired rows when the cursor is on the left fringe. (set_window_cursor_after_update): Limit cursor's hpos by -1 from below, not by 0, for when the cursor is on the left fringe. xdisp.c (unproduce_glyphs): New function. (display_line): Use it when produced glyphs are discarded from R2L glyph rows. (append_composite_glyph): In R2L rows, prepend the glyph rather than appending it. term.c (append_composite_glyph): In R2L rows, prepend the glyph rather than append it. Set up the resolved_level and bidi_type attributes of the appended glyph. (produce_special_glyphs): Mirror the backslash continuation character in R2L lines.

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