Vim 8 pre-announcement

[Bram Moolenaar]

Hello Vim users,

Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
released in about two weeks.

This is a last chance to modify new features in a way that is not
backwards compatible. Once 8.0 is out we can't make changes that would
break plugins.

An overview of new features can be found in:
https://github.com/vim/vim/blob/master/runtime/doc/version8.txt
A version with links (but a day older):
http://vimhelp.appspot.com/version8.txt.html

Please review the new features, try them out and report what should be
changed on the vim-dev maillist. Of course you should also report bugs
you find.

Happy Vimming!


PS. If you are interested in meeting Vim users: Vimfest is happening in
Berlin Sept. 16-18. http://vimfest.org


--
How To Keep A Healthy Level Of Insanity:
9. As often as possible, skip rather than walk.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Tony Mechelynck]

On Tue, Aug 16, 2016 at 6:43 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt

IIUC, ":help version8.txt" in the latest (today's) runtime files gives
the same as the above, with the usual Vim hotlinks: double-click a
help tag, or put the cursor on it and hit Ctrl-]

The current version8.txt is dated 2016 Aug 16 at the end of its first line.

> A version with links (but a day older):
> http://vimhelp.appspot.com/version8.txt.html
>
> Please review the new features, try them out and report what should be
> changed on the vim-dev maillist. Of course you should also report bugs
> you find.
>
> Happy Vimming!
>
>
> PS. If you are interested in meeting Vim users: Vimfest is happening in
> Berlin Sept. 16-18. http://vimfest.org
>
>
> --
> How To Keep A Healthy Level Of Insanity:
> 9. As often as possible, skip rather than walk.
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>

Best regards,
Tony.

[skywind3000]

Bram:

> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.

Can we have a binary mode in channels ? Which could be used to implement
a virtual terminal inside vim in VimScript.

According to the ":help channel", There is a "raw" mode in channels, but it
will treat the whole message as a string, not a binary data.

[Bryan Richter]

On Tue, Aug 16, 2016 at 06:43:47PM +0200, Bram Moolenaar wrote:
>
> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt

These are exciting changes! However, after reading through the help
text for 'packages', I was rather surprised by a few things. Primarily
the last advantage listed:

A package can contain plugins that are automatically loaded on
startup and ones that are only loaded when needed with `:packadd`.

As it currently stands, there are a variety of 'plugin managers' that,
it would seem, could be superseded by 'packages'. Unfortunately, of
all of the dozens of plugins I have enjoyed managing with these
managers,

- None are compatible with 'packages' because of the design of this
"advantage" (using start/ and opt/).
- None need it
- Maintaining backward compatibility looks troubling, to say the
least

The elegance of existing package managers is that plugins *are*
packages. 'packages' breaks that elegance.

In summary, every plugin I use today is not compatible with
'packages'. When vim8 is released, they will all have to be updated.
But I don't think they will be updated to support 'packages'. Instead,
I suspect their documentation will be updated to say, "Don't use
'packages'".

Thus, I am very interested to learn of the rationale for these design
decisions.

Sorry if this has been discussed to death elsewhere. This is the
second major release of vim that I've "lived through", but I'm new to
the mailing list. :)

-Bryan

[thinca]

Hi Bram,

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

:help job-term says:

*job-term*
"term": "open" Start a terminal and connect the job
stdin/stdout/stderr to it.
NOTE: Not implemented yet!

This is not implemented yet. Is this not implemented in Vim 8.0?

Thanks,
thinca

[LCD 47]

On 17 August 2016, Bryan Richter <b...@chreekat.net> wrote:
[...]

> In summary, every plugin I use today is not compatible with
> 'packages'.

[...]

All plugins are compatible with packages. You just need to move
them from where you used to put them.

/lcd

[Bryan Richter]

Ok, I've seen some of the poor leaps I was making. Current packages
are, in fact, compatible with 'packages'. Proof:

With pathogen:

packages=(
a
b
...)
mkdir -p ~/.vim/bundle
cd !$
for p in $packages; do
git clone $package
done

With packages:

packages=(
a
b
...)
for p in $packages; do
mkdir -p ~/.vim/pack/$package/start
cd !$
git clone $package
done

What is still true, however, is that any package designed for
'packages' will be incompatible with all current plugin managers,
since they are unaware of the start/opt subdirectories.

Newer versions of the managers can, of course, be modified to support
both old- and new-style packages — but it's still a little unfortunate
that there will be such a thing as "old- and new-style packages".

I retract my shock and horror and ask that it be replaced with a
passing dismay.

Thanks.

[Xavier Noria]

On Wed, Aug 17, 2016 at 3:21 PM, Bryan Richter <b...@chreekat.net> wrote:

    packages=(
      a
      b
      ...)
    for p in $packages; do
        mkdir -p ~/.vim/pack/$package/start
        cd !$
        git clone $package
    done

 

From the description of the feature I imagined one could basically have a local bundle:

    ~/.vim/pack/bundle/start

where you just throw individual plugins in a similar manner as how you do with pathogen.vim, and expect proper packages to appear and have their own directory.

Maybe people that have already used packages have some best practices in mind.

[Nicola]

You may search for the thread "Packages: best practices?" from last
March, where I outlined my ideas.

Nicola

[LCD 47]

Or like this:

packages=(
a
b
...
)
mkdir -p ~/.vim/pack/bundle/start

cd !$
for p in $packages; do
git clone "$p"

done

> What is still true, however, is that any package designed for
> 'packages' will be incompatible with all current plugin managers,
> since they are unaware of the start/opt subdirectories.

[...]

No. You really should read the discussion on vim_dev. While the
current implementation didn't make everybody happy, plugins designed for
"packages" don't need to be incompatible with existing plugin managers.

/lcd

[Bram Moolenaar]

Raw mode is nearly binary. The only limitation I'm aware of is that it
can't handle NUL bytes. And since there is no way to deal with binary
data anyway in Vim script, it's probably the only thing possible.

An alternative is NL mode, then you get lines at a time where NUL bytes
have been changed to NL bytes. But it will be stuck waiting for the
next NL.

--
This planet has -- or rather had -- a problem, which was this: most
of the people living on it were unhappy for pretty much of the time.
Many solutions were suggested for this problem, but most of these
were largely concerned with the movements of small green pieces of
paper, which is odd because on the whole it wasn't the small green
pieces of paper that were unhappy.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

[Nikolay Aleksandrovich Pavlov]

2016-08-18 0:17 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
>
> Skywind3000 wrote:
>
>> > Hello Vim users,
>> >
>> > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
>> > released in about two weeks.
>> >
>> > This is a last chance to modify new features in a way that is not
>> > backwards compatible. Once 8.0 is out we can't make changes that would
>> > break plugins.
>>
>> Can we have a binary mode in channels ? Which could be used to implement
>> a virtual terminal inside vim in VimScript.
>>
>> According to the ":help channel", There is a "raw" mode in channels, but it
>> will treat the whole message as a string, not a binary data.
>
> Raw mode is nearly binary. The only limitation I'm aware of is that it
> can't handle NUL bytes. And since there is no way to deal with binary
> data anyway in Vim script, it's probably the only thing possible.

Neovim handled this just fine from the very beginning: just callback
receives not a string, but a `readfile(,'b')`-style list. Though it
led to some confusion (line `"abc\n"` may be received as `['abc', '']`
or `['ab']` and `['c', '']`, but some plugin authors thought that
Neovim is waiting for line to finish, so `'ab'` in the second example
is the whole line), this is the only normal way to represent binary
data in VimL. Another variant is a list like `[0x61, 0x62, 0x63,
0x0A]` which has very high overhead.

>
> An alternative is NL mode, then you get lines at a time where NUL bytes
> have been changed to NL bytes. But it will be stuck waiting for the
> next NL.
>
> --
> This planet has -- or rather had -- a problem, which was this: most
> of the people living on it were unhappy for pretty much of the time.
> Many solutions were suggested for this problem, but most of these
> were largely concerned with the movements of small green pieces of
> paper, which is odd because on the whole it wasn't the small green
> pieces of paper that were unhappy.
> -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>

[Roland Puntaier]

Hello Bram,

On 8/16/2016 6:43 PM, Bram Moolenaar wrote:

> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt
> A version with links (but a day older):
> http://vimhelp.appspot.com/version8.txt.html
>
> Please review the new features, try them out and report what should be
> changed on the vim-dev maillist. Of course you should also report bugs
> you find.
>
> Happy Vimming!
>
>
> PS. If you are interested in meeting Vim users: Vimfest is happening in
> Berlin Sept. 16-18. http://vimfest.org

