Commit 4d66f9fe authored by Glenn Morris's avatar Glenn Morris

Merge from origin/emacs-26

cc3ad9a3 ; * CONTRIBUTE: Clarify rules for committing to release branc...
a89dbe2a * doc/misc/dbus.texi (Type Conversion): Fix typo.  (Bug#33551)
03ee726f ; Add comment to `customize-package-emacs-version-alist'
bce1d1af Improve documentation of gdb-mi.el
parents 2064cd4c cc3ad9a3
......@@ -287,15 +287,23 @@ the current release branch. Periodically, the current release branch
is merged into the master, using the gitmerge function described in
admin/notes/git-workflow.
If you are fixing a bug that exists in the current release, be sure to
commit it to the release branch; it will be merged to the master
branch later by the gitmerge function.
Documentation fixes (in doc strings, in manuals, and in comments)
should always go to the release branch, if the documentation to be
fixed exists and is relevant to the release-branch codebase. Doc
fixes are always considered "safe" -- even when a release branch is in
feature freeze, it can still receive doc fixes.
If you are fixing a bug that exists in the current release, you should
generally commit it to the release branch; it will be merged to the
master branch later by the gitmerge function. However, when the
release branch is for Emacs version NN.2 and later, or when it is for
Emacs version NN.1 that is in the very last stages of its pretest,
that branch is considered to be in a feature freeze: only bug fixes
that are "safe" or are fixing major problems should go to the release
branch, the rest should be committed to the master branch. This is so
to avoid destabilizing the next Emacs release. If you are unsure
whether your bug fix is "safe" enough for the release branch, ask on
the emacs-devel mailing list.
Documentation fixes (in doc strings, in manuals, in NEWS, and in
comments) should always go to the release branch, if the documentation
to be fixed exists and is relevant to the release-branch codebase.
Doc fixes are always considered "safe" -- even when a release branch
is in feature freeze, it can still receive doc fixes.
When you know that the change will be difficult to merge to the
master (e.g., because the code on master has changed a lot), you can
......
......@@ -934,6 +934,7 @@ height and width values during the debugging session.
@cindex GDB User Interface layout
@vindex gdb-many-windows
@vindex gdb-show-main
If the variable @code{gdb-many-windows} is @code{nil} (the default),
@kbd{M-x gdb} normally displays only the GUD interaction buffer.
However, if the variable @code{gdb-show-main} is also non-@code{nil},
......@@ -1033,6 +1034,15 @@ allows you to go backwards, which can be useful for running through
code that has already executed, in order to examine its execution in
more detail.
@vindex gdb-mi-decode-strings
If the file names of the source files are shown with octal escapes,
set the variable @code{gdb-mi-decode-strings} to the appropriate
coding-system, most probably @code{utf-8}. (This is @code{nil} by
default because GDB may emit octal escapes in situations where
decoding is undesirable, and also because the program being debugged
might use an encoding different from the one used to encode non-ASCII
file names on your system.)
@node Breakpoints Buffer
@subsubsection Breakpoints Buffer
......@@ -1172,6 +1182,11 @@ also updates the Locals buffer
(described in the next section).
@end iftex
@vindex gdb-stack-buffer-addresses
If you want the frame address to be shown each stack frame,
customize the variable @code{gdb-stack-buffer-addresses} to a
non-@code{nil} value.
@node Other GDB Buffers
@subsubsection Other GDB Buffers
......
......@@ -1015,7 +1015,7 @@ but different to
The value for a byte D-Bus type can be any integer in the range 0
through 255. If a character is used as argument, modifiers
represented outside this range are stripped of. For example,
represented outside this range are stripped off. For example,
@code{:byte ?x} is equal to @code{:byte ?\M-x}, but it is not equal to
@code{:byte ?\C-x} or @code{:byte ?\M-\C-x}.
......
......@@ -69,7 +69,11 @@
(replace-regexp-in-string "\n" "" (emacs-version))))))
(unless (string-equal "ok" x) (error "%s" x)))
;; Tramp versions integrated into Emacs.
;; Tramp versions integrated into Emacs. If a user option declares a
;; `:package-version' which doesn't belong to an integrated Tramp
;; version, it must be added here as well (see `tramp-syntax', for
;; example). This can be checked by something like
;; (customize-changed "26.1")
(add-to-list
'customize-package-emacs-version-alist
'(Tramp ("2.0.55" . "22.1") ("2.0.57" . "22.2") ("2.0.58-pre" . "22.3")
......@@ -78,8 +82,8 @@
("2.2.3-24.1" . "24.1") ("2.2.3-24.1" . "24.2") ("2.2.6-24.3" . "24.3")
("2.2.9-24.4" . "24.4") ("2.2.11-24.5" . "24.5")
("2.2.13.25.1" . "25.1") ("2.2.13.25.2" . "25.2")
("2.2.13.25.2" . "25.3") ("2.3.3" . "26.1")
("2.3.3.26.1" . "26.1") ("2.3.5.26.2" . "26.2")))
("2.2.13.25.2" . "25.3")
("2.3.3" . "26.1") ("2.3.3.26.1" . "26.1") ("2.3.5.26.2" . "26.2")))
(add-hook 'tramp-unload-hook
(lambda ()
......
......@@ -1120,13 +1120,15 @@ line, and no execution takes place."
(defcustom gdb-show-changed-values t
"If non-nil change the face of out of scope variables and changed values.
Out of scope variables are suppressed with `shadow' face.
Changed values are highlighted with the face `font-lock-warning-face'."
Changed values are highlighted with the face `font-lock-warning-face'.
Used by Speedbar."
:type 'boolean
:group 'gdb
:version "22.1")
(defcustom gdb-max-children 40
"Maximum number of children before expansion requires confirmation."
"Maximum number of children before expansion requires confirmation.
Used by Speedbar."
:type 'integer
:group 'gdb
:version "22.1")
......
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