Commit 8f68449c authored by Glenn Morris's avatar Glenn Morris

Merge from origin/emacs-26

0b810ebc Fix a typo in char-width-table
3f00db7c Minor update in admin/notes/unicode
bcd0115e Fix lisp indent infloop on unfinished strings (Bug#37045)
5f992d19 Improve commentary in composite.el
3a04be20 ; Improve commentary in xdisp.c
15de1d11 Fix markup in dired-x.texi
bda7fc75 ; Fix typo in a doc string of speedbar.el
6f57ef9d * src/callproc.c (Fcall_process): Doc fix.

# Conflicts:
#	doc/misc/dired-x.texi
#	lisp/international/characters.el
#	src/callproc.c
parents 65dc07f5 0b810ebc
......@@ -62,6 +62,9 @@ of OTF script tags in otf-script-alist, whose source is on this page:
https://docs.microsoft.com/en-us/typography/opentype/spec/scripttags
Other databases in fontset.el might also need to be updated as needed.
One notable place to check is the function setup-default-fontset,
where new scripts will generally need some addition, most probably to
the list of "simple" scripts (search for "Simple").
The function 'ucs-names', defined in lisp/international/mule-cmds.el,
might need to be updated because it knows about used and unused ranges
......
This diff is collapsed.
......@@ -555,6 +555,11 @@ All non-spacing characters have this function in
;; This sequence doesn't start with a proper base character.
((memq (get-char-code-property (lgstring-char gstring 0)
'general-category)
;; "Improper" base characters are of the following general
;; categories:
;; Mark (nonspacing, combining, enclosing)
;; Separator (space, line, paragraph)
;; Other (control, format, surrogate)
'(Mn Mc Me Zs Zl Zp Cc Cf Cs))
nil)
......@@ -647,6 +652,7 @@ All non-spacing characters have this function in
de (+ de yoff)))
((and (= class 0)
(eq (get-char-code-property (lglyph-char glyph)
;; Me = enclosing mark
'general-category) 'Me))
;; Artificially laying out glyphs in an enclosing
;; mark is difficult. All we can do is to adjust
......@@ -772,7 +778,8 @@ prepending a space before it."
'general-category)
'Cf)
(progn
;; Compose by replacing with a space.
;; Compose Cf (format) control characters by
;; replacing with a space.
(lglyph-set-char glyph 32)
(lglyph-set-width glyph 1)
(setq i (1+ i)))
......
......@@ -822,7 +822,7 @@ by more than one line to cross a string literal."
(setq last-sexp (nth 2 ppss)))
(setq depth (car ppss))
;; Skip over newlines within strings.
(nth 3 ppss))
(and (not (eobp)) (nth 3 ppss)))
(let ((string-start (nth 8 ppss)))
(setq ppss (parse-partial-sexp (point) (point-max)
nil nil ppss 'syntax-table))
......@@ -838,17 +838,22 @@ by more than one line to cross a string literal."
indent-stack)))))
(prog1
(let (indent)
(cond ((= (forward-line 1) 1) nil)
;; Negative depth, probably some kind of syntax error.
(cond ((= (forward-line 1) 1)
;; Can't move to the next line, apparently end of buffer.
nil)
((null indent-stack)
;; Reset state.
;; Negative depth, probably some kind of syntax
;; error. Reset the state.
(setq ppss (parse-partial-sexp (point) (point))))
((car indent-stack))
((integerp (setq indent (calculate-lisp-indent ppss)))
(setf (car indent-stack) indent))
((consp indent) ; (COLUMN CONTAINING-SEXP-START)
(car indent))
;; This only happens if we're in a string.
;; This only happens if we're in a string, but the
;; loop should always skip over strings (unless we hit
;; end of buffer, which is taken care of by the first
;; clause).
(t (error "This shouldn't happen"))))
(setf (lisp-indent-state-stack state) indent-stack)
(setf (lisp-indent-state-ppss-point state) ppss-point)
......
......@@ -986,7 +986,7 @@ with L, LRE, or LRO Unicode bidi character type.")
(#x1039 . #x103A)
(#x103D . #x103E)
(#x1058 . #x1059)
(#x105E . #x1160)
(#x105E . #x1060)
(#x1071 . #x1074)
(#x1082 . #x1082)
(#x1085 . #x1086)
......
......@@ -697,7 +697,7 @@ singular expression. This variable will be turned into
function `speedbar-add-supported-extension' to add a new extension at
runtime, or use the configuration dialog to set it in your init file.
If you add an extension to this list, and it does not appear, you may
need to also modify `completion-ignored-extension' which will also help
need to also modify `completion-ignored-extensions' which will also help
file completion."
:group 'speedbar
:type '(repeat (regexp :tag "Extension Regexp"))
......
......@@ -220,7 +220,7 @@ DEFUN ("call-process", Fcall_process, Scall_process, 1, MANY, 0,
doc: /* Call PROGRAM synchronously in separate process.
The remaining arguments are optional.
The program's input comes from file INFILE (nil means `/dev/null').
The program's input comes from file INFILE (nil means `null-device').
If you want to make the input come from an Emacs buffer, use
`call-process-region' instead.
......
......@@ -152,6 +152,8 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
description of the environment in which the text is to be
displayed. But this is too early, read on.
Iteration over buffer and strings.
Characters and pixmaps displayed for a range of buffer text depend
on various settings of buffers and windows, on overlays and text
properties, on display tables, on selective display. The good news
......@@ -176,6 +178,46 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
current X and Y position, and lots of other stuff you can better
see in dispextern.h.
The "stop position".
Some of the fields maintained by the iterator change relatively
infrequently. These include the face of the characters, whether
text is invisible, the object (buffer or display or overlay string)
being iterated, character composition info, etc. For any given
buffer or string position, these sources of information that
affects the display can be determined by calling the appropriate
primitives, such as Fnext_single_property_change, but both these
calls and the processing of their return values is relatively
expensive. To optimize redisplay, the display engine checks these
sources of display information only when needed. To that end, it
always maintains the position of the next place where it must stop
and re-examine all those potential sources. This is called "stop
position" and is stored in the stop_charpos field of the iterator.
The stop position is updated by compute_stop_pos, which is called
whenever the iteration reaches the current stop position and
processes it. Processing a stop position is done by handle_stop,
which invokes a series of handlers, one each for every potential
source of display-related information; see the it_props array for
those handlers. For example, one handler is handle_face_prop,
which detects changes in face properties, and supplies the face ID
that the iterator will use for all the glyphs it generates up to
the next stop position; this face ID is the result of realizing the
face specified by the relevant text properties at this position.
Each handler called by handle_stop processes the sources of display
information for which it is "responsible", and returns a value
which tells handle_stop what to do next.
Once handle_stop returns, the information it stores in the iterator
fields will not be refreshed until the iteration reaches the next
stop position, which is computed by compute_stop_pos called at the
end of handle_stop. compute_stop_pos examines the buffer's or
string's interval tree to determine where the text properties
change, finds the next position where overlays and character
composition can change, and stores in stop_charpos the closest
position where any of these factors should be reconsider.
Producing glyphs.
Glyphs in a desired matrix are normally constructed in a loop
calling get_next_display_element and then PRODUCE_GLYPHS. The call
to PRODUCE_GLYPHS will fill the iterator structure with pixel
......@@ -191,23 +233,28 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
Frame matrices.
That just couldn't be all, could it? What about terminal types not
supporting operations on sub-windows of the screen? To update the
display on such a terminal, window-based glyph matrices are not
well suited. To be able to reuse part of the display (scrolling
lines up and down), we must instead have a view of the whole
screen. This is what `frame matrices' are for. They are a trick.
Frames on terminals like above have a glyph pool. Windows on such
a frame sub-allocate their glyph memory from their frame's glyph
supporting operations on sub-windows of the screen (a.k.a. "TTY" or
"text-mode terminal")? To update the display on such a terminal,
window-based glyph matrices are not well suited. To be able to
reuse part of the display (scrolling lines up and down), we must
instead have a view of the whole screen. This is what `frame
matrices' are for. They are a trick.
Frames on text terminals have a glyph pool. Windows on such a
frame sub-allocate their glyph memory from their frame's glyph
pool. The frame itself is given its own glyph matrices. By
coincidence---or maybe something else---rows in window glyph
matrices are slices of corresponding rows in frame matrices. Thus
writing to window matrices implicitly updates a frame matrix which
provides us with the view of the whole screen that we originally
wanted to have without having to move many bytes around. To be
honest, there is a little bit more done, but not much more. If you
plan to extend that code, take a look at dispnew.c. The function
build_frame_matrix is a good starting point.
wanted to have without having to move many bytes around. Then
updating all the visible windows on text-terminal frames is done by
using the frame matrices, which allows frame-global optimization of
what is actually written to the glass.
To be honest, there is a little bit more done, but not much more.
If you plan to extend that code, take a look at dispnew.c. The
function build_frame_matrix is a good starting point.
Bidirectional display.
......@@ -220,9 +267,10 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
concerned, the effect of calling bidi_move_to_visually_next, the
main interface of the reordering engine, is that the iterator gets
magically placed on the buffer or string position that is to be
displayed next. In other words, a linear iteration through the
buffer/string is replaced with a non-linear one. All the rest of
the redisplay is oblivious to the bidi reordering.
displayed next in the visual order. In other words, a linear
iteration through the buffer/string is replaced with a non-linear
one. All the rest of the redisplay is oblivious to the bidi
reordering.
Well, almost oblivious---there are still complications, most of
them due to the fact that buffer and string positions no longer
......@@ -231,7 +279,8 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
monotonously changing with vertical positions. Also, accounting
for face changes, overlays, etc. becomes more complex because
non-linear iteration could potentially skip many positions with
changes, and then cross them again on the way back...
changes, and then cross them again on the way back (see
handle_stop_backwards)...
One other prominent effect of bidirectional display is that some
paragraphs of text need to be displayed starting at the right
......@@ -252,7 +301,7 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
This way, the terminal-specific back-end can still draw the glyphs
left to right, even for R2L lines.
Bidirectional display and character compositions
Bidirectional display and character compositions.
Some scripts cannot be displayed by drawing each character
individually, because adjacent characters change each other's shape
......@@ -272,15 +321,15 @@ along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
Each of these grapheme clusters is then delivered to PRODUCE_GLYPHS
in the direction corresponding to the current bidi scan direction
(recorded in the scan_dir member of the `struct bidi_it' object
that is part of the buffer iterator). In particular, if the bidi
iterator currently scans the buffer backwards, the grapheme
clusters are delivered back to front. This reorders the grapheme
clusters as appropriate for the current bidi context. Note that
this means that the grapheme clusters are always stored in the
LGSTRING object (see composite.c) in the logical order.
that is part of the iterator). In particular, if the bidi iterator
currently scans the buffer backwards, the grapheme clusters are
delivered back to front. This reorders the grapheme clusters as
appropriate for the current bidi context. Note that this means
that the grapheme clusters are always stored in the LGSTRING object
(see composite.c) in the logical order.
Moving an iterator in bidirectional text
without producing glyphs
without producing glyphs.
Note one important detail mentioned above: that the bidi reordering
engine, driven by the iterator, produces characters in R2L rows
......@@ -284,7 +284,11 @@ Expected initialization file: `%s'\"
(lisp-indent-line)
(should (equal (buffer-string) "prompt> foo"))))
(ert-deftest lisp-indent-unfinished-string ()
"Don't infloop on unfinished string (Bug#37045)."
(with-temp-buffer
(insert "\"\n")
(lisp-indent-region (point-min) (point-max))))
(provide 'lisp-mode-tests)
;;; lisp-mode-tests.el ends here
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment