Screen update issue with incsearch in latest code
Hi, I pretty much lurk here these days but remember seeing some discussion on changes to do with incremental search. I am seeing strange screen jumps with incremental search with the current version 7.4.2295. This is on on Windows and linux. The following will reproduce the issue on Windows. Start in the VIM source directory and invoke vim with gvim -u NONE -U NONE if_cscope.h. Next enable incsearch with ":set incsearch" and then start a search with "/Sto" - this should cause the display to jump to an enum near the end of the file. At this point delete the o to leave "/St" as the search pattern and then hit return to finish the search. I see VIM jumping back to the top of the file but with the cursor at the same position as for the search. If then hit j to go down one line vim jumps back to the end of the file where the original search succeeded. The action that seems to trigger the unexpected jumps around the buffer is deleting characters from the search pattern. It can be confusing as the screen doesn't initially display what you are expecting (with the cursor appearing beyond the end of a line sometimes) and then any cursor movement cause the display to jump again. HTH - TTFN Mike -- Tennis racket broken, anyone got a extra cat? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Syntax files: Removed check for version < 600
Yesterday I went through all the syntax files and removed the parts that were there only for Vim versions older than 6.0. Most checks were "version < 600" or "version < 508". Since these versions are ancient there is no use for these checks. Quite a few actively maintained syntax files had already dropped the version check. Waiting for old files to be updated or going around to reach out to maintainers would take a very long time. So I just did the change to improve consistency and avoid that these useless lines get copied over when someone creates a new syntax file. If you maintain a syntax file, please compare with the version currently in the repository and update your local copy, if needed. You can also remove the use of the HiLink command and use ":hi def link" directly. I don't expect this change to cause any problem. Let me know if you spot something anyway. -- FIXME and XXX are two common keywords used to mark broken or incomplete code not only since XXX as a sex reference would grab everybody's attention but simply due to the fact that Vim would highlight these words. -- Hendrik Scholz /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Screen update issue with incsearch in latest code
Yep, it is a regression introduced by the work for CTRL-N/P with incsearch in 7.4.2259. On 31/08/2016 12:09, Mike Williams wrote: Hi, I pretty much lurk here these days but remember seeing some discussion on changes to do with incremental search. I am seeing strange screen jumps with incremental search with the current version 7.4.2295. This is on on Windows and linux. The following will reproduce the issue on Windows. Start in the VIM source directory and invoke vim with gvim -u NONE -U NONE if_cscope.h. Next enable incsearch with ":set incsearch" and then start a search with "/Sto" - this should cause the display to jump to an enum near the end of the file. At this point delete the o to leave "/St" as the search pattern and then hit return to finish the search. I see VIM jumping back to the top of the file but with the cursor at the same position as for the search. If then hit j to go down one line vim jumps back to the end of the file where the original search succeeded. The action that seems to trigger the unexpected jumps around the buffer is deleting characters from the search pattern. It can be confusing as the screen doesn't initially display what you are expecting (with the cursor appearing beyond the end of a line sometimes) and then any cursor movement cause the display to jump again. HTH - TTFN Mike Mike -- Tennis racket broken, anyone got a extra cat? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Screen update issue with incsearch in latest code
Thanks for the report and sorry for that. I'll look into it and post an update. Best, Christian Am 2016-08-31 15:36, schrieb Mike Williams: Yep, it is a regression introduced by the work for CTRL-N/P with incsearch in 7.4.2259. On 31/08/2016 12:09, Mike Williams wrote: Hi, I pretty much lurk here these days but remember seeing some discussion on changes to do with incremental search. I am seeing strange screen jumps with incremental search with the current version 7.4.2295. This is on on Windows and linux. The following will reproduce the issue on Windows. Start in the VIM source directory and invoke vim with gvim -u NONE -U NONE if_cscope.h. Next enable incsearch with ":set incsearch" and then start a search with "/Sto" - this should cause the display to jump to an enum near the end of the file. At this point delete the o to leave "/St" as the search pattern and then hit return to finish the search. I see VIM jumping back to the top of the file but with the cursor at the same position as for the search. If then hit j to go down one line vim jumps back to the end of the file where the original search succeeded. The action that seems to trigger the unexpected jumps around the buffer is deleting characters from the search pattern. It can be confusing as the screen doesn't initially display what you are expecting (with the cursor appearing beyond the end of a line sometimes) and then any cursor movement cause the display to jump again. HTH - TTFN Mike Mike -- Tennis racket broken, anyone got a extra cat? -- -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Update Japanese translations to catch up 7.4.2295
Ah, I have forgot to notice one thing. It includes totor.ja files from this release. It was granted by the author Yasuhiro Matsumoto (mattn) Thanks 2016-08-31 23:05 GMT+09:00 MURAOKA Taro : > Hi Bram and the list. > > > I want to update Japanese files for Vim as attached. > It is a release from https://github.com/vim-jp/lang-ja, > and you can see details at > https://github.com/vim-jp/lang-ja/releases/tag/20160831 > > I'm very happy if it was included to Vim 8.0 release ;) > > Best > -- > MURAOKA Taro -- MURAOKA Taro -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] add tests for :undolist and the normal U command
Dominique Pellé wrote: > Attached patch adds tests for: > - the :undolist command > - the normal U command > > According to https://coveralls.io/github/vim/vim?branch=master > these were not yet covered by tests. Thanks! -- Two percent of zero is almost nothing. /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2296
Patch 7.4.2296
Problem:No tests for :undolist and "U" command.
Solution: Add tests. (Dominique Pelle)
Files: src/testdir/test_undo.vim
*** ../vim-7.4.2295/src/testdir/test_undo.vim 2016-07-29 16:15:13.038677979
+0200
--- src/testdir/test_undo.vim 2016-08-31 20:30:21.412980092 +0200
***
*** 129,134
--- 129,167
close!
endfunc
+ func Test_undolist()
+ new
+ set ul=100
+
+ let a=execute('undolist')
+ call assert_equal("\nNothing to undo", a)
+
+ " 1 leaf (2 changes).
+ call feedkeys('achange1', 'xt')
+ call feedkeys('achange2', 'xt')
+ let a=execute('undolist')
+ call assert_match("^\nnumber changes when *saved\n *2 *2 .*$", a)
+
+ " 2 leaves.
+ call feedkeys('u', 'xt')
+ call feedkeys('achange3\', 'xt')
+ let a=execute('undolist')
+ call assert_match("^\nnumber changes when *saved\n *2 *2 *.*\n *3 *2
.*$", a)
+ close!
+ endfunc
+
+ func Test_U_command()
+ new
+ set ul=100
+ call feedkeys("achange1\", 'xt')
+ call feedkeys("achange2\", 'xt')
+ norm! U
+ call assert_equal('', getline(1))
+ norm! U
+ call assert_equal('change1change2', getline(1))
+ close!
+ endfunc
+
func Test_undojoin()
new
call feedkeys("Go\", 'xt')
*** ../vim-7.4.2295/src/version.c 2016-08-30 10:56:38.914580533 +0200
--- src/version.c 2016-08-31 20:31:05.592558787 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2296,
/**/
--
Amnesia is one of my favorite words, but I forgot what it means.
/// Bram Moolenaar -- b...@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///
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim exits with "BadWindow (invalid window parameter)" when highlighting large regions (#1023)
On Wed, Aug 31, 2016 at 6:44 PM, Antony Lee wrote: > See above. > See what above? Please do the following in the gvim version where you experience the problem: :redir > ~/vim-version.txt :version :redir END then attach the resulting ~/vim-version.txt to a reply email. Please don't use copy-paste but "add attachment", there are fewer mailing errors that way. Best regards, Tony. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] gvim exits with "BadWindow (invalid window parameter)" when highlighting large regions (#1023)
Hi Tony! On Mi, 31 Aug 2016, Tony Mechelynck wrote: > On Wed, Aug 31, 2016 at 6:44 PM, Antony Lee wrote: > > See above. > > > See what above? He hanged the first message in the github issue tracker and added the version info there as well: https://github.com/vim/vim/issues/1023#issue-174242520 Best, Christian -- Wir liefen beim Zweikampf nebeneinander her, und da habe ich ihn wohl leicht retouchiert. -- Olaf Thon -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
bug with :changes?
Bram,
I see the following behaviour:
fun! Test()
new
call setline(1, range(1,100))
call append('$', ['a', 'b', 'c', 'd'])
call append('$', ['Z', 'Y', 'X', 'W'])
endfu
call vim like this:
vim -u NONE -N -S testfile.vim
Now check the :changes command:
:changes
This will show:
,
| :changes
| change line col text
| 1 1050 Z
| >
| Press ENTER or type command to continue
`
While I had expected 3 changes like this:
,
| :changes
| change line col text
| 3 20 2
| 2 1010 a
| 1 1050 Z
| >
| Press ENTER or type command to continue
`
Best,
Christian
--
Man mochte über Adenauer denken, was man wollte. Man wußte jedenfalls
genau, woran man war.
-- Willy Brandt
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
warning W19 from self destructing augroup
Hello, I have a Vim plugin that needs to access a persistent variable stored in viminfo. The viminfo file is however loaded _after_ the plugins therefore the script has to use the VimEnter autocommand to get to the global variable. I have wrapped this autocommand in a single-use augroup, which is removed as a part of the autocommand callback as follows: function onVimStartup() " apply global variable from viminfo autocmd! TmpGroup augroup! TmpGroup endfunction augroup TmpGroup au VimEnter * call onVimStartup() augroup END After patch 2117 the plugin started displaying the W19 warning "W19: Deleting augroup that is still in use" and the ":augroup" command in Vim shows "--Deleted--" in place of the TmpGroup. Is this a bug or an expected behavior? The TmpGroup is already empty at the "augroup!" line although its autocommand is still executing. Would it be possible to allow the augroup removal complete when augroup is already empty? If not - is there some other way how to do a self-destructing VimEnter autocommand? Thank you, Pavol -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: bug with :changes?
Hi vim-dev!
On Mi, 31 Aug 2016, Christian Brabandt wrote:
> Bram,
> I see the following behaviour:
>
> fun! Test()
> new
> call setline(1, range(1,100))
> call append('$', ['a', 'b', 'c', 'd'])
> call append('$', ['Z', 'Y', 'X', 'W'])
> endfu
>
> call vim like this:
> vim -u NONE -N -S testfile.vim
>
> Now check the :changes command:
> :changes
>
> This will show:
> ,
> | :changes
> | change line col text
> | 1 1050 Z
> | >
> | Press ENTER or type command to continue
> `
>
> While I had expected 3 changes like this:
> ,
> | :changes
> | change line col text
> | 3 20 2
> | 2 1010 a
> | 1 1050 Z
> | >
> | Press ENTER or type command to continue
> `
I think I know what is happening, one needs to manually break the
undolist.
Sorry for the noise.
Best,
Christian
--
Wußten Sie schon...
... daß im Hamburger Hafen mehr Pariser als Hamburger schwimmen?
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Update Japanese translations to catch up 7.4.2295
Taro Muraoka wrote: > Sorry for multiple mails. > > vim-jp members found trivial mistakes of the previous release. > And I have fixed those with attached. > If you want to known more details, please check this URL. > > https://github.com/vim-jp/lang-ja/releases/tag/20160901 Thanks! -- hundred-and-one symptoms of being an internet addict: 118. You are on a first-name basis with your ISP's staff. /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[bug] g< does not work with execute()/redir
There is a bug when using g< with execute()
One cannot capture it's output using execute()/redir:
:echo "a\nb\nc\nd\n"
(press enter prompt)
:norm! g<
(shows the echo output again)
:let b=execute(':unsilent norm! g<')
:echo empty(b)
1
:norm! g<
(does not output anything)
Best,
Christian
--
Ich gehe jetzt in den Birkenwald,
denn meine Pillen wirken bald.
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
inconsistency with zw
The documentation states this: , | *zw* | zwLike "zg" but mark the word as a wrong (bad) word. | If the word already appears in 'spellfile' it is | turned into a comment line. See |spellfile-cleanup| | for getting rid of those. ` However, if a word was added to the spellfile using zw and later commented using zg, it will be explicitly marked as bad word. See this sample script: fu Test_spell() new set spell spelllang=en spellfile=/tmp/XSpellfile.add call append(0, 'goood') 1 norm! zg $put =readfile(&spellfile) norm! zw $put =readfile(&spellfile) " rm temporary spellfile call delete(&spellfile) endfu call Test_spell() vim -u NONE -N -S test.vim This will output something like this: , | goood | | goood | #oood | goood/! ` The first word is the initial word, enterd using append() from the script. The third line contains the added word from the spellfile after having used 'zg' and the 4-5 lines contains the entries in the spellfile after using 'zw' I don't think that is a problem, but at least the documentation should be adjusted. Best, Christian -- F: Was ist der Unterschied zwischen einer Traube und einem Elefanten? A: Eine Traube ist violett. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[patch] clarify how to set up set t_8f and set t_8b in :help xterm-true-color
Hi I've seen several times users being confused about how to set up t_8f and t_8b, needed for some terminals to get 'termguicolors' feature to work. Copy/pasting the following 2 lines from :help xterm-true-color does not work, since ^[ needs to be typed as a single Escape char: set t_8f=^[[38:2:%lu:%lu:%lum set t_8b=^[[48:2:%lu:%lu:%lum Attached patch attempts to clarify how to set t_8f and t_8b. I've also been confused myself with getting 'termguicolors' to work, as it works for some terminals but not others. How about listing in help files terminals where 'termguicolors' is known to work and terminal where it known to not work? I've only tried 'termguicolors' on xubuntu-14.04 and xubuntu-15.10: 'termguicolors' did not work with: - xfce4-terminal 0.6.3 (xubuntu-14.04, xubuntu-15.10) - gnome-terminal 3.6.2 (xubuntu-14.04) - MATE Terminal 1.10.1 (xubuntu-15.10) 'termguicolors' worked with: - XTerm (297, xubuntu-14.04) - gnome-terminal (3.16.2, xubuntu-15.10) I'm hoping that support for 'termguicolors' is better in more recent distributions. Regards Dominique -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt index 1eea20f..7558074 100644 --- a/runtime/doc/term.txt +++ b/runtime/doc/term.txt @@ -435,7 +435,8 @@ with all semicolons replaced by colons (this is actually more compatible, but less widely supported): > set t_8f=^[[38:2:%lu:%lu:%lum set t_8b=^[[48:2:%lu:%lu:%lum -(replace `^[` with real escape) +(replace `^[` with an escape character, which can be entered by typing the +2 keys in Insert mode) These options contain printf strings, with |printf()| (actually, its C equivalent hence `l` modifier) invoked with the t_ option value and three
YML formatting inconsistent bug
As reported here: https://bugs.archlinux.org/task/50557 Description: When formatting a YML file, it's left inconsistent. http://s.natalian.org/2016-08-29/vim-yml.mp4 https://github.com/kaihendry/count/blob/master/.travis.yml filetype detection:ON plugin:ON indent:ON filetype=yaml Additional info: * 7.4.2143-1 Steps to reproduce: 1. Load https://github.com/kaihendry/count/blob/master/.travis.yml 2. Format buffer to notice inconsistent indenting Many thanks, -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Timer can not stop in its callback
Hi Bram,
Timer can not stop in its callback.
```
let t = timer_start(1000, { timer -> timer_stop(timer) }, {'repeat': -1})
```
This timer doesn't stop. timer_pause() doesn't also work in callback.
We can stop this timer from the outside of callback: call timer_stop(t)
I think this is bug and should be fixed before Vim 8.0.
Regards,
--
thinca
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
omission in :h file-pattern?
The docs at :h file-pattern don't mention it, but I seem to be able to use
"\=" just fine in autocmd patterns, and it seems to mean what it means in
:h pattern-overview ("zero or one").
For instance, `au SomeGroup *.[xgb]z2\= some_command` will fire on files
with any of the following extensions:
.xz
.gz
.bz2
.bz
Maybe this a fluke and it's not supposed to work this way. But if it is
supposed to work this way it should be in the docs at :h file-pattern
-Manny
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
How to execute a command like sort by job?
Hi Bram and list, :help channel-close says: Once done with the channel, disconnect it like this: > call ch_close(channel) When a socket is used this will close the socket for both directions. When pipes are used (stdin/stdout/stderr) they are all closed. This might not be what you want! Stopping the job with job_stop() might be better. It seems there is no way to close only stdin. How to execute a command that waits the end of input, like sort? Best regards, -- thinca -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: YML formatting inconsistent bug
Am 2016-09-01 04:16, schrieb Kai Hendry: As reported here: https://bugs.archlinux.org/task/50557 Description: When formatting a YML file, it's left inconsistent. http://s.natalian.org/2016-08-29/vim-yml.mp4 https://github.com/kaihendry/count/blob/master/.travis.yml filetype detection:ON plugin:ON indent:ON filetype=yaml Additional info: * 7.4.2143-1 Steps to reproduce: 1. Load https://github.com/kaihendry/count/blob/master/.travis.yml 2. Format buffer to notice inconsistent indenting Please report to the maintainer of the corresponding runtime/indent/yaml.vim file (as written in the header of that file). You can find out, which file is used by running the :scriptnames command in a yaml file. Best, Christian -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: omission in :h file-pattern?
Manuel Ortega wrote:
> The docs at :h file-pattern don't mention it, but I seem to be able to use
> "\=" just fine in autocmd patterns, and it seems to mean what it means in :h
> pattern-overview ("zero or one").
>
> For instance, `au SomeGroup *.[xgb]z2\= some_command` will fire on files
> with any of the following extensions:
>
> .xz
> .gz
> .bz2
> .bz
>
> Maybe this a fluke and it's not supposed to work this way. But if it is
> supposed to work this way it should be in the docs at :h file-pattern
>
> -Manny
I think that it's not expected and I see it a bug.
glob2regpat() gives what look like unexpected
results for:
:echo glob2regpat('a\=')
Actual: ^a\=$
Expected: ^a\\=$
:echo glob2regpat('a\+')
Actual: ^a\+$
Expected: ^a\\+$
:echo glob2regpat('a\d')
Actual: ^a\d$
Expected: ^a\\d$
And many probably many other cases
where \ is special in regexp, but not special
in glob special characters.
The \ character is also interpreted differently
on Windows (directory separator) in glob patterns,
which is not clear to me. Will glob2regpat('a\=')
match files that start with "=" in the "a" directory
on Windows?
:help wildcard which describes glob special
characters is too short and not precise enough.
Regards
Dominique
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: omission in :h file-pattern?
Am 2016-09-01 07:41, schrieb Dominique Pellé:
Manuel Ortega wrote:
The docs at :h file-pattern don't mention it, but I seem to be able to
use
"\=" just fine in autocmd patterns, and it seems to mean what it means
in :h
pattern-overview ("zero or one").
For instance, `au SomeGroup *.[xgb]z2\= some_command` will fire on
files
with any of the following extensions:
.xz
.gz
.bz2
.bz
Maybe this a fluke and it's not supposed to work this way. But if it
is
supposed to work this way it should be in the docs at :h file-pattern
-Manny
I think that it's not expected and I see it a bug.
glob2regpat() gives what look like unexpected
results for:
:echo glob2regpat('a\=')
Actual: ^a\=$
Expected: ^a\\=$
:echo glob2regpat('a\+')
Actual: ^a\+$
Expected: ^a\\+$
:echo glob2regpat('a\d')
Actual: ^a\d$
Expected: ^a\\d$
And many probably many other cases
where \ is special in regexp, but not special
in glob special characters.
I believe this is not true. The documentation mentions this:
,[ :h file-pattern ]-
| *file-pattern*
| The pattern is interpreted like mostly used in file names:
| * matches any sequence of characters; Unusual: includes path
| [...]
| \ special meaning like in a |pattern|
| [...]
`
So one can expect '\=' to work like a regexp pattern.
Best,
Christian
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
