view READMEdir/README_os390.txt @ 34416:0a458b49e1e6 v9.1.0131

patch 9.1.0131: buffer-completion may not always find all matches Commit: https://github.com/vim/vim/commit/0dc0bff000fd804c6b0778ccc4554a4e4c82c8c9 Author: Christian Brabandt <cb@256bit.org> Date: Sat Feb 24 14:12:13 2024 +0100 patch 9.1.0131: buffer-completion may not always find all matches Problem: buffer-completion code too complicated and does not always find all matches (irisjae) Solution: do not try to anchor pattern to beginning of line or directory-separator, always return all matches Note: we are considering the non-fuzzy buffer-matching here. Currently, the buffer-completion code makes 2 attempts to match a pattern against the list of available patterns. First try is to match the pattern and anchor it to either the beginning of the file name or at a directory-separator (// or \\). When a match is found, Vim returns the matching buffers and does not try to find a match anywhere within a buffer name. So if you have opened two buffers like /tmp/Foobar.c and /tmp/MyFoobar.c using `:b Foo` will only complete to the first filename, but not the second (the same happens with `getcompletion('Foo', 'buffer')`). It may make sense, that completion priorities buffer names at directory boundaries, but it inconsistent, may cause confusion why a certain buffer name is not completed when typing `:b Foo<C-D>` which returns only a single file name and then pressing Enter (to switch to that buffer), Vim will error with 'E93: More than one match for Foo'). Similar things may happen when wiping the /tmp/Foobar.c pattern and afterwards the completion starts completing other buffers. So let's simplify the code and always match the pattern anywhere in the buffer name, do not try to favor matches at directory boundaries. This is also simplifies the code a bit, we do not need to run over the list of buffers several times, but only twice. fixes #13894 closes: #14082 Signed-off-by: Christian Brabandt <cb@256bit.org>
author Christian Brabandt <cb@256bit.org>
date Sat, 24 Feb 2024 14:30:03 +0100
parents 4635e43f2c6f
children
line wrap: on
line source

README_os390.txt for version 9.1 of Vim: Vi IMproved.

This readme explains how to build Vim on z/OS.  Formerly called OS/390.
See "README.txt" for general information about Vim.

Most likely there are not many users out there using Vim on z/OS. So chances
are good, that some bugs are still undiscovered.

Getting the source to z/OS:
==========================

First get the source code in one big tar file and ftp it a binary to z/OS. If
the tar file is initially compressed with gzip (tar.gz) or bzip2 (tar.bz2)
uncompress it on your PC, as these tools are (most likely) not available on
the mainframe.

To reduce the size of the tar file you might compress it into a zip file. On
z/OS Unix you might have the command "jar" from java to uncompress a zip. Use:
        jar xvf <zip file name>

Unpack the tar file on z/OS with 
        pax -o from=ISO8859-1,to=IBM-1047 -rf vim.tar

Note: The Vim source contains a few bitmaps etc which will be destroyed by
this command, but these files are not needed on zOS (at least not for the
console version).


Compiling:
==========

Vim can be compiled with or without GUI support. For 7.4 only the compilation
without GUI was tested. Below is a section about compiling with X11 but this
is from an earlier version of Vim.

Console only:
-------------

If you build VIM without X11 support, compiling and building is nearly
straightforward. 

Change to the vim directory and do:

    # Don't use c89!
    # Allow intermixing of compiler options and files.

    $ export CC=cc
    $ export _CC_CCMODE=1
    $./configure --with-features=normal --without-x --enable-gui=no
    $ cd src
    $ make

      There may be warnings:
        - include files not found (libc, sys/param.h, ...)
        - Redeclaration of ... differs from ...
        -- just ignore them.

    $ make test

      This will produce lots of garbage on your screen (including error
      messages). Don't worry.

      If the test stops at one point in vim (might happen in test 11), just
      press :q!

      Expected test failures:
        11: If you don't have gzip installed
        24: test of backslash sequences in regexp are ASCII dependent
        42: Multibyte is not supported on z/OS
        55: ASCII<->EBCDIC sorting
        57: ASCII<->EBCDIC sorting
        58: Spell checking is not supported with EBCDIC
        71: Blowfish encryption doesn't work

    $ make install


With X11:
---------

WARNING: This instruction was not tested with Vim 7.4 or later.

There are two ways for building VIM with X11 support. The first way is simple
and results in a big executable (~13 Mb), the second needs a few additional
steps and results in a much smaller executable (~4.5 Mb). These examples
assume you want Motif.

  The easy way:
    $ export CC=cc
    $ export _CC_CCMODE=1
    $ ./configure --enable-max-features --enable-gui=motif
    $ cd src
    $ make

    With this VIM is linked statically with the X11 libraries.

  The smarter way:
    Make VIM as described above. Then create a file named 'link.sed' with the
    following content (see src/link.390):

	s/-lXext  *//g
	s/-lXmu  *//g
	s/-lXm	*/\/usr\/lib\/Xm.x /g
	s/-lX11  */\/usr\/lib\/X11.x /g
	s/-lXt	*//g
	s/-lSM	*/\/usr\/lib\/SM.x /g
	s/-lICE  */\/usr\/lib\/ICE.x /g

    Then do:
    $ rm vim
    $ make

    Now Vim is linked with the X11-DLLs.

    See the Makefile and the file link.sh on how link.sed is used.