From 184f8423492f62b67b499efc53582dad4917ca5a Mon Sep 17 00:00:00 2001 From: zeertzjq Date: Wed, 20 Dec 2023 07:02:48 +0800 Subject: vim-patch:955652f6df9c (#26667) runtime(doc): Update change.txt (vim/vim#13725) Fix-up and clarify commit e06f2b498ccca921f34a1bec4464f042a5a2cabd https://github.com/vim/vim/commit/955652f6df9c4a1048fde8028c5c7f7871b5f71a Co-authored-by: K.Takata --- runtime/doc/change.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'runtime') diff --git a/runtime/doc/change.txt b/runtime/doc/change.txt index 61e7c0c6e0..703addf51a 100644 --- a/runtime/doc/change.txt +++ b/runtime/doc/change.txt @@ -424,9 +424,12 @@ octal number. Note that when 'nrformats' includes "octal", decimal numbers with leading zeros cause mistakes, because they can be confused with octal numbers. -Note similarly, when 'nrformats' includes "bin", binary numbers with a leading -'0b' or '0B' can be interpreted as hexadecimal rather than binary since '0b' -are valid hexadecimal digits. +Note similarly, when 'nrformats' includes both "bin" and "hex", binary numbers +with a leading '0x' or '0X' can be interpreted as hexadecimal rather than +binary since '0b' are valid hexadecimal digits. CTRL-A on "0x0b11" results in +"0x0b12", not "0x0b100". +When 'nrformats' includes "bin" and doesn't include "hex", CTRL-A on "0b11" in +"0x0b11" results in "0x0b100". When the number under the cursor is too big to fit into 64 bits, it will be rounded off to the nearest number that can be represented, and the -- cgit