From 17073af84d7eaedc81d84fc16f8aa0db215c6a31 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 12:59:50 -0400 Subject: [PATCH 01/13] ; Improve robustness of package-report-bug * lisp/emacs-lisp/package.el (package-report-bug): Do not assume that every entry in 'custom-current-group-alist' has a non-nil entry for a filename. It is possible for a group to not be associated with any file, e.g. when a 'defgroup' form is evaluated using 'eval-expression'. (bug#64543) --- lisp/emacs-lisp/package.el | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 3e6acd9b388..58ca19f7fe2 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -4637,13 +4637,14 @@ DESC must be a `package-desc' object." vars) (dolist-with-progress-reporter (group custom-current-group-alist) "Scanning for modified user options..." - (dolist (ent (get (cdr group) 'custom-group)) - (when (and (custom-variable-p (car ent)) - (boundp (car ent)) - (not (eq (custom--standard-value (car ent)) - (default-toplevel-value (car ent)))) - (file-in-directory-p (car group) (package-desc-dir desc))) - (push (car ent) vars)))) + (when (and (car group) + (file-in-directory-p (car group) (package-desc-dir desc))) + (dolist (ent (get (cdr group) 'custom-group)) + (when (and (custom-variable-p (car ent)) + (boundp (car ent)) + (not (eq (custom--standard-value (car ent)) + (default-toplevel-value (car ent))))) + (push (car ent) vars))))) (dlet ((reporter-prompt-for-summary-p t)) (reporter-submit-bug-report maint name vars)))) From ce3f9fba1a32260ff837d689ac6928a75bab86d9 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Mon, 17 Jul 2023 22:02:38 +0200 Subject: [PATCH 02/13] ; Improve accuracy of out-out-order message insertion * lisp/net/rcirc.el (rcirc-print): Do not ignore the return value of 'next-single-property-change'. --- lisp/net/rcirc.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el index cf1b952086a..1ddffe8dec9 100644 --- a/lisp/net/rcirc.el +++ b/lisp/net/rcirc.el @@ -2059,7 +2059,7 @@ connection." (point-min))) (when (let ((then (get-text-property (point) 'rcirc-time))) (and then (not (time-less-p time then)))) - (next-single-property-change (point) 'hard) + (goto-char (next-single-property-change (point) 'hard)) (forward-char 1) (throw 'exit nil)))) (goto-char (line-beginning-position)) From 77f489421ec2958351cda612ddccf53581f41a74 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 18 Jul 2023 14:58:09 +0300 Subject: [PATCH 03/13] ; * src/xdisp.c: Minor improvements of the commentary. --- src/xdisp.c | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 763af7d3bc8..aa63742e23d 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -107,31 +107,33 @@ along with GNU Emacs. If not, see . */ . try_cursor_movement - This function tries to update the display if the text in the - window did not change and did not scroll, only point moved, and - it did not move off the displayed portion of the text. + This optimization is applicable if the text in the window did + not change and did not scroll, only point moved, and it did not + move off the displayed portion of the text. In that case, the + window's glyph matrix is still valid, and only the position of + the cursor might need to be updated. . try_window_reusing_current_matrix - This function reuses the current matrix of a window when text - has not changed, but the window start changed (e.g., due to + This function reuses the current glyph matrix of a window when + text has not changed, but the window start changed (e.g., due to scrolling). . try_window_id - This function attempts to redisplay a window by reusing parts of - its existing display. It finds and reuses the part that was not - changed, and redraws the rest. (The "id" part in the function's - name stands for "insert/delete", not for "identification" or - somesuch.) + This function attempts to update a window's glyph matrix by + reusing parts of its current glyph matrix. It finds and reuses + the part that was not changed, and regenerates the rest. (The + "id" part in the function's name stands for "insert/delete", not + for "identification" or somesuch.) . try_window - This function performs the full, unoptimized, redisplay of a - single window assuming that its fonts were not changed and that - the cursor will not end up in the scroll margins. (Loading - fonts requires re-adjustment of dimensions of glyph matrices, - which makes this method impossible to use.) + This function performs the full, unoptimized, generation of a + single window's glyph matrix, assuming that its fonts were not + changed and that the cursor will not end up in the scroll + margins. (Loading fonts requires re-adjustment of dimensions of + glyph matrices, which makes this method impossible to use.) The optimizations are tried in sequence (some can be skipped if it is known that they are not applicable). If none of the From 927e8b470fc342fcdefa68a75ce01f3a45300dc7 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 18 Jul 2023 15:57:01 +0300 Subject: [PATCH 04/13] ; * doc/lispref/keymaps.texi (Extended Menu Items): Add @pxref. --- doc/lispref/keymaps.texi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/lispref/keymaps.texi b/doc/lispref/keymaps.texi index 9e36d6716b9..66bb834192c 100644 --- a/doc/lispref/keymaps.texi +++ b/doc/lispref/keymaps.texi @@ -2506,7 +2506,8 @@ get a non-selectable menu item. This is mostly useful when creating separator lines and the like. The tail of the list, @var{item-property-list}, has the form of a -property list which contains other information. +property list (@pxref{Property Lists}) which contains other +information. Here is a table of the properties that are supported: From d172cd59854699c00de3b57a91e48ff70a4210f8 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 18 Jul 2023 16:17:15 +0300 Subject: [PATCH 05/13] ; * doc/lispref/keymaps.texi (Modifying Menus): Add cross-references. --- doc/lispref/keymaps.texi | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/doc/lispref/keymaps.texi b/doc/lispref/keymaps.texi index 66bb834192c..24b7738caff 100644 --- a/doc/lispref/keymaps.texi +++ b/doc/lispref/keymaps.texi @@ -3172,14 +3172,15 @@ the menu. To put it elsewhere in the menu, use @code{keymap-set-after}: @defun keymap-set-after map key binding &optional after Define a binding in @var{map} for @var{key}, with value @var{binding}, -just like @code{define-key}, but position the binding in @var{map} after -the binding for the event @var{after}. The argument @var{key} should -represent a single menu item or key, and @var{after} should be a -single event type---a symbol or a character, not a sequence. The new -binding goes after the binding for @var{after}. If @var{after} is -@code{t} or is omitted, then the new binding goes last, at the end of -the keymap. However, new bindings are added before any inherited -keymap. +just like @code{keymap-set} (@pxref{Changing Key Bindings}), but +position the binding in @var{map} after the binding for the event +@var{after}. The argument @var{key} should represent a single menu +item or key, and should satisfy @code{key-valid-p} (@pxref{Key +Sequences}). @var{after} should be a single event type---a symbol or +a character, not a sequence. The new binding goes after the binding +for @var{after}. If @var{after} is @code{t} or is omitted, then the +new binding goes last, at the end of the keymap. However, new +bindings are added before any inherited keymap. Here is an example: From f063f79a4933f21dc72c6a24b60f98197543d3de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= Date: Tue, 18 Jul 2023 15:42:55 +0200 Subject: [PATCH 06/13] Convert NUL-containing NSString objects to Lisp strings correctly This cures the inability to paste text containing NUL from other applications on macOS, introduced by mistake in 7e3c2b553f (bug#64697). * src/nsfns.m ([NSString lispString]): Use make_string instead of build_string which relies on NUL-termination. --- src/nsfns.m | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/nsfns.m b/src/nsfns.m index 8804a7df7cf..5ae2cc77bb2 100644 --- a/src/nsfns.m +++ b/src/nsfns.m @@ -3829,7 +3829,9 @@ handled fairly well by the NS libraries (displayed with distinct /* Make a Lisp string from an NSString. */ - (Lisp_Object)lispString { - return build_string ([self UTF8String]); + // make_string behaves predictably and correctly with UTF-8 input. + return make_string ([self UTF8String], + [self lengthOfBytesUsingEncoding: NSUTF8StringEncoding]); } @end From 815185344713aafb314c6c413ba9f146a7ff017f Mon Sep 17 00:00:00 2001 From: Arash Esbati Date: Tue, 18 Jul 2023 23:07:01 +0200 Subject: [PATCH 07/13] ; * admin/notes/bugtracker: Use 'e.g.' throughout the document. --- admin/notes/bugtracker | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker index deb06f552cc..d1edad17177 100644 --- a/admin/notes/bugtracker +++ b/admin/notes/bugtracker @@ -39,7 +39,7 @@ tags 123 moreinfo|unreproducible|wontfix|patch|notabug For a list of all bugs, see https://debbugs.gnu.org/db/pa/lemacs.html This is a static page, updated once a day. There is also a dynamic -list, generated on request. This accepts various options, eg to see +list, generated on request. This accepts various options, e.g. to see the most recent bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?newest=100 @@ -138,7 +138,8 @@ The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases. ** To not get acknowledgment mail from the tracker, add an "X-Debbugs-No-Ack:" header (with any value). If you use Gnus, -you can add an element to gnus-posting-styles to do this automatically, eg: +you can add an element to gnus-posting-styles to do this automatically, +e.g.: ("gnu-emacs\\(-pretest\\)?-bug" ("X-Debbugs-No-Ack" "yes")) @@ -222,7 +223,7 @@ Mail-Followup-To: 123@debbugs.gnu.org, person-who-closed ** Setting bug parameters. There are two ways to set the parameters of bugs in the database (tags, severity level, etc). When you report a new bug, you can -provide a "pseudo-header" at the start of the report, eg: +provide a "pseudo-header" at the start of the report, e.g.: Package: emacs Version: 23.0.60 @@ -258,7 +259,7 @@ where VERSION is XX.YY numerical version number, like 42.1. *** To reopen a closed bug: reopen 123 -*** Bugs can be tagged in various ways (eg wontfix, patch, etc). +*** Bugs can be tagged in various ways (e.g. wontfix, patch, etc). The available tags are: patch wontfix moreinfo unreproducible fixed notabug help security confirmed easy See https://debbugs.gnu.org/Developer#tags @@ -310,7 +311,7 @@ This will add a usertag "any-tag-you-like" to bug#1234. The tag will be associated with the user "emacs". If you omit the first line, the tag will be associated with your email address. -The syntax of the usertags command is the same as that of tags (eg wrt +The syntax of the usertags command is the same as that of tags (e.g. wrt the optional [=+-] argument). b) In an initial submission, in the pseudo-header: @@ -340,12 +341,12 @@ than one email address, but it does not seem to work for me.) **** To find bugs tagged with a specific usertag: This works just like a normal tags search, but with the addition of a -"users" field. Eg: +"users" field. E.g.: https://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=calendar *** To merge bugs: -Eg when bad replies create a bunch of new bugs for the same report. +E.g. when bad replies create a bunch of new bugs for the same report. Bugs must all be in the same state (e.g. same package(s) and severity -- see 'reassign' and 'severity' below), but need not have the same tags (tags are merged). E.g.: @@ -557,7 +558,7 @@ debbugs-submit. Approved mail is passed on to the tracker. tracker, since mail from whitelisted senders goes straight through.) NOTE: An alternative to this would be to use listhelper AT nongnu.org -as a moderator address. Eg the emacs-bug-tracker list uses this. +as a moderator address. E.g. the emacs-bug-tracker list uses this. It does basic spam processing on the moderator requests and automatically rejects the obviously bogus ones. Someone still has to accept the good ones though. The advantage of this would not be having From ac075176bf077ad79272e3d6c032c0658e4e19fc Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Wed, 19 Jul 2023 15:05:52 +0300 Subject: [PATCH 08/13] ; * admin/notes/bugtracker: Fix punctuation. --- admin/notes/bugtracker | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker index d1edad17177..b47061884d6 100644 --- a/admin/notes/bugtracker +++ b/admin/notes/bugtracker @@ -39,7 +39,7 @@ tags 123 moreinfo|unreproducible|wontfix|patch|notabug For a list of all bugs, see https://debbugs.gnu.org/db/pa/lemacs.html This is a static page, updated once a day. There is also a dynamic -list, generated on request. This accepts various options, e.g. to see +list, generated on request. This accepts various options, e.g., to see the most recent bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?newest=100 @@ -98,7 +98,7 @@ you might want to have a dialog with the owner address, outside of normal bug reporting.) ** When reporting a new bug, to send a Cc to another address -(e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header. +(e.g., bug-cc-mode@gnu.org), do NOT just use a Cc: header. Instead, use "X-Debbugs-Cc:". This ensures the Cc address(es) will get a mail with the bug report number in. If you do not do this, each reply in the subsequent discussion might end up creating a new bug. @@ -230,7 +230,7 @@ Version: 23.0.60 Severity: minor This can also include tags, or any X-Debbugs- setting. -Some things (e.g. submitter) don't seem to work here. +Some things (e.g., submitter) don't seem to work here. Otherwise, send mail to the control server, control@debbugs.gnu.org. At the start of the message body, supply the desired commands, one per @@ -259,12 +259,12 @@ where VERSION is XX.YY numerical version number, like 42.1. *** To reopen a closed bug: reopen 123 -*** Bugs can be tagged in various ways (e.g. wontfix, patch, etc). +*** Bugs can be tagged in various ways (e.g., wontfix, patch, etc). The available tags are: patch wontfix moreinfo unreproducible fixed notabug help security confirmed easy See https://debbugs.gnu.org/Developer#tags The list of tags can be prefixed with +, - or =, meaning to add (the -default), remove, or reset the tags. E.g.: +default), remove, or reset the tags. E.g.: tags 123 + wontfix @@ -311,7 +311,7 @@ This will add a usertag "any-tag-you-like" to bug#1234. The tag will be associated with the user "emacs". If you omit the first line, the tag will be associated with your email address. -The syntax of the usertags command is the same as that of tags (e.g. wrt +The syntax of the usertags command is the same as that of tags (e.g., wrt the optional [=+-] argument). b) In an initial submission, in the pseudo-header: @@ -346,10 +346,10 @@ This works just like a normal tags search, but with the addition of a https://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=calendar *** To merge bugs: -E.g. when bad replies create a bunch of new bugs for the same report. -Bugs must all be in the same state (e.g. same package(s) and severity +e.g., when bad replies create a bunch of new bugs for the same report. +Bugs must all be in the same state (e.g., same package(s) and severity -- see 'reassign' and 'severity' below), but need not have the same -tags (tags are merged). E.g.: +tags (tags are merged). E.g.: merge 123 124 125 ... @@ -558,7 +558,7 @@ debbugs-submit. Approved mail is passed on to the tracker. tracker, since mail from whitelisted senders goes straight through.) NOTE: An alternative to this would be to use listhelper AT nongnu.org -as a moderator address. E.g. the emacs-bug-tracker list uses this. +as a moderator address. E.g., the emacs-bug-tracker list uses this. It does basic spam processing on the moderator requests and automatically rejects the obviously bogus ones. Someone still has to accept the good ones though. The advantage of this would not be having From 86f2d6d62fce90d19815503e3e99ac9c4d4585af Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Wed, 19 Jul 2023 17:54:53 +0300 Subject: [PATCH 09/13] ; * src/xdisp.c: Improve commentary. (Bug#64596) --- src/xdisp.c | 120 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 77 insertions(+), 43 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index aa63742e23d..3a347c1f923 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -21,17 +21,17 @@ along with GNU Emacs. If not, see . */ Redisplay. - Emacs separates the task of updating the display from code - modifying global state, e.g. buffer text. This way functions - operating on buffers don't also have to be concerned with updating - the display. + Emacs separates the task of updating the display -- which we call + "redisplay" -- from the code modifying global state, e.g. buffer + text. This way functions operating on buffers don't also have to + be concerned with updating the display as result of their + operations. - Updating the display is triggered by the Lisp interpreter when it - decides it's time to do it. This is done either automatically for - you as part of the interpreter's command loop or as the result of - calling Lisp functions like `sit-for'. The C function - `redisplay_internal' in xdisp.c is the only entry into the inner - redisplay code. + Redisplay is triggered by the Lisp interpreter when it decides it's + time to do it. This is done either automatically for you as part + of the interpreter's command loop, or as the result of calling Lisp + functions like `sit-for'. The C function `redisplay_internal' in + xdisp.c is the only entry into the inner redisplay code. The following diagram shows how redisplay code is invoked. As you can see, Lisp calls redisplay and vice versa. @@ -75,35 +75,68 @@ along with GNU Emacs. If not, see . */ and to make these changes visible. Preferably it would do that in a moderately intelligent way, i.e. fast. - Changes in buffer text can be deduced from window and buffer - structures, and from some global variables like `beg_unchanged' and - `end_unchanged'. The contents of the display are additionally - recorded in a `glyph matrix', a two-dimensional matrix of glyph - structures. Each row in such a matrix corresponds to a line on the - display, and each glyph in a row corresponds to a column displaying - a character, an image, or what else. This matrix is called the - `current glyph matrix' or `current matrix' in redisplay - terminology. + At its highest level, redisplay can be divided into 3 distinct + steps, all of which are visible in `redisplay_internal': - For buffer parts that have been changed since the last update, a - second glyph matrix is constructed, the so called `desired glyph - matrix' or short `desired matrix'. Current and desired matrix are - then compared to find a cheap way to update the display, e.g. by - reusing part of the display by scrolling lines. The actual update - of the display of each window by comparing the desired and the - current matrix is done by `update_window', which calls functions - which draw to the glass (those functions are specific to the type - of the window's frame: X, w32, NS, etc.). + . decide which windows on which frames need their windows + considered for redisplay + . for each window whose display might need to be updated, compute + a structure, called "glyph matrix", which describes how it + should look on display + . actually update the display of windows on the glass where the + newly obtained glyph matrix differs from the one produced by the + previous redisplay cycle + + The first of these steps is done by `redisplay_internal' itself, by + looping through all the frames and testing their various flags, + such as their visibility. The result of this could be that only + the selected window on the selected frame must be redisplayed, or + it could conclude that other windows need to be considered as well. + + The second step considers each window that might need to be + redisplayed. This could be only the selected window, or the window + trees of one or more frames. The function which considers a window + and decides whether it actually needs redisplay is + `redisplay_window'. It does so by looking at the changes in + position of point, in buffer text, in text properties, overlays, + etc. These changes can be deduced from window and buffer + structures, and from some global variables like `beg_unchanged' and + `end_unchanged'. The current contents of the display are recorded + in a `glyph matrix', a two-dimensional matrix of glyph structures. + Each row in such a matrix corresponds to a line on the display, and + each glyph in a row corresponds to a column displaying a character, + an image, or what else. This matrix is called the `current glyph + matrix', or `current matrix', in redisplay terminology. + + For buffer parts that have been changed since the last redisplay, + `redisplay_window' constructs a second glyph matrix is constructed, + the so called `desired glyph matrix' or short `desired matrix'. It + does so in the most optimal way possible, avoiding the examination + of text that didn't change, reusing portions of the current matrix + if possible, etc. It could, in particular, decide that a window + doesn't need to be redisplayed at all. + + This second step of redisplay also updates the parts of the desired + matrix that correspond to the mode lines, header lines, and + tab-lines of the windows which need that; see `display_mode_lines'. + + In the third and last step, the current and desired matrix are then + compared to find a cheap way to update the display, e.g. by reusing + part of the display by scrolling lines. The actual update of the + display of each window by comparing the desired and the current + matrix is done by `update_window', which calls functions which draw + to the glass (those functions are specific to the type of the + window's frame: X, w32, NS, etc.). Once the display of a window on the glass has been updated, its desired matrix is used to update the corresponding rows of the current matrix, and then the desired matrix is discarded. You will find a lot of redisplay optimizations when you start - looking at the innards of redisplay. The overall goal of all these - optimizations is to make redisplay fast because it is done - frequently. Some of these optimizations are implemented by the - following functions: + looking at the innards of `redisplay_window'. The overall goal of + all these optimizations is to make redisplay fast because it is + done frequently. Some of these optimizations are implemented by + the following functions: . try_cursor_movement @@ -142,16 +175,17 @@ along with GNU Emacs. If not, see . */ Note that there's one more important optimization up Emacs's sleeve, but it is related to actually redrawing the potentially - changed portions of the window/frame, not to reproducing the - desired matrices of those potentially changed portions. Namely, - the function update_frame and its subroutines, which you will find - in dispnew.c, compare the desired matrices with the current - matrices, and only redraw the portions that changed. So it could - happen that the functions in this file for some reason decide that - the entire desired matrix needs to be regenerated from scratch, and - still only parts of the Emacs display, or even nothing at all, will - be actually delivered to the glass, because update_frame has found - that the new and the old screen contents are similar or identical. + changed portions of the window/frame as part of the third step, not + to generating the desired matrices of those potentially changed + portions. Namely, the function `update_frame' and its subroutines, + which you will find in dispnew.c, compare the desired matrices with + the current matrices, and only redraw the portions that changed. + So it could happen that the functions in this file for some reason + decide that the entire desired matrix needs to be regenerated from + scratch, and still only parts of the Emacs display, or even nothing + at all, will be actually delivered to the glass, because + `update_frame' has found that the new and the old screen contents + are similar or identical. Desired matrices. @@ -161,7 +195,7 @@ along with GNU Emacs. If not, see . */ redisplay tries to optimize its work, and thus only generates glyphs for rows that need to be updated on the screen. Rows that don't need to be updated are left "disabled", and their contents - should be ignored. + in the desired matrix should be ignored. The function `display_line' is the central function to look at if you are interested in how the rows of the desired matrix are From 9d93c6ba14aa0bdb312553ebbda751fe70c14852 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Wed, 19 Jul 2023 19:28:48 +0300 Subject: [PATCH 10/13] ; * src/xdisp.c: Fix typos in the commentary. --- src/xdisp.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 3a347c1f923..5a014e87e6c 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -109,11 +109,11 @@ along with GNU Emacs. If not, see . */ matrix', or `current matrix', in redisplay terminology. For buffer parts that have been changed since the last redisplay, - `redisplay_window' constructs a second glyph matrix is constructed, - the so called `desired glyph matrix' or short `desired matrix'. It - does so in the most optimal way possible, avoiding the examination - of text that didn't change, reusing portions of the current matrix - if possible, etc. It could, in particular, decide that a window + `redisplay_window' constructs a second glyph matrix, the so called + `desired glyph matrix' or short `desired matrix'. It does so in + the most optimal way possible, avoiding the examination of text + that didn't change, reusing portions of the current matrix if + possible, etc. It could, in particular, decide that a window doesn't need to be redisplayed at all. This second step of redisplay also updates the parts of the desired @@ -123,9 +123,9 @@ along with GNU Emacs. If not, see . */ In the third and last step, the current and desired matrix are then compared to find a cheap way to update the display, e.g. by reusing part of the display by scrolling lines. The actual update of the - display of each window by comparing the desired and the current - matrix is done by `update_window', which calls functions which draw - to the glass (those functions are specific to the type of the + display of each window, by comparing the desired and the current + matrix, is done by `update_window', which calls functions which + draw to the glass (those functions are specific to the type of the window's frame: X, w32, NS, etc.). Once the display of a window on the glass has been updated, its From 5de5e4b4d0a0d90240ca055d29f264be39831e16 Mon Sep 17 00:00:00 2001 From: Po Lu Date: Thu, 20 Jul 2023 15:55:07 +0800 Subject: [PATCH 11/13] Fix typos and ommissions in cus-edit.el * lisp/cus-edit.el (custom-display): Add missing display types. --- lisp/cus-edit.el | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el index 0373842de09..9ec10e63221 100644 --- a/lisp/cus-edit.el +++ b/lisp/cus-edit.el @@ -3533,7 +3533,11 @@ GNUstep or Macintosh OS Cocoa interface.") (const :format "PGTK " :sibling-args (:help-echo "\ Pure-GTK interface.") - ns) + pgtk) + (const :format "Haiku " + :sibling-args (:help-echo "\ +Haiku interface.") + haiku) (const :format "DOS " :sibling-args (:help-echo "\ Plain MS-DOS.") From 3af27a4b815906c2ee38cbaf3a765289b3df061a Mon Sep 17 00:00:00 2001 From: Po Lu Date: Thu, 20 Jul 2023 16:01:34 +0800 Subject: [PATCH 12/13] Improve commentary in nsfns.m * src/nsfns.m (lispString): Avoid C++ comment and make the commentary actually relevant to the reason `make_string' is used. --- src/nsfns.m | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/nsfns.m b/src/nsfns.m index 5ae2cc77bb2..fe565a423aa 100644 --- a/src/nsfns.m +++ b/src/nsfns.m @@ -3829,7 +3829,11 @@ handled fairly well by the NS libraries (displayed with distinct /* Make a Lisp string from an NSString. */ - (Lisp_Object)lispString { - // make_string behaves predictably and correctly with UTF-8 input. + /* `make_string' creates a string with a given length, instead of + searching for a trailing NULL byte to determine its end. This is + important because this function is called to convert NSString + objects containing clipboard data, which can contain NUL bytes, + into Lisp strings. (bug#64697) */ return make_string ([self UTF8String], [self lengthOfBytesUsingEncoding: NSUTF8StringEncoding]); } From 4bd8e8c6d2b75d678c13ae34c401668d3e8eecc7 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Thu, 20 Jul 2023 13:23:01 +0300 Subject: [PATCH 13/13] ; * src/xdisp.c: Fix wording in commentary. --- src/xdisp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 5a014e87e6c..fdb4acd71bf 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -78,8 +78,7 @@ along with GNU Emacs. If not, see . */ At its highest level, redisplay can be divided into 3 distinct steps, all of which are visible in `redisplay_internal': - . decide which windows on which frames need their windows - considered for redisplay + . decide which frames need their windows to be considered for redisplay . for each window whose display might need to be updated, compute a structure, called "glyph matrix", which describes how it should look on display