Hi,
2019/9/30 Mon 20:55:28 UTC+9 Ni Va wrote:
>
> Found that this command call system('which msvcrt-ruby260.dll') causes
> segfault under windows, which does not exist.
> Surprised that it causes segfault.
>
> Thank you.
>
Can you bisect which version causes this issue?
If you want to get more d
Patch 8.1.2104
Problem:The normal.c file is too big.
Solution: Move do_pending_operator() to ops.c. (Yegappan Lakshmanan,
closes #4999).
Files: src/normal.c, src/ops.c, src/proto/normal.pro, src/proto/ops.pro,
src/globals.h
*** ../vim-8.1.2103/src/normal.c
Paul Jolly wrote:
> Just a quick status update: our govim builds have been very solid
> since these changes. Test failures we've seen have been gopls related,
> so at least as far as we've been able to tell so far the SafeState*
> changes are working well.
Glad to hear this solution works. I h
Patch 8.1.2103
Problem:wrong error message if "termdebugger" is not executable.
Solution: Check if "termdebugger" is executable and give a clear error
message. (Ozaki Kiichi, closes #5000) Fix indents.
Files: runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
*** ../vi
Stucki wrote:
> > When I change "set nrformats-=octal" in defaults.vim to something that
> > is not 8 bytes, then the report goes away.
> > If I set another buffer-local variable to a value with 8 bytes that
> > one is also reported. I don't think Vim itself does something special
> > for an 8
Found that this command call system('which msvcrt-ruby260.dll') causes
segfault under windows, which does not exist.
Surprised that it causes segfault.
Thank you.
Le lundi 30 septembre 2019 13:28:36 UTC+2, Christian Brabandt a écrit :
>
>
> On Mo, 30 Sep 2019, Ni Va wrote:
>
> > Hi,
> >
> >
On Mo, 30 Sep 2019, Ni Va wrote:
> Hi,
>
>
> Since same compilation under windows 10 MSYS2 32bits to build , I got a seg
> fault on gvim launch.
> Sorry but gdb didn't tell me exact source.
>
> Thank you in advance.
try starting without any configuration files to rule plugins and
settings o
Hi Bram,
> Thanks for helping to work through this.
Just a quick status update: our govim builds have been very solid
since these changes. Test failures we've seen have been gopls related,
so at least as far as we've been able to tell so far the SafeState*
changes are working well.
Thanks again,
Hi,
Since same compilation under windows 10 MSYS2 32bits to build , I got a seg
fault on gvim launch.
Sorry but gdb didn't tell me exact source.
Thank you in advance.
This is my build command :
> make -f Make_ming.mak OLE=yes DEBUG=yes GUI=yes XPM=no DIRECTx=yes
> DYNAMIC_LUA=yes LUA=./lua-
