Re: netrw: Apply the latest changes to v174b
Hi, I've updated the patch a bit. Regards, Ken Takata 2024年1月9日(火) 15:17 Ken Takata : > Hi Dr. Chip, > > Many changes to netrw are added in the Vim repository, but they are not > included in your Web site. > I created a patch to apply the latest changes in the Vim repository to > netrw v174b. > Could you apply this patch to your code? > > Regards, > Ken Takata > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAKNHtdnvk3VoKs%2B_RR0Q%2B_X-SBiXyS5NAnAn_j%3D4ChWqxwtkmA%40mail.gmail.com. netrw-patch-for-v174b-2.diff Description: Binary data
netrw: Apply the latest changes to v174b
Hi Dr. Chip, Many changes to netrw are added in the Vim repository, but they are not included in your Web site. I created a patch to apply the latest changes in the Vim repository to netrw v174b. Could you apply this patch to your code? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAKNHtdn3%2BMuyt81Ufh9Fbq2ij4qLfeWcSJBx7yUZwbKbhcNenQ%40mail.gmail.com. netrw-patch-for-v174b.diff Description: Binary data
Re: bug(?): Unicode Symbol as half-width in CJK
Hi, This kind of displaying error can happen by the ambiguous width characters. This can happen when the character width defined by the selected font and the width that Vim is recognizing don't match. (For console version of Vim, the width that the terminal emulator is recognizing must also match.) Normally, this can be controlled by the 'ambiwidth' option. If you use CJK fonts, setting this to "double" might be better. KaoriYa Vim provides an additional setting to the 'ambiwidth' option. It provides ambiwidth=auto setting which automatically recognize the width from the actual font. (ambiwidth=auto is the default setting for KaoriYa Vim.) If you use DirectWrite, the issue can be more complicated. If a glyph isn't found in the current font, Windows automatically find the glyph from other fonts. E.g. If you select a double-width font, but if the glyph from a single-width font is used, the width can be changed. (KaoriYa Vim's ambiwidth=auto patch doesn't support DirectWrite, but I have an additional patch to support it.) If you need a fine tuning, you can also use setcellwidths(). Regards, Ken Takata 2023年12月18日月曜日 10:01:58 UTC+9 Korean user1 (in CJK): > In CJK, this bug is very old, but it has not been fixed yet. I believed > someone would be interested in it and solve it, but until now I'm inquiring > here because no one seems to be interested. > > As far as I know, in text editors like vim Only fixed-width fonts are > available. > > In the CJK area, CJK characters and Unicode symbols It is called > 'full-width character', and in comparison, English characters are called > 'half-width characters'. > > In other words, the width of the CJ[image: > vim-input-unicode-symbol-halfwidth-problems-korean.gif]K character is > exactly twice the width of the English character. In addition, the 'Unicode > symbol' should also be marked twice as wide. In vim, however, most of the > 'unicode symbols' are treated as half-width characters and are not > displayed correctly. > > I have attached a GIF animation file for easy understanding. > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/a020d4c3-8fb3-48f1-9544-a6117b5d2c9cn%40googlegroups.com.
Re: Updates on the Vim project
Hi Christian, > For a similar reason and because of the mess I created with the > mercurial mirror, I am thinking to retire the mercurial repository. I > think it is pretty clear that nowadays git is the preferred VCS of > choice for most programmers. To be honest, I'm still using the mercurial mirror on osdn.net. I use MQ (mercurial queues) to manage my personal patches. There are some similar tools for Git (guilt, etc.), but they had some issues (for my usecases) when I tried them. Regards, Ken Takata 2023年8月24日木曜日 14:58:12 UTC+9 Ernie Rael: > Hoping https://github.com/vim/vim/pull/12192 is merged. > > Vim 9.1 has a nsec profiling clock available; but without this PR, which > fixes a severe timing problem related to user function calls, we can't > say v9.1 has high accuracy profiling. > > -ernie > > On 23/08/23 1:18 PM, Christian Brabandt wrote: > > Hi, > > this is a small update over what happened the last few weeks. > > > > Over the last days, I have been merging mostly runtime file changes, > > small improvements to the Vim9 class implementations and bug fixes. > > > > If you check the Milestone¹ for the release 9.1, most of the remaining > > changes are small runtime changes, for which I'd like to get an > > ACK/NACK. > > > > Thanks for all your contributions, this is really appreciated! > > > > I am not sure, what the status of the Vim9 classes implementation is and > > if we are going to get further improvements there or if we can consider > > this "good enough". > > > > @Yegappan, what is your opinion? > > > > If you are a runtime file maintainer, or you have been providing > > translations, now it's time to check your runtime files against the > > version in the Vim repository and please consider sending updated files. > > > > I also checked the huntr organization, but it looks like there are no > > open security issues reported over there. > > > > On a somewhat related note, I have been asked how to handle security > > issues in the future and I am thinking about creating a "private" list > > for this. Not sure how to handle packagers or if it is good enough, if I > > mark commits/mails with some security related flag. > > > > Regarding the vim Homepage, I'll move it to a new hoster after the > > release has been done. I got several offers so that should not be a > > problem. I'll also need to check the amount of work to migrate the old > > php5 code to an updated php version. > > > > Regarding the ftp server, I decided to no longer use it. I checked with > > the owners and while they were willing to help, I come to the conclusion > > that it stems from an old time and it no longer required, so I will not > > update the data there. I may however need to download the generated > > spell files and move this to the new Vim Homepage, once it has been > > moved. > > > > For a similar reason and because of the mess I created with the > > mercurial mirror, I am thinking to retire the mercurial repository. I > > think it is pretty clear that nowadays git is the preferred VCS of > > choice for most programmers. > > > > Let me know, what you all think. > > __ > > ¹) > https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1 > > > > Thanks, > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/21d47fad-079d-41dd-ab99-81af48f60e07n%40googlegroups.com.
Re: Where is Bram?
I am really sad to hear this news. Currently, only three members have the commit access to the Vim repository, but no one has the admin privileges of the Vim organization. I'm going to ask GitHub support to request the admin privileges for the three members. I also think that it would be better to enable GitHub Discussions in the Vim repository. At least, the following two issues should be moved to Discussions: https://github.com/vim/vim/issues/12728 https://github.com/vim/vim/issues/12730 The problem might be that they are not redirected to the vim_dev mailing list. What do you think? Regards, Ken Takata 2023年8月6日日曜日 1:11:39 UTC+9 Christian Brabandt: > Am 2023-08-05 16:30, schrieb Yegappan Lakshmanan: > > On Sat, Aug 5, 2023 at 5:53 AM Maxim Kim wrote: > >> > >> https://groups.google.com/g/vim_announce/c/tWahca9zkt4 > >> > > > > I am truly saddened and shocked to hear this news. > > > > I have been following him for more than 25 years and have interacted > > with him for more than 22 years. He has been an inspiration to me and > > many others. He has really changed the world for the better. He has > > single handedly improved the productivity of countless developers and > > companies around the world. He dedicated his entire life to work on > > Vim. His vision and ability to design some of the most complex > > features > > (such as the vim9script compiler, spell check, syntax highlighting, > > channels, tab pages, virtual text, and many others) have always amazed > > me. > > > > We will all miss him deeply. Rest In Peace, Bram, and thank you for > > everything. > > > As all of you, so was I deeply shocked when I heard the news. Bram was a > great leader > to the Vim community and I really enjoyed working with him over the past > years, since I became > involved with the development of Vim almost 20 years ago. > > Bram was of great inspiration in creating a great community, helping > people with his charity and > he was a great mentor. And now he left too soon. We lost a great leader > and I regret never having > met him in person... > > However to all of the community: I will continue and I hope all of the > other contributors will > also keep up the good work. I do have access to the Vim homepage and the > Vim organization (not sure > if all the rights, but I am sure we will work on the details in the near > future. > > Once I return from vacation, I'll go through the PRs and review them > (and also commit the missing > patch to github). I'll welcome anybody to contribute to make Vim better. > > I still don't know all the internals of the various areas (vim9, virtual > text, syntax highlighting to name > a few) and I don't know how much time I can dedicate, but I hope > together we will be able to continue > successfully. > > > Thanks, > Chris > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/d71778b7-7e2c-44d7-b938-fadee2c8b9e9n%40googlegroups.com.
Fix indentation in Netrw 174a
Hi Dr. Chip, I've just tried Netrw 174a from your site and confirmed that the changes in https://github.com/vim/vim/pull/12150 have been included. Thank you. However, I found that the indentation is not correct. Could you check the attached patch? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAKNHtdmtS44HzqP6y8SV4-Ogx0M_spJv_LqCJ_%2B4Ri5_0z1fhA%40mail.gmail.com. netrw-fix-indent.diff Description: Binary data
Re: building vim with clang and python3 support
Hi, So, you are using the beta version of python 3.12, right? Then, if_python3.c should be updated to support python 3.12, I think. Regards, Ken Takata 2023年6月1日木曜日 2:50:46 UTC+9 N i c o l a s: > Hi, > > From vim.9.0.1594 source, I obtain this error trying to build gvim HUGE > version under win10 with python3(12) support. > > > c -Wl,-Bdynamic -lgcc_eh -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic -lole32 > -luuid > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa07b): undefined reference to > `__imp_PyLong_Type' > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa088): undefined reference to > `__imp_PyBool_Type' > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa644): undefined reference to > `__imp_PyLong_Type' > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa64d): undefined reference to > `__imp_PyBool_Type' > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa6c4): undefined reference to > `__imp_PyLong_Type' > D:/msys64/mingw64/bin/ld: > gobjx86-64/if_python3.o:if_python3.c:(.text+0xa6cd): undefined reference to > `__imp_PyBool_Type' > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > make: [Make_cyg_ming.mak:1126: gvim.exe] Error 1 (ignored) > > > My FLAGS are these : > > * CC=clang CXX=clang++ -pipe OLE=yes GUI=yes XPM=no DIRECTx=yes ASAN=no > DYNAMIC_LUA=yes LUA=./lua-5.4.6/src LUA_VER=54 PYTHON3=D:/Python312 > DYNAMIC_PYTHON3=yes PYTHON3_VER=312 -I /d/python312/include > DYNAMIC_PYTHON3_DLL=python312.dllRUBY=D:/Ruby32-x64 DYNAMIC_RUBY=yes > RUBY_VER=32 RUBY_API_VER_LONG=3.2.0 > -I/d/Ruby32-x64/include/ruby-3.2.0/ruby SODIUM=yes TERMINAL=yes > EVENT_LOOP=yes STATIC_STDCPLUS=yes WINVER=0x0A00 > > The install_PC.txt file just tell that for a clang compilation : > > CC=clang > CXX=clang++ > make -f Make_ming.mak DEBUG=yes ASAN=yes > > Thank you for help > > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/73ae1253-405e-4503-96ef-08cd0278be69n%40googlegroups.com.
Re: Vim Windows binaries are 3 weeks old
Hi Christian, I think that the master branch used to be updated by your server. But it seems that the master branch has not updated. Any issues in your server? Regards, Ken Takata 2023年4月13日木曜日 15:59:25 UTC+9 Christian Brabandt: > > On Mi, 12 Apr 2023, igo...@gmail.com wrote: > > > This should be correct link: > > https://github.com/vim/vim-win32-installer/releases/latest > > but it looks like web server automatically rewrites URL to the latest > tag, so > > that is why I have got address from previous post. > > I have no idea what is going on and don't see why appveyor is no longer > triggered. > > > Best, > Christian > -- > Die Kennworte des Wieners: Wie komm denn i dazu? Es zahlt sich ja net > aus! Tun S' Ihnen nix an! > -- Arthur Schnitzler > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5688d379-8adb-4d52-b026-defa89e7abf9n%40googlegroups.com.
Re: wiki page messge and wiki page setting
Hi Bram, I confirmed that you updated the wiki page. > I don't think we have had a problem with this until now. Did you have > to remove something before? Only once, but there was spam a few months ago. Regards, Ken Takata 2022年4月13日水曜日 19:01:04 UTC+9 Bram Moolenaar: > > Ken - > > > Someone added a message about Ukraine to the wiki page: > > https://github.com/vim/vim/wiki > > > > What do you think of this? > > If you don't like this, I can revert it. > > I'm OK with expressing support for the Ukraine, but this is over the > top. Not sure where else to put it. On Vim.org I just added the flag > colors. It's still a bit too much too, I'll see if I can change that. > > A link to a payment site suggests that we think it is OK, but I have no > idea where the money goes, thus we should not do that. Someone who > wants to donate can find places for that easily. > > > Currently, the wiki pages can be edited by anyone. > > There is a setting to restrict editing to the members of the vim > repository. > > What do you think of this setting? > > I don't think we have had a problem with this until now. Did you have > to remove something before? > > - Bram > > -- > BEDEVERE: And that, my lord, is how we know the Earth to be banana-shaped. > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- br...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/01a9f330-52c9-496b-8a52-e75156f3681an%40googlegroups.com.
wiki page messge and wiki page setting
Hi Bram, Someone added a message about Ukraine to the wiki page: https://github.com/vim/vim/wiki What do you think of this? If you don't like this, I can revert it. Currently, the wiki pages can be edited by anyone. There is a setting to restrict editing to the members of the vim repository. What do you think of this setting? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/008429a1-4dbb-4643-9c1d-8d387041191dn%40googlegroups.com.
Re: Libsodium error sodium.h
Hi, Couldn't reproduce. Does sodium.h exist in C:\msys64\mingw64\include (for 64-bit) and/or C:\msys64\mingw32\include (for 32-bit)? 2022年3月7日月曜日 6:27:47 UTC+9 niva...@gmail.com: > Hi Ken, > > Just getting same error after match 4519 of vim: sodium.h is not > regognized. > > foo.bar@I-1 MINGW32 ~ > # pacman -Qi mingw-w64-x86_64-libsodium > Name: mingw-w64-x86_64-libsodium > Version : 1.0.18-2 > Description : P(ortable|ackageable) NaCl-based crypto library > (mingw-w64) > Architecture: any > URL : https://github.com/jedisct1/libsodium > Licenses: custom:ISC > Groups : None > Provides: None > Depends On : mingw-w64-x86_64-gcc-libs > Optional Deps : None > Required By : None > Optional For: None > Conflicts With : None > Replaces: None > Installed Size : 1376.62 KiB > Packager: CI (msys2-autobuild/8ebdca93/751008704) > Build Date : Thu Apr 15 08:41:50 2021 > Install Date: Sat Mar 5 15:39:43 2022 > Install Reason : Explicitly installed > Install Script : No > Validated By: Signature > > > Flags are: > OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes LUA=./lua-5.4.4/src > LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes PYTHON3_VER=311 > DYNAMIC_PYTHON3_DLL=python311.dll RUBY=c:/Ruby31 DYNAMIC_RUBY=yes > RUBY_VER=31 RUBY_API_VER_LONG=3.1.0 -I/c/Ruby31-x64/include/ruby-3.1.0/ruby > SODIUM=yes TERMINAL=yes EVENT_LOOP=yes STATIC_STDCPLUS=yes WINVER=0x0A00 > > Would you bypass build ? (y/n)nmake for i686 > make -f Make_ming.mak OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes > LUA=./lua-5.4.4/src LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes > PYTHON3_VER=311 DYNAMIC_PYTHON3_DLL=python311.dll RUBY=c:/Ruby31 > DYNAMIC_RUBY=yes RUBY_VER=31 RUBY_API_VER_LONG=3.1.0 > -I/c/Ruby31-x64/include/ruby-3.1.0/ruby SODIUM=yes TERMINAL=yes > EVENT_LOOP=yes STATIC_STDCPLUS=yes WINVER=0x0A00 DEBUG=no > > mkdir -p gobji686 > gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0A00 -D_WIN32_WINNT=0x0A00 > -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H > -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG > -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP -DFEAT_TERMINAL > -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI > -DHAVE_SODIUM -DDYNAMIC_SODIUM -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD > -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=i686 -Wall > -I./lua-5.4.4/src/include -I./lua-5.4.4/src -DFEAT_LUA -DDYNAMIC_LUA > -DDYNAMIC_LUA_DLL=\"lua54.dll\" -DFEAT_RUBY -I c:/Ruby31/include/ruby-3.1.0 > -I c:/Ruby31/include/ruby-3.1.0/i386-mingw32 -DDYNAMIC_RUBY > -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby310.dll\" -DRUBY_VERSION=31 -DFEAT_PYTHON3 > -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python311.dll\" -O3 > -fomit-frame-pointer -freg-struct-return alloc.c -o gobji686/alloc.o > > In file included from alloc.c:14: > vim.h:506:11: fatal error: sodium.h: No such file or directory > 506 | # include > | ^~ > compilation terminated. > mingw32-make: *** [Make_cyg_ming.mak:1184: gobji686/alloc.o] Error 1 > > Le dimanche 6 mars 2022 à 11:02:08 UTC+1, Ni Va a écrit : > >> Okay Thanks a lot Ken, >> >> Do i have to download your fix on Make_cyg_ming.mak? >> Because I tried removing -I include directive and DYNAMIC_SODIUM_DLL, >> just leaving SODIUM=yes and got same error. >> >> Thank in advance. >> NV >> >> Le dimanche 6 mars 2022 à 07:46:10 UTC+1, ktakat...@gmail.com a écrit : >> >>> Hi, >>> >>> The current version of Make_cyg_ming.mak only supports setting "yes" to >>> the "SODIUM" option. >>> If you install libsodium from pacman, you can use "SODIUM=yes". >>> I created PR #9896 to fix that. >>> >>> Specifying -*I./libsodium-win32-1.0.18/include *in the command line is >>> not correct. It specifies the include directory for "make" not for "gcc". >>> We don't have the "DYNAMIC_SODIUM_DLL" option (yet). We cannot specify >>> the name of the DLL. >>> >>> 2022年3月6日日曜日 3:07:53 UTC+9 niva...@gmail.com: >>> Hi, I encounter this error trying to link gvim with mingw32 make on Win10 Informations Interfaces c:/Ruby31 c:/Python310 Flags are: OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes LUA=./lua-5.4.4/src LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes PYTHON3_VER=311 DYNAMIC_PYTHON3_DLL=python311.dll RUBY=c:/Ruby31 DYNAMIC_RUBY=yes RUBY_VER=31 RUBY_API_VER_LONG=3.1.0 -I/c/Ruby31-x64/include/ruby-3.1.0/ruby DYNAMIC_SODIUM=yes SODIUM=libsodium-win32-1.0.18 DYNAMIC_SODIUM_DLL=libsodium-23.dll -I./libsodium-win32-1.0.18/include TERMINAL=yes EVENT_LOOP=yes STATIC_STDCPLUS=yes WINVER=0x0A00 Would you bypass build ? (y/n)n make for i686 make -f Make_ming.mak OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes LUA=./lua-5.4.4/src LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes PYTHON3_VER=311
Re: Libsodium error sodium.h
Hi, The current version of Make_cyg_ming.mak only supports setting "yes" to the "SODIUM" option. If you install libsodium from pacman, you can use "SODIUM=yes". I created PR #9896 to fix that. Specifying -*I./libsodium-win32-1.0.18/include *in the command line is not correct. It specifies the include directory for "make" not for "gcc". We don't have the "DYNAMIC_SODIUM_DLL" option (yet). We cannot specify the name of the DLL. 2022年3月6日日曜日 3:07:53 UTC+9 niva...@gmail.com: > Hi, > > I encounter this error trying to link gvim with mingw32 make on Win10 > > Informations Interfaces > c:/Ruby31 > c:/Python310 > > Flags are: > OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes LUA=./lua-5.4.4/src > LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes PYTHON3_VER=311 > DYNAMIC_PYTHON3_DLL=python311.dll RUBY=c:/Ruby31 DYNAMIC_RUBY=yes > RUBY_VER=31 RUBY_API_VER_LONG=3.1.0 -I/c/Ruby31-x64/include/ruby-3.1.0/ruby > DYNAMIC_SODIUM=yes SODIUM=libsodium-win32-1.0.18 > DYNAMIC_SODIUM_DLL=libsodium-23.dll -I./libsodium-win32-1.0.18/include > TERMINAL=yes EVENT_LOOP=yes STATIC_STDCPLUS=yes WINVER=0x0A00 > > Would you bypass build ? (y/n)n > make for i686 > make -f Make_ming.mak OLE=yes GUI=yes XPM=no DIRECTx=yes DYNAMIC_LUA=yes > LUA=./lua-5.4.4/src LUA_VER=54 PYTHON3=c:/Python310 DYNAMIC_PYTHON3=yes > PYTHON3_VER=311 DYNAMIC_PYTHON3_DLL=python311.dll RUBY=c:/Ruby31 > DYNAMIC_RUBY=yes RUBY_VER=31 RUBY_API_VER_LONG=3.1.0 > -I/c/Ruby31-x64/include/ruby-3.1.0/ruby DYNAMIC_SODIUM=yes > SODIUM=libsodium-win32-1.0.18 DYNAMIC_SODIUM_DLL=libsodium-23.dll - > *I./libsodium-win32-1.0.18/include* TERMINAL=yes EVENT_LOOP=yes > STATIC_STDCPLUS=yes WINVER=0x0A00 DEBUG=no > > mkdir -p gobji686 > gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0A00 -D_WIN32_WINNT=0x0A00 > -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H -DHAVE_SODIUM -DHAVE_GETTEXT > -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE > -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6 -DHAVE_INET_NTOP > -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_DIRECTX -DDYNAMIC_DIRECTX > -DFEAT_DIRECTX_COLOR_EMOJI -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD > -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=i686 -Wall > -I./lua-5.4.4/src/include -I./lua-5.4.4/src -DFEAT_LUA -DDYNAMIC_LUA > -DDYNAMIC_LUA_DLL=\"lua54.dll\" -DFEAT_RUBY -I c:/Ruby31/include/ruby-3.1.0 > -I c:/Ruby31/include/ruby-3.1.0/i386-mingw32 -DDYNAMIC_RUBY > -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby310.dll\" -DRUBY_VERSION=31 -DFEAT_PYTHON3 > -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python311.dll\" -O3 > -fomit-frame-pointer -freg-struct-return alloc.c -o gobji686/alloc.o > In file included from alloc.c:14: > vim.h:506:11: fatal error: sodium.h: No such file or directory > 506 | # include > | ^~ > compilation terminated. > mingw32-make: *** [Make_cyg_ming.mak:1183: gobji686/alloc.o] Error 1 > > > > > Just a check of header sodium > foo.bar@pc MINGW32 /c/Users/foo.bar/source/Vim.8.2.4510/src > # ls ./*libsodium-win32-1.0.18/include*/ > sodium sodium.h > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e6e88b2e-3440-4ae2-bc01-038df5af54a0n%40googlegroups.com.
Re: "The Vim Mercurial repository" page needs to be updated
Hi Bram, Thank you, but... > > > Either of the three sites should work, "three" should be changed to "two". I also found that the link in https://www.vim.org/develop.php should be updated. > If you prefer to use Mercurial over git, there is an alternative: the > Mercurial mirror on BitBucket <https://bitbucket.org/vim-mirror/vim>. Regards, Ken Takata 2021年6月1日火曜日 3:04:45 UTC+9 Bram Moolenaar: > > Ken Takata wrote: > > > https://www.vim.org/mercurial.php needs to be updated because BitBucket > > stopped supporting mercurial. > > There are there places needs to be updated. > > > > Here: > > > > > You can obtain Vim for the first time with either one of these > commands: > > > hg clone https://bitbucket.org/vim-mirror/vim > > > hg clone http://hg.256bit.org/vim > > > hg clone https://hg.osdn.net/view/vim/vim > > > > here: > > > > > Either of the three sites should work, but bitbucket will stop > supporting > > Mercurial in 2020. 256bit.org is a single server maintained by > Christian > > Brabandt. The osdn.net site is where this website is also hosted and > has > > full support. > > > > and here: > > > > > 1. Clone the repository > > > ~/code $ hg clone https://bitbucket.org/vim-mirror/vim > > Thanks for the hints. I have updated the page now. > > -- > An indication you must be a manager: > You give constructive feedback to your dog. > > /// Bram Moolenaar -- br...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ca253996-fca2-41a9-a48e-ad6eeb40449dn%40googlegroups.com.
"The Vim Mercurial repository" page needs to be updated
Hi Bram, https://www.vim.org/mercurial.php needs to be updated because BitBucket stopped supporting mercurial. There are there places needs to be updated. Here: > You can obtain Vim for the first time with either one of these commands: > hg clone https://bitbucket.org/vim-mirror/vim > hg clone http://hg.256bit.org/vim > hg clone https://hg.osdn.net/view/vim/vim here: > Either of the three sites should work, but bitbucket will stop supporting Mercurial in 2020. 256bit.org is a single server maintained by Christian Brabandt. The osdn.net site is where this website is also hosted and has full support. and here: > 1. Clone the repository > ~/code $ hg clone https://bitbucket.org/vim-mirror/vim Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2ace9f32-1bc9-4505-ba8d-3554f8e3100en%40googlegroups.com.
Re: Travis CI builds are very slow
Hi Bram, 2021年1月2日土曜日 5:35:14 UTC+9 Bram Moolenaar: > > Ken Takata wrote: > > > Now we are using GitHub Actions. So, the most of the issues were solved. > > But we still need to use Travis CI for some environments. > > As I wrote before, travis-ci.org will shutdown, so we have to migrate > to > > travis-ci.com. > > > > jram, could you migrate it with the following instractions? > > > https://docs.travis-ci.com/user/migrate/open-source-repository-migration#migrating-a-repository > > > < > https://docs.travis-ci.com/user/migrate/open-source-repository-migration> > > I have already sent a request to enable GitHub Apps and I think you have > > enabled it. > > But I don't have an access to do the further steps. > > Could you enable GitHub Apps on the vim/vim repository? > > > > Christian, I think that the vim/vim-appimage repository is also using > > travis-ci.org. > > It should be also migrated to travis-ci.com. > > I have added the travis app, but on travis-ci.com I only see > colorschemes, vim-history and a couple of others, but not "vim". > > Maybe it takes some time to show up, since it's much bigger? > > In the "Migrate" tab I see "vim" greyed out, and the info box says > "Migration is not available for this account". > > There is a "Sign up for the beta" button, but it doesn't appear to have > an effect. > > Now I can see the same page; "vim" and "vim-appimage" are greyed out. Maybe you need to "Sign up for the beta" on both travis-ci.org and travis-ci.com? https://travis-ci.community/t/migration-is-not-available-for-this-account/10490 Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/057f937a-f4bb-40c5-bc79-b6bff18d5dc3n%40googlegroups.com.
Re: Travis CI builds are very slow
Hi and Christian Bram, 2020年11月24日火曜日 18:57:43 UTC+9 Ken Takata: > Hi, > > 2020年11月24日火曜日 18:30:52 UTC+9 Bram Moolenaar: > >> >> Christian wrote: >> >> > On Mo, 23 Nov 2020, Yegappan Lakshmanan wrote: >> > >> > > The Travis CI builds are very slow for the last month or so. >> > > It looks like the total number of parallel Linux builds for all >> > > the open source projects has been limited to 400 or so >> > > (you can see the flat line in the graph for the active >> > > Linux builds in this https://www.traviscistatus.com/ page). >> > > >> > > This might be related to the new pricing model: >> > > https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing >> > > >> > > I don't know whether they will make an exception for Vim. >> > >> > Yes, I have also noticed this and this is annoying. I wonder whether it >> > makes sense to migrate away from Travis to either Github Actions or >> some >> > other CI service. >> >> First thing to do would be to ask them to give Vim a free account. >> They might be Vim users themselves. >> >> -- >> Why doesn't Tarzan have a beard? >> >> /// 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 /// >> > > Another thing we must consider is that travis-ci.org will shutdown at the > end of this year. > If we still use Travis CI, we have to migrate to travis-ci.com. > https://docs.travis-ci.com/user/migrate/open-source-repository-migration > > Now we are using GitHub Actions. So, the most of the issues were solved. But we still need to use Travis CI for some environments. As I wrote before, travis-ci.org will shutdown, so we have to migrate to travis-ci.com. Bram, could you migrate it with the following instractions? https://docs.travis-ci.com/user/migrate/open-source-repository-migration#migrating-a-repository <https://docs.travis-ci.com/user/migrate/open-source-repository-migration> I have already sent a request to enable GitHub Apps and I think you have enabled it. But I don't have an access to do the further steps. Could you enable GitHub Apps on the vim/vim repository? Christian, I think that the vim/vim-appimage repository is also using travis-ci.org. It should be also migrated to travis-ci.com. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0a46d89b-f104-4214-81e6-1b9a97a7e510n%40googlegroups.com.
Re: Travis CI builds are very slow
Hi, 2020年11月24日火曜日 18:30:52 UTC+9 Bram Moolenaar: > > Christian wrote: > > > On Mo, 23 Nov 2020, Yegappan Lakshmanan wrote: > > > > > The Travis CI builds are very slow for the last month or so. > > > It looks like the total number of parallel Linux builds for all > > > the open source projects has been limited to 400 or so > > > (you can see the flat line in the graph for the active > > > Linux builds in this https://www.traviscistatus.com/ page). > > > > > > This might be related to the new pricing model: > > > https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing > > > > > > I don't know whether they will make an exception for Vim. > > > > Yes, I have also noticed this and this is annoying. I wonder whether it > > makes sense to migrate away from Travis to either Github Actions or some > > other CI service. > > First thing to do would be to ask them to give Vim a free account. > They might be Vim users themselves. > > -- > Why doesn't Tarzan have a beard? > > /// 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 /// > Another thing we must consider is that travis-ci.org will shutdown at the end of this year. If we still use Travis CI, we have to migrate to travis-ci.com. https://docs.travis-ci.com/user/migrate/open-source-repository-migration Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/855e986d-edb9-4bc8-ac7c-32816a1df5b3n%40googlegroups.com.
Re: Patch 8.2.1028
Hi Bram,
2020年6月22日月曜日 3時38分54秒 UTC+9 Bram Moolenaar:
>
>
> Ken Takata wrote:
>
> > 2020年6月21日日曜日 22時53分37秒 UTC+9 Bram Moolenaar:
> > >
> > >
> > > Patch 8.2.1028
> > > Problem:Vim9: no error for declaring buffer, window, etc.
> variable.
> > > Solution: Give an error. Unify the error messages.
> > > Files: src/evalvars.c, src/globals.h, src/vim9compile.c,
> > > src/proto/vim9compile.pro,
> src/testdir/test_vim9_expr.vim,
> > > src/testdir/test_vim9_script.vim
> > >
> > >
> > ! EXTERN char e_declare_var[]INIT(= N_("E1016: Cannot declare
> a%s
> > > variable: %s"));
> > >
> >
> > This is tricky.
> >
> >
> > > + case 'g': scope = " global"; break;
> > > + case 'b': scope = " buffer"; break;
> > > + case 'w': scope = " window"; break;
> > > + case 't': scope = " tab"; break;
> > > + case 'v': scope = " v:"; break;
> > > + case '$': scope = "n environment"; break;
> >
> > These strings should be translatable.
>
> I suppose that's consistent with other places where these words are
> used. It won't work for "an environment", I'll make that a separate
> message. Hopefully that is not needed for the other cases.
>
How about this?
EXTERN char e_declare_var[]INIT(= N_("E1016: Cannot declare %s
variable: %s"));
case 'g': scope = _("a global"); break;
case 'b': scope = _("a buffer"); break;
case 'w': scope = _("a window"); break;
case 't': scope = _("a tab"); break;
case 'v': scope = _("a v:"); break;
case '$': scope = _("an environment"); break;
> This message is only used once, but still defined in globals.h.
> I'm wondering if we should either move a message like this to where it
> is used, or put all messages together, and sort them on number. One
> disadvantage is that the context of the message may be less clear.
>
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/07fff910-33c0-4d65-a9a5-afa8a6ff2ebao%40googlegroups.com.
Re: Patch 8.2.1028
Hi Bram,
2020年6月21日日曜日 22時53分37秒 UTC+9 Bram Moolenaar:
>
>
> Patch 8.2.1028
> Problem:Vim9: no error for declaring buffer, window, etc. variable.
> Solution: Give an error. Unify the error messages.
> Files: src/evalvars.c, src/globals.h, src/vim9compile.c,
> src/proto/vim9compile.pro, src/testdir/test_vim9_expr.vim,
> src/testdir/test_vim9_script.vim
>
>
! EXTERN char e_declare_var[]INIT(= N_("E1016: Cannot declare a%s
> variable: %s"));
>
This is tricky.
> + case 'g': scope = " global"; break;
> + case 'b': scope = " buffer"; break;
> + case 'w': scope = " window"; break;
> + case 't': scope = " tab"; break;
> + case 'v': scope = " v:"; break;
> + case '$': scope = "n environment"; break;
>
These strings should be translatable.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/89a8a08d-a462-4596-8a3c-e3f02f4359e5o%40googlegroups.com.
Re: Patch 8.2.0932
Hi Bram, 2020/6/9 Tue 1:55:38 UTC+9 Bram Moolenaar wrote: > > > Patch 8.2.0932 > Problem:Missspelling spelllang. > Oh, you misspelled the word misspelling. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/c9f6e8b4-f98b-4f8e-9045-75566e88466bo%40googlegroups.com.
Re: Cannot build "small" gvim on Windows
Hi, 2020/5/18 Mon 9:37:10 UTC+9 Michael Soyka wrote: > > Vim developers, > > When I try to build gvim on Wiindows XP using mingw with FEATURES=SMALL, I > get "windowsVersion undeclared" on line 839 of file os_win32.c. This > variable is instantiated in globals.h but only if FEAT_EVAL is defined and > this happens only for NORMAL builds. > > The compilation error goes away and the test suite passes if the > "windowsVersion" variable is moved out of the ifdef-block but I'm not > experienced enough to know if that is the right thing to do so I defer to > others for a patch. > > - mike > "windowsVersion" is used only in the windowsversion() function. So, I think that the attached patch is better. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/4759046f-813e-4b8e-bdb0-90f1245be026%40googlegroups.com. diff --git a/src/os_win32.c b/src/os_win32.c --- a/src/os_win32.c +++ b/src/os_win32.c @@ -815,8 +815,10 @@ PlatformId(void) ovi.dwOSVersionInfoSize = sizeof(ovi); GetVersionEx(); +#ifdef FEAT_EVAL vim_snprintf(windowsVersion, sizeof(windowsVersion), "%d.%d", (int)ovi.dwMajorVersion, (int)ovi.dwMinorVersion); +#endif if ((ovi.dwMajorVersion == 6 && ovi.dwMinorVersion >= 2) || ovi.dwMajorVersion > 6)
Re: Patch 8.2.0775
Hi,
2020/5/18 Mon 0:29:52 UTC+9 Cesar wrote:
>
> By building on Windows 7 with Mingw-w64 I'm getting:
>
> [...]
> obji686/if_lua.o:if_lua.c:(.text+0x4096): undefined reference to
> `luaL_loadstring'
> collect2.exe: error: ld returned 1 exit status
> make: *** [gvim.exe] Error 1
> Error by compiling gvim.exe
>
> --
> Cesar
>
Attached patch should fix the issue.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/be7f3b5b-88d0-4472-ada4-c9c45ce73e47%40googlegroups.com.
# HG changeset patch
# Parent 81713f67883d0bb0545e0b48347d5b709ec382df
diff --git a/src/if_lua.c b/src/if_lua.c
--- a/src/if_lua.c
+++ b/src/if_lua.c
@@ -119,6 +119,7 @@ static luaV_Funcref *luaV_pushfuncref(lu
#define luaL_buffinit dll_luaL_buffinit
#define luaL_addlstring dll_luaL_addlstring
#define luaL_pushresult dll_luaL_pushresult
+#define luaL_loadstring dll_luaL_loadstring
// lua
#if LUA_VERSION_NUM <= 501
#define lua_tonumber dll_lua_tonumber
@@ -213,6 +214,7 @@ lua_State *(*dll_luaL_newstate) (void);
void (*dll_luaL_buffinit) (lua_State *L, luaL_Buffer *B);
void (*dll_luaL_addlstring) (luaL_Buffer *B, const char *s, size_t l);
void (*dll_luaL_pushresult) (luaL_Buffer *B);
+int (*dll_luaL_loadstring) (lua_State *L, const char *s);
// lua
#if LUA_VERSION_NUM <= 501
lua_Number (*dll_lua_tonumber) (lua_State *L, int idx);
@@ -325,6 +327,7 @@ static const luaV_Reg luaV_dll[] = {
{"luaL_buffinit", (luaV_function) _luaL_buffinit},
{"luaL_addlstring", (luaV_function) _luaL_addlstring},
{"luaL_pushresult", (luaV_function) _luaL_pushresult},
+{"luaL_loadstring", (luaV_function) _luaL_loadstring},
// lua
#if LUA_VERSION_NUM <= 501
{"lua_tonumber", (luaV_function) _lua_tonumber},
Re: 'visualbell' seems not to work in the GTK3 GUI
Hi Tony,
2020/5/17 Sun 22:11:11 UTC+9 Tony Mechelynck wrote:
>
> gvim 8.2.773 (Big) with GTK3 GUI
> :echo exists('+errorbells') exists('+visualbell') answers 1 1
> My vimrc includes the following:
> if exists('+errorbells') && exists('+visualbell')
> set errorbells visualbell
> if has('gui_running')
> au GUIEnter * set t_vb= ^[\|250f
> endif
> endif
>
> (in the autocmmand, the ^[ is a real Esc) and when I ask :verbose set
> vb? t_vb? in the GUI the answer is
>
> visualbell
> Last set from ~/.vimrc line 437
> t_vb=^[|250f
> Last set from ~/.vimrc line 439
>
> with the ^[ in blue and the rest in black
> and yet, when I hit Esc in Normal mode in the GUI, nothing happens. No
> sound, no temporary inversion of the background.
>
> If I comment away the autocommand, t_vb is et at is defaut i.e ^[|f
> but I still don't see any visualbell
>
> Oh, and BTW 'belloff' is at its default (empty).
>
> With the same vimrc and the same executable but invoked as "vim" in an
> xterm, I see
> t_vb=^[[?5h$<100/>^[[?5l
>
> and there is a faint but discernible visualbell. In a konsole, t_vb
> has the same value as in xterm and the visualbell is much more
> visible.
>
> Best regards,
> Tony.
>
gui_mch_flash() is not implemented for GTK3:
https://github.com/vim/vim/blob/ed37d9b3241abe7c302c7ac606df80037aecdb46/src/gui_gtk_x11.c#L5941-L5943
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/e2e5e059-4fcc-4765-add7-ed928ee11dda%40googlegroups.com.
Re: gcc 10.1 warnings
Hi, 2020/5/10 Sun 6:38:41 UTC+9 John Marriott wrote: > > > On 10-May-2020 07:11, Bram Moolenaar wrote: > > Any specified reason you exclude clang here? I thought it was using the > > same runtime library. > > > > > Ah no. It looks like I pinched too much from stackoverflow. Whoops sorry > :-) > I don't think we need to use #if here. Attached patch should be enough. Additionally, at least Windows 7's msvcrt.dll doesn't support the "z" specifier. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ac8d33b1-f1cc-4a98-a68e-c212db0a3977%40googlegroups.com. diff --git a/src/vim.h b/src/vim.h --- a/src/vim.h +++ b/src/vim.h @@ -341,9 +341,9 @@ typedef unsigned int int_u; #ifdef _WIN64 typedef unsigned __int64 long_u; typedef __int64 long_i; -# define SCANF_HEX_LONG_U "%Ix" -# define SCANF_DECIMAL_LONG_U "%Iu" -# define PRINTF_HEX_LONG_U "0x%Ix" +# define SCANF_HEX_LONG_U "%llx" +# define SCANF_DECIMAL_LONG_U "%llu" +# define PRINTF_HEX_LONG_U "0x%llx" #else // Microsoft-specific. The __w64 keyword should be specified on any typedefs // that change size between 32-bit and 64-bit platforms. For any such type,
Re: gcc 10.1 warnings
Hi,
2020/5/9 Sat 20:06:48 UTC+9 Ken Takata wrote:
>
> Hi John,
>
> 2020/5/9 Sat 16:30:42 UTC+9 John Marriott wrote:
>>
>> Hi All,
>>
>> After cleaning my vim source repo and rebuilding with the brand new gcc
>> 10.1 (mingw64), I get these warnings:
>>
>> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
>> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_MSWIN
>> -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
>> -freg-struct-return main.c -o gobjnative/main.o
>> In file included from main.c:11:
>> main.c: In function 'early_arg_scan':
>> vim.h:343:33: warning: 'I' flag used with '%x' gnu_scanf format
>> [-Wformat=]
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ^
>> vim.h:343:33: note: in definition of macro 'SCANF_HEX_LONG_U'
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ^
>> vim.h:343:36: note: format string is defined here
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ^
>> vim.h:343:33: warning: format '%x' expects argument of type 'unsigned
>> int *', but argument 3 has type 'long_u *' {aka 'long lo
>> ng unsigned int *'} [-Wformat=]
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ^
>> vim.h:343:33: note: in definition of macro 'SCANF_HEX_LONG_U'
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ^
>> vim.h:343:36: note: format string is defined here
>>343 | # define SCANF_HEX_LONG_U "%Ix"
>>| ~~^
>>| |
>>|unsigned int *
>>| %Illx
>> vim.h:344:33: warning: format '%u' expects argument of type 'unsigned
>> int *', but argument 3 has type 'long_u *' {aka 'long lo
>> ng unsigned int *'} [-Wformat=]
>>344 | # define SCANF_DECIMAL_LONG_U "%Iu"
>>| ^
>> vim.h:344:33: note: in definition of macro 'SCANF_DECIMAL_LONG_U'
>>344 | # define SCANF_DECIMAL_LONG_U "%Iu"
>>| ^
>> vim.h:344:36: note: format string is defined here
>>344 | # define SCANF_DECIMAL_LONG_U "%Iu"
>>| ~~^
>>| |
>>|unsigned int *
>>| %Illu
>>
>> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
>> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_MSWIN
>> -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
>> -freg-struct-return dict.c -o gobjnative/dict.o
>> In file included from dict.c:14:
>> In function 'dictitem_copy',
>> inlined from 'dict_extend' at dict.c:936:9:
>> vim.h:1591:26: warning: 'strcpy' offset 0 from the object at ''
>> is out of the bounds of referenced subobject 'di_key'
>> with type 'char_u[1]' {aka 'unsigned char[1]'} at offset 0
>> [-Warray-bounds]
>> 1591 | #define STRCPY(d, s) strcpy((char *)(d), (char *)(s))
>>| ^~~~
>> vim.h:1591:26: note: in definition of macro 'STRCPY'
>> 1591 | #define STRCPY(d, s) strcpy((char *)(d), (char *)(s))
>>| ^~
>> In file included from vim.h:1815,
>> from dict.c:14:
>> dict.c: In function 'dict_extend':
>> structs.h:1466:12: note: subobject 'di_key' declared here
>> 1466 | char_u di_key[1]; // key (actually longer!)
>>| ^~
>>
>> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
>> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_MSWIN
>> -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
>> -freg-struct-return evalvars.c -o gobjnative/evalvars.o
>> evalvars.c: In function 'lookup_scriptvar':
>> cc1.exe: warning: function may return address of local variable
>> [-Wreturn-local-addr]
>> evalvars.c:2504:12: note: declared here
>> 2504 | char_u buffer[30];
>>| ^~
>>
>> gcc -c -I. -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603
>> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_MSWIN
>> -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer
>> -freg-struct-return userfunc.c -o gobjnative/userfunc.o
>> In file included from userfunc.c:14:
>> In function 'cat_func_name',
>> inlined from 'get_user_func_name' at userfunc.c:3425:2:
>> vim.h:1591:26: warning: 'strcpy' offset 0 from the object at ''
>> is out of the bounds of referenced subobject 'uf_name
&
Re: gcc 10.1 warnings
> userfunc.c: In function 'get_user_func_name': > structs.h:1569:12: note: subobject 'uf_name' declared here > 1569 | char_u uf_name[1]; // name of function (actually longer); can >| ^~~ > > > I've had a look at the vim.h warning (the one from main.c). From what I > can gather the "I" in the "%Ix" and "%Iu" scan format strings is a > MS-specific thing. Anyhow, replacing the "I" with "z" in the format > strings (lines 343 to 345 in vim.h) makes the warnings go away (see the > attached patch). > > Not sure about the others at the moment. > > Cheers > John > Unfortunately, older MSVC (e.g. VC 2010) doesn't support "z" specifier. Do the warnings disappear if you change "%I" to "%I64"? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/619b331e-4f42-49ae-a8ae-539d84be955a%40googlegroups.com.
Re: Patch 8.2.0463
Hi Bram, 2020/3/29 Sun 4:45:18 UTC+9 Bram Moolenaar wrote: > > > Ken Takata wrote: > > > 2020/3/28 Sat 5:09:20 UTC+9 Bram Moolenaar wrote: > > > > > > I wrote: > > > > > > > Patch 8.2.0463 > > > > Problem:Build error without float and channel feature. (John > > > Marriott) > > > > Solution: Define return types always. > > > > Files: src/globals.h, src/evalfunc.c > > > > > > Somehow the git commit got the wrong description and tag. > > > Don't think that can be fixed afterwards. > > > > > > > You cannot modify the commit message, but you can modify the tag by `git > > tag -f` and `git push -f`. > > The usual git command puzzle... OK, I think I figured it out, check if > it's OK now. > Thanks. The tags are okay now. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/42b68493-43e0-491f-84ac-b8ab0b10f270%40googlegroups.com.
Re: Patch 8.2.0463
Hi Bram, 2020/3/28 Sat 5:09:20 UTC+9 Bram Moolenaar wrote: > > > I wrote: > > > Patch 8.2.0463 > > Problem:Build error without float and channel feature. (John > Marriott) > > Solution: Define return types always. > > Files: src/globals.h, src/evalfunc.c > > Somehow the git commit got the wrong description and tag. > Don't think that can be fixed afterwards. > You cannot modify the commit message, but you can modify the tag by `git tag -f` and `git push -f`. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/fe712c76-b23a-4fa6-a4d7-d6aa32ab711b%40googlegroups.com.
Re: Pending appveyor build requests are not canceled when a PR is updated
Hi Christian, 2020/3/16 Mon 17:08:13 UTC+9 Christian Brabandt wrote: > > > On Sa, 14 Mär 2020, Dominique Pellé wrote: > > > Yegappan Lakshmanan > wrote: > > > > > Hi, > > > > > > When a PR is updated multiple times quickly, multiple build requests > > > are submitted to Travis-CI and Appveyor. In Travis-CI only the last > > > build request is processed and all the older pending build requests > are > > > canceled. But in Appveyor all the build requests are processed > > > in sequence. Is it possible to cancel all the pending build requests > > > for a PR when a build request is submitted in Appveyor? > > > > > > Thanks, > > > Yegappan > > > > Also, I experienced tests that were hanging in Appveyor and > > Appveyor would time out after 1 hour. It's too much. It wastes > > time. Appveyor tests normally take about 18 min. So a time out > > of 30 min would give enough margin. > > I have enabled Rolling builds for PRs, that should make sure, only the > latest commit is tested. I also lowered the build-timeout to 30 > minutes. And finally I enabled parallel builds, however it is not clear > to me, if this is only active for msbuild projects, so it might not have > an effect. > Parallel builds may not work for the Free plan. https://www.appveyor.com/docs/parallel-testing/#requirements > but jobs will run in series as the Free plan allows 1 concurrent job per account. One possible option is utilizing GitHub Actions. It supports parallel builds. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/a2221631-c93c-4c70-81ea-e455f015d3be%40googlegroups.com.
Re: Trying to build with MinGW
Hi, 2020/3/9 Mon 0:02:21 UTC+9 Bram Moolenaar wrote: > > > John Marriott wrote: > > > On 08-Mar-2020 00:39, Bram Moolenaar wrote: > > > On my Windows 10 laptop I'm trying to build a non-GUI debug version > with > > > MinGW. It has a few complaints, first one is that INT_MAX was not > > > defined. I solved that by including in vim.h. > > > > > > Building with the terminal feature fails with > > > LPROC_THREAD_ATTRIBUTE_LIST undefined. > > > > > > I disabled FEAT_TERMINAL for now, then the linking fails with > > > "-municode" not being defined. > > > > > > Is this perhaps because my MinGW version is too old? > > > > > > > > Hi Bram, > > > > Yeah I reckon it's old. I have been using mingw64 to build both vim and > > gvim for years now with no problems. > > > > It could be time to update. > > > > In case you were wondering, I use the latest x64 builds from here > > (currently gcc v9.2.1): https://gcc-mcf.lhmouse.com > > I've also used builds from here: > > https://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64 > > I've not tried it but I think builds from here work as well (gcc v9.1): > > https://nuwen.net/mingw.html > > For an older gcc release: > > > https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh > > > Thanks for the hints. > > I tried the second entry in INSTALLpc.txt, using MSYS2 with MinGW, but > the website appears to be down. > > It would be nice if we have one way that "just works"... > It seems that the msys2 site is down these few days. You can download the installer from here for now: https://sourceforge.net/projects/msys2/files/latest/download Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0a3438f2-fd8d-4c51-986e-f80518d6c864%40googlegroups.com.
Re: Buffer write message is incorrect (take 2)
Hi, 2020/2/22 Sat 6:39:30 UTC+9 John Marriott wrote: > > Hi All, > > I have just applied a bunch of patches to my HP-UX (non-gui) build to > bring it up to 8.2.0292 and noticed that the message that is displayed when > a buffer is written isn't right. > > For example (note the number of chars): > > > My Win64 build looks ok: > > > Here is output of ':ver' of the HP-UX build: > :ver > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 21 2020 09:56:41) > Included patches: 1-292 > Compiled by John > Normal version without GUI. Features included (+) or not (-): > +acl +cursorbind+insert_expand +mouse_sgr > -ruby -title > -arabic-cursorshape -job -mouse_sysmouse > +scrollbind-toolbar > +autocmd +dialog_con+jumplist -mouse_urxvt > -signs +user_commands > -autochdir +diff -keymap +mouse_xterm > -smartindent -vartabs > -autoservername-digraphs +lambda +multi_byte > -sound +vertsplit > -balloon_eval -dnd -langmap -multi_lang > -spell +virtualedit > -balloon_eval_term -ebcdic+libcall -mzscheme > -startuptime +visual > -browse-emacs_tags+linebreak -netbeans_intg > +statusline+visualextra > +builtin_terms +eval -lispindent +num64 > -sun_workshop -viminfo > +byte_offset +ex_extra +listcmds +packages > +syntax+vreplace > -channel +extra_search +localmap -path_extra > +tag_binary+wildignore > +cindent -farsi -lua -perl > -tag_old_static+wildmenu > -clientserver +file_in_path -menu -persistent_undo > -tag_any_white +windows > -clipboard +find_in_path -mksession -popupwin > -tcl +writebackup > +cmdline_compl -float +modify_fname -printer > -termguicolors -X11 > +cmdline_hist -folding +mouse -profile > -terminal -xfontset > +cmdline_info -footer-mouseshape -python > +terminfo -xim > +comments +fork()-mouse_dec -python3 > -termresponse -xpm > -conceal -gettext -mouse_gpm -quickfix > +textobjects -xsmp > -cryptv-hangul_input -mouse_jsbterm -reltime > -textprop -xterm_clipboard > -cscope-iconv -mouse_netterm -rightleft > -timers-xterm_save >system vimrc file: "$VIM/vimrc" > user vimrc file: "$HOME/.vimrc" > 2nd user vimrc file: "~/.vim/vimrc" > user exrc file: "$HOME/.exrc" >defaults file: "$VIMRUNTIME/defaults.vim" > fall-back for $VIM: "/usr/local/share/vim" > Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -D_REENTRANT > Linking: cc -L/usr/local/lib -o vim -lm -ltermlib > > I'm not sure which patch caused this. > > Cheers > John > Maybe 8.2.0271 causes it. Does the HP-UX compiler supports 64-bit integer? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/1c01e749-0c39-47b1-95c3-b48080d3ede4%40googlegroups.com.
Re: Behavior of `:silent !{cmd}`
Hi Bram,
2020/2/8 Sat 7:03:24 UTC+9 Bram Moolenaar wrote:
>
>
> Ken Takata wrote:
>
> > `:help :!` says:
> >
> > Vim redraws the screen after the command is finished,
> > because it may have printed any text. This requires a
> > hit-enter prompt, so that you can read any messages.
> > To avoid this use: >
> > :silent !{cmd}
> > <The screen is not redrawn then, thus you have to use
> > CTRL-L or ":redraw!" if the command did display
> > something.
> >
> > However, I think this is not accurate.
> >
> > If 't_ti' and 't_te' are set to empty, then `:silent !{cmd}` keeps
> showing
> > the
> > output of the command. User needs to use CTRL-L to show the Vim screen
> > again.
> > (This behavior matches the help.)
> >
> > On the other hand, if 't_ti' and 't_te' are set to default, Vim uses
> > alternate
> > screen, then `:silent !{cmd}` shows a blank screen after the execution
> of
> > the
> > command (even the command didn't display anything). User still needs to
> use
> > CTRL-L to show the Vim screen again.
> > This behavior differs from the help, and I don't think it is useful at
> all.
> > How about restoring the Vim screen automatically when alternate screen
> is
> > enabled? E.g.:
> >
> > --- a/src/ex_cmds.c
> > +++ b/src/ex_cmds.c
> > @@ -1469,6 +1469,8 @@ do_shell(
> > wait_return(term_console ? -1 : msg_silent == 0); // see below
> > # else
> > wait_return(msg_silent == 0);
> > +if (swapping_screen() && msg_silent > 0)
> > +redraw_later_clear();
> > # endif
> > no_wait_return = save_nwr;
> > }
> >
> >
> > The help should be also updated.
>
> The problem appears to be that t_te includes ESC [J, which clears the
> screen. When I remove the ":silent !ls" command is OK.
>
> I wonder why it's in the default t_te entry. Can we just remove it?
>
In my environment, t_te is "^[[?1049l^[[23;0;0t".
"^[[J" is not included.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/2d18e58e-645a-47b1-8162-a034337fd59f%40googlegroups.com.
Re: Behavior of `:silent !{cmd}`
Hi,
2020/2/7 Fri 18:19:53 UTC+9 Ken Takata wrote:
>
> Hi,
>
> `:help :!` says:
>
> Vim redraws the screen after the command is finished,
> because it may have printed any text. This requires a
> hit-enter prompt, so that you can read any messages.
> To avoid this use: >
> :silent !{cmd}
> <The screen is not redrawn then, thus you have to use
> CTRL-L or ":redraw!" if the command did display
> something.
>
> However, I think this is not accurate.
>
> If 't_ti' and 't_te' are set to empty, then `:silent !{cmd}` keeps showing
> the
> output of the command. User needs to use CTRL-L to show the Vim screen
> again.
> (This behavior matches the help.)
>
> On the other hand, if 't_ti' and 't_te' are set to default, Vim uses
> alternate
> screen, then `:silent !{cmd}` shows a blank screen after the execution of
> the
> command (even the command didn't display anything). User still needs to use
> CTRL-L to show the Vim screen again.
> This behavior differs from the help, and I don't think it is useful at
> all.
> How about restoring the Vim screen automatically when alternate screen is
> enabled? E.g.:
>
> --- a/src/ex_cmds.c
> +++ b/src/ex_cmds.c
> @@ -1469,6 +1469,8 @@ do_shell(
> wait_return(term_console ? -1 : msg_silent == 0); // see below
> # else
> wait_return(msg_silent == 0);
> +if (swapping_screen() && msg_silent > 0)
> +redraw_later_clear();
> # endif
> no_wait_return = save_nwr;
> }
>
>
> The help should be also updated.
>
Hmm, it seems that Google Groups' Web interface automatically expands tabs
into spaces.
I attached the correct patch.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/b4f79029-78d2-42e4-bc6d-2f0b2250f957%40googlegroups.com.
# HG changeset patch
# Parent 27e92debb9725d72601e4c20b897978f7d3018c4
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -1469,6 +1469,8 @@ do_shell(
wait_return(term_console ? -1 : msg_silent == 0); // see below
# else
wait_return(msg_silent == 0);
+ if (swapping_screen() && msg_silent > 0)
+ redraw_later_clear();
# endif
no_wait_return = save_nwr;
}
Behavior of `:silent !{cmd}`
Hi,
`:help :!` says:
Vim redraws the screen after the command is finished,
because it may have printed any text. This requires a
hit-enter prompt, so that you can read any messages.
To avoid this use: >
:silent !{cmd}
<The screen is not redrawn then, thus you have to use
CTRL-L or ":redraw!" if the command did display
something.
However, I think this is not accurate.
If 't_ti' and 't_te' are set to empty, then `:silent !{cmd}` keeps showing
the
output of the command. User needs to use CTRL-L to show the Vim screen
again.
(This behavior matches the help.)
On the other hand, if 't_ti' and 't_te' are set to default, Vim uses
alternate
screen, then `:silent !{cmd}` shows a blank screen after the execution of
the
command (even the command didn't display anything). User still needs to use
CTRL-L to show the Vim screen again.
This behavior differs from the help, and I don't think it is useful at all.
How about restoring the Vim screen automatically when alternate screen is
enabled? E.g.:
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -1469,6 +1469,8 @@ do_shell(
wait_return(term_console ? -1 : msg_silent == 0); // see below
# else
wait_return(msg_silent == 0);
+if (swapping_screen() && msg_silent > 0)
+redraw_later_clear();
# endif
no_wait_return = save_nwr;
}
The help should be also updated.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/15c982cf-26a0-4300-be9b-08ea48027a28%40googlegroups.com.
Re: vim.exe locks-up in Test_range()
Hi,
I also faced the same issue.
2020/1/28 Tue 19:18:26 UTC+9 Bram Moolenaar wrote:
>
>
> Michael Soyka wrote:
>
> > Builtin function feedinput is called in Test_range, file
> > testdir/test_functions.vim. This function works only with +unix or GUI
> is
> > running. Calling this function will cause vim.exe (without GUI) to
> lockup
> > (Windows 10).
> >
> > I've not used "CheckUnix" and "CheckGui" in the attached patch so that
> the
> > throw message is not misleading.
>
> Can you try if using feedkeys() instead of test_feedinput() works?
> We don't need a very low-level input here.
>
> Alternatively, this mechanism should work like it's done in
> Test_inputlist():
>
> call feedkeys(":let c = inputlist(['Select color:', '1. red', '2.
> green', '3. blue'])\1\", 'tx')
I tried it locally and it worked fine.
I also find another issue related to this.
* When vim.exe is compiled with VIMDLL, test_feedinput() causes an infinite
loop.
gui.in_use should be checked.
* Call of json_encode() was not in the alphabetical order. Sort it and add
a comment.
Please check the attached patch.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/607efec4-bb56-452d-aa76-110b40adac47%40googlegroups.com.
# HG changeset patch
# Parent 784e3f41d80510bc75551c73a38555084112f746
diff --git a/src/testdir/test_functions.vim b/src/testdir/test_functions.vim
--- a/src/testdir/test_functions.vim
+++ b/src/testdir/test_functions.vim
@@ -1849,12 +1849,10 @@ func Test_range()
call assert_equal(1, index(range(1, 5), 2))
" inputlist()
- call test_feedinput("1\")
- call assert_equal(1, inputlist(range(10)))
- call test_feedinput("1\")
- call assert_equal(1, inputlist(range(3, 10)))
-
- call assert_equal('[0,1,2,3]', json_encode(range(4)))
+ call feedkeys(":let result = inputlist(range(10))\1\", 'x')
+ call assert_equal(1, result)
+ call feedkeys(":let result = inputlist(range(3, 10))\1\", 'x')
+ call assert_equal(1, result)
" insert()
call assert_equal([42, 1, 2, 3, 4, 5], insert(range(1, 5), 42))
@@ -1867,6 +1865,9 @@ func Test_range()
" join()
call assert_equal('0 1 2 3 4', join(range(5)))
+ " json_encode()
+ call assert_equal('[0,1,2,3]', json_encode(range(4)))
+
" len()
call assert_equal(0, len(range(0)))
call assert_equal(2, len(range(2)))
diff --git a/src/testing.c b/src/testing.c
--- a/src/testing.c
+++ b/src/testing.c
@@ -640,6 +640,11 @@ f_test_feedinput(typval_T *argvars, typv
#ifdef USE_INPUT_BUF
char_u *val = tv_get_string_chk([0]);
+# ifdef VIMDLL
+if (!gui.in_use)
+ return;
+# endif
+
if (val != NULL)
{
trash_input_buf();
[doc][patch] Typo in options.txt
Hi Bram, I found a typo in options.txt: --- a/runtime/doc/options.txt +++ b/runtime/doc/options.txt @@ -5253,7 +5253,7 @@ A jump table for the options with a short description can be found at |Q_op|. default because it makes using the pull down menus a little goofy, as a pointer transit may activate a window unintentionally. MS-Windows: Also see 'scrollfocus' for what window is scrolled when -using the mouse scroll whel. +using the mouse scroll wheel. *'mousehide'* *'mh'* *'nomousehide'* *'nomh'* 'mousehide' 'mh'boolean(default on) Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/46e81e81-7dfe-4c80-a8ae-7ffaa427cf45%40googlegroups.com.
Re: Fix regressions in the latest runtime files update
Hi Bram and Charles,
2020/1/11 Sat 3:57:27 UTC+9 Bram Moolenaar wrote:
>
>
> Ken Takata wrote:
>
> > There are many regressions in Charles' plugins in the latest runtime
> file
> > update
> > as reported at
> >
> https://github.com/vim/vim/commit/2963456ff2b740244b3a064785fe681b1998d75e#r36734504
>
> > .
> > Please check the attached patch.
>
> Thanks, I'll include it. I hope Charles will update the upstream
> version.
>
>
I forgot one more change:
--- a/runtime/doc/pi_netrw.txt
+++ b/runtime/doc/pi_netrw.txt
@@ -4306,4 +4306,4 @@ netrw:
==
Modelines: {{{1
- vim:tw=78:ts=8:ft=help:norl:fdm=marker
+ vim:tw=78:ts=8:noet:ft=help:norl:fdm=marker
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/68de796e-dd18-47ef-8811-17457314f527%40googlegroups.com.
Fix regressions in the latest runtime files update
Hi Bram and Charles, There are many regressions in Charles' plugins in the latest runtime file update as reported at https://github.com/vim/vim/commit/2963456ff2b740244b3a064785fe681b1998d75e#r36734504 . Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAKNHtdkU96wDjTbUjHyMWeQCAbFGXCm1Rec9ZuEV7rqAY9EmjA%40mail.gmail.com. fix-regressions-in-charles-plugins.patch Description: Binary data
Re: Patch 8.2.0090
Hi Bram, 2020/1/6 Mon 6:11:29 UTC+9 Bram Moolenaar wrote: > > > Patch 8.2.0090 > Problem:Generated files show up in git status. > Solution: Ignore a few more files. > Files:.gitignore > I think that similar changes are needed for .hgignore: --- a/.hgignore +++ b/.hgignore @@ -10,6 +10,7 @@ src/auto/gui_gtk_gresources.h src/objects/.dirstamp src/objects src/tags +src/types.vim # We do need src/auto/configure. src/auto/config.cache @@ -86,6 +87,7 @@ src/kword_test # Generated by "make install" runtime/doc/tags +runtime/doc/doctags # Generated by "make shadow". The directory names could be anything but we # restrict them to shadow (the default) or shadow-* Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/fea8c2c6-79c4-4618-9df6-802fc82737c7%40googlegroups.com.
Re: Vim9 script: first steps
Hi Bram,
2020/1/3 Fri 19:02:13 UTC+9 Bram Moolenaar wrote:
>
>
> Yasuhiro Matsumoto wrote:
>
> > Why you don't use { ?
>
> I know this will trigger a discussion. Nearly all languages use blocks
> ending with "}". It's much easier to see where a block ends that way
> than using "endif", "endwhile", etc., it stands out.
>
> Since we already have the start of the block without extra punctuation,
> there is no need to add a "{" there. It would be pointless to add it.
>
Text objects like "a{" or "i{" don't work well without the starting "{".
Also "%" may not work well.
> The only place where "{" will appear is a block by itself, used to
> declare a variable:
>
> {
>let tmp = 0
> ...
> }
> " tmp not available here
>
> If you don't like using "}" you can use "endif", "endfor", etc. as before.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/e77d44ae-1897-4caa-b896-9e9c24f348ec%40googlegroups.com.
Re: Patch 8.2.0080
Hi Bram, 2020/1/3 Fri 6:40:12 UTC+9 Bram Moolenaar wrote: > > > Patch 8.2.0080 > Problem:Globals using INIT4() are not in the tags file. > Solution: Adjust the tags command. > Files:src/configure.ac, src/auto/configure > Similar changes are needed for Make_cyg_ming.mak and Make_mvc.mak. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/1de9a5da-dd4d-4804-8dbf-09102654a1a1%40googlegroups.com. # HG changeset patch # Parent 0d61e653682cd690e5e69eef447c4dbfe7870583 diff --git a/src/Make_cyg_ming.mak b/src/Make_cyg_ming.mak --- a/src/Make_cyg_ming.mak +++ b/src/Make_cyg_ming.mak @@ -115,7 +115,7 @@ endif ifndef CTAGS # this assumes ctags is Exuberant ctags -CTAGS = ctags -I INIT+ --fields=+S +CTAGS = ctags -I INIT+,INIT2+,INIT3+,INIT4+,INIT5+ --fields=+S endif # Link against the shared version of libstdc++ by default. Set diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak --- a/src/Make_mvc.mak +++ b/src/Make_mvc.mak @@ -334,7 +334,7 @@ FEATURES = HUGE !ifndef CTAGS # this assumes ctags is Exuberant ctags -CTAGS = ctags -I INIT+ --fields=+S +CTAGS = ctags -I INIT+,INIT2+,INIT3+,INIT4+,INIT5+ --fields=+S !endif !ifndef CSCOPE
Re: Vim 8.2 is released!
Hi Christian, It seems that the hg mirror repositories are missing two tags: v8.2.0 and v8.2.. Could you add those tags? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/321b8da0-011e-49d8-bc78-f1c68a60ef27%40googlegroups.com.
Re: Vim 8.2 is released!
Hi Bram, I found a missing feature which should have been added in the *new-vimscript-8.2* section in the version8.txt. |optional-function-argument| was added in 8.1.1310. It's too late for the release notes, but it might be better to update version8.txt. I also found a typo: --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -25897,7 +25897,7 @@ Makefiles for old Amiga compilers were r If a swap file is found without any changes it is automatically deleted. The FEAT_TAG_OLDSTATIC code was removed, it slowed down tag searches. -The FEAT_TAG_ANYWHITE code was removed, is was not enabled in any build. +The FEAT_TAG_ANYWHITE code was removed, it was not enabled in any build. The UNICODE16 code was removed, it was not useful. Workshop support was removed, nobody was using it. The Aap build files were removed, they were outdated. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5c6958f0-ca86-40a9-8c9b-4a3807077627%40googlegroups.com.
Re: Vim 8.2 is released!
Hi Christian, 2019/12/13 Fri 17:09:18 UTC+9 Christian Brabandt wrote: > > > On Do, 12 Dez 2019, Bram Moolenaar wrote: > > > Announcing: Vim (Vi IMproved) version 8.2 > > Congratulations! > > > Signed versions will appear soon at: > > https://github.com/vim/vim-win32-installer/releases > > For some reason, the automatic job failed today because of a download > timeout when trying to download the racket dependencies. I tried to > manually trigger a build, but that fails again every time. > > I can download it locally fine, so not sure what problem Appveyor has. > Hopefully this is just a hickup, that goes away. > Looking at the log of AppVeyor, it seems that now "download.racket-lang.org" is redirected to "mirror.racket-lang.org" which caused a trouble before: https://github.com/vim/vim-win32-installer/pull/116. Isn't it better to use "www.cs.utah.edu" or some another mirror? (www.cs.utah.edu is one of the official mirrors.) Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/f34ff8ca-f03e-46cc-9c7f-0947207d55f2%40googlegroups.com.
Re: Vim 8.2 is released!
Hi, 2019/12/13 Fri 3:38:41 UTC+9 Heptite wrote: > > On Thu, 12 Dec 2019, Christian J. Robinson wrote: > > > :echo v:version > > 801 > > > > This happens in my manually compiled version and in the Windows > > executable I got from vim.org. > > Correction, this does NOT happen with the version I got from vim.org, > and I resolved the issue with my local compile by doing a full > reconfig and recompile. > > Sorry for the noise. > I remember that you reported the same issue when Vim 8.1 was released. Looking at the Windows makefiles, I found that some dependencies to version.h are missing. So this can happen when MSVC or MinGW is used. I will prepare a patch when I have a time. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/6952abc4-db0b-4e8a-ae1b-915bcdd1413f%40googlegroups.com.
Re: [doc][patch] Update documents of Charles' plugins
Hi Bram, 2019/12/9 Mon 14:02:11 UTC+9 Ken Takata wrote: > > Hi Charles and Bram, > > I found some mistakes in the documents of Charles' plugins. > Could you check and merge the attached patch? > You made a mistake in the latest runtime file update. A single quote was removed. Could you apply the following patch? --- a/runtime/doc/pi_netrw.txt +++ b/runtime/doc/pi_netrw.txt @@ -1184,7 +1184,7 @@ One may easily "bookmark" the currently *.netrwbook* Bookmarks are retained in between sessions of vim in a file called .netrwbook as a |List|, which is typically stored in the first directory on the user's -runtimepath'; entries are kept in sorted order. +'runtimepath'; entries are kept in sorted order. If there are marked files and/or directories, mb will add them to the bookmark list. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/f7353f74-a485-43ae-9db9-7e84cf1cd89b%40googlegroups.com.
[doc][patch] Update documents of Charles' plugins
Hi Charles and Bram, I found some mistakes in the documents of Charles' plugins. Could you check and merge the attached patch? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAKNHtd%3DaSmoCpqhSfGaNqhPsHmyj26v7af1qMqAdXBDSZFFgUA%40mail.gmail.com. fix-doc-drchipplugins.patch Description: Binary data
Re: Upcoming Vim 8.2 release
Hi Bram, Here is another patch for the latest version8.txt: --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -40841,7 +40841,7 @@ Files:src/register.c, src/testdir/t Patch 8.1.2376 Problem:Preprocessor indents are incorrect. Solution: Fix the indents. (Ken Takata, closes #5298) -Files:src/drawline.c, src/gui_w32.c src/os_mswin.c src/os_win32.c +Files:src/drawline.c, src/gui_w32.c, src/os_mswin.c, src/os_win32.c, src/proto.h Patch 8.1.2377 Commas were missing. Retards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/9f708409-469f-49a5-8ab0-9feb6c90c6ad%40googlegroups.com.
Re: Patch 8.1.2389
Hi Bram, 2019/12/5 Thu 21:42:51 UTC+9 Bram Moolenaar wrote: > > > Ken Takata wrote: > > > 2019/12/5 Thu 6:17:35 UTC+9 Bram Moolenaar wrote: > > > > > > > > > Patch 8.1.2389 > > > Problem:Using old C style comments. > > > Solution: Use // comments where appropriate. > > > Files:src/libvterm/src/screen.c, > src/libvterm/src/unicode.c, > > > src/libvterm/src/vterm.c, src/libvterm/t/harness.c, > > > src/libvterm/include/vterm.h, src/xdiff/xdiffi.c, > > > src/xdiff/xemit.c, src/xdiff/xhistogram.c, > > > src/xdiff/xpatience.c, > > > src/xdiff/xutils.c, src/xdiff/xdiff.h, src/xdiff/xdiffi.h, > > > src/xdiff/xemit.h, src/xdiff/xinclude.h, > src/xdiff/xmacros.h, > > > src/xdiff/xprepare.h, src/xdiff/xtypes.h, > src/xdiff/xutils.h > > > > > > > Do we need to change the coding style of the files which are imported > > from other projects? > > I'll continue with the files in the src directory, and probably src/xxd. > Are there others? > I think that libvterm and xdiff should keep the original comment style, so that we can easily keep them in sync with upstream, or send patches to upstream (if needed). Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e912d8dc-b61e-4bac-ad83-18538d962e91%40googlegroups.com.
Re: Patch 8.1.2389
Hi Bram, 2019/12/5 Thu 6:17:35 UTC+9 Bram Moolenaar wrote: > > > Patch 8.1.2389 > Problem:Using old C style comments. > Solution: Use // comments where appropriate. > Files:src/libvterm/src/screen.c, src/libvterm/src/unicode.c, > src/libvterm/src/vterm.c, src/libvterm/t/harness.c, > src/libvterm/include/vterm.h, src/xdiff/xdiffi.c, > src/xdiff/xemit.c, src/xdiff/xhistogram.c, > src/xdiff/xpatience.c, > src/xdiff/xutils.c, src/xdiff/xdiff.h, src/xdiff/xdiffi.h, > src/xdiff/xemit.h, src/xdiff/xinclude.h, src/xdiff/xmacros.h, > src/xdiff/xprepare.h, src/xdiff/xtypes.h, src/xdiff/xutils.h > Do we need to change the coding style of the files which are imported from other projects? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/721ed78f-45d1-4cee-8ebc-dedab131113c%40googlegroups.com.
Re: Upcoming Vim 8.2 release
Hi Bram,
2019/12/3 Tue 12:20:00 UTC+9 Ken Takata wrote:
>
> Hi Bram,
>
> 2019/12/3 Tue 4:42:50 UTC+9 Bram Moolenaar wrote:
>>
>>
>> Ken Takata wrote:
>>
>> > I saw the latest version8.txt.
>> > In the "Vim script improvements" section, the ".." operator is not
>> described
>> > explicitly. (It is described as a part of `:scriptversion`.)
>> > How about adding it explicitly?
>>
>> Well, I like to keep this an overview with not too many details.
>>
>> > For the improvements and changes in Vim 8.2, I'd like to list my works
>> for
>> > Windows as well:
>> >
>> > * Revised Windows installer.
>> > Supports translations, silent install, nice appearance.
>> > * VIMDLL: make it possible to merge the common part of gVim and Vim
>> into a
>> > DLL.
>> > This can reduce the total install size.
>>
>> We already had VIMDLL, but it was basically removed and re-implemented.
>>
>
> Ah, I completely forgot about the old VIMDLL implementation. ;-)
> The old one just created a DLL for gvim.exe and didn't share the code with
> vim.exe.
> I wonder if the original author intended to share the code with gvim.exe
> and vim.exe (in a future).
>
>
> > (Enabling this or not in the official Windows package is up to you,
>> Bram.
>> > vim-win32-installer doesn't enable this yet, though.)
>>
>> I rather not change it so short before a release.
>>
>
> OK, enabling VIMDLL by default is a next task for Vim 8.3 (or later).
> If we enable it, we also need to update the nsis script.
> I consider preparing that.
>
>
> > * Drop support for old compilers.
>> > Borland C++, MSVC 2008 or older.
>> >
>> > And other improvements in Vim 8.2 are:
>> >
>> > * Improved 'incsearch'.
>> > * Support modifyOtherKeys.
>> > * Support ConPTY on Windows 10.
>> > Full colors are available in the terminal mode.
>> > * Added /= and %= assignment operators.
>>
>> I updated the text to also mention things that were removed and
>> graduated:
>>
>>
>> Vim script
>> improvements*new-vimscript-8.2*
>> ---
>>
>> Functions can now be called in a chain, using "->": >
>> mylist->filter(filterexpr)->map(mapexpr)->sort()->join()
>> The new `:eval` command can be used if the chain has no result.
>>
>> The `:scriptversion` command was added to allow for changes that are not
>> backwards compatible. E.g. to only use ".." for string concatenation, so
>> that
>> "." can be used to access a dictionary member consistently.
>>
>> `:const` was added to allow for declaring a variable that cannot change:
>> >
>> const TIMER_DELAY = 400
>>
>> A heredoc-style assignment was added to easily assign a list of lines to
>> a
>> variable without quoting or line continuation: >
>> let lines =<< trim END
>>line one
>>line two
>> END
>>
>> The |Blob| type was added. This makes it easy to deal with binary data.
>>
>> The /= and %= assignment operators were added.
>>
>> A Dictionary can be defined with #{} where the keys are used literally.
>> This
>> avoids having to use quotes: >
>> let options = #{width: 30, height: 24}
>>
>>
>> Other improvements*new-other-8.2*
>> --
>>
>> - When 'incsearch' is set it also applies to `:substitute`.
>> - |modifyOtherKeys| was added to allow mapping more key combinations.
>> - ConPTY support was added for Windows 10, supports full color in the
>> terminal.
>> - The windows installer supports translations, silent install and looks
>> better.
>>
>>
>> Changed*changed-8.2*
>>
>> ---
>>
>> The xdiff library was included to avoid the need for an external diff
>> program
>> and to make updating diffs much faster.
>>
>> The code is using a few more modern C features, such as // comments.
>>
>> Support for old compilers has been dropped: Borland C++, MSVC 2008.
>>
>> Hangul input support was removed, it actually didn't work.
>>
>> The FEAT_TAG_OLDSTATIC code was removed, it slowed down tag searches.
>> The
Re: Upcoming Vim 8.2 release
Hi Bram,
2019/12/3 Tue 4:42:50 UTC+9 Bram Moolenaar wrote:
>
>
> Ken Takata wrote:
>
> > I saw the latest version8.txt.
> > In the "Vim script improvements" section, the ".." operator is not
> described
> > explicitly. (It is described as a part of `:scriptversion`.)
> > How about adding it explicitly?
>
> Well, I like to keep this an overview with not too many details.
>
> > For the improvements and changes in Vim 8.2, I'd like to list my works
> for
> > Windows as well:
> >
> > * Revised Windows installer.
> > Supports translations, silent install, nice appearance.
> > * VIMDLL: make it possible to merge the common part of gVim and Vim into
> a
> > DLL.
> > This can reduce the total install size.
>
> We already had VIMDLL, but it was basically removed and re-implemented.
>
Ah, I completely forgot about the old VIMDLL implementation. ;-)
The old one just created a DLL for gvim.exe and didn't share the code with
vim.exe.
I wonder if the original author intended to share the code with gvim.exe
and vim.exe (in a future).
> (Enabling this or not in the official Windows package is up to you,
> Bram.
> > vim-win32-installer doesn't enable this yet, though.)
>
> I rather not change it so short before a release.
>
OK, enabling VIMDLL by default is a next task for Vim 8.3 (or later).
If we enable it, we also need to update the nsis script.
I consider preparing that.
> * Drop support for old compilers.
> > Borland C++, MSVC 2008 or older.
> >
> > And other improvements in Vim 8.2 are:
> >
> > * Improved 'incsearch'.
> > * Support modifyOtherKeys.
> > * Support ConPTY on Windows 10.
> > Full colors are available in the terminal mode.
> > * Added /= and %= assignment operators.
>
> I updated the text to also mention things that were removed and
> graduated:
>
>
> Vim script improvements*new-vimscript-8.2*
> ---
>
> Functions can now be called in a chain, using "->": >
> mylist->filter(filterexpr)->map(mapexpr)->sort()->join()
> The new `:eval` command can be used if the chain has no result.
>
> The `:scriptversion` command was added to allow for changes that are not
> backwards compatible. E.g. to only use ".." for string concatenation, so
> that
> "." can be used to access a dictionary member consistently.
>
> `:const` was added to allow for declaring a variable that cannot change: >
> const TIMER_DELAY = 400
>
> A heredoc-style assignment was added to easily assign a list of lines to a
> variable without quoting or line continuation: >
> let lines =<< trim END
>line one
>line two
> END
>
> The |Blob| type was added. This makes it easy to deal with binary data.
>
> The /= and %= assignment operators were added.
>
> A Dictionary can be defined with #{} where the keys are used literally.
> This
> avoids having to use quotes: >
> let options = #{width: 30, height: 24}
>
>
> Other improvements*new-other-8.2*
> --
>
> - When 'incsearch' is set it also applies to `:substitute`.
> - |modifyOtherKeys| was added to allow mapping more key combinations.
> - ConPTY support was added for Windows 10, supports full color in the
> terminal.
> - The windows installer supports translations, silent install and looks
> better.
>
>
> Changed*changed-8.2*
>
> ---
>
> The xdiff library was included to avoid the need for an external diff
> program
> and to make updating diffs much faster.
>
> The code is using a few more modern C features, such as // comments.
>
> Support for old compilers has been dropped: Borland C++, MSVC 2008.
>
> Hangul input support was removed, it actually didn't work.
>
> The FEAT_TAG_OLDSTATIC code was removed, it slowed down tag searches.
> The FEAT_TAG_ANYWHITE code was removed, is was not enabled in any build.
> The UNICODE16 code was removed, it was not useful.
> Workshop support was removed, nobody was using it.
> The Aap build files were removed, they were outdated.
> Farsi support was removed, it was outdated and unused.
>
> VIMDLL was re-implemented, this shares the common parts between vim and
> gvim
> to reduce the total install size.
>
> The following features are now included in all versions: |+mbyte|,
> |+virtualedit|, |+vreplace|, |+localmap|, |+cmdline_hist|,
&g
Re: Upcoming Vim 8.2 release
Hi Bram, 2019/11/30 Sat 6:13:22 UTC+9 Bram Moolenaar wrote: > > > It appears the number of bug reports is getting lower. I have included > many pending pull requests. I think we are getting closer to a release. > > If you have any runtime updates, please send them now! > > I'm also wondering: what is your favorite improvement since Vim 8.1? > I saw the latest version8.txt. In the "Vim script improvements" section, the ".." operator is not described explicitly. (It is described as a part of `:scriptversion`.) How about adding it explicitly? --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -25844,6 +25844,9 @@ Functions can now be called in a chain, mylist->filter(filterexpr)->map(mapexpr)->sort()->join() The new `:eval` command can be used when there is no result. +The ".." operator was added for string concatenation to avoid confusion with a +key access operator for dictionaries. + The `:scriptversion` command was added to allow for changes that are not backwards compatible. E.g. to only use ".." for string concatenation. (I don't know the official name for the "dict.key" operator, though.) For the improvements and changes in Vim 8.2, I'd like to list my works for Windows as well: * Revised Windows installer. Supports translations, silent install, nice appearance. * VIMDLL: make it possible to merge the common part of gVim and Vim into a DLL. This can reduce the total install size. (Enabling this or not in the official Windows package is up to you, Bram. vim-win32-installer doesn't enable this yet, though.) * Drop support for old compilers. Borland C++, MSVC 2008 or older. And other improvements in Vim 8.2 are: * Improved 'incsearch'. * Support modifyOtherKeys. * Support ConPTY on Windows 10. Full colors are available in the terminal mode. * Added /= and %= assignment operators. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/89da54f9-2560-4891-b146-f7541273261f%40googlegroups.com.
doc: Fix typos in version8.txt
Hi, I found some typos in version8.txt. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2cd618dc-0cf2-4afb-ba05-42e267024ced%40googlegroups.com. # HG changeset patch # Parent 07191fc00394251f30c5b06ee64bbd5d8f9f4673 diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -953,7 +953,7 @@ Problem:A script cannot detect wheth Solution: Add the "v:hlsearch" variable. (ZyX) Files: src/eval.c, src/ex_docmd.c, src/option.c, src/screen.c, src/search.c, src/tag.c, src/vim.h, - src/testdir/test101.in, src/testdir/test101.ok, + src/testdir/test101.in, src/testdir/test101.ok, src/testdir/Make_amiga.mak, src/testdir/Make_dos.mak, src/testdir/Make_ming.mak, src/testdir/Make_os2.mak, src/testdir/Make_vms.mms, src/testdir/Makefile @@ -1714,7 +1714,7 @@ Files: src/ex_cmds.c Patch 7.4.210 Problem:Visual block mode plus virtual edit doesn't work well with tabs. - (Liang Li) + (Liang Li) Solution: Take coladd into account. (Christian Brabandt) Files: src/ops.c, src/testdir/test39.in, src/testdir/test39.ok @@ -3930,7 +3930,7 @@ Solution: Don't add one when this woul Files: src/eval.c Patch 7.4.579 -Problem:Wrong cursor positioning when 'linebreak' is set and lines wrap. +Problem:Wrong cursor positioning when 'linebreak' is set and lines wrap. Solution: Fix it. (Christian Brabandt) Files: src/charset.c, src/screen.c @@ -3967,7 +3967,7 @@ Files: src/ex_cmds.h, src/testdir/te src/testdir/test_command_count.ok Patch 7.4.586 -Problem:Parallel building of the documentation html files is not reliable. +Problem:Parallel building of the documentation html files is not reliable. Solution: Remove a cyclic dependency. (Reiner Herrmann) Files: runtime/doc/Makefile @@ -6470,7 +6470,7 @@ Files: src/os_unix.c Patch 7.4.1008 Problem:The OS/2 code pollutes the source while nobody uses it these days. -Solution: Drop the support for OS/2. +Solution: Drop the support for OS/2. Files: src/feature.h, src/globals.h, src/macros.h, src/option.h, src/os_unix.c, src/os_unix.h, src/proto/os_unix.pro, src/vim.h, src/digraph.c, src/eval.c, src/ex_cmds.c, src/ex_docmd.c, @@ -15402,7 +15402,7 @@ Files: src/screen.c, src/testdir/Ma src/testdir/test_display.vim Patch 8.0.0127 -Problem:Cancelling completion still inserts text when formatting is done +Problem:Cancelling completion still inserts text when formatting is done for 'textwidth'. (lacygoill) Solution: Don't format when CTRL-E was typed. (Hirohito Higashi, closes #1312) @@ -16957,7 +16957,7 @@ Files: src/gen_opt_test.vim Patch 8.0.0387 Problem:compiler warnings Solution: Add type casts. (Christian Brabandt) -Files: src/channel.c, src/memline.c, +Files: src/channel.c, src/memline.c Patch 8.0.0388 Problem:filtering lines through "cat", without changing the line count, @@ -17669,7 +17669,7 @@ Files: src/testdir/test_autocmd.vim Patch 8.0.0499 Problem:taglist() does not prioritize tags for a buffer. -Solution: Add an optional buffer argument. (Duncan McDougall, closes #1194) +Solution: Add an optional buffer argument. (Duncan McDougall, closes #1194) Files: runtime/doc/eval.txt, src/evalfunc.c, src/proto/tag.pro, src/Makefile, src/tag.c, src/testdir/test_alot.vim, src/testdir/test_taglist.vim @@ -19966,7 +19966,7 @@ Files: src/normal.c Patch 8.0.0875 Problem:Crash with weird command sequence. (Dominique Pelle) -Solution: Use vim_snprintf() instead of STRCPY(). +Solution: Use vim_snprintf() instead of STRCPY(). Files: src/misc1.c Patch 8.0.0876 @@ -21134,7 +21134,7 @@ Problem:term_start() does not take c returns the wrong pty. Solution: Support "callback", "out_cb" and "err_cb". Fix terminal without a window. Fix reading from multiple channels. -Files: src/terminal.c, src/proto/terminal.pro, src/channel.c, +Files: src/terminal.c, src/proto/terminal.pro, src/channel.c Patch 8.0.1077 Problem:No debugger making use of the terminal window. @@ -29600,7 +29600,7 @@ Files: src/testdir/test_gn.vim, src/ src/normal.c Patch 8.1.0630 -Problem: "wincmd p
Re: Patch 8.1.2344
Hi, 2019/11/28 Thu 14:52:43 UTC+9 Ken Takata wrote: > > Hi, > > 2019/11/28 Thu 7:07:02 UTC+9 Ken Takata wrote: >> >> Hi, >> >> 2019/11/28 Thu 6:51:22 UTC+9 Christian Brabandt wrote: >>> >>> >>> On Mi, 27 Nov 2019, Bram Moolenaar wrote: >>> >>> > What was the error on FreeBSD? I thought it also suppored Posix. >>> >>> https://cirrus-ci.com/task/5566942320001024 >>> >>> In file included from os_unix.c:87: >>> /usr/include/sys/consio.h:262:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short font_size; >>> ^ >>> /usr/include/sys/consio.h:263:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short mv_row, mv_col; >>> ^ >>> /usr/include/sys/consio.h:264:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short mv_rsz, mv_csz; >>> ^ >>> /usr/include/sys/consio.h:265:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short mv_hsz; >>> ^ >>> /usr/include/sys/consio.h:269:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char mv_ovscan; >>> ^ >>> /usr/include/sys/consio.h:270:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char mk_keylock; >>> ^ >>> /usr/include/sys/consio.h:319:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char ti_name[TI_NAME_LEN]; >>> ^ >>> /usr/include/sys/consio.h:320:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char ti_desc[TI_DESC_LEN]; >>> ^ >>> In file included from os_unix.c:88: >>> /usr/include/sys/fbio.h:196:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char *red; /* red color map elements */ >>> ^ >>> /usr/include/sys/fbio.h:197:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char *green; /* green color map elements */ >>> ^ >>> /usr/include/sys/fbio.h:198:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char *blue; /* blue color map elements */ >>> ^ >>> /usr/include/sys/fbio.h:282:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short accessible_width; /* accessible bytes in >>> scanline */ >>> ^ >>> /usr/include/sys/fbio.h:283:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short accessible_height; /* number of accessible >>> scanlines */ >>> ^ >>> /usr/include/sys/fbio.h:284:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short line_bytes; /* number of bytes/scanline */ >>> ^ >>> /usr/include/sys/fbio.h:285:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short hdb_capable;/* can this thing hardware db? >>> */ >>> ^ >>> /usr/include/sys/fbio.h:286:2: error: unknown type name 'u_short'; did >>> you mean 'short'? >>> u_short vmsize; /* video memory size */ >>> ^ >>> /usr/include/sys/fbio.h:287:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char boardrev; /* board revision # */ >>> ^ >>> /usr/include/sys/fbio.h:288:2: error: unknown type name 'u_char'; did >>> you mean 'char'? >>> u_char pad0; >>> ^ >>> /usr/include/sys/fbio.h:289:2: error: unknown type name 'u_long'; did >>> you mean 'long'? >>> u_long pad1; >>> ^ >>> fatal error: too many errors emitted, stopping now [-ferror-limit=] >>> 20 errors generated. >>> gmake[2]: *** [Makefile:3338: objects/os_unix.o] Error 1 >>> gmake[2]: Leaving directory '/tmp/cirrus-ci-build/src' >>> gmake[1]: *** [Makefile:2030: reconfig] Error 2 >>> gmake[1]: Leaving directory '/tmp/cirrus-ci-build/src' >>> gmake: *** [Makefile:29: first] Error 2
Re: Patch 8.1.2344
Hi, 2019/11/28 Thu 7:07:02 UTC+9 Ken Takata wrote: > > Hi, > > 2019/11/28 Thu 6:51:22 UTC+9 Christian Brabandt wrote: >> >> >> On Mi, 27 Nov 2019, Bram Moolenaar wrote: >> >> > What was the error on FreeBSD? I thought it also suppored Posix. >> >> https://cirrus-ci.com/task/5566942320001024 >> >> In file included from os_unix.c:87: >> /usr/include/sys/consio.h:262:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short font_size; >> ^ >> /usr/include/sys/consio.h:263:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short mv_row, mv_col; >> ^ >> /usr/include/sys/consio.h:264:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short mv_rsz, mv_csz; >> ^ >> /usr/include/sys/consio.h:265:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short mv_hsz; >> ^ >> /usr/include/sys/consio.h:269:2: error: unknown type name 'u_char'; did >> you mean 'char'? >> u_char mv_ovscan; >> ^ >> /usr/include/sys/consio.h:270:2: error: unknown type name 'u_char'; did >> you mean 'char'? >> u_char mk_keylock; >> ^ >> /usr/include/sys/consio.h:319:2: error: unknown type name 'u_char'; did >> you mean 'char'? >> u_char ti_name[TI_NAME_LEN]; >> ^ >> /usr/include/sys/consio.h:320:2: error: unknown type name 'u_char'; did >> you mean 'char'? >> u_char ti_desc[TI_DESC_LEN]; >> ^ >> In file included from os_unix.c:88: >> /usr/include/sys/fbio.h:196:2: error: unknown type name 'u_char'; did you >> mean 'char'? >> u_char *red; /* red color map elements */ >> ^ >> /usr/include/sys/fbio.h:197:2: error: unknown type name 'u_char'; did you >> mean 'char'? >> u_char *green; /* green color map elements */ >> ^ >> /usr/include/sys/fbio.h:198:2: error: unknown type name 'u_char'; did you >> mean 'char'? >> u_char *blue; /* blue color map elements */ >> ^ >> /usr/include/sys/fbio.h:282:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short accessible_width; /* accessible bytes in scanline >> */ >> ^ >> /usr/include/sys/fbio.h:283:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short accessible_height; /* number of accessible >> scanlines */ >> ^ >> /usr/include/sys/fbio.h:284:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short line_bytes; /* number of bytes/scanline */ >> ^ >> /usr/include/sys/fbio.h:285:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short hdb_capable;/* can this thing hardware db? */ >> ^ >> /usr/include/sys/fbio.h:286:2: error: unknown type name 'u_short'; did >> you mean 'short'? >> u_short vmsize; /* video memory size */ >> ^ >> /usr/include/sys/fbio.h:287:2: error: unknown type name 'u_char'; did you >> mean 'char'? >> u_char boardrev; /* board revision # */ >> ^ >> /usr/include/sys/fbio.h:288:2: error: unknown type name 'u_char'; did you >> mean 'char'? >> u_char pad0; >> ^ >> /usr/include/sys/fbio.h:289:2: error: unknown type name 'u_long'; did you >> mean 'long'? >> u_long pad1; >> ^ >> fatal error: too many errors emitted, stopping now [-ferror-limit=] >> 20 errors generated. >> gmake[2]: *** [Makefile:3338: objects/os_unix.o] Error 1 >> gmake[2]: Leaving directory '/tmp/cirrus-ci-build/src' >> gmake[1]: *** [Makefile:2030: reconfig] Error 2 >> gmake[1]: Leaving directory '/tmp/cirrus-ci-build/src' >> gmake: *** [Makefile:29: first] Error 2 >> Exit status: 2 >> > >> > I think being specific is OK, thus checking for __FreeBSD__ would be >> OK. >> > Otherwise we would need a configure check of some kind. >> > >> > > If we use __FreeBSD__, maybe we also need to add checks for other BSDs. > It seems that "BSD" is defined in sys/param.h, so how about this patch? > > --- a/src/vim.h > +++ b/src/vim.h > @@ -36,7 +36,10 @@ > Err
Re: Patch 8.1.2352
Hi Christian, 2019/11/28 Thu 7:09:08 UTC+9 Christian Brabandt wrote: > > > On Mi, 27 Nov 2019, Bram Moolenaar wrote: > > > Patch 8.1.2352 > > Problem:CI doesn't cover FreeBSD. > > Solution: Configure Cirrus-CI. (Christian Brabandt, closes #5273) > > Files:.cirrus.yml, README.md > > You are too fast ;) > This patch is not appeared in mercurial mirrors. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/9a6920b4-83d2-48c4-9df1-e286a9d18877%40googlegroups.com.
Re: Ctrl-V behavior broken in insert and command modes
Hi, 2019/11/28 Thu 10:15:10 UTC+9 Gary Johnson wrote: > > Entering Ctrl-V in insert mode or on the command line used to allow > the following character to be inserted literally. Now, when > I follow Ctrl-V with another Ctrl-V, this sequence is inserted: > > ^[[27;5;118~ > > I don't know when this started--I just noticed it in Vim 8.1.2300 on > Linux. I verified that Ctrl-V works correctly in the same terminal > (xterm 330) with Vim 8.0.1453. Both tests were run with "-N -u > NONE". > > This was fixed with 8.1.2350. If you still need to use 8.1.2300, you can disable the behavior by: let _TI = "" let _TE = "" See `:help modifyOtherKeys` for detail. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/7339483d-15ef-474c-a3d3-e68a468cb196%40googlegroups.com.
Re: Patch 8.1.2350
Hi,
2019/11/28 Thu 5:59:01 UTC+9 Bram Moolenaar wrote:
>
>
> Ken Takata wrote:
>
> > 2019/11/27 Wed 3:34:01 UTC+9 Bram Moolenaar wrote:
> > >
> > >
> > > Patch 8.1.2350
> > > Problem:Other text for CTRL-V in Insert mode with modifyOtherKeys.
> > > Solution: Convert the Escape sequence back to key as if
> modifyOtherKeys
> > > is
> > > not set, and use CTRL-SHIFT-V to get the Escape sequence
> > > itself.
> > > (closes #5254)
> > > Files:runtime/doc/insert.txt, runtime/doc/cmdline.txt,
> > > src/edit.c,
> > > src/proto/edit.pro, src/term.c, src/proto/term.pro,
> > > src/getchar.c,
> > > src/proto/getchar.pro, src/testdir/test_termcodes.vim,
> > > src/ex_getln.c
> > >
> >
> > This patch works nicely. However, I have a question.
> > It seems that mappings are applied to the Esc sequence inserted by
> > CTRL-SHIFT-V.
> >
> > E.g. consider the following mapping which automatically insert a closing
> > bracket
> > when an opening bracket is typed:
> >
> > :inoremap [ []
> >
> > Then type CTRL-SHIFT-V CTRL-V in insert mode.
> > "^[[118;5u]" is inserted instead of "^[[118;5u". ("]" is automatically
> > added.)
> >
> > Is this intentional? Isn't it better not to apply mappings to
> CTRL-SHIFT-V?
>
> I believe this hasn't changed: The CTRL-V only takes the next character
> literally, not any following ones. Thus only the Esc is used as-is, the
> rest is consumed as normal characters. Same happens with a function key
> starting with Esc-[.
>
> Do you think this changed?
I don't know whether this is changed or not, just noticed this behavior by
testing this patch.
> The CTRL-V only takes the next character literally, not any following
ones.
Ah, I got it. That explains the current behavior.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/a757a119-313b-42f5-bd9b-0234d83395df%40googlegroups.com.
Re: Patch 8.1.2344
Hi, 2019/11/28 Thu 6:51:22 UTC+9 Christian Brabandt wrote: > > > On Mi, 27 Nov 2019, Bram Moolenaar wrote: > > > What was the error on FreeBSD? I thought it also suppored Posix. > > https://cirrus-ci.com/task/5566942320001024 > > In file included from os_unix.c:87: > /usr/include/sys/consio.h:262:2: error: unknown type name 'u_short'; did > you mean 'short'? > u_short font_size; > ^ > /usr/include/sys/consio.h:263:2: error: unknown type name 'u_short'; did > you mean 'short'? > u_short mv_row, mv_col; > ^ > /usr/include/sys/consio.h:264:2: error: unknown type name 'u_short'; did > you mean 'short'? > u_short mv_rsz, mv_csz; > ^ > /usr/include/sys/consio.h:265:2: error: unknown type name 'u_short'; did > you mean 'short'? > u_short mv_hsz; > ^ > /usr/include/sys/consio.h:269:2: error: unknown type name 'u_char'; did > you mean 'char'? > u_char mv_ovscan; > ^ > /usr/include/sys/consio.h:270:2: error: unknown type name 'u_char'; did > you mean 'char'? > u_char mk_keylock; > ^ > /usr/include/sys/consio.h:319:2: error: unknown type name 'u_char'; did > you mean 'char'? > u_char ti_name[TI_NAME_LEN]; > ^ > /usr/include/sys/consio.h:320:2: error: unknown type name 'u_char'; did > you mean 'char'? > u_char ti_desc[TI_DESC_LEN]; > ^ > In file included from os_unix.c:88: > /usr/include/sys/fbio.h:196:2: error: unknown type name 'u_char'; did you > mean 'char'? > u_char *red; /* red color map elements */ > ^ > /usr/include/sys/fbio.h:197:2: error: unknown type name 'u_char'; did you > mean 'char'? > u_char *green; /* green color map elements */ > ^ > /usr/include/sys/fbio.h:198:2: error: unknown type name 'u_char'; did you > mean 'char'? > u_char *blue; /* blue color map elements */ > ^ > /usr/include/sys/fbio.h:282:2: error: unknown type name 'u_short'; did you > mean 'short'? > u_short accessible_width; /* accessible bytes in scanline > */ > ^ > /usr/include/sys/fbio.h:283:2: error: unknown type name 'u_short'; did you > mean 'short'? > u_short accessible_height; /* number of accessible > scanlines */ > ^ > /usr/include/sys/fbio.h:284:2: error: unknown type name 'u_short'; did you > mean 'short'? > u_short line_bytes; /* number of bytes/scanline */ > ^ > /usr/include/sys/fbio.h:285:2: error: unknown type name 'u_short'; did you > mean 'short'? > u_short hdb_capable;/* can this thing hardware db? */ > ^ > /usr/include/sys/fbio.h:286:2: error: unknown type name 'u_short'; did you > mean 'short'? > u_short vmsize; /* video memory size */ > ^ > /usr/include/sys/fbio.h:287:2: error: unknown type name 'u_char'; did you > mean 'char'? > u_char boardrev; /* board revision # */ > ^ > /usr/include/sys/fbio.h:288:2: error: unknown type name 'u_char'; did you > mean 'char'? > u_char pad0; > ^ > /usr/include/sys/fbio.h:289:2: error: unknown type name 'u_long'; did you > mean 'long'? > u_long pad1; > ^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > 20 errors generated. > gmake[2]: *** [Makefile:3338: objects/os_unix.o] Error 1 > gmake[2]: Leaving directory '/tmp/cirrus-ci-build/src' > gmake[1]: *** [Makefile:2030: reconfig] Error 2 > gmake[1]: Leaving directory '/tmp/cirrus-ci-build/src' > gmake: *** [Makefile:29: first] Error 2 > Exit status: 2 > > > > I think being specific is OK, thus checking for __FreeBSD__ would be OK. > > Otherwise we would need a configure check of some kind. > > > If we use __FreeBSD__, maybe we also need to add checks for other BSDs. It seems that "BSD" is defined in sys/param.h, so how about this patch? --- a/src/vim.h +++ b/src/vim.h @@ -36,7 +36,10 @@ Error: configure did not run properly. Check auto/config.log. # endif -# if defined(UNIX) && !defined(MACOS_X) +# ifdef HAVE_SYS_PARAM_H +# include +# endif +# if defined(UNIX) && !defined(MACOS_X) && !defined(BSD) // Needed for strptime(). Needs to be done early, since header files can // include other header files and end up including time.h, where these symbols // matter for Vim. Regards, Ken Takata -- -- You received this message from the "vim_dev" maillist. Do not top
Re: Patch 8.1.2344
Hi, 2019/11/28 Thu 5:05:12 UTC+9 Christian Brabandt wrote: > > > On Di, 26 Nov 2019, Bram Moolenaar wrote: > > > Patch 8.1.2344 > > Problem:Cygwin: warning for using strptime(). > > Solution: Move defining _XOPEN_SOURCE and __USE_XOPEN to vim.h. (Ken > Takata, > > closes #5265) Use 700 for _XOPEN_SOURCE for mkdtemp(). > > Files:src/os_unix.h, src/vim.h > > This still breaks on BSD like systems. > > How about the following patch on top of it? > > diff --git a/src/vim.h b/src/vim.h > index 9b49ba1a9..c0053ce14 100644 > --- a/src/vim.h > +++ b/src/vim.h > @@ -36,8 +36,8 @@ > Error: configure did not run properly. Check auto/config.log. > # endif > > -# if defined(UNIX) && !defined(MACOS_X) > -// Needed for strptime(). Needs to be done early, since header files can > +# if defined(UNIX) && !defined(MACOS_X) && !defined(__unix__) > +// Needed for strptime() on Cygwin. Needs to be done early, since header > files can > // include other header files and end up including time.h, where these > symbols > // matter for Vim. > // 700 is needed for mkdtemp(). > __unix__ is also defined on Cygwin. So, the warning will occur again. The original issue looks Cygwin specific, so using __CYGWIN__ might be better: #ifdef __CYGWIN__ // Needed for strptime() on Cygwin. Needs to be done early, since header files can ... Then os_unix.h needs to be reverted before 8.1.2344? Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/18b944ec-5c5c-4bd2-bfed-597b9f393850%40googlegroups.com.
Re: Patch 8.1.2350
Hi Bram,
2019/11/27 Wed 3:34:01 UTC+9 Bram Moolenaar wrote:
>
>
> Patch 8.1.2350
> Problem:Other text for CTRL-V in Insert mode with modifyOtherKeys.
> Solution: Convert the Escape sequence back to key as if modifyOtherKeys
> is
> not set, and use CTRL-SHIFT-V to get the Escape sequence
> itself.
> (closes #5254)
> Files:runtime/doc/insert.txt, runtime/doc/cmdline.txt,
> src/edit.c,
> src/proto/edit.pro, src/term.c, src/proto/term.pro,
> src/getchar.c,
> src/proto/getchar.pro, src/testdir/test_termcodes.vim,
> src/ex_getln.c
>
This patch works nicely. However, I have a question.
It seems that mappings are applied to the Esc sequence inserted by
CTRL-SHIFT-V.
E.g. consider the following mapping which automatically insert a closing
bracket
when an opening bracket is typed:
:inoremap [ []
Then type CTRL-SHIFT-V CTRL-V in insert mode.
"^[[118;5u]" is inserted instead of "^[[118;5u". ("]" is automatically
added.)
Is this intentional? Isn't it better not to apply mappings to CTRL-SHIFT-V?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/e868ceeb-ec79-4764-80ab-a2efe5baad28%40googlegroups.com.
Re: Patch 8.1.2320
Hi, 2019/11/19 Tue 18:04:35 UTC+9 Elimar Riesebieter wrote: > > * Elimar Riesebieter > [2019-11-19 09:44 > +0100]: > > > * Bram Moolenaar > [2019-11-18 22:02 > +0100]: > > > > > > > > Patch 8.1.2320 > > > Problem:Insufficient test coverage for quickfix. > > > Solution: Add more tests. Fix uncovered problem. (Yegappan > Lakshmanan, > > > closes #5238) > > > Files:src/quickfix.c, src/testdir/test_quickfix.vim > > > > Building on amd64 I get: > > > > Failures: > > From test_quickfix.vim: > > Found errors in Test_helpgrep(): > > function RunTheTest[40]..Test_helpgrep[1]..5_test_xhelpgrep > line 42: Expected ['col', [['leaf', 1067], ['row', [['leaf', 1066], > ['leaf', 1065] but got ['row', [['col', [['leaf', 1067], ['leaf > > ', 1066]]], ['leaf', 1065]]] > > function RunTheTest[40]..Test_helpgrep[3]..5_test_xhelpgrep > line 42: Expected ['col', [['leaf', 1075], ['row', [['leaf', 1074], > ['leaf', 1073] but got ['row', [['col', [['leaf', 1075], ['leaf > > ', 1074]]], ['leaf', 1073]] > > This is on i386 and powerps as well. > > Looks like the same with https://github.com/vim/vim/pull/5244. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/8a812f84-b45d-485e-8183-5cc6b0041344%40googlegroups.com.
Re: gVim for Windows - Patch to fill empty space around text area
Hi Bram,
2019/11/15 Fri 6:36:36 UTC+9 Bram Moolenaar wrote:
>
>
> Simon wrote:
>
> > Attached is a patch to solve a long-standing issue in gVim when
> > using dark backgrounds. e.g.
> >
> > https://github.com/vim/vim/issues/349
> > https://www.reddit.com/r/vim/search/?q=gvim%20borders_sr=1
> >
> > * This mini patch automatically changes the main window to the
> > background colour thus eliminating white-space to the right and bottom
> > edge - it looks great
> >
> > * I have utilised the static s_brush so it will always contain the
> > main window background brush just as before
> >
> > * The previous brush is deleted after being replaced by the new one
> >
> > * I have checked for memory leaks
> >
> >
> > Thanks for everything. :)
>
> The other use of SetClassLongPtr() is inside an #ifdef.
> I suppose for older compilers.
> How about this:
>
> gui_mch_new_colors(void)
> {
> HBRUSH prevBrush;
>
> s_brush = CreateSolidBrush(gui.back_pixel);
> #ifdef SetClassLongPtr
> prevBrush = (HBRUSH)SetClassLongPtr(
> s_hwnd, GCLP_HBRBACKGROUND,
> (LONG_PTR)s_brush);
> #else
> prevBrush = (HBRUSH)SetClassLong(
>s_hwnd, GCL_HBRBACKGROUND,
> (long_u)s_brush);
> #endif
> InvalidateRect(s_hwnd, NULL, TRUE);
> DeleteObject(prevBrush);
> }
>
I don't remember when SetClassLongPtr() was added. At least, VC 2008 has
it, and VC 6 doesn't have it.
We already dropped support for Windows 9x, so I don't think we need to keep
support old compilers
which support Win9x. I think we can drop support for VC 2005 or older.
How about always using SetClassLongPtr()?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/9b6f1167-2864-42ae-b5f1-69d3ec140c8b%40googlegroups.com.
Update Japanese messages
Hi Bram and the list, I'd like to update Japanese translations. Could you merge the contents from the attached file into Vim? The same file is also available at the vim-jp/lang-ja repository: https://github.com/vim-jp/lang-ja/releases/tag/2019 Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cb9b4285-fba5-4fea-b8e0-2465b07f5783%40googlegroups.com. vim-lang-ja-po-2019.tar.xz Description: Binary data
Re: Patch 8.1.2242
Hi, 2019/11/4 Mon 20:37:24 UTC+9 James McCoy wrote: > > On Mon, Nov 4, 2019, 05:28 Bram Moolenaar > wrote: > >> >> > On Sun, Nov 03, 2019 at 09:20:20PM +0100, Bram Moolenaar wrote: >> > > >> > > Christian wrote: >> > > >> > > > On So, 03 Nov 2019, Bram Moolenaar wrote: >> > > > >> > > > > Right, "make vimtags" doesn't work. I'm not sure how widespread >> "type" >> > > > > is, I think "which" should be safer. >> > > > >> > > > type or command -v is the command one should use nowadays. For a >> really >> > > > deep dive into what to use, I suggest this great article: >> > > > >> > > > https://unix.stackexchange.com/a/85250/303213 >> > > >> > > Hmm, not that great. It doesn't list what command is available in >> which >> > > version of a shell. It does mention that "which" is widely available, >> > > while "type" is not. >> > >> > FWIW, "command -v ..." is specified in POSIX. "type" is as well, but as >> > an XSI extension. >> >> In tcsh: >> >> $ command -v vim >> command: Command not found. >> >> Perfect error message :-). >> > > Tcsh isn't /bin/sh, so I'm not sure why that's relevant. This is in the > context of a Makefile, which uses /bin/sh. > >> We already use "command -v" in src/po/Makefile. I think it can be also safely used in runtime/doc/Makefile. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/950f3960-a640-4229-ba0d-3c08fa3b9e1b%40googlegroups.com.
Re: Patch 8.1.2242
Hi, 2019/11/4 Mon 1:47:22 UTC+9 Tony Mechelynck wrote: > > On Sun, Nov 3, 2019 at 5:42 PM Ken Takata > wrote: > > > > Hi, > > > > 2019/11/4 Mon 0:50:37 UTC+9 Tony Mechelynck wrote: > >> > >> After recompiling just 8.1.2245 there were no changes to the docs, so > >> when running "make install" after that, runtime/doc/Makefile target > >> "vimtags" did nothing; yet at that point (runtime/doc/Makefile line > >> 325 or src/Makefile line 2373) 25 or so empty lines were written on > >> the console. I'm baffled. (I'm compiling in a konsole 18.12.3 terminal > >> maximized to 244 columns by 73 lines.) > >> > >> I checked that the --clean argument is still found at that point in > >> the src/Makefile; but in this case Vim seems not to have been invoked > >> anyway. > >> > >> Best regards, > >> Tony. > >> > >> P.S. Here's the relevant part of the console output: > >> > >> generating help tags > >> make[1]: Entering directory '/root/.build/vim/vim-hg/runtime/doc' > >> > > ... > >> > >> > >> make[1]: Leaving directory '/root/.build/vim/vim-hg/runtime/doc' > > > > > > How about just redirecting stdout to null? > > IIRC, the whole idea of _not_ redirecting stdout to /dev/null was in > order to get a message if there were duplicate helptags (as there was > for *gm* at motion.txt line 230 until the latest runtime files > update). > > The error message for duplicate tags goes to stderr, so it will be shown on the terminal. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/49bbdefe-b83b-43ce-b4c3-ba53e6b308c6%40googlegroups.com.
Re: Patch 8.1.2242
Hi, 2019/11/4 Mon 0:50:37 UTC+9 Tony Mechelynck wrote: > > After recompiling just 8.1.2245 there were no changes to the docs, so > when running "make install" after that, runtime/doc/Makefile target > "vimtags" did nothing; yet at that point (runtime/doc/Makefile line > 325 or src/Makefile line 2373) 25 or so empty lines were written on > the console. I'm baffled. (I'm compiling in a konsole 18.12.3 terminal > maximized to 244 columns by 73 lines.) > > I checked that the --clean argument is still found at that point in > the src/Makefile; but in this case Vim seems not to have been invoked > anyway. > > Best regards, > Tony. > > P.S. Here's the relevant part of the console output: > > generating help tags > make[1]: Entering directory '/root/.build/vim/vim-hg/runtime/doc' > > ... > > make[1]: Leaving directory '/root/.build/vim/vim-hg/runtime/doc' > How about just redirecting stdout to null? --- a/runtime/doc/Makefile +++ b/runtime/doc/Makefile @@ -323,7 +323,7 @@ all: tags vim.man evim.man vimdiff.man v # Use Vim to generate the tags file. Can only be used when Vim has been # compiled and installed. Supports multiple languages. vimtags: $(DOCS) -@if test -x $(VIMEXE); then $(VIMEXE) --clean -eX -u doctags.vim; \ +@if test -x $(VIMEXE); then $(VIMEXE) -eX -u doctags.vim > /dev/null; \ else echo "vim executable $(VIMEXE) not found"; fi # Use "doctags" to generate the tags file. Only works for English! I'm not sure whether --clean is really needed. I'm also wandering `type $(VIMEXE) > /dev/null` might be better than `test -x $(VIMEXE)`. `test -x` doesn't allow to use vim in $PATH. --- a/runtime/doc/Makefile +++ b/runtime/doc/Makefile @@ -323,7 +323,7 @@ all: tags vim.man evim.man vimdiff.man v # Use Vim to generate the tags file. Can only be used when Vim has been # compiled and installed. Supports multiple languages. vimtags: $(DOCS) -@if test -x $(VIMEXE); then $(VIMEXE) --clean -eX -u doctags.vim; \ +@if type $(VIMEXE) > /dev/null; then $(VIMEXE) -eX -u doctags.vim > /dev/null; \ else echo "vim executable $(VIMEXE) not found"; fi # Use "doctags" to generate the tags file. Only works for English! Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/af7b8d97-f906-46b5-adc0-6f03c799ac9b%40googlegroups.com.
Re: Patch 8.1.2128
Hi Bram, 2019/10/10 Thu 20:23:32 UTC+9 Bram Moolenaar wrote: > > > Patch 8.1.2128 > Problem:Renamed libvterm sources makes merging difficult. > Solution: Rename back to the original name and only rename the .o files. > Also clean the libvterm build artifacts. (James McCoy, > closes #5027) > Files:src/libvterm/src/termmouse.c, src/libvterm/src/mouse.c, > src/libvterm/src/termscreen.c, src/libvterm/src/screen.c, > src/Makefile, src/configure.ac, src/auto/configure, > src/Make_cyg_ming.mak, src/Make_mvc.mak > This fails to compile with MSVC. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/d30aabeb-9e86-4f38-8e3a-f510ad61d920%40googlegroups.com. # HG changeset patch # Parent dd7838fd19933550764e651f4598e447ab77f9b5 diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak --- a/src/Make_mvc.mak +++ b/src/Make_mvc.mak @@ -1741,31 +1741,31 @@ CCCTERM = $(CC) $(CFLAGS) -Ilibvterm/inc -D_CRT_SECURE_NO_WARNINGS $(OUTDIR)/vterm_encoding.obj: $(OUTDIR) libvterm/src/encoding.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/encoding.c $(OUTDIR)/vterm_keyboard.obj: $(OUTDIR) libvterm/src/keyboard.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/keyboard.c $(OUTDIR)/vterm_mouse.obj: $(OUTDIR) libvterm/src/mouse.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/mouse.c $(OUTDIR)/vterm_parser.obj: $(OUTDIR) libvterm/src/parser.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/parser.c $(OUTDIR)/vterm_pen.obj: $(OUTDIR) libvterm/src/pen.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/pen.c $(OUTDIR)/vterm_screen.obj: $(OUTDIR) libvterm/src/screen.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/screen.c $(OUTDIR)/vterm_state.obj: $(OUTDIR) libvterm/src/state.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/state.c $(OUTDIR)/vterm_unicode.obj: $(OUTDIR) libvterm/src/unicode.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/unicode.c $(OUTDIR)/vterm_vterm.obj: $(OUTDIR) libvterm/src/vterm.c $(TERM_DEPS) - $(CCCTERM) /Fo$@ $< + $(CCCTERM) /Fo$@ libvterm/src/vterm.c # $CFLAGS may contain backslashes and double quotes, escape them both.
Re: Vim.8.1.2102 - 32 bits on windows SegFault
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 detail information on gdb, try adding the -g option
to CFLAGS by editing Make_cyg_ming.mak.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/6fde93c7-b20c-4181-a837-89d66d3721a3%40googlegroups.com.
Re: Patch 8.1.2082
Hi Bram,
2019/9/27 Fri 20:09:37 UTC+9 Bram Moolenaar wrote:
>
>
> Patch 8.1.2082
> Problem:Some files have a weird name to fit in 8.3 characters.
> Solution: Use a nicer names.
> Files:Filelist, Makefile, src/popupmnu.c, src/popupmenu.c,
> src/proto/popupmnu.pro, src/proto/popupmenu.pro,
> src/Make_cyg_ming.mak, src/Make_morph.mak, src/Make_mvc.mak,
> src/Make_vms.mms, src/Makefile, src/proto.h, src/README.md,
> src/uninstal.c, src/uninstall.c, uninstal.txt, uninstall.txt,
> nsis/gvim.nsi, src/INSTALLpc.txt, src/dosinst.c, src/dosinst.h
>
>
It looks that your change is not enough. Please check the attached patch.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/a303d4da-77cc-4ed3-9d72-584a36735166%40googlegroups.com.
# HG changeset patch
# Parent 427fa39e0797cb63d0af15739fc79ff2d8f393b4
diff --git a/nsis/README.txt b/nsis/README.txt
--- a/nsis/README.txt
+++ b/nsis/README.txt
@@ -14,7 +14,7 @@ 2. Go to the src directory and build:
gvim.exe (the OLE version),
vimrun.exe,
install.exe,
- uninstal.exe,
+ uninstall.exe,
tee/tee.exe,
xxd/xxd.exe,
diff --git a/runtime/doc/gui_w32.txt b/runtime/doc/gui_w32.txt
--- a/runtime/doc/gui_w32.txt
+++ b/runtime/doc/gui_w32.txt
@@ -171,14 +171,14 @@ 2. Add these keys:
path {path}\gvim.exe
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\vim 5.6
DisplayName Vim 5.6: Edit with Vim popup menu entry
- UninstallString {path}\uninstal.exe
+ UninstallString {path}\uninstall.exe
Replace {path} with the path that leads to the executable.
Don't type {default}, this is the value for the key itself.
To remove "Edit with Vim" from the popup menu, just remove the registry
-entries mentioned above. The "uninstal.exe" program can do this for you. You
-can also use the entry in the Windows standard "Add/Remove Programs" list.
+entries mentioned above. The "uninstall.exe" program can do this for you.
+You can also use the entry in the Windows standard "Add/Remove Programs" list.
If you notice that this entry overrules other file type associations, set
those associations again by hand (using Windows Explorer, see above). This
diff --git a/runtime/doc/usr_90.txt b/runtime/doc/usr_90.txt
--- a/runtime/doc/usr_90.txt
+++ b/runtime/doc/usr_90.txt
@@ -480,9 +480,9 @@ probably contains your vimrc file and ot
be careful.
Else, if you installed Vim with the zip archives, the preferred way is to use
-the "uninstal" program (note the missing l at the end). You can find it in
-the same directory as the "install" program, e.g., "c:\vim\vim61". This
-should also work from the usual "install/remove software" page.
+the "uninstall" program. You can find it in the same directory as the
+"install" program, e.g., "c:\vim\vim61". This should also work from the usual
+"install/remove software" page.
However, this only removes the registry entries for Vim. You have to
delete the files yourself. Simply select the directory "vim\vim61" and delete
it recursively. There should be no files there that you changed, but you
diff --git a/src/GvimExt/GvimExt.reg b/src/GvimExt/GvimExt.reg
--- a/src/GvimExt/GvimExt.reg
+++ b/src/GvimExt/GvimExt.reg
@@ -17,4 +17,4 @@ REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\Vim 8.1]
"DisplayName"="Vim 8.1: Edit with Vim popup menu entry"
- "UninstallString"="uninstal.exe"
+ "UninstallString"="uninstall.exe"
diff --git a/src/GvimExt/README.txt b/src/GvimExt/README.txt
--- a/src/GvimExt/README.txt
+++ b/src/GvimExt/README.txt
@@ -11,7 +11,7 @@ registry entries.
In special situations you might want to make changes by hand. Check these
items:
-- The gvimext.dll, gvim.exe and uninstal.exe either need to be in the search
+- The gvimext.dll, gvim.exe and uninstall.exe either need to be in the search
path, or you have to set the full path in the registry entries. You could
move the gvimext.dll to the "windows\system" or "windows\system32"
directory, where the other DLL files are.
diff --git a/src/proto/popupmenu.pro b/src/proto/popupmenu.pro
--- a/src/proto/popupmenu.pro
+++ b/src/proto/popupmenu.pro
@@ -1
[patch] Fix wrong usage of rtp in menu.vim
Hi, I think 'packpath' should be used instead of 'rtp' for searching colorschemes in menu.vim. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/70519127-891b-43f4-b609-4bcb45e8598f%40googlegroups.com. # HG changeset patch # Parent c17eeafdd83471a8f1bb0344cab75c8253c9655b diff --git a/runtime/menu.vim b/runtime/menu.vim --- a/runtime/menu.vim +++ b/runtime/menu.vim @@ -359,8 +359,8 @@ func! s:SetupColorSchemes() abort let s:did_setup_color_schemes = 1 let n = globpath(, "colors/*.vim", 1, 1) - let n += globpath(, "pack/*/start/*/colors/*.vim", 1, 1) - let n += globpath(, "pack/*/opt/*/colors/*.vim", 1, 1) + let n += globpath(, "pack/*/start/*/colors/*.vim", 1, 1) + let n += globpath(, "pack/*/opt/*/colors/*.vim", 1, 1) " Ignore case for VMS and windows, sort on name let names = sort(map(n, 'substitute(v:val, "\\c.*[/:\\]]\\([^/:]*\\)\\.vim", "\\1", "")'), 1)
Re: History missing
Hi, 2019/7/22 Mon 23:21:52 UTC+9 Paul wrote: > I suppose it was something in the recent viminfo changes (commits 1727-1728) > that has made my commandline and search history inaccessible, ie. empty `q:` > and `q/` lists. I note that the history is still there in the viminfo file. > Reverting to an earlier version (in my case, 1694), resolves the issue and I > can access those histories via the respective commands once more. I confirmed that 8.1.1727 doesn't have the problem. It seems that 8.1.1728 is the offending commit. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/587f9583-f64e-4da7-9797-aa228fda712e%40googlegroups.com.
Re: Patch 8.1.1705
Hi,
2019/7/17 Wed 5:04:31 UTC+9 Bram Moolenaar wrote:
> Patch 8.1.1705
> Problem:Using ~{} for a literal dict is not nice.
> Solution: Use #{} instead.
> Files:runtime/doc/eval.txt runtime/doc/popup.txt, src/eval.c,
> src/testdir/test_listdict.vim src/testdir/test_popupwin.vim
Thank you for adopting my idea.
BTW, the following changes are also needed.
--- a/src/dict.c
+++ b/src/dict.c
@@ -709,7 +709,7 @@ dict2string(typval_T *tv, int copyID, in
}
/*
- * Get the key for *{key: val} into "tv" and advance "arg".
+ * Get the key for #{key: val} into "tv" and advance "arg".
* Return FAIL when there is no valid key.
*/
static int
@@ -731,7 +731,7 @@ get_literal_key(char_u **arg, typval_T *
/*
* Allocate a variable for a Dictionary and fill it from "*arg".
- * "literal" is TRUE for *{key: val}
+ * "literal" is TRUE for #{key: val}
* Return OK or FAIL. Returns NOTDONE for {expr}.
*/
int
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/98107b45-a15c-4c1b-82cb-571ee5f253f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1698
Hi, 2019/7/16 Tue 16:26:55 UTC+9 Ken Takata wrote: > Hi, > > 2019/7/16 Tue 15:27:48 UTC+9 Christian Brabandt wrote: > > On Mo, 15 Jul 2019, Bram Moolenaar wrote: > > > > > > > > I wrote: > > > > > > > Patch 8.1.1698 > > > > Problem:Appveyor build with MSVC fails. > > > > Solution: Remove the sed command > > > > Files: ci/appveyor.bat > > > > > > This solved the problem, but now we have the ugly progress bar output > > > back. Can this be disabled somehow? > > > > Pipe the linker output to the sed command, something like this: > > > > sed -e '/^< Make_mvc2.mak > > I suggest the following instead: > > sed -e "s/@<<$/@<< | sed -e 's#.*r.*##'/" Make_mvc.mak > Make_mvc2.mak > > The sed workaround should be added just after "link @<<". > > > > However Ken just mentioned, that the sed workaround isn't needed > > anymore, so I am confused whether this is still a problem? > > > > https://github.com/vim/vim-win32-installer/pull/139/commits/7212b47f60a58531b80b2edd6c146dc1f4b9bba7 > > The progress counter is not shown on the AppVeyor's Web interface, but it > remains in the log file downloaded from AppVeyor. I created a PR for this to see if this actually works: https://github.com/vim/vim/pull/4684 Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/f1bbde50-5ad5-4072-befd-3c1e9ad83bd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1698
Hi, 2019/7/16 Tue 15:27:48 UTC+9 Christian Brabandt wrote: > On Mo, 15 Jul 2019, Bram Moolenaar wrote: > > > > > I wrote: > > > > > Patch 8.1.1698 > > > Problem:Appveyor build with MSVC fails. > > > Solution: Remove the sed command > > > Files:ci/appveyor.bat > > > > This solved the problem, but now we have the ugly progress bar output > > back. Can this be disabled somehow? > > Pipe the linker output to the sed command, something like this: > > sed -e '/^< Make_mvc2.mak I suggest the following instead: sed -e "s/@<<$/@<< | sed -e 's#.*r.*##'/" Make_mvc.mak > Make_mvc2.mak The sed workaround should be added just after "link @<<". > However Ken just mentioned, that the sed workaround isn't needed > anymore, so I am confused whether this is still a problem? > > https://github.com/vim/vim-win32-installer/pull/139/commits/7212b47f60a58531b80b2edd6c146dc1f4b9bba7 The progress counter is not shown on the AppVeyor's Web interface, but it remains in the log file downloaded from AppVeyor. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cd3c87ca-1dc1-4aa3-bbdf-f46a3a4cdb47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1692
Hi,
2019/7/15 Mon 1:23:21 UTC+9 Bram Moolenaar wrote:
> Patch 8.1.1692
> Problem:Using *{} for literal dict is not backwards compatible. (Yasuhiro
> Matsumoto)
> Solution: Use ~{} instead.
> Files:runtime/doc/eval.txt runtime/doc/popup.txt, src/eval.c,
> src/testdir/test_listdict.vim src/testdir/test_popupwin.vim,
> src/testdir/dumps/Test_popupwin_07.dump,
> src/testdir/dumps/Test_popupwin_mask_2.dump,
> src/testdir/dumps/Test_popupwin_mask_3.dump,
> src/testdir/dumps/Test_popupwin_mask_4.dump,
> src/testdir/dumps/Test_popupwin_mask_5.dump,
> src/testdir/dumps/Test_popupwin_scroll_2.dump,
> src/testdir/dumps/Test_popupwin_scroll_3.dump,
> src/testdir/dumps/Test_popupwin_scroll_4.dump
I personally prefer #{} than ~{}.
'~' is used as a bitwise not operator in C. So, when I see ~{}, I would doubt
if it is a bitwise not of {}. (Vim script doesn't have a ~ operator, though.)
Dictionary is called as hash in some other languages, and # is also called
hash. So, #{} might be easy to remember. And I don't think that #{} have a
compatibility problem.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/206adb15-dd61-46b2-86f2-e996f390be77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1684
Hi Christian, 2019/7/15 Mon 22:21:36 UTC+9 Christian Brabandt wrote: > On Mo, 15 Jul 2019, Bram Moolenaar wrote: > > > > > Christian wrote: > > > > > On Mo, 15 Jul 2019, Bram Moolenaar wrote: > > > > > > > You quoted the end of the error message, do you have the whole line? > > > > > > Here we go: > > > > > > link /nologo /opt:ref /LTCG:STATUS /HIGHENTROPYVA:NO > > > /subsystem:windows,5.02 -out:gvim.exe .\ObjGXOULYHTRZAMD64\arabic.obj > > > .\ObjGX ... ib xpm\x64\lib-vc14\libXpm.lib /PDB:gvim.pdb -debug | sed -e > > > 's#.*\r.*##' > > > > > > NMAKE : fatal error U1095: expanded command line 'link /nologo /opt:ref > > > /LTCG:STATUS /HIGHENTROPYVA:NO /subsystem:windows,5.02 -out:gvim.exe > > > .\ObjGXOULYHTRZAMD64\arabic.obj .\ObjGXO ... b-vc14\libXpm.lib > > > /PDB:gvim.pdb -debug | sed -e 's#.*\r.*##'' too long > > > Stop. > > > Command exited with code 1 > > > > > > > > It looks like a command line length limit applies somewhere. Not sure > > > > > how this can be fixed. > > > > > > > > Perhaps the tool can read the list of files from somewhere? > > > > > > Apparently that might be possible: > > > https://stackoverflow.com/a/9344985/789222 > > > > Can someone make a patch for that? > > I don't have a nmake environment to test, but I suppose the following > should work according to the sparse documentation I found online. I am > not entirely sure, if the trailing backslashes should be kept or not, > but I thought they might not be necessary... > > Can someone test it? > > diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak > index 8901a7c31..89d5515ae 100644 > --- a/src/Make_mvc.mak > +++ b/src/Make_mvc.mak > @@ -1271,15 +1271,19 @@ all:$(MAIN_TARGET) \ > > !if "$(VIMDLL)" == "yes" > > +# Makes use of nmakes response files to capture the arguments in a file and > read it back using the @< +# > $(VIMDLLBASE).dll: $(OUTDIR) $(OBJ) $(XDIFF_OBJ) $(GUI_OBJ) $(CUI_OBJ) > $(OLE_OBJ) $(OLE_IDL) $(MZSCHEME_OBJ) \ > $(LUA_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(PYTHON3_OBJ) > $(RUBY_OBJ) $(TCL_OBJ) \ > $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) $(NETBEANS_OBJ) > $(CHANNEL_OBJ) $(XPM_OBJ) \ > version.c version.h > $(CC) $(CFLAGS_OUTDIR) version.c > - $(link) $(LINKARGS1) /dll -out:$(VIMDLLBASE).dll $(OBJ) $(XDIFF_OBJ) > $(GUI_OBJ) $(CUI_OBJ) $(OLE_OBJ) \ > - $(LUA_OBJ) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) > $(PYTHON3_OBJ) $(RUBY_OBJ) \ > - $(TCL_OBJ) $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) > $(NETBEANS_OBJ) $(CHANNEL_OBJ) \ > - $(XPM_OBJ) $(OUTDIR)\version.obj $(LINKARGS2) > + $(link) @<< > +$(LINKARGS1) /dll -out:$(VIMDLLBASE).dll $(OBJ) $(XDIFF_OBJ) $(GUI_OBJ) > $(CUI_OBJ) $(OLE_OBJ) > +$(LUA_OBJ) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(PYTHON3_OBJ) > $(RUBY_OBJ) > +$(TCL_OBJ) $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) $(NETBEANS_OBJ) > $(CHANNEL_OBJ) > +$(XPM_OBJ) $(OUTDIR)\version.obj $(LINKARGS2) > +<< > > $(GVIM).exe: $(OUTDIR) $(EXEOBJG) $(VIMDLLBASE).dll > $(link) $(LINKARGS1) /subsystem:$(SUBSYSTEM) -out:$(GVIM).exe > $(EXEOBJG) $(VIMDLLBASE).lib $(LIBC) > @@ -1296,10 +1300,12 @@ $(VIM).exe: $(OUTDIR) $(OBJ) $(XDIFF_OBJ) $(GUI_OBJ) > $(CUI_OBJ) $(OLE_OBJ) $(OLE > $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) $(NETBEANS_OBJ) > $(CHANNEL_OBJ) $(XPM_OBJ) \ > version.c version.h > $(CC) $(CFLAGS_OUTDIR) version.c > - $(link) $(LINKARGS1) /subsystem:$(SUBSYSTEM) -out:$(VIM).exe $(OBJ) > $(XDIFF_OBJ) $(GUI_OBJ) $(CUI_OBJ) $(OLE_OBJ) \ > - $(LUA_OBJ) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) > $(PYTHON3_OBJ) $(RUBY_OBJ) \ > - $(TCL_OBJ) $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) > $(NETBEANS_OBJ) $(CHANNEL_OBJ) \ > - $(XPM_OBJ) $(OUTDIR)\version.obj $(LINKARGS2) > + $(link) @<< > +$(LINKARGS1) /subsystem:$(SUBSYSTEM) -out:$(VIM).exe $(OBJ) $(XDIFF_OBJ) > $(GUI_OBJ) $(CUI_OBJ) $(OLE_OBJ) > +$(LUA_OBJ) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(PYTHON3_OBJ) > $(RUBY_OBJ) > +$(TCL_OBJ) $(CSCOPE_OBJ) $(TERM_OBJ) $(SOUND_OBJ) $(NETBEANS_OBJ) > $(CHANNEL_OBJ) > +$(XPM_OBJ) $(OUTDIR)\version.obj $(LINKARGS2) > +<< > if exist $(VIM).exe.manifest mt.exe -nologo -manifest > $(VIM).exe.manifest -updateresource:$(VIM).exe;1 > > !endif I confirmed that your patch worked fine. (I had to apply your patch manually, though.) Regards,
Re: Patch 8.1.1657
Hi Bram,
2019/7/10 Wed 6:22:41 UTC+9 Bram Moolenaar wrote:
> Patch 8.1.1657
> Problem:Terminal: screen updates from 'balloonexpr' are not displayed.
> Solution: Update the screen if needed. Fix the word position for
> "mousemoved".
> Files:src/beval.c, src/proto/beval.pro, src/popupwin.c,
> src/normal.c,
> src/proto/normal.pro
...
> *** 1437,1442
> --- 1437,1443
> {
> typval_T res;
>
> + ch_log(NULL, "closing popup %d", wp->w_id);
> res.v_type = VAR_NUMBER;
> res.vval.v_number = -2;
> // Careful: this makes "wp" invalid.
> *** ../vim-8.1.1656/src/normal.c 2019-07-07 18:27:52.365277132 +0200
> --- src/normal.c 2019-07-09 23:21:57.510482992 +0200
> ***
> *** 2325,2330
> --- 2325,2331
> ui_may_remove_balloon();
> if (p_bevalterm)
> {
> + ch_log(NULL, "setting balloon timer");
> profile_setlimit(p_bdlay, _due);
> bevalexpr_due_set = TRUE;
> }
> ***
Are these change intentional? Or just for debugging?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/6b5462db-31e3-413f-8a6e-e735b3ef28be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1595
Hi, 2019/6/26 Wed 7:34:39 UTC+9 Bram Moolenaar wrote: > Patch 8.1.1595 > Problem:MS-Windows with VIMDLL: colors wrong in console. > Solution: Do not set the GUI colors when not using the GUI. (Ken Takata, > closes #4588) > Files:src/syntax.c The commit message is not correct. It should be: > Problem:MS-Windows with VIMDLL: colors wrong in GUI. > Solution: Do not set the term GUI colors when using the GUI. (Ken Takata, Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/fcc423c4-be04-4dba-b2b0-321897640165%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[patch] Duplicated error number E996
Hi,
The patch 8.1.1574 added E996, however, it has been already used by the
:const patch. We should use a new number.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/975151d2-edf5-4db2-beeb-2cc8324af2a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 837bf0d725d53ec3a655ccf2e90af3f0aa414256
diff --git a/runtime/doc/popup.txt b/runtime/doc/popup.txt
--- a/runtime/doc/popup.txt
+++ b/runtime/doc/popup.txt
@@ -483,7 +483,7 @@ The second argument of |popup_create()|
tab page.
Otherwise the number of the tab page the popup is
displayed on; when invalid the popup is not created
- and an error is given. *E996*
+ and an error is given. *E997*
title Text to be displayed above the first item in the
popup, on top of any border. If there is no top
border one line of padding is added to put the title
diff --git a/src/popupwin.c b/src/popupwin.c
--- a/src/popupwin.c
+++ b/src/popupwin.c
@@ -892,7 +892,7 @@ popup_create(typval_T *argvars, typval_T
tp = find_tabpage(tabnr);
if (tp == NULL)
{
- semsg(_("E996: Tabpage not found: %d"), tabnr);
+ semsg(_("E997: Tabpage not found: %d"), tabnr);
return NULL;
}
}
Re: [patch] fix typo in documents
Hi, 2019/6/22 Sat 8:39:26 UTC+9 h_east wrote: > Hi Bram and developers, > > Attach a patch to fix the typo of the document. > Please confirm it. One more patch here. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/4057e92c-19f5-4f0a-9302-6cc49c83cafb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. diff --git a/runtime/doc/autocmd.txt b/runtime/doc/autocmd.txt --- a/runtime/doc/autocmd.txt +++ b/runtime/doc/autocmd.txt @@ -876,7 +876,7 @@ OptionSet After setting an option. Th || indicates what option has been set. |v:option_type| indicates whether it's global -or local scoped +or local scoped. |v:option_command| indicates what type of set/let command was used (follow the tag to see the table).
Re: Patch 8.1.1492
Hi,
2019/6/8 Sat 19:05:45 UTC+9 Bram Moolenaar wrote:
> Patch 8.1.1492
> Problem:MS-Windows: when "!" is in 'guioptions' ":!start" fails.
> Solution: Do not use a terminal window when the shell command begins with
> "!start". (Yasuhiro Matsumoto, closes #4504)
> Files:src/misc2.c, src/os_win32.c
> --- 3251,3261
> /* The external command may update a tags file, clear cached tags. */
> tag_freematch();
>
> ! if (cmd == NULL || *p_sxq == NUL
> ! #if defined(FEAT_GUI_MSWIN) && defined(FEAT_TERMINAL)
> ! || vim_strchr(p_go, GO_TERMINAL) != NULL
> ! #endif
> ! )
> retval = mch_call_shell(cmd, opt);
> else
> {
I think we need a check for gui.in_use for VIMDLL here:
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -3253,7 +3253,11 @@ call_shell(char_u *cmd, int opt)
if (cmd == NULL || *p_sxq == NUL
#if defined(FEAT_GUI_MSWIN) && defined(FEAT_TERMINAL)
- || vim_strchr(p_go, GO_TERMINAL) != NULL
+ || (
+# ifdef VIMDLL
+ gui.in_use &&
+# endif
+ vim_strchr(p_go, GO_TERMINAL) != NULL)
#endif
)
retval = mch_call_shell(cmd, opt);
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/9073f822-cba7-48e8-b96c-83159b4ac121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: build error since today (invalid UTF-8)
Hi, 2019/6/7 Fri 15:12:59 UTC+9 Christian Brabandt wrote: > On Do, 06 Jun 2019, Ken Takata wrote: > > > Or, should we also mark gettext v0.19 to v0.19.6 as broken? > > I believe, when I tried to git bisect the issue yesterday, the first bad > commit was around 0.19.3 > > But I don't think it matters much, Ubuntu 14.04 has version 0.18.3 and > is already end-of-life for standard support. That leaves us with Ubuntu > 16.04 which is at version 0.19.7 However the version might look like > this for non-tagged releases: 0.19.7- Even it is a non-tagged version, `msgfmt --version` on Ubuntu 16.04 returns 0.19.7. > So I would just check for 0.19.7 (without '$') So I think we can keep '$'. Checking 0.19.3 to 0.19.6 might be not so useful, but checking them doesn't have any penalty, I think. --- a/src/configure.ac +++ b/src/configure.ac @@ -4302,8 +4302,13 @@ if test "$enable_nls" = "yes"; then AC_MSG_CHECKING([if msgfmt supports --desktop]) MSGFMT_DESKTOP= if "$MSGFMT" --help | grep -e '--desktop' >/dev/null; then - AC_MSG_RESULT([yes]) - MSGFMT_DESKTOP="gvim.desktop vim.desktop" + if "$MSGFMT" --version | grep '0.19.[[3-7]]$' >/dev/null; then + dnl GNU gettext 0.19.7's --desktop is broken. + AC_MSG_RESULT([broken]) + else + AC_MSG_RESULT([yes]) + MSGFMT_DESKTOP="gvim.desktop vim.desktop" + fi else AC_MSG_RESULT([no]) fi Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/7055aa5c-b100-47e7-aa61-5e44898a6fbf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: build error since today (invalid UTF-8)
Hi, 2019/6/7 Fri 12:05:15 UTC+9 Ken Takata wrote: > Hi, > > 2019/6/7 Fri 5:51:02 UTC+9 Bram Moolenaar wrote: > > > I see someone else posted earlier about the same issue. > > > But those suggestions and also latest git rev do not resolve issue for me. > > > > The problem appears to be a broken version of msgfmt. > > We can't fix that in Vim. And it appears to be a real problem, thus > > ignoring it also doesn't appear to be a good idea. > > > > Is this a build error or an error for "make install"? > > This is an error for "make". > > How about checking the version of broken msgfmt? > It seems that v0.19.7 is broken. > > --- a/src/configure.ac > +++ b/src/configure.ac > @@ -4302,8 +4302,13 @@ if test "$enable_nls" = "yes"; then >AC_MSG_CHECKING([if msgfmt supports --desktop]) >MSGFMT_DESKTOP= >if "$MSGFMT" --help | grep -e '--desktop' >/dev/null; then > - AC_MSG_RESULT([yes]) > - MSGFMT_DESKTOP="gvim.desktop vim.desktop" > + if "$MSGFMT" --version | grep '0.19.7$' >/dev/null; then > + dnl GNU gettext 0.19.7's --desktop is broken. > + AC_MSG_RESULT([no]) > + else > + AC_MSG_RESULT([yes]) > + MSGFMT_DESKTOP="gvim.desktop vim.desktop" > + fi >else > AC_MSG_RESULT([no]) >fi Or, should we also mark gettext v0.19 to v0.19.6 as broken? If so: --- a/src/configure.ac +++ b/src/configure.ac @@ -4302,8 +4302,13 @@ if test "$enable_nls" = "yes"; then AC_MSG_CHECKING([if msgfmt supports --desktop]) MSGFMT_DESKTOP= if "$MSGFMT" --help | grep -e '--desktop' >/dev/null; then - AC_MSG_RESULT([yes]) - MSGFMT_DESKTOP="gvim.desktop vim.desktop" + if "$MSGFMT" --version | grep '0.19$\|0.19.[[1-7]]$' >/dev/null; then + dnl GNU gettext 0.19.7's --desktop is broken. + AC_MSG_RESULT([broken]) + else + AC_MSG_RESULT([yes]) + MSGFMT_DESKTOP="gvim.desktop vim.desktop" + fi else AC_MSG_RESULT([no]) fi Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2364c29e-58a9-4330-913f-1bd23e1a747f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: build error since today (invalid UTF-8)
Hi, 2019/6/7 Fri 5:51:02 UTC+9 Bram Moolenaar wrote: > > I see someone else posted earlier about the same issue. > > But those suggestions and also latest git rev do not resolve issue for me. > > The problem appears to be a broken version of msgfmt. > We can't fix that in Vim. And it appears to be a real problem, thus > ignoring it also doesn't appear to be a good idea. > > Is this a build error or an error for "make install"? This is an error for "make". How about checking the version of broken msgfmt? It seems that v0.19.7 is broken. --- a/src/configure.ac +++ b/src/configure.ac @@ -4302,8 +4302,13 @@ if test "$enable_nls" = "yes"; then AC_MSG_CHECKING([if msgfmt supports --desktop]) MSGFMT_DESKTOP= if "$MSGFMT" --help | grep -e '--desktop' >/dev/null; then - AC_MSG_RESULT([yes]) - MSGFMT_DESKTOP="gvim.desktop vim.desktop" + if "$MSGFMT" --version | grep '0.19.7$' >/dev/null; then + dnl GNU gettext 0.19.7's --desktop is broken. + AC_MSG_RESULT([no]) + else + AC_MSG_RESULT([yes]) + MSGFMT_DESKTOP="gvim.desktop vim.desktop" + fi else AC_MSG_RESULT([no]) fi Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ec7adb40-c0b6-438b-8564-8efb6c2735f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: resolve() on Windows breaking change
Hi,
2019/6/5 Wed 5:25:13 UTC+9 Mike Williams wrote:
> On 04/06/2019 19:18, Bram Moolenaar wrote:
> >
> > Mike Williams wrote:
> >
> >> It looks like the change to Windows for resolve() in 8.1.1417 was a
> >> breaking change. I use the NERDtree plugin and any build after than
> >> change results in NERDtree reports plain files on Windows as links. See
> >> attached image.
> >>
> >> I guess the question is. is this wrong in VIM or a bad assumption in
> >> NERDtree in what resolve() returns? Since it is a breaking change in
> >> VIM I thought I would start the ball rolling here.
> >
> > Perhaps NERDtree checks if the returned path is a full path?
> > Assuming you still have the older Vim version, compare the output of
> > resolve() for some simple files, is it different?
>
> It is different. 8.1.1416 does not return a full path for simple files
> while 8.1.1417 onwards does.
>
> > The docs say:
> > On MS-Windows, when {filename} is a shortcut (a .lnk file),
> > returns the path the shortcut points to in a simplified form.
> > When {filename} is a symbolic link or junction point, return
> > the full path to the target. If the target of junction is
> > removed, return {filename}.
> >
> > It says some more about a simplified result. But that wasn't changed.
>
> Based on the above it means that there is no way to tell the difference
> between a simple file and a symbolic link or junction point, getftype()
> does not help on Windows. But perhaps that does not matter.
>
> Spelunking in NERDtree the root cause of the problem is directory
> separators. It seems a bit free in always using '/' when building
> paths. Now that resolve() returns a full path filepath checks based on
> string comparison fails. A local hack^wfix confirms this but NERDtree
> is still able to detect symbolic links so there must some other method
> to distinguish that I am not aware of.
>
> I'll bounce over to GitHub to report this.
>
> TTFN
>
> Mike
I created a PR for this: https://github.com/vim/vim/pull/4492
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/c9a6fd8d-7dd5-491d-9cf9-a025b5b9ea11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[patch] Suppress GCC warning
Hi,
GCC 9.1 warns this:
In file included from textprop.c:30:
textprop.c: In function 'join_prop_lines':
vim.h:1688:37: warning: 'props' may be used uninitialized in this function
[-Wmaybe-uninitialized]
1688 | # define mch_memmove(to, from, len) memmove((char*)(to), (char*)(from),
(size_t)(len))
| ^~~
textprop.c:1221:13: note: 'props' was declared here
1221 | char_u *props;
| ^
The following patch seems to solve the warning:
--- a/src/textprop.c
+++ b/src/textprop.c
@@ -1240,9 +1240,12 @@ join_prop_lines(
if (line == NULL)
return;
mch_memmove(line, newp, len);
-l = oldproplen * sizeof(textprop_T);
-mch_memmove(line + len, props, l);
-len += l;
+if (oldproplen > 0)
+{
+ l = oldproplen * sizeof(textprop_T);
+ mch_memmove(line + len, props, l);
+ len += l;
+}
for (i = 0; i < count - 1; ++i)
if (prop_lines[i] != NULL)
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/3def014c-d055-45e2-9803-222a6a07fa73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[patch] Trivial fixes for popup
Hi,
Here are some fixes for comments and indents.
Please check.
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/87fd9403-dffe-4dcd-ade0-5f479587a6f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 1c753dc934df1562605ad7c095284ffd81166b29
diff --git a/src/popupwin.c b/src/popupwin.c
--- a/src/popupwin.c
+++ b/src/popupwin.c
@@ -186,7 +186,7 @@ apply_options(win_T *wp, buf_T *buf UNUS
wp->w_zindex = dict_get_number(dict, (char_u *)"zindex");
-#if defined(FEAT_TIMERS)
+# if defined(FEAT_TIMERS)
// Add timer to close the popup after some time.
nr = dict_get_number(dict, (char_u *)"time");
if (nr > 0)
@@ -204,7 +204,7 @@ apply_options(win_T *wp, buf_T *buf UNUS
clear_tv();
}
}
-#endif
+# endif
// Option values resulting in setting an option.
str = dict_get_string(dict, (char_u *)"highlight", FALSE);
@@ -565,7 +565,7 @@ typedef enum
/*
* popup_create({text}, {options})
* popup_atcursor({text}, {options})
- * When called from f_popup_atcursor() "atcursor" is TRUE.
+ * When called from f_popup_atcursor() "type" is TYPE_ATCURSOR.
*/
static void
popup_create(typval_T *argvars, typval_T *rettv, create_type_T type)
@@ -984,7 +984,7 @@ f_popup_getpos(typval_T *argvars, typval
}
/*
- * f_popup_getoptions({id})
+ * popup_getoptions({id})
*/
void
f_popup_getoptions(typval_T *argvars, typval_T *rettv)
Re: [doc][patch] Fix typos and mistakes in version8.txt
Hi Bram, 2019/5/28 Tue 5:22:09 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > I found many typos and mistakes in version8.txt. > > Please check the attached patch. > > I'll include it, thanks! I found some more missing contributor names. Also found a mistake in my previous patch. Please check this additional patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/cbdaceb6-a813-4631-8472-6c739d9ec22a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent d23a1e01c99f074e385dba25bcd490fd0fbe0055 diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -26929,7 +26929,8 @@ Files: src/testdir/test_spell.vim Patch 8.1.0201 Problem:Newer Python uses "importlib" instead of "imp". -Solution: Use "importlib" for newer Python versions. (closes #3163) +Solution: Use "importlib" for newer Python versions. (Ozaki Kiichi, +closes #3163) Files: src/if_py_both.h, src/testdir/test87.in Patch 8.1.0202 @@ -26980,9 +26981,8 @@ Solution: Use ANSI function declaratio Files: src/eval.c, src/evalfunc.c, src/list.c Patch 8.1.0211 -Problem:Expanding a file name "~" results in $HOME. -Solution: Change "~" to "./~" before expanding. (Aidan Shafran, -closes #3072) +Problem:Expanding a file name "~" results in $HOME. (Aidan Shafran) +Solution: Change "~" to "./~" before expanding. (closes #3072) Files: src/testdir/test_expand.vim, src/ex_docmd.c, src/eval.c, src/proto/eval.pro, src/evalfunc.c, src/if_cscope.c, src/misc1.c @@ -27157,7 +27157,8 @@ Solution: Add a test that shows the be Files: src/testdir/test_tabpage.vim Patch 8.1.0242 -Problem:Insert mode completion may use an invalid buffer pointer. +Problem:Insert mode completion may use an invalid buffer pointer. (Akib +Nizam) Solution: Check for ins_buf to be valid. (closes #3290) Files: src/edit.c @@ -27716,7 +27717,8 @@ Files: src/ex_cmds2.c, src/testdir/t src/testdir/test_command_count.vim Patch 8.1.0342 -Problem:Crash when a callback deletes a window that is being used. +Problem:Crash when a callback deletes a window that is being used. (Ozaki +Kiichi) Solution: Do not unload a buffer that is being displayed while redrawing the screen. Also avoid invoking callbacks while redrawing. (closes #2107) @@ -28449,7 +28451,8 @@ Files: src/memline.c Patch 8.1.0464 Problem:MS-Windows: job_info() has cmd without backslashes. (Daniel Hahler) -Solution: Use rem_backslash(). (closes #3517, closes #3404) +Solution: Use rem_backslash(). (closes #3517, closes #3404) Add a test. +(Yasuhiro Matsumoto) Files: src/misc2.c, src/testdir/test_channel.vim Patch 8.1.0465 (after 8.1.0452) @@ -32473,7 +32476,8 @@ Files: src/autocmd.c Patch 8.1.1116 Problem:Cannot enforce a Vim script style. -Solution: Add the :scriptversion command. (closes #3857) +Solution: Add the :scriptversion command. (idea by Yasuhiro Matsumoto, +closes #3857) Files: runtime/doc/repeat.txt, runtime/doc/eval.txt, src/eval.c, src/ex_cmds.h, src/evalfunc.c, src/ex_cmds2.c, src/proto/ex_cmds2.pro, src/structs.h, src/buffer.c, src/main.c, @@ -34158,13 +34162,13 @@ Files: src/fileio.c, src/testdir/tes Patch 8.1.1380 Problem: MS-Windows building VIMDLL with MSVC: SUBSYSTEM is not set. -Solution: Invert condition. (closes #4422) +Solution: Invert condition. (Ken Takata, closes #4422) Files: src/Make_mvc.mak Patch 8.1.1381 Problem:MS-Windows: missing build dependency. Solution: Make gui_dwrite.cpp depend on gui_dwrite.h. (Ken Takata, -closes #4423 +closes #4423) Files: src/Make_cyg_ming.mak, src/Make_mvc.mak Patch 8.1.1382
[doc][patch] Write about binary numbers
Hi, Recently Vim supported binary numbers, but it was not written in usr_41.txt. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e3662a88-0dac-463b-846c-b382bf91e274%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent b9bc5c44cccaeca348e2e0f703ec4847c54bc7d2 diff --git a/runtime/doc/usr_41.txt b/runtime/doc/usr_41.txt --- a/runtime/doc/usr_41.txt +++ b/runtime/doc/usr_41.txt @@ -105,20 +105,21 @@ We won't explain how |:for| and |range() if you are impatient. -THREE KINDS OF NUMBERS - -Numbers can be decimal, hexadecimal or octal. A hexadecimal number starts -with "0x" or "0X". For example "0x1f" is decimal 31. An octal number starts -with a zero. "017" is decimal 15. Careful: don't put a zero before a decimal -number, it will be interpreted as an octal number! +FOUR KINDS OF NUMBERS + +Numbers can be decimal, hexadecimal, octal or binary. A hexadecimal number +starts with "0x" or "0X". For example "0x1f" is decimal 31. An octal number +starts with a zero. "017" is decimal 15. A binary number starts with "0b" or +"0B". For example "0b101" is decimal 5. Careful: don't put a zero before a +decimal number, it will be interpreted as an octal number! The ":echo" command always prints decimal numbers. Example: > :echo 0x7f 036 < 127 30 ~ -A number is made negative with a minus sign. This also works for hexadecimal -and octal numbers. A minus sign is also used for subtraction. Compare this -with the previous example: > +A number is made negative with a minus sign. This also works for hexadecimal, +octal and binary numbers. A minus sign is also used for subtraction. Compare +this with the previous example: > :echo 0x7f -036 < 97 ~
[doc][patch] Fix typos and mistakes in version8.txt
Hi, I found many typos and mistakes in version8.txt. Please check the attached patch. Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/582c3c66-ccb7-4f9d-bfec-bca47a955b20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent fa44d421644114e77f5f46d21f1b4c652120b6c5 diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt --- a/runtime/doc/version8.txt +++ b/runtime/doc/version8.txt @@ -25914,7 +25914,7 @@ Files: runtime/doc/eval.txt, runtime Patch 8.1.0021 Problem:Clang warns for undefined behavior. -Solution: Move #ifdef outside of sprintf() call.(suggestion by Michael +Solution: Move #ifdef outside of sprintf() call. (suggestion by Michael Jarvis, closes #2946) Files: src/term.c @@ -25930,7 +25930,7 @@ Solution: Use mch_memmove() instead of Files: src/memline.c Patch 8.1.0024 -Problem:% command not testded on #ifdef and comment. +Problem:% command not tested on #ifdef and comment. Solution: Add tests. (Dominique Pelle, closes #2956) Files: src/testdir/test_goto.vim @@ -25946,7 +25946,7 @@ Files: src/testdir/test_terminal.vim Patch 8.1.0027 Problem:Difficult to make a plugin that feeds a line to a job. -Solution: Add the nitial code for the "prompt" buftype. +Solution: Add the initial code for the "prompt" buftype. Files: runtime/doc/channel.txt, runtime/doc/eval.txt, runtime/doc/options.txt, runtime/doc/tags, runtime/doc/todo.txt, src/Makefile, src/buffer.c, src/channel.c, src/diff.c, src/edit.c, @@ -25966,7 +25966,7 @@ Solution: Skip test with redirection o Files: src/testdir/test_terminal.vim Patch 8.1.0030 -Problem:Stoping Vim running in a terminal may not work. +Problem:Stopping Vim running in a terminal may not work. Solution: Instead of sending send CTRL-O. Files: src/testdir/screendump.vim, src/testdir/test_prompt_buffer.vim @@ -26046,8 +26046,8 @@ Solution: Return FAIL from get_bad_opt Files: src/ex_docmd.c, src/testdir/test_plus_arg_edit.vim Patch 8.1.0044 -Problem:If a test function exists Vim this may go unnoticed. -Solution: Check for a test funtion quitting Vim. Fix tests that did exit +Problem:If a test function exits Vim this may go unnoticed. +Solution: Check for a test function quitting Vim. Fix tests that did exit Vim. Files: src/testdir/runtest.vim, src/testdir/test_assert.vim @@ -26330,7 +26330,7 @@ Solution: Only use debugbreak() on MS- Files: runtime/pack/dist/opt/termdebug/plugin/termdebug.vim Patch 8.1.0094 -Problem:Help text "usage:" is not capatalized. +Problem:Help text "usage:" is not capitalized. Solution: Make it "Usage:". (closes #3044) Files: src/main.c @@ -26980,8 +26980,9 @@ Solution: Use ANSI function declaratio Files: src/eval.c, src/evalfunc.c, src/list.c Patch 8.1.0211 -Problem:Expanding a file name "~" results in $HOME. (Aidan Shafran) -Solution: Change "~" to "./~" before expanding. (closes #3072) +Problem:Expanding a file name "~" results in $HOME. +Solution: Change "~" to "./~" before expanding. (Aidan Shafran, +closes #3072) Files: src/testdir/test_expand.vim, src/ex_docmd.c, src/eval.c, src/proto/eval.pro, src/evalfunc.c, src/if_cscope.c, src/misc1.c @@ -27692,7 +27693,7 @@ Solution: Allow :file without argument Files: src/ex_docmd.c, src/testdir/test_quickfix.vim Patch 8.1.0338 -Problem:MS-Windows: VTP doesn't work properly with Powershell. +Problem:MS-Windows: VTP doesn't work properly with PowerShell. Solution: Adjust the color index. (Nobuhiro Takasaki, closes #3347) Files: src/os_win32.c @@ -27795,7 +27796,7 @@ Files: src/testdir/test_packadd.vim Patch 8.1.0355 Problem:Incorrect adjusting the popup menu for the preview window. -Solution: Compute position and height properl. (Ronan Pigott) Also show at +Solution: Compute position and height properly. (Ronan Pigott) Also show at least ten items. (closes #3414) Files: src/popupmnu.c @@ -28388,7 +28389,7 @@ Files: src/os_win32.c, runtime/doc/m Patch 8.1.0453 Problem:MS-Windows: executable() is not reliable. -Solution: Use $PATHEXT properly. (Yasuhiro Matsumoto, closes #3412) +Solution: Use $PATHEXT properly. (Y
Re: Patch 8.1.1406
Hi Bram, 2019/5/27 Mon 5:18:15 UTC+9 Bram Moolenaar wrote: > Patch 8.1.1406 > Problem:popup_hide() and popup_show() not implemented yet. > Solution: Implement the functions. > Files:src/popupwin.c, src/proto/popupwin.pro, src/evalfunc.c, > src/structs.h, runtime/doc/popup.txt, src/screen.c, src/vim.h, > src/testdir/test_popupwin.vim ... > --- 612,621 > #define VALID_BOTLINE 0x20// w_botine and w_empty_rows are valid > #define VALID_BOTLINE_AP 0x40 // w_botine is approximated > #define VALID_TOPLINE 0x80// w_topline is valid (for cursor > position) > ! > ! // Values for w_popup_flags. > ! #define PFL_HIDDEN 1 // popup is not displayed > ! #define PFL_REDRAWN 2 // popup was just redrawn > > /* >* Terminal highlighting attribute bits. The PFL_HIDDEN definition conflicts with the Windows' winsock2 definition: https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/9nghy0drxbyiohfp?fullLog=true#L316 > C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\winsock2.h(985): > warning C4005: 'PFL_HIDDEN': macro redefinition > C:\projects\vim-win32-installer\vim\src\vim.h(617): note: see previous > definition of 'PFL_HIDDEN' This occurs when if_perl is enabled. (We don't enable if_perl in the vim/vim repository on AppVeyor.) Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/0bb9196d-b395-422d-aed2-0b543719ca9d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: E484 after GVIM update
Hi,
2019/5/23 Thu 9:36:27 UTC+9 Ken Takata wrote:
> That's too bad.
> Unfortunately, I cannot repoduce this yet.
> Does this simple case work?
>
> gvim --clean
> :echo system('dir')
>
> Does the problem occur only with gvim? not on vim.exe?
Ah! `gui.in_use` is not set when system() is executed from _vimrc.
How about the attached patch?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/c4ed0550-02c0-45c9-9577-9a23dfe18f2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
index 54ca4de7d..1320981f5 100644
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -4500,7 +4500,7 @@ mch_system_c(char *cmd, int options)
mch_system(char *cmd, int options)
{
#ifdef VIMDLL
-if (gui.in_use)
+if (gui.in_use || gui.starting)
return mch_system_g(cmd, options);
else
return mch_system_c(cmd, options);
@@ -4821,7 +4821,7 @@ mch_call_shell(
{
cmdlen =
#ifdef FEAT_GUI_MSWIN
- (gui.in_use ?
+ (gui.in_use || gui.starting ?
(!s_dont_use_vimrun && p_stmp ?
STRLEN(vimrun_path) : STRLEN(p_sh) + STRLEN(p_shcf))
: 0) +
@@ -4834,7 +4834,7 @@ mch_call_shell(
#if defined(FEAT_GUI_MSWIN)
if (
# ifdef VIMDLL
- gui.in_use &&
+ (gui.in_use || gui.starting) &&
# endif
need_vimrun_warning)
{
@@ -4853,7 +4853,7 @@ mch_call_shell(
}
if (
# ifdef VIMDLL
- gui.in_use &&
+ (gui.in_use || gui.starting) &&
# endif
!s_dont_use_vimrun && p_stmp)
/* Use vimrun to execute the command. It opens a console
@@ -4865,7 +4865,7 @@ mch_call_shell(
p_sh, p_shcf, cmd);
else
# ifdef VIMDLL
- if (gui.in_use)
+ if (gui.in_use || gui.starting)
# endif
vim_snprintf((char *)newcmd, cmdlen, "%s %s %s %s %s",
p_sh, p_shcf, p_sh, p_shcf, cmd);
@@ -4889,7 +4889,7 @@ mch_call_shell(
/* Print the return value, unless "vimrun" was used. */
if (x != 0 && !(options & SHELL_SILENT) && !emsg_silent
#if defined(FEAT_GUI_MSWIN)
- && (gui.in_use ?
+ && (gui.in_use || gui.starting ?
((options & SHELL_DOOUT) || s_dont_use_vimrun || !p_stmp) : 1)
#endif
)
Re: E484 after GVIM update
Hi,
2019/5/23 Thu 5:29:48 UTC+9 Bram Moolenaar wrote:
> > > 2019/5/16 Thu 15:50:40 UTC+9 Ni Va wrote:
> > > > Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> > > > > Hi,
> > > > >
> > > > > 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > > > > > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > > > > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > > > > > > On Tuesday, April 30, 2019 at 3:31:31 AM UTC-4,
> > > > > > > > niva...@gmail.com wrote:
> > > > > > > > > Le mardi 30 avril 2019 08:49:27 UTC+2, niva...@gmail.com a
> > > > > > > > > écrit :
> > > > > > > > > > Le mardi 30 avril 2019 07:46:42 UTC+2, Christian Brabandt a
> > > > > > > > > > écrit :
> > > > > > > > > > > On Mo, 29 Apr 2019, Blay263 wrote:
> > > > > > > > > > >
> > > > > > > > > > > > After updating my vim version I am getting the error
> > > > > > > > > > > > below:
> > > > > > > > > > > >
> > > > > > > > > > > > E484: Can't open file
> > > > > > > > > > > > C:\Users\\AppData\Local\Temp\VIoCC2F.tmp
> > > > > > > > > > > >
> > > > > > > > > > > > I am using GVIM on windows with the WSL subsytem. It
> > > > > > > > > > > > looks like the way the escape sequences work has
> > > > > > > > > > > > changed.
> > > > > > > > > > >
> > > > > > > > > > > So what is in that particular line of your .vimrc? Might
> > > > > > > > > > > already be
> > > > > > > > > > > fixed by 8.1.1239
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Christian
> > > > > > > > > > > --
> > > > > > > > > > > Bauer Pichler fährt zur Kur. Schon bald bekommt er Post
> > > > > > > > > > > von seiner Frau:
> > > > > > > > > > > "Heute ist unser Ochse eingegangen. Nun weiß ich nicht so
> > > > > > > > > > > recht, soll ich
> > > > > > > > > > > einen neuen kaufen oder auf Dich warten?"
> > > > > > > > > >
> > > > > > > > > > Same problem at startup
> > > > > > > > > >
> > > > > > > > > > E484: Can't open file
> > > > > > > > > > C:\Users\NICOLA~1.VAL\AppData\Local\Temp\VIo9A
> > > > > > > > > > 54.tmp
> > > > > > > > > >
> > > > > > > > > > line 184 of _vimrc:
> > > > > > > > > > let
> > > > > > > > > > g:Explorer_RubyLibPath=substitute(fnamemodify(system('which
> > > > > > > > > > '.g:Explorer_RubyLibName),":p"),':..',':',"")
> > > > > > > > >
> > > > > > > > > Same problem with Vim.8.1.1239 patch
> > > > > > > >
> > > > > > > > Line 645:
> > > > > > > > let g:startify_custom_header =
> > > > > > > > \ map(split(system('fortune -s'), '\n'), '" ".
> > > > > > > > v:val') + ['']
> > > > > > >
> > > > > > > This version works fine:
> > > > > >
> > > > > > Under windows 10, gvim.8.1.1239 launched in administrator or not,
> > > > > > there is a change using system func like that:
> > > > > > let g:Explorer_RubyLibName = 'msvcrt-ruby260.dll'
> > > > > > let try1=system('which '.g:Explorer_RubyLibName)
> > > > > >
> > > > > >
> > > > > > It causes this kind of error accessing temp file:
> > > > > > E484: Can't open file C:\Users\FOO~1.BAR\AppData\Local\Temp\VIoC1
> > > > > > 0E.tmp
> > > > >
> > > > > Can you bisect to find the offending patch?
> > > > >
> > > > > Regards,
> > > > > Ken Takata
> > > >
> > > > Sorry I tried to rollback until 8.1.1210 but since I got this kind of
> > > > errors (attached) I cannot bisect.
> > >
> > > Then, can you edit proto/usercmd.pro and change "compl" to "complp"
> > > manually?
> >
> > It's between 8.1.1229 ans 8.1.1230.
>
> That must be the VIMDLL change then.
That's too bad.
Unfortunately, I cannot repoduce this yet.
Does this simple case work?
gvim --clean
:echo system('dir')
Does the problem occur only with gvim? not on vim.exe?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/9b28b35e-150d-4f8e-8291-954af47d3eae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: E484 after GVIM update
Hi,
2019/5/16 Thu 15:50:40 UTC+9 Ni Va wrote:
> Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> > Hi,
> >
> > 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > > > On Tuesday, April 30, 2019 at 3:31:31 AM UTC-4, niva...@gmail.com
> > > > > wrote:
> > > > > > Le mardi 30 avril 2019 08:49:27 UTC+2, niva...@gmail.com a écrit :
> > > > > > > Le mardi 30 avril 2019 07:46:42 UTC+2, Christian Brabandt a écrit
> > > > > > > :
> > > > > > > > On Mo, 29 Apr 2019, Blay263 wrote:
> > > > > > > >
> > > > > > > > > After updating my vim version I am getting the error below:
> > > > > > > > >
> > > > > > > > > E484: Can't open file
> > > > > > > > > C:\Users\\AppData\Local\Temp\VIoCC2F.tmp
> > > > > > > > >
> > > > > > > > > I am using GVIM on windows with the WSL subsytem. It looks
> > > > > > > > > like the way the escape sequences work has changed.
> > > > > > > >
> > > > > > > > So what is in that particular line of your .vimrc? Might
> > > > > > > > already be
> > > > > > > > fixed by 8.1.1239
> > > > > > > >
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Christian
> > > > > > > > --
> > > > > > > > Bauer Pichler fährt zur Kur. Schon bald bekommt er Post von
> > > > > > > > seiner Frau:
> > > > > > > > "Heute ist unser Ochse eingegangen. Nun weiß ich nicht so
> > > > > > > > recht, soll ich
> > > > > > > > einen neuen kaufen oder auf Dich warten?"
> > > > > > >
> > > > > > > Same problem at startup
> > > > > > >
> > > > > > > E484: Can't open file
> > > > > > > C:\Users\NICOLA~1.VAL\AppData\Local\Temp\VIo9A
> > > > > > > 54.tmp
> > > > > > >
> > > > > > > line 184 of _vimrc:
> > > > > > > let g:Explorer_RubyLibPath=substitute(fnamemodify(system('which
> > > > > > > '.g:Explorer_RubyLibName),":p"),':..',':',"")
> > > > > >
> > > > > > Same problem with Vim.8.1.1239 patch
> > > > >
> > > > > Line 645:
> > > > > let g:startify_custom_header =
> > > > > \ map(split(system('fortune -s'), '\n'), '" ". v:val') +
> > > > > ['']
> > > >
> > > > This version works fine:
> > >
> > > Under windows 10, gvim.8.1.1239 launched in administrator or not, there
> > > is a change using system func like that:
> > > let g:Explorer_RubyLibName = 'msvcrt-ruby260.dll'
> > > let try1=system('which '.g:Explorer_RubyLibName)
> > >
> > >
> > > It causes this kind of error accessing temp file:
> > > E484: Can't open file C:\Users\FOO~1.BAR\AppData\Local\Temp\VIoC1
> > > 0E.tmp
> >
> > Can you bisect to find the offending patch?
> >
> > Regards,
> > Ken Takata
>
> Sorry I tried to rollback until 8.1.1210 but since I got this kind of errors
> (attached) I cannot bisect.
Then, can you edit proto/usercmd.pro and change "compl" to "complp" manually?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/34bc0106-a54a-4fdd-9ee9-fa0e8302c5b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: E484 after GVIM update
Hi,
2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > On Tuesday, April 30, 2019 at 3:31:31 AM UTC-4, niva...@gmail.com wrote:
> > > > Le mardi 30 avril 2019 08:49:27 UTC+2, niva...@gmail.com a écrit :
> > > > > Le mardi 30 avril 2019 07:46:42 UTC+2, Christian Brabandt a écrit :
> > > > > > On Mo, 29 Apr 2019, Blay263 wrote:
> > > > > >
> > > > > > > After updating my vim version I am getting the error below:
> > > > > > >
> > > > > > > E484: Can't open file C:\Users\\AppData\Local\Temp\VIoCC2F.tmp
> > > > > > >
> > > > > > > I am using GVIM on windows with the WSL subsytem. It looks like
> > > > > > > the way the escape sequences work has changed.
> > > > > >
> > > > > > So what is in that particular line of your .vimrc? Might already be
> > > > > > fixed by 8.1.1239
> > > > > >
> > > > > >
> > > > > > Best,
> > > > > > Christian
> > > > > > --
> > > > > > Bauer Pichler fährt zur Kur. Schon bald bekommt er Post von seiner
> > > > > > Frau:
> > > > > > "Heute ist unser Ochse eingegangen. Nun weiß ich nicht so recht,
> > > > > > soll ich
> > > > > > einen neuen kaufen oder auf Dich warten?"
> > > > >
> > > > > Same problem at startup
> > > > >
> > > > > E484: Can't open file C:\Users\NICOLA~1.VAL\AppData\Local\Temp\VIo9A
> > > > > 54.tmp
> > > > >
> > > > > line 184 of _vimrc:
> > > > > let g:Explorer_RubyLibPath=substitute(fnamemodify(system('which
> > > > > '.g:Explorer_RubyLibName),":p"),':..',':',"")
> > > >
> > > > Same problem with Vim.8.1.1239 patch
> > >
> > > Line 645:
> > > let g:startify_custom_header =
> > > \ map(split(system('fortune -s'), '\n'), '" ". v:val') + ['']
> >
> > This version works fine:
>
> Under windows 10, gvim.8.1.1239 launched in administrator or not, there is a
> change using system func like that:
> let g:Explorer_RubyLibName = 'msvcrt-ruby260.dll'
> let try1=system('which '.g:Explorer_RubyLibName)
>
>
> It causes this kind of error accessing temp file:
> E484: Can't open file C:\Users\FOO~1.BAR\AppData\Local\Temp\VIoC1
> 0E.tmp
Can you bisect to find the offending patch?
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/61db4292-2042-4116-b9af-ecd9f6abb53b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.1146
Hi,
2019/5/14 Tue 5:58:30 UTC+9 Jason Franklin wrote:
> Bram,
>
> Thank you so much for taking the time to work with me on this.
>
> Unfortunately, I still can't get the colors to match on the latest build
> (patch 8.1.1330). I should note that the color scheme is much closer than it
> was before, but it looks like some of the colors are being modified when
> displayed in the Vim terminal window. The latest colors script still does
> not match in both cases.
>
> I have attached an updated version of the output of "colors" in both GNOME
> Terminal and in the Vim terminal window (vim at latest build).
>
> The point of interest is this: The color for yellow and for white is darker
> in the Vim terminal window. You can see this when positioning the
> screenshots side by side. I have noticed that other color schemes also show
> this same result (i.e., darker colors in Vim terminal). I will provide
> screenshots upon request. I don't know what might cause this... I did a git
> blame on the latest terminal.c file and I can't see anything with colors that
> seems odd.
>
> It may be that all of the colors here are slightly darker in the vim terminal
> window. It's so slight that it may be hard to tell. Again, a side-by-side
> comparison is the only way to really see this.
>
> I also want to note that showing bold text in bright colors has been disabled
> in GNOME Terminal.
>
> Thanks,
> Jason
I also noticed that the colors on Cygwin + mintty with 256-color mode are
wrong since 8.1.1146. Especially, yellow becomes brown.
The following patch seems to fix the problem:
--- a/src/terminal.c
+++ b/src/terminal.c
@@ -2432,6 +2432,8 @@ color2index(VTermColor *color, int fg, i
if (color->ansi_index != VTERM_ANSI_INDEX_NONE)
{
+ if (t_colors == 256)
+ return color->ansi_index;
// The first 16 colors and default: use the ANSI index.
switch (color->ansi_index)
{
Regards,
Ken Takata
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/16349e9a-904c-465d-ad4d-424c94b217a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[patch][win32] Indent preprocessor directives in Make_cyg_ming.mak
Hi, Preprocessor directives in Make_cyg_ming.mak are not indented now. The following patch indents them: https://bitbucket.org/k_takata/vim-ktakata-mq/src/330d810f8c533c58a67a010d786cdbc37ea634f8/indent-make_cyg_ming.patch?at=default Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/d701a237-3e2f-41dd-b9d4-ab6bd49cd430%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[patch][win32] Indent preprocessor directives in Make_mvc.mak properly
Hi, Preprocessor directives in Make_mvc.mak are not properly indented now. The following patch indents them properly: https://bitbucket.org/k_takata/vim-ktakata-mq/src/685efe556ac637c1df1961e758fbd68b74903ccb/indent-make_mvc.patch?at=default Regards, Ken Takata -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/fe2cfbab-35c6-46d7-be7a-75111da0d6d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
