Hi John,
2016-10-18(Tue) 12:03:44 UTC+9 JohnBeckett:
> Vim 8 deploys $VIMRUNTIME/defaults.vim which includes an autocmd
> to "jump to the last known cursor position".
> That can generate E315.
>
> Execute the following to create two files and exit.
> At exit, the cursor is on the last line of
Vim 8 deploys $VIMRUNTIME/defaults.vim which includes an autocmd
to "jump to the last known cursor position".
That can generate E315.
Execute the following to create two files and exit.
At exit, the cursor is on the last line of each file.
gvim -N -u NONE
:tabe test1.tmp
:put =range(1,90)
:w
> Seems like a reasonable solution. So the test fails for the current
> Vim? Or does it fail sometimes?
Sometimes. Especially, according to travis-ci, it is highly probable to fail on
Mac; about half or more.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type
On Monday, October 17, 2016 at 5:06:47 PM UTC-4, Tommy A wrote:
> Thanks again, Bram! There is one (hopefully last) issue. This works
> perfectly when using `` and ``, but the problem remains the same
> when `` and `` are used.
It looks like adding `(void)stop_arrow()` on line 1431 of edit.c
Thanks again, Bram! There is one (hopefully last) issue. This works perfectly
when using `` and ``, but the problem remains the same when ``
and `` are used.
On Monday, October 17, 2016 at 2:47:40 PM UTC-4, Bram Moolenaar wrote:
> Tommy Allen wrote:
>
> > This was a faster turn around than I
Brad King wrote:
> On 10/14/2016 04:04 PM, Bram Moolenaar wrote:
> > Either this needs to be donein the C syntax, or we need an folding
> > option to enable this behavior.
>
> Thanks for taking a look. It can't currently be done purely in syntax
> definitions so I've revised the change to add
Ozaki Kiichi wrote:
> The following will fix #1155.
>
> https://gist.github.com/ichizok/26d571401be0685267ebf0790e964903
>
> [cause of problem]
>
> This problem may occur on some *nix environment.
>
> Calling job_stop immediately after job_start, child process may receive signal
> before
Tommy Allen wrote:
> This was a faster turn around than I expected, thanks! Unfortunately
> there's another issue that comes from this: undo items are
> overwritten. If you place text on the line, then press ``, the
> undo entry should be created for the text on that line (e.g. "aaa").
> If
Patch 8.0.0042 (after 8.0.0041)
Problem:When using Insert mode completion with 'completeopt' containing
"noinsert" change is not saved for undo. (Tommy Allen)
Solution: Call stop_arrow() before inserting for pressing Enter.
Files: src/edit.c, src/testdir/test_popup.vim
On 10/14/2016 04:04 PM, Bram Moolenaar wrote:
> Either this needs to be donein the C syntax, or we need an folding
> option to enable this behavior.
Thanks for taking a look. It can't currently be done purely in syntax
definitions so I've revised the change to add a new syntax command:
2016-10-18(Tue) 0:13:48 UTC+9 Shougo:
> Issue#1168 repro steps doesn't seem to asynchronous for me. Where is the
> asynchronous?
>
>
>
> Because it uses complete_check() and complete_add().
(Below is Off topic)
No.
In this case, Those functions are not asynchronous because they are called
Hi.
The following will fix #1155.
https://gist.github.com/ichizok/26d571401be0685267ebf0790e964903
[cause of problem]
This problem may occur on some *nix environment.
Calling job_stop immediately after job_start, child process may receive signal
before reset_signals().
Therefore
Bram,
This was a faster turn around than I expected, thanks! Unfortunately there's
another issue that comes from this: undo items are overwritten. If you place
text on the line, then press ``, the undo entry should be created for the
text on that line (e.g. "aaa"). If you jump to the end of
13 matches
Mail list logo