Problem: Vim still supports compiling on NeXTSTEP
Solution: Drop Support (Damien Lejay)
The NeXTSTEP operating system has been obsolete for decades. The
special-case code required to support it adds unnecessary complexity,
preprocessor conditionals, and non-standard workarounds to the codebase.
This commit removes all support for NeXTSTEP, simplifying the code and
build system in several ways:
- Replaced custom configure checks for `union wait` with a standard `AC_CHECK_FUNCS` call for `waitpid`.
- Removed all conditional code that used the non-standard `union wait` for process status, relying solely on a standard `int`.
- Replaced calls to the non-standard `wait4()` function with the POSIX-standard `waitpid()`.
- Cleaned up headers (`os_unix.h`, `os_unixx.h`) to remove NeXT-specific workarounds and macros.
- Removed obsolete NeXT compilation instructions from the INSTALL file.
This change improves maintainability and makes the Unix process handling code more linear and compliant with modern POSIX standards.
related: #18079
closes: #19582
Signed-off-by: Damien Lejay <damien@lejay.be>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- :retab! line 1 and line 4 (main page heading).
- Use four columns whitespace before "by [Author]" in the user manual
heading to match the reference manual formatting.
- double space headings.
closes: #18648
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Use double sentence spacing and wrap lines at 'textwidth'. Code
examples and tables were not wrapped unless this had already been done
locally.
closes: #18453
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Haiku: no full-screen support
Solution: Add support for toggling full-screen using the keyboard
(rymdbar)
Makes toggling using keyboard possible. This change does not add any
`:fullscreen` command (Which currently only macVim has).
See https://www.haiku-os.org/docs/userguide/en/keyboard-shortcuts.html
for motivation on key combination used, as well as terminology choice.
With vim being inconsistent (`:help intro` suggests <A> and <M>, while
<Alt> is used at a dozen other places) following Haiku nomenclature
seems most appropriate.
closes: #18235
Signed-off-by: rymdbar <rymdbar@x20.se>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Nextstep support still included
Solution: Deprecate Nextstep code and undef corresponding feature flag
closes: #18131
Signed-off-by: Damien Lejay <damien@lejay.be>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CTRL-X CTRL-R only completes individual words from registers,
making it difficult to insert complete register content.
Solution: Add consecutive CTRL-X CTRL-R support - first press completes
words, second press completes full register lines, similar to
CTRL-X CTRL-L and CTRL-X CTRL-P behavior (glepnir).
closes: #17395
Signed-off-by: glepnir <glephunter@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: not easily possible to complete from register content
Solution: add register-completion submode using i_CTRL-X_CTRL-R
(glepnir)
closes: #17354
Signed-off-by: glepnir <glephunter@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: regexp: max \U and \%U value is limited by INT_MAX but gives a
confusing error message (related: v8.1.0985).
Solution: give a better error message when the value reaches INT_MAX
When searching Vim allows to get up to 8 hex characters using the /\V
and /\%V regex atoms. However, when using "/\UFFFFFFFF" the code point is
already above what an integer variable can hold, which is 2,147,483,647.
Since patch v8.1.0985, Vim already limited the max codepoint to INT_MAX
(otherwise it caused a crash in the nfa regex engine), but instead of
error'ing out it silently fell back to parse the number as a backslash
value and not as a codepoint value and as such this "/[\UFFFFFFFF]" will
happily find a "\" or an literal "F". And this "/[\d127-\UFFFFFFFF]"
will error out as "reverse range in character class).
Interestingly, the max Unicode codepoint value is U+10FFFF which still
fits into an ordinary integer value, which means, that we don't even
need to parse 8 hex characters, but 6 should have been enough.
However, let's not limit Vim to search for only max 6 hex characters
(which would be a backward incompatible change), but instead allow all 8
characters and only if the codepoint reaches INT_MAX, give a more
precise error message (about what the max unicode codepoint value is).
This allows to search for "[\U7FFFFFFE]" (will likely return "E486
Pattern not found") and "[/\U7FFFFFF]" now errors "E1517: Value too
large, max Unicode codepoint is U+10FFFF".
While this change is straight forward on architectures where long is 8
bytes, this is not so simple on Windows or 32bit architectures where long
is 4 bytes (and therefore the test fails there). To account for that,
let's make use of the vimlong_T number type and make a few corresponding
changes in the regex engine code and cast the value to the expected data
type. This however may not work correctly on systems that doesn't have
the long long datatype (e.g. OpenVMS) and probably the test will fail
there.
fixes: #16949closes: #16994
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: OS/2 and MS-DOS are still mentioned, even though support was
removed long ago.
Solution: Update documentation. (Yegappan Lakshmanan, closes#5368)
Problem: Remarks about functionality not in Vi clutters the help.
Solution: Move all info about what is new in Vim or already existed in Vi to
vi_diff.txt. Remove {not in Vi} remarks. (closes#4268) Add
"noet" to the help files modeline. Also include many other help
file improvements.
Problem: {not in Vi} remarks get in the way of useful help text.
Solution: Make a list of all Vi options, instead of mentioning what Vi does
not have. Update the help text for options.
Christian Brabandt
Doug Kearns
Ola Söder
Luna Razzaghipour
rymdbar
Hirohito Higashi
Damien Lejay
glepnir
Milly
Cthulhux
Bram Moolenaar