I was wondering whether you could also include into Vim 8 the following patch
(the original reason for pull request https://github.com/vim/vim/pull/543,
which you can reject, since the langmap part doesn't seem to have a chance in, anyway)
The behavior this patch tries to achieve is given by the test case in the patch.

diff --git src/getchar.c src/getchar.c
index 1c170cc..ce68a2f 100644
--- src/getchar.c
+++ src/getchar.c
@@ -2144,12 +2144,15 @@ vgetorpeek(int advance)
/*
* Only consider an entry if the first character
* matches and it is for the current state.
- * Skip ":lmap" mappings if keys were mapped.
*/
if (mp->m_keys[0] == c1
&& (mp->m_mode & local_State)
- && ((mp->m_mode & LANGMAP) == 0
- || typebuf.tb_maplen == 0))
+ /* && ((mp->m_mode & LANGMAP) == 0 ||
typebuf.tb_maplen == 0)
+ * Used to skip ":lmap" mappings for keymap'ed
keys here,
+ * but the result of the keymap is not placed in
the register,
+ * so the register content needs to be remapped
here.
+ */
+ )
{
#ifdef FEAT_LANGMAP
int nomap = nolmaplen;
diff --git src/testdir/test_digraph.vim src/testdir/test_digraph.vim
index 9550085..3578ced 100644
--- src/testdir/test_digraph.vim
+++ src/testdir/test_digraph.vim
@@ -450,6 +450,20 @@ func! Test_loadkeymap()
bw!
endfunc

+func! Test_registerkeymap()
+ if !has('keymap')
+ return
+ endif
+ new
+ set keymap=russian-jcukenwin
+ set iminsert=1
+ call feedkeys("qqods\<esc>qdd@q", 'tx')
+ call assert_equal("вы", getline('.'))
+ " reset keymap and encoding option
+ set keymap=
+ bw!
+endfunc
+
func! Test_digraph_cmndline()
" Create digraph on commandline
" This is a hack, to let Vim create the digraph in commandline mode

[Bram Moolenaar]

Roland Puntaier wrote:

> I was wondering whether you could also include into Vim 8 the following patch
> (the original reason for pull request https://github.com/vim/vim/pull/543,
> which you can reject, since the langmap part doesn't seem to have a chance in, anyway)
> The behavior this patch tries to achieve is given by the test case in
> the patch.

This is the wrong solution, it is not backwards compatible and will
cause problems.

The todo list mentions the right solution:

- in vgetorpeek() apply langmap to the typeahead buffer and put the result in
a copy-buffer, only when langmap is appropriate for the current mode. Then
check for mapping and let gotchars() work on the copy-buffer.
- Remove LANGMAP_ADJUST() in other parts of the code. Make sure the mode is
covered by the above change.
So that replaying the register doesn't use keymap/langmap and still does the
same thing.

I know this is much more difficult to implement, but we should not
include a bad hack for that reason.

--
If you put 7 of the most talented OSS developers in a room for a week
and asked them to fix a bug in a spreadsheet program, in 1 week
you'd have 2 new mail readers and a text-based web browser.

[tjg]

(Sorry if this is not the right place to ask the following question)
I use vim's conceal feature (for comments/tags/notes/reminders/corrections/variants, etc...) about the text (not code) I write in .txt files. This allows me to see either the ur-text, or the full W.I.P.

However I am a little frustrated by one fact : conceal hides the text I want to hide, but :

- if the line (text + concealed comments) I write is longer than the screen width (in my case about 200 characters),
- even though my text is 150 characters long and my concealed comments are 100 characters long
- it will show one line but in 2 screen lines, because, if I have correctly understood, it works on the full text and not only on the un-concealed text

I insist : this is a minor frustration, but has this problem been by any chance treated in vim 8.0 ?

Thanks in advance, and thanks for vim

[skywind3000]

Bram:

> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>

Visual C++ 6 can play a sound when build stop.

so Can I have a command ':bell' to ring the bell to notify myself that my async-build job has finished and I should check the quickfix output now while I am focusing on editing or navigating source.

[skywind3000]

afplay or other command line utilities could be used to play a .wav file in the desktop gvim, but there is no way to make a voice in a terminal vim.