emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

master 85ad861600: ; * src/xterm.c: Minor fixes of the commentary.


From: Eli Zaretskii
Subject: master 85ad861600: ; * src/xterm.c: Minor fixes of the commentary.
Date: Wed, 23 Feb 2022 08:08:17 -0500 (EST)

branch: master
commit 85ad8616007e286c237bb2906d1928bb551462e7
Author: Eli Zaretskii <eliz@gnu.org>
Commit: Eli Zaretskii <eliz@gnu.org>

    ; * src/xterm.c: Minor fixes of the commentary.
---
 src/xterm.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/src/xterm.c b/src/xterm.c
index a3c3c6f3f4..4b463da5f8 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -117,9 +117,10 @@ along with GNU Emacs.  If not, see 
<https://www.gnu.org/licenses/>.  */
    background pixel values.
 
    Usually, one graphics context is computed for each face when it is
-   first about to be displayed, and this graphics context is the one
-   which is used for future X drawing operations in a glyph string
-   with that face.  (See `prepare_face_for_display' in xfaces.c).
+   about to be displayed for the first time, and this graphics context
+   is the one which is used for future X drawing operations in a glyph
+   string with that face.  (See `prepare_face_for_display' in
+   xfaces.c).
 
    However, when drawing glyph strings for special display elements
    such as the cursor, or mouse sensitive text, different GCs may be
@@ -155,11 +156,11 @@ along with GNU Emacs.  If not, see 
<https://www.gnu.org/licenses/>.  */
    onto the physical display.
 
    When the visual class is TrueColor, the colormap will be indexed
-   based on the red, green, and blue components of the pixel values,
-   and the colormap will be statically allocated as to contain linear
-   ramps for each component.  As such, most of the color allocation
-   described below is bypassed, and the pixel values are computed
-   directly from the color.
+   based on the red, green, and blue (RGB) components of the pixel
+   values, and the colormap will be statically allocated so as to
+   contain linear ramps for each component.  As such, most of the
+   color allocation described below is bypassed, and the pixel values
+   are computed directly from the color.
 
    Otherwise, each time Emacs wants a pixel value that corresponds to
    a color, Emacs has to ask the X server to obtain the pixel value



reply via email to

[Prev in Thread] Current Thread [Next in Thread]