Re: vim9 exported functions not recognized by ctags
Hi, I created an issue for this: https://github.com/universal-ctags/ctags/issues/3913 2023年12月29日金曜日 18:20:34 UTC+9 Christian Brabandt: > Hi, > perhaps someone :) should send a PR to > https://github.com/universal-ctags/ctags to add support for Vim9 Script? > > Thanks, > Chris > -- > An investment in knowledge always pays the best interest. > -- Benjamin Franklin > -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/8d407822-7e3e-44c8-b283-51130d0c598bn%40googlegroups.com.
Re: Windows 9.0.1341 colorscheme or syntax bug?
Hi Chainsaw, It has been changed recently. If you want to use :: as comment, add the following line in your .vimrc: let dosbatch_colons_comment = 1 See `:help ft-dosbatch-syntax` for detail. Regards, Ken Takata 2023年2月24日金曜日 1:36:19 UTC+9 Chainsaw: > Hello, > > I reported this on vim/colorschemes github last night, but it may be a > problem with Vim syntax files starting with 9.0.1341. > > For .cmd and .bat files, the latest colorschemes (02-22-2023) with the > latest Windows nightly build of Vim, now displays any lines starting > with :: (two colons used for comment lines) using a white foreground and > red background. > > Thanks > -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ed8e8dff-ac2f-4c3d-b6bd-b0f9ea38181en%40googlegroups.com.
Re: clipbaord internals ques
Hi, 2020/5/18 Mon 13:02:44 UTC+9 M Kelly wrote: > > Hi, > > Just curious, what is the mechanism by which vim saves to the clipboard ? > For example if I am on a X11 system but in termnal vim and I have > clipboard set to unnamed > and I highlight in visual mode some lines and then y(ank) them - does vim > use OSC 52 ? > Or does it (even tho its the terminal) use X11 to update the PRIMARY ? > I will try to figure this out from the code but just wondered if anyone > knew this already. > > thx as always for all things vim, > -m > Vim uses X11 even on terminal to support clipboard. If you use Vim which is compiled without X11, you will find that the clipboard feature (in output of `:version`) is disabled. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/364454a8-3b5b-4c4b-94c2-6e182277eaeb%40googlegroups.com.
Re: issue subtituting new lines
Hi, 2020/5/20 Wed 6:58:58 UTC+9 Eli the Bearded wrote: > > Christian Brabandt > wrote: > > On Di, 19 Mai 2020, Eli the Bearded wrote: > >> And that would look like this in vi, nvi, and vim up until recently: > >> :%s/%%/^M/g > >> On the versions that break that, it instead looks like this: > >> :%s/%%/^[[27;5;109~/g > > A feature or a bug i suppose. What you are seeing are the effects of the > > modifyOtherKeys feature of Vim and xterm (see :h modifyOtherKeys). > > > > I am not sure why it happens for you when pressing CTRL-V in command > > line mode, it does work for me as expected, unless you accidentally > > pressed Shift-Ctrl-V instead of Ctrl-V > > No, I was quite careful in what I typed. But reading :h modifyOtherKeys > leads me to understand what is going on. > > If, when modifyOtherKeys is enabled, instead of: > > colon percent s slash percent percent slash ctrl-v ctrl-m slash g enter > > I type: > > colon percent s slash percent percent slash ctrl-v enter slash g enter > > I get the: > > :%s/%%/^M/g > > output I expect. xterm and vim are trying to represent a as > different than with that setting and I'm seeing the results. But > since is what I really want, actually using works. > > I'll have to mull over if I consider this an improvement or not. > > > To disable it, set the t_TI and t_TE terminal settings to the empty > > string: > > > > let _TI="" > > let _TE="" > > Why that syntax instead of "set t_TI=|set t_TE="? I'm already using > "set t_Co=0" in ~/.vimrc to disable colors. (Specifically it sets > the number of colors available to zero.) In testing, both forms seem > to work in .vimrc, and neither seems to work from the ":" prompt -- > even after I ":!ls" as suggested by the help page. > > Thanks for finding that. > > Elijah > I think this behavior is fixed in 8.1.2350. Both Ctrl-V Ctrl-M and Ctrl-V will input ^M now. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/de8b0963-143c-4fd8-aecc-87f7e031813f%40googlegroups.com.
Re: Best way to launch a URL from within VIM
Hi, 2019/9/27 Fri 15:08:27 UTC+9 J S wrote: > > Vim 7.something under (MS) Windows 7. > > I want to do the equivalent of: > > :!start http://something > > But that doesn't work. > This should work as described in ":help :!start". Which version of Vim do you use? Win32 version or Cygwin (MSYS2) version? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/1757cdcd-d4fb-4771-a475-c29b71e12b23%40googlegroups.com.
Re: [OT(?)] Ubuntu 18 now defaults to 4-space tabs
Hi, 2019/9/10 Tue 16:01:30 UTC+9 Tobiah wrote: > > We upgraded a server to 18.04 and now when I start typing > a python file (seems to be triggered by the .py extension) > the tabs default to 4 spaces. We have decades of code that > use tab characters, and it has not been our intention to > change that. > > I found a /usr/share/vim/vim80/indent/python.vim and tried > moving it out of the way, but the behavior was still there. > > I know I can put a modeline in every file but I was hoping > to do it for every user and for every file. > > > Thanks! > Recent version of ftplugin/python.vim has the following lines: https://github.com/vim/vim/blob/8fe1000e9c3438d0ff36cf2340f0f0e48f8fb89f/runtime/ftplugin/python.vim#L116-L119 So, if you don't want do use the recommended indent style, write the following setting in your .vimrc: let g:python_recommended_style = 0 Older versions of ftplugin/python.vim may not have the setting. Then you may need to overwrite the recommended setting by autocommand or some other way. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/7d598eb1-735c-42e9-b75e-88890c22d819%40googlegroups.com.
Re: Setting the language
Hi, 2019/5/20 Mon 18:16:49 UTC+9 Axel Bender wrote: > @Ken > > Thanks for the reply. > > set encoding=utf-8 is my default setting... > > However, in Windows: > - how can I influence the values of v:lc_time, v:lang, and v:ctype? > - how can I influence the way the internal sort command sorts (in Linux - > having set $LC_ALL to "de_DE.UTF-8") sorting works with /bin/sort. > > Questions over questions... ;-) The internal sort doesn't affected by the locale. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/cd6f1d9f-0263-48ad-b7a3-919d0f959229%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Setting the language
Hi, 2019/5/20 Mon 15:52:09 UTC+9 Axel Bender wrote: > @Christian, > > Thanks for your reply. > > Is there any reason why anyone would not want UTF8? (just joking...) > > That's exactly the problem, I can't set the language to UTF-8 for the various > types (messages, ctype, time) in Windows. > > language english_United States.1252 works (but is not what I want). > language english_United States.65001 (which represents UTF-8 in Windows) > doesn't (as does english_United States.UTF-8 or english.United States.utf8), > which all result in E197 being thrown. > > I see no other way to influence the collation for sorting regions, e.g. with > '<,'>sort than setting the language... > > I explicitly do not want Windows 1252. If you want to use UTF-8, write the following line in your .vimrc (_vimrc): set encoding=utf-8 :language cannot be used for setting the encoding. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/96470c80-bd2f-4cff-b355-23099516afb8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows build: STATIC_STDCPLUS=yes no longer works
Hi, 2019/2/20 Wed 22:31:56 UTC+9 Salman Halim wrote: > Hello, > > > I upgraded my GVim on Windows from 8.1.822 to 8.1.956 yesterday. I noticed > that the STATIC_STDCPLUS=yes no longer seems to have an effect and that I > need to have both libwinpthread-1.dll and libgcc_s_dw2-1.dll. I didn't for > 8.1.822. > > > I build using 32-bit MSys with this: > > > > cd vim/src > > > mingw32-make -f Make_ming.mak -j$NUMBER_OF_PROCESSORS GUI=yes FEATURES=HUGE > PYTHON=c:/Python27 PYTHON_VER=27 DYNAMIC_PYTHON=yes STATIC_STDCPLUS=yes > > > Perhaps the removal of DOS did something? > > > Thank you, Could you try the attached patch? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent a7fe8a7065f3ebf6b9d67c8a8a157c9ff77a5e92 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 @@ -934,7 +934,7 @@ ifeq (yes, $(USE_STDCPLUS)) LINK = $(CXX) ifeq (yes, $(STATIC_STDCPLUS)) #LIB += -static-libstdc++ -static-libgcc -LIB += -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic +LIB += -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic endif else LINK = $(CC)
Re: CTRL-F Setting
Hi, 2019/1/26 Sat 6:49:01 UTC+9 SteveW wrote: > I realize this topic is kind of old but I think it is important. > > Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by > default. At a minimum, mswin.vim should not be setup to be sourced by > default (with notes on how to add it if you want the Windows functionality). > > Vim is vim - basic functions should not be changed just because you are on > Windows. This discussion is outdated. Have you tried the new installer after 8.0.1232? Now the installer has a choice whether you want to source mswin.vim or not. (And it doesn't source mswin.vim by default now.) Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to use file explorer on my local gVim to access remote file system?
Hi, 2018/11/12 Mon 17:09:52 UTC+9 Igor Forca wrote: > Hi, > I am using latest gVim v8.1.0513 nightly build on Windows 7, both 64-bit. > > I have several Linux machines accessible using ssh. Now I am using local > machine's Vim through Putty on every machine. But there are several problems, > there are different versions on Vim (some pretty old one) and there are > different vim settings, different syntax highlighting etc and there is > sometimes even lack of responsiveness and similar. > > On my Windows I have gVim customized to my wishes. > > From my Windows PC's gVim I would like to access files on remote Linux > machines, edit and save. On my PC I have created text file with the following > commands: > > let g:netrw_silent = 1 > let g:netrw_scp_cmd = "\"C:\\Programs\\PuTTY\\pscp.exe\" -pw mypassword " > e scp://myuserid@192.168.1.20//path/to/file.txt > > When I open a gVim on Windows I can source that file: > :source commands.vim > > and file.txt from remote machines is opened, I can edit it and save changes > it works perfectly for individual file. > > Now to the problem. I have hundreds of files that I need to edit. So it would > be way more convenient to open file explorer for remote file system. > On my local machine to access my local PC's files I can open file explorer > with command: :E > How to do this for remote machine? > > I looked into commands.vim and changed the last line to: > e scp://myuserid@192.168.1.20//path/ > > but I get the error: > **error** (netrw) your g:netrw_list_cmd is empty; perhaps ssh is not > executable on your system So, did you set g:netrw_list_cmd? If not try setting it. E.g. https://stackoverflow.com/a/8996320 > let g:netrw_list_cmd = "plink.exe -P # -pw MyPass u...@host.com ls -Fa " Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Compiling Vim on Ubuntu
Hi David, 2018/11/6 Tue 10:30:56 UTC+9 David Fishburn wrote: > I am having a hard time getting gvim to compile on Ubuntu 16.04 > > > When I run this: > > > ./configure --enable-gui > > > > > checking for X... (cached) no > checking if X11 header files can be found... yes > checking --enable-gui argument... no GUI support > checking for X11/SM/SMlib.h... (cached) no > > > This is a standard install of Ubuntu (in a VM), running the dfeault GUI comes > with Ubuntu (Unity). > > > I have tried just about everything I can think to get the required support. > > > sudo apt-get update > > sudo apt-get > build-dep vim > > > sudo apt-get > build-dep vim-gtk > > > sudo apt-get install git > sudo apt-get install build-essentials > sudo apt-get install > vim-gnome > > > > sudo apt-get install > libncursesw5-dev > > > > sudo apt-get update > > > > > > /var/tmp/user0/vim8_from_git/vim8# > ./configure --enable-gui | grep gui > > > checking > --enable-gui argument... no GUI support > > > > > > /var/tmp/user0/vim8_from_git/vim8# > apt build-dep vim > > > Reading > package lists... Done > > > E: > You must put some 'source' URIs in your sources.list > > > > > > sudo apt-get update > > > If this does not fix > the issue, edit /etc/apt/sources.list, e.g. using > > > sudo vim > /etc/apt/sources.list > > > and ensure that the > deb-src lines are not commented out. > > > sudo > apt upgrade > > > sudo > apt -get build-dep vim > > > sudo > apt -get build-dep vim-gtk > > > I can't really think what else to try to install to get the GUI support. How about using "./configure --enable-gui=gtk2" instead? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: runtime: Update NSIS syntax
Hi, 2018/10/2 Tue 23:42:35 UTC+9 Ken Takata wrote: > Dear Bram, > > I have updated the NSIS syntax file. > There was a mistake in highlighting the lables. > Please include this. I should have sent to vim_dev. Sorry. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
runtime: Update NSIS syntax
Dear Bram, I have updated the NSIS syntax file. There was a mistake in highlighting the lables. Please include this. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. <>
Re: E121 : Undefined variable: paste#paste_cmd on Vim 8.1 1-436 second launch
Hi Ni, 2018/9/27 Thu 18:47:04 UTC+9 Ni Va wrote: > Hi, > > I use this last built version of Vim. > > VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 26 2018 13:46:15) > MS-Windows 32-bit GUI version with OLE support > Included patches: 1-436 > Compiled by ni.va > Huge version with GUI. > > > > Under Windows Seven 64 bits, on second launch of this Vim (deployed as > standalone dir) from ~\AppData\Local\Temp, I encounter this warning : > > Error detected while processing ~\AppData\Local\Temp\ > Vim_x86\vim81\menu.vim: > > line 163: > E121: Undefined variable: paste#paste_cmd > E15: Invalid expression: 'vnoremenu
Re: Vim Silent Install Issue
Hi, 2018/9/14 Fri 17:27:52 UTC+9 Devashish Kar wrote: > On Thursday, September 6, 2018 at 2:36:41 PM UTC+5:30, Devashish Kar wrote: > > Hi Team > > > > With the latest version of Vim, I can see a pop-up coming at the end of > > install asking if we want to see the README file (snapshot attached). Being > > an admin, my job is to install it silently (using "gvim81.exe /S") in a > > Win10 machine but this box is not being suppressed, can you help me do that? > > > > Thanks! > > > > -Devashish > > Hi All, been a long time but got no response on this. Can somebody suggest me > if there's any possibility to suppress the box during the end of install? Sorry for the late response. This is a well known issue and there are some PR for this. E.g. https://github.com/vim/vim/pull/751 Moreover, there are many TODO items in the todo.txt: Improve the installer for MS-Windows. There are a few alternatives: - Add silent install option. (Shane Lee, #751) - Installer from Cream (Steve Hall). - Modern UI 2.0 for the Nsis installer. (Guopeng Wen) https://github.com/gpwen/vim-installer-mui2 - make it possible to do a silent install, see http://nsis.sourceforge.net/Docs/Chapter4.html#4.12 Version from Guopeng Wen does this. - MSI installer: https://github.com/petrkle/vim-msi/ - The one on Issue 279. Problem: they all work slightly different (e.g. don't install vimrun.exe). How to test that it works well for all Vim users? Unfortunately there are no progress. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] minpac v2.0: a minimal package manager for Vim 8 (and Neovim)
Hi all, 2017/4/22 Sat 14:06:44 UTC+9 Ken Takata wrote: > Hi all, > > I announce release of minpac ver 1.0. > It is a minimal package manager for Vim 8 (and Neovim). > > https://github.com/k-takata/minpac > > Minpac utilizes the packages feature of Vim 8, and uses the jobs feature for > parallel install/update. So, it is simple and fast. > > Have fun! I announce release of minpac v2.0. https://github.com/k-takata/minpac This version supports showing the status of plugin update or installation in a separate window. I also updated the document and added some useful example commands. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Start terminal in a given directory
Hi, 2018/8/24 Fri 1:19:18 UTC+9 Lifepillar wrote: > On 23/08/2018 15:28, Jason Franklin wrote: > > The documentation under term_start() was recently updated > > to include this option. > > So, I have likely searched the help in a version without your patch, > which, has led me to believe that "cwd" was not supported. > > Thanks for letting me know! > Life. The "cwd" option was supported by Vim 8.0.0902. If you use older than that version, you may want to try this: new | lcd /path/to/dir | terminal ++curwin Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Avoid "auto" short paths
Hi,
2018/8/10 Fri 5:09:25 UTC+9 Bram Moolenaar wrote:
> > This is the company environment, is very common users have they own disk
> > areas at the network of the company, which usually is a drive mapping and
> > set at HOMEDRIVE and HOMEPATH.
>
> So HOMEDRIVE and HOMEPATH are always set? Then these should be used,
> they are checked before USERPROFILE.
>
> > When I open the file , at %USERPROFILE% which is my local drive , vim
> > internally change the path references from c:\Users\cinacio (%USERPROFILE%)
> > to "~" .
> > But when vim expand "~" and exists HOMEDRIVE and HOMEPATH set, they use it.
> >
> > I know I can force my HOME setting %HOME%=3D%USERPROFILE% at windows
> > environment.
> > But I have others programs at my desktop and I don't know how this can
> > affect them, so I would to avoid set the %HOME%
> >
> > That's why I would force vim works always with absolute path.
>
> When HOMEDRIVE and HOMEPATH are set, then USERPROFILE should not be
> used. Are you saying that HOMEDRIVE and HOMEPATH are sometimes not set?
> That effectively means your home directory moves around, so it's
> expected that Vim doesn't handle that.
>
> Using an absolute path has the opposite effect: If your home directory
> is on a dynamically mounted drive, the drive letter can change while
> it's still the same directory. Then using "~/" is actually avoiding
> problems. Thus we can't use the full path as a default.
>
> I think having to set $HOME is acceptable.
I found inconsistency in misc1.c.
init_homedir() initialises the static variable homedir by checking the
following environment variables:
1. HOME
2. HOMEDRIVE + HOMEPATH
3. USERPROFILE
And vim_getenv("HOME") returns a value with the homedir variable.
However home_replace() uses mch_getenv("HOME") and it doesn't uses
vim_getenv("HOME") nor homedir.
Maybe home_replace() should use homedir instead of mch_getenv("HOME")?
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: How to insert text on current text position when I press key in vim in insert and normal mode?
Hi, 2018/6/15 Fri 9:26:22 UTC+9 Gena Makhomed wrote: > Web site http://vimdoc.sourceforge.net/htmldoc/help.html > was not updated from 2010 year - this is bug or feature? There are at least two Web help sites which are up to date: http://vimhelp.appspot.com/ https://vim-jp.org/vimdoc-en/ Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to replace edit command calling netrw by own function call
Hi, 2018/6/13 Wed 19:54:54 UTC+9 Ni Va wrote: > Hi, > > > When you type :e it opens netrw explore command. > > Is it possible to replace it by my own function call. I think that the best way to know that is reading the code of netrw itself or some other similar plugins (e.g. nerdtree). https://github.com/scrooloose/nerdtree/blob/cb9f4db6ffc98f055954801cfced9399a1da829a/plugin/NERD_tree.vim#L170-L175 Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: organize dll
Hi, 2017/12/8 Fri 20:06:32 UTC+9 Ni Va wrote: > Le vendredi 8 décembre 2017 11:27:40 UTC+1, Ken Takata a écrit : > > Hi, > > > > 2017/12/8 Fri 18:46:16 UTC+9 Ni Va wrote: > > > Hi, > > > > > > > > > Instead of deploy external dll in $vimruntime, is it possible to organize > > > them in their own directories? > > > > > > In _vimrc > > > " ext dlls > > > exe 'set luadll='.$vimruntime.'/extDlls/lua/lua53.dll' > > > exe 'set rubydll='.$vimruntime.'/extDlls/ruby/x64-msvcrt-ruby240.dll' > > > > > > > > > It seems to not working after test. > > > > If a DLL doesn't require another DLL, it might be possible. > > However x64-msvcrt-ruby240.dll requires another DLLs. In that case, the DLLs > > should be placed in a directory in $PATH. > > > > Regards, > > Ken Takata > > Under Windows %PATH% or can I overload system path by runtimepath or path var > under vim ? You can change it from Vim. E.g.: let $PATH .= ';c:\somewhere' Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: bad display of output utf-8 chars
Hi,
2017/12/8 Fri 1:02:09 UTC+9 Tony Mechelynck wrote:
> On Thu, Dec 7, 2017 at 3:44 PM, Ni Va <nivaem...@gmail.com> wrote:
> > Le jeudi 7 décembre 2017 00:59:53 UTC+1, dwierenga a écrit :
> >> On Wed, Dec 6, 2017 at 3:18 PM, Ni Va <niva...@gmail.com> wrote:
> >> Yes thank you Tony and Mr Gentis,
> >>
> >>
> >>
> >> Enter chcp under windows console return 850 so you're right Tony.
> >>
> >> So i can try to redirect robocopy's output even if it is so far of my idea
> >> ( getting output data live at runtime)
> >>
> >>
> >>
> >>
> >>
> >>
> >> robocopy.exe has an explicit /UNICODE flag to control the output encoding.
> >> You may want to try that before re-architecting your process to deal
> >> with redirected output.
> >
> >
> > For the moment it works with my output showmessages func fixed.
> >
> > function! sequencerutil#showmessages() abort " {{{
> > let debug_file=tempname()
> > exe 'redir! > ' . debug_file .'|silent messages|redir END'
> > call setqflist(readfile(debug_file))
> > set encoding=cp850
> > copen
> > endfunc "}}}
> >
> >
> >
> > Nota : /UNILOG option causes errors combined with /MIR that I need
>
> Changing 'encoding' anywhere other than your vimrc (which is sourced
> before loading the first editfile) can have disastrous results,
> because it changes how the contents of all text in Vim memory is
> interpreted but it doesn't reload any files already in memory. If at
> that moment you already have another file loaded (a help file, maybe:
> some of them, including options.txt for the 'langmap' example, are in
> "true" UTF-8) it could become hopelessly garbled.
>
> Alas, ":copen" doesn't accept a ++enc modifier.
Sorry, I don't follow the discussion, but if you use `:grep`, `:make` or
some other commands, you can use the 'makeencoding' option to set the
encoding for those commands. (If you use recent versions of Vim.)
If you use setqflist() to set qflist, you may want to use iconv() to
convert the encoding.
E.g.
call setqflist(iconv(readfile(debug_file), 'cp1252', ))
Maybe you can also try or 'char' instead of 'cp1252'.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: organize dll
Hi, 2017/12/8 Fri 18:46:16 UTC+9 Ni Va wrote: > Hi, > > > Instead of deploy external dll in $vimruntime, is it possible to organize > them in their own directories? > > In _vimrc > " ext dlls > exe 'set luadll='.$vimruntime.'/extDlls/lua/lua53.dll' > exe 'set rubydll='.$vimruntime.'/extDlls/ruby/x64-msvcrt-ruby240.dll' > > > It seems to not working after test. If a DLL doesn't require another DLL, it might be possible. However x64-msvcrt-ruby240.dll requires another DLLs. In that case, the DLLs should be placed in a directory in $PATH. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim windows vundle and vimrc
Hi, 2017/11/17 Fri 15:26:59 UTC+9 phk1 wrote: > I installed vim in Windows 8.1. Myngw too and git. Im trying to configure the > vimrc to load plugins. I listed all plugins, ok. Installed all plugins, ok > too. But the plugins don't load. > > The path os plugins is the root. ~/_vimrc. ~/.vim/bundle/... > > My vimrc file: > > set nocompatible " be iMproved, required > filetype off " required > > " set the runtime path to include Vundle and initialize > set rtp+=~/.vim/bundle/Vundle.vim > call vundle#begin() I think this is caused by the difference of rtp on Windows and other platforms. See the official wiki page: https://github.com/VundleVim/Vundle.vim/wiki/Vundle-for-Windows You need to adjust rtp and add an argument to vundle#begin(). Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi,
2017/10/25 Wed 21:28:50 UTC+9 Christian Brabandt wrote:
> Hi Ken,
> I briefly looked at your patch and have some feedback.
>
> On Mi, 25 Okt 2017, Ken Takata wrote:
>
> > Changes are:
> > * Merge the two patches into one.
> > * Update the document.
> > * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> > I'm still wondering what is the best name for this variable.
> > * Remove `has('win16')`. Not needed anymore.
> > * Add to the "Show File Types in Menu" item. Showing the command
> > of this item is not so useful.
>
> +If you want to have all these items already present at startup, add: >
> +:let do_lazyload_menus = 1
>
> I think this variable should either be called `do_no_lazyload_menus` or
> the value should be 0, since by default the menus will be lazy loaded.
Okay, I changed it to `do_no_lazyload_menus`:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/cda66cbfc90b98a5ca6c16229ee129fd448c1bad/improve-loading-menu.vim.patch?fileviewer=file-view-default
Actually, menu.vim only checks the existence of the global variable, the value
is not checked. This is the same as other variable in menu.vim.
> + let n = globpath(, "colors/*.vim")
>
> I think that should be
>
> + let n = globpath(, "colors/*.vim", 1, 1)
>
> So you have a list available already and don't need to split later on
> manually and you probably do want to ignore the suffixes and wildignore
> options, if only the user having set them to bad values.
>
> The same holds for the keymap and compiler runtime files.
It makes the code simpler. Updated.
> + augroup SetupLazyloadMenus
> +au!
> +au CursorHold,CursorHoldI * call SetupLazyloadMenus() | au!
> SetupLazyloadMenus
> + augroup END
>
> Is this actually a good idea to delete the augroup from within itself?
Deleting autocommands in the group is a usual usage. The similar usage can be
found in `augroup LoadBufferMenu` in menu.vim. Moreover, just using `au!`
in an augroup is a normal usage. Deleting an autogroup within itself by
`augroup!` doesn't work in contrast. It causes W19 or E936.
Actually, I want to delete the group here...
> BTW: there are many runtime file variables. Perhaps we should start to
> document internal runtime file variables in a help file at a central
> place.
>
> Also I am starting to wonder, whether it would make sense to start using
> a common prefix, so that the names are more consistent and less likely
> to clash with user variables, e.g. something like
> vim_ftplugin_undo
> vim_indent_undo
> vim_menu_init_immediate
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi,
2017/10/25 Wed 6:20:09 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > > 096.000 072.000 025.000: sourcing
> > > > > > D:\Logiciels\Vim\vim80\filetype.vim
> > > > >
> > > > > menu.vim uses `globpath()` to search some kind of files under the
> > > > runtimepath.
> > > > > If you search `globpath` in menu.vim, you may find the following
> > > > > lines:
> > > > >
> > > > > let s:n = globpath(, "colors/*.vim")
> > > > > let s:n = globpath(, "keymap/*.vim")
> > > > > let s = globpath(, "spell/*." . enc . ".spl")
> > > > > let s:n = globpath(, "compiler/*.vim")
> > > > >
> > > > > Color schemes, keymaps, spell files and compiler plugins are searched
> > > > > when
> > > > > menu.vim is loaded.
> > > > > This is why it takes long time to be loaded.
> > > > >
> > > > > Unlike those items, file types are not listed automatically. If a
> > > > > user
> > > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > > If we use a similar way for color schemes etc., the startup time
> > > > > would be
> > > > > reduced.
> > > >
> > > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > > globpath().
> > > >
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default
> > > >
> > > > Instead of searching colors/*.vim and other files, the following
> > > > menuitems are
> > > > added in the menu:
> > > >
> > > > Edit > Show Color Schemes in Menu
> > > > Edit > Show Keymaps in Menu
> > > > Tools > Show Compiler Settings in Menu
> > > >
> > > > If these menuitems are selected, all available colorschemes etc. are
> > > > shown
> > > > in the menu. If a user want to load them at startup, the following line
> > > > can be added in .vimrc:
> > > > :let do_globpath_menus = 1
> > > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > >
> > > >
> > > > In my environment, the loading time of menu.vim is:
> > > > Without this patch: 30 - 50 ms
> > > > Skip using globpath: 15 - 20 ms
> > >
> > > Not a very big difference. But still worth it if you never use those
> > > menus.
> > >
> > > I wonder if we can do this lazily. Thus fill in the missing entries
> > > when we start waiting for the user to type. Should be around the same
> > > place where timers may be triggered. Not sure if we can do it with an
> > > actual timer from the menu.vim script though. Might need a special kind
> > > of timer. Perhaps an "idle timer"?
> >
> > How about this additional patch, then?
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default=file-view-default
> >
> > This uses CursorHold to load the menuitems when idle.
>
> I like the idea. I'll wait for a few people to try it out.
I have updated the patches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/c58b17bb22261436910d77dcda76409edd962ad5/improve-loading-menu.vim.patch?at=default=file-view-default
Changes are:
* Merge the two patches into one.
* Update the document.
* Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
I'm still wondering what is the best name for this variable.
* Remove `has('win16')`. Not needed anymore.
* Add to the "Show File Types in Menu" item. Showing the command
of this item is not so useful.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi Bram, 2017/10/24 Tue 5:45:40 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote: > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim > > > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim > > > > > > menu.vim uses `globpath()` to search some kind of files under the > > runtimepath. > > > If you search `globpath` in menu.vim, you may find the following lines: > > > > > > let s:n = globpath(, "colors/*.vim") > > > let s:n = globpath(, "keymap/*.vim") > > > let s = globpath(, "spell/*." . enc . ".spl") > > > let s:n = globpath(, "compiler/*.vim") > > > > > > Color schemes, keymaps, spell files and compiler plugins are searched when > > > menu.vim is loaded. > > > This is why it takes long time to be loaded. > > > > > > Unlike those items, file types are not listed automatically. If a user > > > selects "Syntax" -> "Show File Types in Menu", they will be listed. > > > If we use a similar way for color schemes etc., the startup time would be > > > reduced. > > > > I wrote a patch for reduce the loading the of menu.vim by skip using > > globpath(). > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default > > > > Instead of searching colors/*.vim and other files, the following menuitems > > are > > added in the menu: > > > > Edit > Show Color Schemes in Menu > > Edit > Show Keymaps in Menu > > Tools > Show Compiler Settings in Menu > > > > If these menuitems are selected, all available colorschemes etc. are shown > > in the menu. If a user want to load them at startup, the following line > > can be added in .vimrc: > > :let do_globpath_menus = 1 > > (This is similar to `:let do_syntax_sel_menu = 1`.) > > > > > > In my environment, the loading time of menu.vim is: > > Without this patch: 30 - 50 ms > > Skip using globpath: 15 - 20 ms > > Not a very big difference. But still worth it if you never use those > menus. > > I wonder if we can do this lazily. Thus fill in the missing entries > when we start waiting for the user to type. Should be around the same > place where timers may be triggered. Not sure if we can do it with an > actual timer from the menu.vim script though. Might need a special kind > of timer. Perhaps an "idle timer"? How about this additional patch, then? https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default=file-view-default This uses CursorHold to load the menuitems when idle. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi, 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote: > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim > > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim > > menu.vim uses `globpath()` to search some kind of files under the runtimepath. > If you search `globpath` in menu.vim, you may find the following lines: > > let s:n = globpath(, "colors/*.vim") > let s:n = globpath(, "keymap/*.vim") > let s = globpath(, "spell/*." . enc . ".spl") > let s:n = globpath(, "compiler/*.vim") > > Color schemes, keymaps, spell files and compiler plugins are searched when > menu.vim is loaded. > This is why it takes long time to be loaded. > > Unlike those items, file types are not listed automatically. If a user > selects "Syntax" -> "Show File Types in Menu", they will be listed. > If we use a similar way for color schemes etc., the startup time would be > reduced. I wrote a patch for reduce the loading the of menu.vim by skip using globpath(). https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default=file-view-default Instead of searching colors/*.vim and other files, the following menuitems are added in the menu: Edit > Show Color Schemes in Menu Edit > Show Keymaps in Menu Tools > Show Compiler Settings in Menu If these menuitems are selected, all available colorschemes etc. are shown in the menu. If a user want to load them at startup, the following line can be added in .vimrc: :let do_globpath_menus = 1 (This is similar to `:let do_syntax_sel_menu = 1`.) In my environment, the loading time of menu.vim is: Without this patch: 30 - 50 ms Skip using globpath: 15 - 20 ms Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim8: changes behavior of the clipboard (middle mouse button)
Hi, 2017/9/5 Tue 9:55:59 UTC+9 Art Breadless wrote: > Hello, > > since I use vim8 on Xubuntu 16.04 after using vim8 and leaving it the middle > mouse button inserts 0~selectedtext~1. > > This did not happen with vim 7.4. and Xubuntu 14 (this is the condiguration I > use at work) > > zuu@kitchen:~/test$ ls > test > > now selecting test by double click before vim8 was started, the niddle mouse > button inserts: > > > zuu@kitchen:~/test$ test > > now starting vim and exiting: > > zuu@kitchen:~/test$ vim > :q > > selecting test and middle mouse button: > > zuu@kitchen:~/test$ 0~test1~ > > This 0~ and 1~ surronders are bad. Has anyone an idea? It seems that bracketed paste mode is not disabled properly when vim exits. See `:help xterm-bracketed-paste` for detail. It might be a bug of vim, however, you can disable it as a workaround by adding the following line in your .vimrc: set t_BE= Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-8 packages and package managers
Hi, 2017/7/8 Sat 23:22:50 UTC+9 Marcin wrote: > Hello vim_use > > Vim-8 has packages. Is this a breaking feature for some of the vim package > managers out there, and to which extend they support it?. I know that > pathogen supports them, what about others like VAM, vundle, neobundle? No, currently pathogen, VAM, vundle and neobundle don't support Vim 8's packages feature. Vim 8's packages feature provides a similar functionality to pathogen, so you don't need to use pathogen if you use Vim 8, but it doesn't provide a way to install/update/uninstall plugins. There are some plugin managers which are built on top of it: * minpac: Written by me and written in Vim script https://github.com/k-takata/minpac * pack: Written in Rust https://github.com/maralla/pack * infect: Written in Ruby https://github.com/csexton/infect * vim-pck: Written in Python https://github.com/nicodebo/vim-pck * vim8-pack: Written in Bash https://github.com/mkarpoff/vim8-pack Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Cursor isn't at right position for Commit message
Hi,
2017/6/6 Tue 16:19:18 UTC+9 Christian Brabandt wrote:
> On So, 04 Jun 2017, Kaartic Sivaraam wrote:
>
> > Hello all,
> >
> > I am currently using Vim 8.0. When I use vim as my preferred editor for
> > git.
> >
> > When I try to commit a change in git it open up vim to type the commit
> > message. Most of the time the text cursor seems to be positioned
> > somewhere in the middle of the commit template (the comments). As a
> > result, I am unable to type in the commit message directly after
> > switching to "insert" mode in vim. Any reasons for this misbehaviour ?
> >
> > Environments:
> > Operating System: Debian GNU/Linux 9 (stretch)
> > Shell: bash
>
> Perhaps, we should disable the last-position jump for commit messages in
> general. Here is a patch:
>
> diff --git a/runtime/defaults.vim b/runtime/defaults.vim
> index 6fd43db51..fdac666e6 100644
> --- a/runtime/defaults.vim
> +++ b/runtime/defaults.vim
> @@ -109,7 +109,7 @@ if has("autocmd")
> " Don't do it when the position is invalid or when inside an event
> handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> - \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> + \ if line("'\"") >= 1 && line("'\"") <= line("$") && !~# 'commit' |
>\ exe "normal! g`\"" |
>\ endif
>
> diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
> index a0cc971fe..b4b6bbfef 100644
> --- a/runtime/doc/eval.txt
> +++ b/runtime/doc/eval.txt
> @@ -5460,7 +5460,8 @@ line({expr}) The result is a Number, which is the
> line number of the file
> < *last-position-jump*
> This autocommand jumps to the last known position in a file
> just after opening it, if the '" mark is set: >
> - :au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") |
> exe "normal! g`\"" | endif
> + :au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") &&
> +\ !~# 'commit' | exe "normal! g`\"" | endif
>
> line2byte({lnum}) *line2byte()*
> Return the byte count from the start of the buffer for line
I write the following setting in my .vimrc to avoid the problem:
augroup vimrc-git
autocmd!
autocmd BufRead {COMMIT_EDITMSG,MERGE_MSG,git-rebase-todo,NOTES_EDITMSG}
\ delmarks \" | 1
augroup END
Another option is changing the setting of Git to always open the first line:
$ git config --global core.editor "vim +1"
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Insert lines at begin of file with writefile
\, 'DYNAMIC_LUA=yes' > \, 'LUA=.\\lua53' > \, 'LUA_VER=53' > \, 'DYNAMIC_PYTHON=yes' > \, 'PYTHON=C:\Python27' > \, 'PYTHON_VER=27' > \, 'DYNAMIC_PYTHON3=no' > \, 'PYTHON3=' > \, 'PYTHON3_VER=' > \, 'EVENT_LOOP=yes' > \, ' > ' > \] > " method 1 : slow to add lines but job able > let cmd = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c", > \"call append(0, ".string(lines2Append).")", > "-c", "wq"] > " call x.add_cmd(cmd) "started as job by job_start( and handlers > > > " method 2 : faster but no job able ??!? > let originalFile = readfile(makefile,'b') > call writefile( lines2Append, makefile, 'b') > call writefile( originalFile, makefile, 'a') Just curious. Why you edit Make_mvc.mak? Normally you just need to specify the option in the command line. E.g.: nmake -f Make_mvc.mak "SDK_INCLUDE_DIR=..." CPU=AMD64 FEATURES=... ... Another option is creating a batch file which sets the options to environment variables, then run nmake. E.g.: @echo off set SDK_INCLUDE_DIR=... set CPU=AMD64 set FEATURES=... ... nmake -f Make_mvc.mak Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi,
2017/5/24 Wed 17:39:34 UTC+9 Ni Va wrote:
> Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit :
> > Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit :
> > > > Thank you
> > > Sped up by using a plugin manager supporting lazy loading or as needed
> > > (vim-addon-manager/Neobundle maybe more).
> > >
> > > Typically sourcing twice is not a problem, often guard [1] like guard
> > > has been setup which is a quick workraound which immediately saves most
> > > time.
> > >
> > > Marc Weber
> > >
> > > [1]
> > >
> > > if exists("loaded_")
> > > finish
> > > endif
> > > let loaded_ = 1
> > >
> > >
> >
> > Ok this one seems better than vundle and save me 100ms at startup but I dig.
> > https://github.com/junegunn/vim-plug
> >
> > Thank you Marc !
>
> Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> Is anyone can advise me or explain to me why some files are loaded twice and
> take twice or more times N msec:
> - vim80/menu.vim
> - vim80\filetype.vim
> 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
menu.vim uses `globpath()` to search some kind of files under the runtimepath.
If you search `globpath` in menu.vim, you may find the following lines:
let s:n = globpath(, "colors/*.vim")
let s:n = globpath(, "keymap/*.vim")
let s = globpath(, "spell/*." . enc . ".spl")
let s:n = globpath(, "compiler/*.vim")
Color schemes, keymaps, spell files and compiler plugins are searched when
menu.vim is loaded.
This is why it takes long time to be loaded.
Unlike those items, file types are not listed automatically. If a user
selects "Syntax" -> "Show File Types in Menu", they will be listed.
If we use a similar way for color schemes etc., the startup time would be
reduced.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: command-t plugin need wrong ruby version
Hi, 2017/4/21 Fri 1:48:01 UTC+9 Sand Glass wrote: > I want to install command-t plugin.(gvim 7.4; windows) > https://github.com/wincent/command-t > It needs ruby 1.9.2. I download the right ruby version. > http://rubyinstaller.org/downloads/archives > But when I run ':ruby 1' to test ruby. It shows Error "E370 > msvcrt-ruby192.dll > lost", then I goto the ruby diretory to search the 192.dll, but only > msvcrt-ruby191.dll, I tried all 192 ruby verion in above page. All of them > 191.dll, I tried to change msvcrt-ruby191.dll to msvcrt-ruby192.dll, not work. > > question: > Is there anyone istall command-t plugin, how do you do it? I think that ruby support of the official Vim 7.4 installer is broken. Ruby's dll has the API version in its name. Ruby 1.9.2's API version is 1.9.1. So the dll name should include 191. However, strangely Vim 7.4 requires 192. I think the easiest way to enable ruby support is using Vim 8.0. (I don't know about command-t.) Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] minpac v1.0: a minimal package manager for Vim 8
Hi Bram,
At first, I have to say one thing: minpac is actually a plugin manager using
the packages feature, not a package manager. It cannot download packages and
install them.
(Maybe it's better to fix the document.)
2017/4/22 Sat 22:18:04 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > I announce release of minpac ver 1.0.
> > It is a minimal package manager for Vim 8 (and Neovim).
> >
> > https://github.com/k-takata/minpac
> >
> > Minpac utilizes the packages feature of Vim 8, and uses the jobs feature for
> > parallel install/update. So, it is simple and fast.
> >
> > Have fun!
>
> Thanks for making this.
>
> Some questions pop up when reading the first page:
> - Does this only work with git repositories?
Yes, minpac supports only git repositories. Nowadays most Vim plugins have
each git repository.
I don't have a plan to support other types of plugins.
I want to keep minpac simple.
> - Does it automatically update, or does the user need to execute a
> command to update the packages?
It doesn't automatically update. If a user want to update plugins,
he need to execute:
call minpac#update()
Minpac doesn't define a command for this, but the user define a command for
this by himself if he want.
> - It mentions "start" plugins and "opt" plugins, who makes that choice?
The user should specify this as an argument of `minpac#add()`.
For "start" plugins:
call minpac#add('account/plugin')
or
call minpac#add('account/plugin', {'type': 'start'})
For "opt" plugins:
call minpac#add('account/plugin', {'type': 'opt'})
> - Is there a list of packages and how to add them?
As I wrote above, minpac actually doesn't manage packages. It only handles
one package, `~/.vim/pack/minpac` by default.
About a list of plugins, the user should register the plugins by `minpac#add()`.
Normally he will write a list in his .vimrc like this:
call minpac#add('account1/plugin1')
call minpac#add('account1/plugin2')
call minpac#add('account2/plugin3')
call minpac#add('https://example.com/account3/plugin4.git')
This is similar to other plugin managers: Vundle, vim-plug, dein.vim, etc.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ANN] minpac v1.0: a minimal package manager for Vim 8
Hi all, I announce release of minpac ver 1.0. It is a minimal package manager for Vim 8 (and Neovim). https://github.com/k-takata/minpac Minpac utilizes the packages feature of Vim 8, and uses the jobs feature for parallel install/update. So, it is simple and fast. Have fun! Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim 'less.sh' script probs w/folds
Hi,
2017/3/28 Tue 6:19:19 UTC+9 L A Walsh wrote:
> If I have a file with folds in it (fdm=marker), and I try to
> display it with the vim 'less.sh' script, there doesn't seem to be
> a way to get rid of all the folds (no 'zR'). I can use the cursor
> keys to move to each fold and open it, but that really defeats
> the idea of using 'less' to scroll through the source by pressing
> 'space' (for example).
>
> Maybe folds should be disabled for the less.sh script?
I'm not sure it should be disabled. However, you can use the following
command as a workaround to open all folds:
:norm! zR
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim maximise weirdness
Hi, 2017/3/15 Wed 0:33:25 UTC+9 Eric Christopherson wrote: > On Tue, Mar 14, 2017 at 5:07 AM, A. S. Budden <abu...@gmail.com> wrote: > > With the newly compiled version of vim (details below), `:simalt ~x` > > doesn't do quite what I was expecting: the window gets bigger but the > > drawn area doesn't - https://snag.gy/3VfqUe.jpg > How interesting -- for me, :simalt ~x works, but actually pressing > doesn't bring down the menu. I have to define a mapping for it > to work: > > > :nnoremap :simalt ~ > :inoremap :simalt ~ I confirmed that `:simalt ~x` worked fine on v8.0.0274. However, on v8.0.0275, `:simalt ~x` makes the window maximized but the contents is not properly updated. I need to hit Ctrl-L to update the contents. Alt-Space doesn't work on neither 0274 nor 0275. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [doc][patch] Fix usage of single quotations
Hi, 2017/2/19 Sun 11:16:16 UTC+9 Ken Takata wrote: > Hi, > > Single quotations are used for options in the Vim documents. However, there > are some parts which uses single quotations for non-option words. They might > sometimes cause confusion, I think. Attached patch fixes them. > It also fixes: > > * Add new tags in term.txt: *terminal-output-codes* and *terminal-key-codes* > * Fix missing tags in term.txt: *'t_PS'* and *'t_PE'* > * Fix typos in usr_02.txt and version8.txt Sorry, I intended to post to vim_dev instead of vim_use. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[doc][patch] Fix usage of single quotations
Hi,
Single quotations are used for options in the Vim documents. However, there
are some parts which uses single quotations for non-option words. They might
sometimes cause confusion, I think. Attached patch fixes them.
It also fixes:
* Add new tags in term.txt: *terminal-output-codes* and *terminal-key-codes*
* Fix missing tags in term.txt: *'t_PS'* and *'t_PE'*
* Fix typos in usr_02.txt and version8.txt
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent db60e75d61fc19a9161cd87e01f0c6ed1a4edc09
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -3430,7 +3430,7 @@ execute({command} [, {silent}]) *exe
"" no `:silent` used
"silent" `:silent` used
"silent!" `:silent!` used
- The default is 'silent'. Note that with "silent!", unlike
+ The default is "silent". Note that with "silent!", unlike
`:redir`, error messages are dropped. When using an external
command the screen may be messed up, use `system()` instead.
*E930*
@@ -4032,10 +4032,10 @@ get({dict}, {key} [, {default}])
get({func}, {what})
Get an item with from Funcref {func}. Possible values for
{what} are:
- 'name' The function name
- 'func' The function
- 'dict' The dictionary
- 'args' The list with arguments
+ "name" The function name
+ "func" The function
+ "dict" The dictionary
+ "args" The list with arguments
*getbufinfo()*
getbufinfo([{expr}])
@@ -7729,7 +7729,7 @@ taglist({expr}) *taglist()*
may appear, they give the name of the entity the tag is
contained in.
- The ex-command 'cmd' can be either an ex search pattern, a
+ The ex-command "cmd" can be either an ex search pattern, a
line number or a line number followed by a byte number.
If there are no matching tags, then an empty list is returned.
diff --git a/runtime/doc/fold.txt b/runtime/doc/fold.txt
--- a/runtime/doc/fold.txt
+++ b/runtime/doc/fold.txt
@@ -64,7 +64,7 @@ whichever is lower. These are empty or
with a character in 'foldignore'. White space is skipped before checking for
characters in 'foldignore'. For C use "#" to ignore preprocessor lines.
-When you want to ignore lines in another way, use the 'expr' method. The
+When you want to ignore lines in another way, use the "expr" method. The
|indent()| function can be used in 'foldexpr' to get the indent of a line.
diff --git a/runtime/doc/hangulin.txt b/runtime/doc/hangulin.txt
--- a/runtime/doc/hangulin.txt
+++ b/runtime/doc/hangulin.txt
@@ -81,8 +81,8 @@ And there should be no ':set guifont'.
':set guifontset'. It means VIM runs without fontset supporting.
So, you can see only English. Hangul does not be correctly displayed.
-After 'fontset' feature is enabled, VIM does not allow using english
-font only in 'font' setting for syntax.
+After "fontset" feature is enabled, VIM does not allow using english
+font only in "font" setting for syntax.
For example, if you use >
:set guifontset=eng_font,your_font
in your .gvimrc, then you should do for syntax >
diff --git a/runtime/doc/helphelp.txt b/runtime/doc/helphelp.txt
--- a/runtime/doc/helphelp.txt
+++ b/runtime/doc/helphelp.txt
@@ -314,7 +314,7 @@ the applicable Vim version. The last fi
date of the file. Each field is separated by a tab.
At the bottom of the help file, place a Vim modeline to set the 'textwidth'
-and 'tabstop' options and the 'filetype' to 'help'. Never set a global option
+and 'tabstop' options and the 'filetype' to "help". Never set a global option
in such a modeline, that can have consequences undesired by whoever reads that
help.
diff --git a/runtime/doc/if_pyth.txt b/runtime/doc/if_pyth.txt
--- a/runtime/doc/if_pyth.txt
+++ b/runtime/doc/if_pyth.txt
@@ -174,8 +174,8 @@ vim.eval(str) *python-eval*
:py tagList = vim.eval('taglist("eval_expr")')
< The latter will return a python list of python dicts, for instance:
- [{'cmd': '/^eval_expr(arg, nextcmd)$/', 'static': 0, 'name':
- 'eval_expr', 'kind': 'f', 'filename': './src/eval.c'}]
+ [{'cmd': '/^eval_expr(arg, nextcmd)$/', 'static': 0, 'name': ~
+ 'eval_expr', 'kind': 'f', 'filename': './src/eval.c'}] ~
vim.bindeval(str) *python-bindeval*
Like |python-eval|, but returns special objects described in
@@ -867,7 +867,7 @@ When compiled
Re: How to do block pasting?
Hi hiwa, 2017年1月4日水曜日 7時54分38秒 UTC+9 hiwa: > Oh Ben, you are right. > > This morning I tried to do THE same task by using ONLY vim key commands like > [h][j][k][l] for cursor movement, then I got the perfect desired result i.e. > a vertical pasting. The lesson I may have learned is "don't use mouse for > cursor movement for gvim rectangular operations", and, "You only should use > those venerable vim key commands". > > I prefer an appropriate set of menu items and mouse operations, though. Gvim > must be a GUIed vim. See ":help gui-mouse-select". It says "quadruple clicking makes it rectangular block-wise." Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: default.vim getting sourced even when vimrc is present
Hi Karthick, 2016/11/7 Mon 22:24:03 UTC+9 Karthick wrote: > Hello all, > > > I just installed the 80-069 version of the MS-Windows Vim installer. I see > the scrolloff option is being set to "5" due to defaults.vim getting sourced. (snip) > In my case, $VIM/_vimrc file *is* present, still defaults.vim is getting > sourced. > > > Maybe even more strangely, defaults.vim is getting sourced even if I do a, > > :let skip_defaults_vim=1 > In the last line of my $VIM/_vimrc file Don't you source vimrc_example.vim from your _vimrc file? If so it might happen, because vimrc_example.vim sources defaults.vim. In that case, setting skip_defaults_vim in the last line has no meaning, because it is already sourced. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows installation questions
Hi, 2016/10/5 Wed 5:43:55 UTC+9 Ritmo2k wrote: > On Tuesday, October 4, 2016 at 1:00:44 PM UTC-6, Ben Fritz wrote: > > Is something missing from the official nightly installers? > > Hi Ben, > I never knew the project was officially producing x64 binaries on github. > I have switched over to them (and I noticed they already bundle diff.exe). > > I would like to use a MSI to make deployments easier at our shop. Its much > easier to schedule install/removal/updates with an MSI. So that being the > case, building an MSI that uses a CA to execute install.exe doesn't really > save me much, hence the reason I was hoping to understand what exactly is > done by the switches. You can check the function RegisterMe() in src/if_ole.cpp. It writes some data to the registry and calls RegisterTypeLib() API. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is vim supporting 24 bit colors?
Hi, 2016/9/23 Fri 16:04:25 UTC+9 Christian Brabandt wrote: > Hi KiYugadgeter! > > On Do, 22 Sep 2016, KiYugadgeter wrote: > > > Is vim supporting 24 bit colors? > > Yes, see :h 'termguicolors' > > > I want to use vim on windows10 bash. > > > > windows 10 bash is supporting 24bit colors on beta version. > > Are you sure? See this: https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/ Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vimrc cannot be load
Hi ibear, 2016/9/23 Fri 22:46:50 UTC+9 Christian Brabandt wrote: > Hi ibear! > > On Fr, 23 Sep 2016, ibear wrote: > > > I build a x64 version of vim from git, copy the new gvim.exe to > > "d:\vim\vim80"(this folder is renamed from my old vim74), create a vimrc > > of "d:\vim\vim80\vimrc", run gvim.exe, but vimrc can not be load! > > > > But I rename "d:\vim\vim80" to "d:\vim\vim8", run gvim.exe again, now vimrc > > can be load. > > > > Does anybody have meeted the same problem? > > In gvim do :version and check the path of 1st-3rd user vimrc. Those > should be used. And also try `:echo $VIM` in gvim. Then, as I wrote in GitHub, read the help (:help $VIM). Important part is here: https://github.com/vim/vim/blob/50ba526fbf3e9e5e0e6b0b3086a4d5df581ebc7e/runtime/doc/starting.txt#L1132-L1133 Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Missing symbols file (pdb) for current gvim windows build (gvim74-1024.exe)
Hi, 2016/5/13 Fri 4:59:07 UTC+9 Bram Moolenaar wrote: > Gabriele Fava wrote; > > > Hello, I was looking for the symbols file of the latest gvim windows > > build published on the ftp site > > (ftp://ftp.vim.org/pub/vim/pc/gvim74-1024.exe). > > It's not in ftp.vim.org/pub/vim/pc, is it somewhere else? > > Sorry, no. Perhaps another Windows build has it? Oh, our vim/vim-win32-installer also don't have pdb files. https://github.com/vim/vim-win32-installer I totally forgot about that. Maybe we should add them... Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: E254?
Hi, 2016/4/27 Wed 2:03:44 UTC+9 Christian Brabandt wrote: > Hi Meino.Cramer! > > On Di, 26 Apr 2016, meino.cra...@gmx.de wrote: > > > Christian Brabandt <cbli...@256bit.org> [16-04-26 17:03]: > > > Am 2016-04-26 05:10, schrieb meino.cra...@gmx.de: > > > >Hi, > > > >with the updates of yesterday (or the day before?) I got a lot of this > > > >output, which wasn't there before: > > > >line 16: > > > >E254: Cannot allocate color none > > > >E254: Cannot allocate color none > > > >line 17: > > > >E254: Cannot allocate color none > > > >line 18: > > > >E254: Cannot allocate color none > > > > > > > > > >E254: Cannot allocate color none > > > >line 48: > > > >E254: Cannot allocate color none > > > >I didn't changed .vimrc and Co. ... > > > >After spiiting out this, vim works fine... > > > >How can I fix it? > > > > > > Do you use the new guicolor setting? What colorscheme are you using? > > > Is the file rgb.txt in your $VIMRUNTIME available? > > > > > > Best, > > > Christian > > > -- > > > -- > > > You received this message from the "vim_use" 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_use" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to vim_use+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > Hi Christian, > > > > new gui-settings??? ;) > > You are joking, man...vim? ***GUI***? > > No way! > > I am using vim on the console! > > (all this with a big smile in my face! 8) > > Well, you might want to read :h 'guicolors' if you updated your Vim > recently. You might want to tell us your version output additionally. > Also please check, that a file $VIMRUNTIME/rgb.txt is available. If you > previously compiled and installed your vim yourself, this file was not > installed, but it is needed by the guicolors feature. You might want to > check, if the 'guicolors' option has been set and where it is set using > :verbose set guicolors? (it is not set by default) The option name 'guicolors' is totally confusing. It should be renamed to 'termguicolors' or something else as discussed in this thread: https://groups.google.com/d/topic/vim_dev/q2LuLFueRbE/discussion > > Or in more settled words: > > No, I am not using gui-settings as far as I know. > > > > The colorscheme is a modificated one...I have attached it to > > this posting... > > If it colornames such as DarkMagenta or Cornsilk and you are using Vim > with 'guicolors' set in the console and you are missing > $VIMRUNTIME/rgb.txt you will see such warnings. I saw the E254 error even without setting 'guicolors', when I used +termtruecolor enabled vim and rgb.txt was not installed. Colorscheme was desert. Installing rgb.txt should fix the E254 error. However, I think it's better to avoid E254 when 'guicolors' is not set and rgb.txt is not installed. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: strikethrough text in gvim
Hi, 2016/4/26 Tue 15:12:51 UTC+9 Christian Brabandt wrote: > Hi Ken! > > On Mo, 25 Apr 2016, Ken Takata wrote: > > > Hi Christian, > > > > 2016/4/26 Tue 1:53:17 UTC+9 Christian Brabandt wrote: > > > Hi Ken! > > > > > > On Do, 10 Mär 2016, Ken Takata wrote: > > > > > > > Hi, > > > > > > > > 2013/10/12 Sat 23:25:06 UTC+9 Ken Takata wrote: > > > > > Hi Christian, > > > > > > > > > > 2013/07/31 Wed 4:56:39 UTC+9 Christian Brabandt wrote: > > > > > > Attached is a patch to try out. It seems to work for me with GTK > > > > > > and Motif Gui. I am a Unix gui and can't say for sure the code for > > > > > > Windows and Mac is actually correct and works, though. > > > > > > > > > > I checked your patch on Windows. It works fine. I checked it with > > > > > the following process: > > > > > > > > > > > gvim -N foo.html > > > > > :syn enable :syn region htmlStrike start="<del\>" end=""me=e-6 > > > > > contains=@htmlTop :hi def htmlStrike term=strikethrough > > > > > cterm=strikethrough gui=strikethrough ifoo > > > > > > > > > > > > > > > > Secondly, I am unsure about the changes to term.c and term.h I > > > > > > don't know, if these changes are actually needed, so I simply took > > > > > > the undercurl code as an example and changed it so it would fit > > > > > > for strikethrough. > > > > > > > > > > I think it is better to add term cap entries. Currently, termcap > > > > > doesn't support strikethrough attributes, so we have to use our own > > > > > attribute names. (E.g. 't_Ts'/'t_Te' or 't_SS'/'t_SE') I also think > > > > > that a new flag (e.g. 't' or 'S') should be added in the 'highlight' > > > > > option. > > > > > > > > > > I and Hayaki Saito updated your patch to add them. After applying > > > > > this patch and setting escape sequences properly, > > > > > > > > > > let _Ts="\e[9m" let _Te="\e[29m" > > > > > > > > > > some terminals (*) will show strikethrough lines. > > > > > > > > > > (*) RLogin: http://nanno.dip.jp/softlib/man/rlogin/ (Japanese) > > > > > pangoterm: https://launchpad.net/pangoterm/ > > > > > > > > I found that this patch cannot be used for GTK3, but I don't know how > > > > to fix it. I hope someone can fix this. > > > > > > Seems like you did fix this with the latest version here: > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/9e19c0c57c4812557e7750629de02986249a5246/strikethrough.diff?fileviewer=file-view-default > > > > I made a fix but I haven't tested it yet. > > > > > Seems to work fine for me. Bram, I think this might be a nice addition > > > for vim 8. > > > > Thank you for checking. Does it work both with GTK2 and GTK3? > > , > | :syn region htmlStrike start=""ms=s+5 end=""me=e-6 > | :hi def htmlStrike gui=strikethrough term=strikethrough > | ifoobar > ` > > This works in GTK2 and GTK3 gui but I couldn't check the terminal, since > I don't have a terminal that has this capability Thank you for checking. Now I check with Win32 GUI and also with terminal (mintty). Both works fine. As I wrote before, I have to set the following esc sequences: let _Ts="\e[9m" let _Te="\e[29m" Hayaki Saito told me that xterm (with patch#305) also supported these sequences. Is it better to set these sequences as default when $TERM is xterm? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Capture columns nummers of matches ending with double byte chars
(Cc-ing to vim_dev)
Hi,
2016/4/26 Tue 15:00:33 UTC+9 rameo wrote:
> >
> > It is much better to download sources from https://github.com/vim/vim.
> >
>
> Found it:
> https://github.com/vim/vim-win32-installer/releases
>
> However...
> Tried:
> gvim_7.4.1782_x86.exe
> gvim_7.4.1786_x86.exe
>
> Both gives an error:
> Error detected while processing vimrc_example.vim
> line 114:
> E919: Directory not found in 'packpath': "pack/*/opt/matchit"
Oops!
We should have updated the nsis script when we turned some scripts into
packages.
Attached patch should fix the problem.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 7dd3dce73b35f7846b891f59a2215cc59ffb0557
diff --git a/nsis/gvim.nsi b/nsis/gvim.nsi
--- a/nsis/gvim.nsi
+++ b/nsis/gvim.nsi
@@ -215,6 +215,28 @@ Section "Vim executables and runtime fil
SetOutPath $0\macros
File ${VIMRT}\macros\*.*
+ SetOutPath $0\pack\dist\opt\dvorak\dvorak
+ File ${VIMRT}\pack\dist\opt\dvorak\dvorak\*.*
+ SetOutPath $0\pack\dist\opt\dvorak\plugin
+ File ${VIMRT}\pack\dist\opt\dvorak\plugin\*.*
+
+ SetOutPath $0\pack\dist\opt\editexisting\plugin
+ File ${VIMRT}\pack\dist\opt\editexisting\plugin\*.*
+
+ SetOutPath $0\pack\dist\opt\justify\plugin
+ File ${VIMRT}\pack\dist\opt\justify\plugin\*.*
+
+ SetOutPath $0\pack\dist\opt\matchit\doc
+ File ${VIMRT}\pack\dist\opt\matchit\doc\*.*
+ SetOutPath $0\pack\dist\opt\matchit\plugin
+ File ${VIMRT}\pack\dist\opt\matchit\plugin\*.*
+
+ SetOutPath $0\pack\dist\opt\shellmenu\plugin
+ File ${VIMRT}\pack\dist\opt\shellmenu\plugin\*.*
+
+ SetOutPath $0\pack\dist\opt\swapmouse\plugin
+ File ${VIMRT}\pack\dist\opt\swapmouse\plugin\*.*
+
SetOutPath $0\plugin
File ${VIMRT}\plugin\*.*
Re: strikethrough text in gvim
Hi Christian, 2016/4/26 Tue 1:53:17 UTC+9 Christian Brabandt wrote: > Hi Ken! > > On Do, 10 Mär 2016, Ken Takata wrote: > > > Hi, > > > > 2013/10/12 Sat 23:25:06 UTC+9 Ken Takata wrote: > > > Hi Christian, > > > > > > 2013/07/31 Wed 4:56:39 UTC+9 Christian Brabandt wrote: > > > > Attached is a patch to try out. It seems to work for me with GTK > > > > and Motif Gui. I am a Unix gui and can't say for sure the code for > > > > Windows and Mac is actually correct and works, though. > > > > > > I checked your patch on Windows. It works fine. I checked it with > > > the following process: > > > > > > > gvim -N foo.html > > > :syn enable :syn region htmlStrike start="<del\>" end=""me=e-6 > > > contains=@htmlTop :hi def htmlStrike term=strikethrough > > > cterm=strikethrough gui=strikethrough ifoo > > > > > > > > > > Secondly, I am unsure about the changes to term.c and term.h I > > > > don't know, if these changes are actually needed, so I simply took > > > > the undercurl code as an example and changed it so it would fit > > > > for strikethrough. > > > > > > I think it is better to add term cap entries. Currently, termcap > > > doesn't support strikethrough attributes, so we have to use our own > > > attribute names. (E.g. 't_Ts'/'t_Te' or 't_SS'/'t_SE') I also think > > > that a new flag (e.g. 't' or 'S') should be added in the 'highlight' > > > option. > > > > > > I and Hayaki Saito updated your patch to add them. After applying > > > this patch and setting escape sequences properly, > > > > > > let _Ts="\e[9m" let _Te="\e[29m" > > > > > > some terminals (*) will show strikethrough lines. > > > > > > (*) RLogin: http://nanno.dip.jp/softlib/man/rlogin/ (Japanese) > > > pangoterm: https://launchpad.net/pangoterm/ > > > > I found that this patch cannot be used for GTK3, but I don't know how > > to fix it. I hope someone can fix this. > > Seems like you did fix this with the latest version here: > https://bitbucket.org/k_takata/vim-ktakata-mq/src/9e19c0c57c4812557e7750629de02986249a5246/strikethrough.diff?fileviewer=file-view-default I made a fix but I haven't tested it yet. > Seems to work fine for me. Bram, I think this might be a nice addition > for vim 8. Thank you for checking. Does it work both with GTK2 and GTK3? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Capture columns nummers of matches ending with double byte chars
Hi rameo, 2016/4/23 Sat 21:37:15 UTC+9 rameo wrote: > Searchpos() doesn't return the right end value of a match if the match end > with a double byte character (èéòìùá...). (encoding utf-8) > Isn't this a bug You might misunderstand the spec of searchpos(). When the 'e' flag is specified, the cursor moves to the last character of the match and searchpos() returns the position of the cursor. It means that the returned value is a byte index of start of the last character, not the end of the character. > The last few years I used match/matchend then I noted that it did not capture > correctly double byte characters within the string. Can you show an example? match()/matchend() return a byte offset, not a character count. FYI, matchstrpos() can be used to get both start and end position after 7.4.1685. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: strikethrough text in gvim
Hi, 2013/10/12 Sat 23:25:06 UTC+9 Ken Takata wrote: > Hi Christian, > > 2013/07/31 Wed 4:56:39 UTC+9 Christian Brabandt wrote: > > Attached is a patch to try out. It seems to work for me with GTK and > > Motif Gui. I am a Unix gui and can't say for sure the code for Windows > > and Mac is actually correct and works, though. > > I checked your patch on Windows. It works fine. > I checked it with the following process: > > > gvim -N foo.html > :syn enable > :syn region htmlStrike start="<del\>" end=""me=e-6 contains=@htmlTop > :hi def htmlStrike term=strikethrough cterm=strikethrough gui=strikethrough > ifoo > > > > Secondly, I am unsure about the changes to term.c and term.h > > I don't know, if these changes are actually needed, so I simply took the > > undercurl code as an example and changed it so it would fit for > > strikethrough. > > I think it is better to add term cap entries. Currently, termcap doesn't > support strikethrough attributes, so we have to use our own attribute names. > (E.g. 't_Ts'/'t_Te' or 't_SS'/'t_SE') > I also think that a new flag (e.g. 't' or 'S') should be added in the > 'highlight' option. > > I and Hayaki Saito updated your patch to add them. After applying this patch > and setting escape sequences properly, > > let _Ts="\e[9m" > let _Te="\e[29m" > > some terminals (*) will show strikethrough lines. > > (*) > RLogin: http://nanno.dip.jp/softlib/man/rlogin/ (Japanese) > pangoterm: https://launchpad.net/pangoterm/ I found that this patch cannot be used for GTK3, but I don't know how to fix it. I hope someone can fix this. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi, 2016/2/28 Sun 2:18:54 UTC+9 Alexas Chee wrote: > Yes, the _vimrc is the same one. > > $HOME is different, though. The Windows one is C:\user\myname; the mingw64 > one is msys2/home/myname. > > But does $HOME matter in this case? Vim will load .vimrc from $HOME. So you might get different results if the .vimrc are different. (E.g. when you set different value in g:vimsyn_embed.) Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: big with windows codepage 65001 (UTF-8)
Hi Ben, 2016/2/27 Sat 9:05:32 UTC+9 Ben Fritz wrote: > On Friday, February 26, 2016 at 4:29:32 PM UTC-6, Ken Takata wrote: > > However recent vim.exe doesn't use 'termencoding'. > > > > Woah, when did that happen? It's 7.4.852. Now vim.exe uses Unicode API. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: gvim acts differently when invoked from mingw64 and ms-windows
Hi, 2016/2/26 Fri 17:16:41 UTC+9 Alexas Chee wrote: > I just built gvim (+tcl) with patch 1421 on mingw64. > I changed file syntax/vim.vim to highlight tcl embeded in vim script (line > 621): > let g:vimsyn_embed= "lmpPrt" > > When invoked directly from ms-windows, it acts just as expected; > but when invoked from mingw bash, it fails to highlight tcl as if vim.vim was > unchanged. > > So I did :syntax in both case and diffed the outputs. All differences are > related to tcl. Some environment variables might be different. How about $HOME? Does the same .vimrc loaded? Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: big with windows codepage 65001 (UTF-8)
Hi, 2016/2/26 Fri 20:45:38 UTC+9 klo uo wrote: > Hi, > > > on Windows I've set my default code page to 65001 (UTF-8) > > > This is how vim looks like: > > > > > > If I change code page to some other, like `chcp 866` if works as expected. Your vim.exe seems old. Try gvim74-1024.exe from http://www.vim.org/download.php#pc . Old vim.exe needs to be set 'termencoding' properly when you change the codepage (or 'encoding'). However recent vim.exe doesn't use 'termencoding'. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re:Re: Blowfish[2] failed to encrypt big text file of 24MB
Hi,
2015/2/14 Sat 6:04:00 UTC+9 Bram Moolenaar wrote:
> Ben Fritz wrote:
>
> > On Friday, February 13, 2015 at 4:16:01 AM UTC-6, might1 wrote:
> > > At 2015-02-13 18:00:32，"might1" <mig...@126.com> wrote:
> > > > Right now, I just tried vim7.4 downloaded from www.vim.org.
> > > According to your way, I tried in commanld line 'vim -u NONE -N
> > > test.txt' and 'gvim -u NONE -N test.txt' to encrypt with blowfish
> > > method, both failed. The resulting files all growed to 113MB. Really
> > > strange! No error jumped out.
> > >
> > > Do you need I attach the resulting encrypted file whose size remains
> > > 113MB after max compression?
> > >
> >
> > Actually, attaching the already encrypted file is pretty much useless.
> >
> > I experimented some, with the attached toy input file (compressed with
> > 7-zip to avoid a huge attachment), and found that the issue seems to be
> > related to writing *new* files somehow.
> >
> > If I create an encrypted output file as follows, everything works fine:
> >
> > :e encrypt_in.txt
> > :saveas encrypt_blowfish2.txt
> > :X
> > password
> > password
> > :w
> >
> > However, if I encrypt as follows, I see the E381 error repeated a bunch of
> > times, and Vim seems to hang if I quit that error and try the password
> > again and write, presumably creating that giant file the OP mentioned:
> >
> > :r encrypt_in.txt
> > ggdd
> > :X
> > password
> > password
> > :w encrypt_blowfish2.txt
> >
> > Oddly enough, this also fails:
> >
> > :r encrypt_in.txt
> > ggdd
> > :w encrypt_blowfish2.txt
> > :X
> > password
> > password
> > :w
> >
> > But this succeeds (after a really long time):
> >
> > :r encrypt_in.txt
> > ggdd
> > :w encrypt_blowfish2.txt
> > :e
> > :X
> > password
> > password
> > :w
> >
> > It seems to be related to encrypting the swapfile for the new file. This
> > fails:
> >
> > :set swapfile noundofile
> > :r encrypt_in.txt
> > ggdd
> > :X
> > password
> > password
> > :w encrypt_blowfish2.txt
> >
> > But this succeeds:
> >
> > :set noswapfile undofile
> > :r encrypt_in.txt
> > ggdd
> > :X
> > password
> > password
> > :w encrypt_blowfish2.txt
> >
> > Using the following Vim version on Windows 7:
> >
> > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb 4 2015 10:16:41)
> > MS-Windows 64-bit GUI version with OLE support
> > Included patches: 1-608
>
> [...]
>
> Since it works fine on Linux, could it be related to "long" not being
> able to store a pointer? It's a common problem for porting a C program
> to Windows.
Perhaps I found a fix for this.
--- a/src/memfile.c
+++ b/src/memfile.c
@@ -1033,7 +1033,7 @@
#ifdef FEAT_CRYPT
/* Decrypt if 'key' is set and this is a data block. */
-if (*mfp->mf_buffer->b_p_key != NUL)
+if (*mfp->mf_buffer->b_p_key != NUL || mfp->mf_old_key != NULL)
ml_decrypt_data(mfp, hp->bh_data, offset, size);
#endif
@@ -1136,7 +1136,7 @@
#ifdef FEAT_CRYPT
/* Encrypt if 'key' is set and this is a data block. */
-if (*mfp->mf_buffer->b_p_key != NUL)
+if (*mfp->mf_buffer->b_p_key != NUL || mfp->mf_old_key != NULL)
{
data = ml_encrypt_data(mfp, data, offset, size);
if (data == NULL)
I checked this only on Windows (but not well).
I hope someone check this more deeply.
I wonder why the problem doesn't occur on Linux.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blowfish[2] failed to encrypt big text file of 24MB
Hi Christian, 2015/12/19 Sat 4:24:00 UTC+9 Christian Brabandt wrote: > On Fr, 18 Dez 2015, Ken Takata wrote: > > > Perhaps I found a fix for this. > > Wasn't this fixes with 7.4.730? Unfortunately, it wasn't. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re:Re: Blowfish[2] failed to encrypt big text file of 24MB
Hi Bram, 2015/12/19 Sat 4:47:19 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > 2015/2/14 Sat 6:04:00 UTC+9 Bram Moolenaar wrote: > > > Ben Fritz wrote: > > > > > > > On Friday, February 13, 2015 at 4:16:01 AM UTC-6, might1 wrote: > > > > > At 2015-02-13 18:00:32，"might1" <mig...@126.com> wrote: > > > > > > Right now, I just tried vim7.4 downloaded from www.vim.org. > > > > > According to your way, I tried in commanld line 'vim -u NONE -N > > > > > test.txt' and 'gvim -u NONE -N test.txt' to encrypt with blowfish > > > > > method, both failed. The resulting files all growed to 113MB. Really > > > > > strange! No error jumped out. > > > > > > > > > > Do you need I attach the resulting encrypted file whose size remains > > > > > 113MB after max compression? > > > > > > > > > > > > > Actually, attaching the already encrypted file is pretty much useless. > > > > > > > > I experimented some, with the attached toy input file (compressed with > > > > 7-zip to avoid a huge attachment), and found that the issue seems to be > > > > related to writing *new* files somehow. > > > > > > > > If I create an encrypted output file as follows, everything works fine: > > > > > > > > :e encrypt_in.txt > > > > :saveas encrypt_blowfish2.txt > > > > :X > > > > password > > > > password > > > > :w > > > > > > > > However, if I encrypt as follows, I see the E381 error repeated a bunch > > > > of times, and Vim seems to hang if I quit that error and try the > > > > password again and write, presumably creating that giant file the OP > > > > mentioned: > > > > > > > > :r encrypt_in.txt > > > > ggdd > > > > :X > > > > password > > > > password > > > > :w encrypt_blowfish2.txt > > > > > > > > Oddly enough, this also fails: > > > > > > > > :r encrypt_in.txt > > > > ggdd > > > > :w encrypt_blowfish2.txt > > > > :X > > > > password > > > > password > > > > :w > > > > > > > > But this succeeds (after a really long time): > > > > > > > > :r encrypt_in.txt > > > > ggdd > > > > :w encrypt_blowfish2.txt > > > > :e > > > > :X > > > > password > > > > password > > > > :w > > > > > > > > It seems to be related to encrypting the swapfile for the new file. > > > > This fails: > > > > > > > > :set swapfile noundofile > > > > :r encrypt_in.txt > > > > ggdd > > > > :X > > > > password > > > > password > > > > :w encrypt_blowfish2.txt > > > > > > > > But this succeeds: > > > > > > > > :set noswapfile undofile > > > > :r encrypt_in.txt > > > > ggdd > > > > :X > > > > password > > > > password > > > > :w encrypt_blowfish2.txt > > > > > > > > Using the following Vim version on Windows 7: > > > > > > > > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb 4 2015 10:16:41) > > > > MS-Windows 64-bit GUI version with OLE support > > > > Included patches: 1-608 > > > > > > [...] > > > > > > Since it works fine on Linux, could it be related to "long" not being > > > able to store a pointer? It's a common problem for porting a C program > > > to Windows. > > It's most likely related to the memory limit, causing Vim to use the > swap file. > > > Perhaps I found a fix for this. > > Thanks! Although I think only the first part matters, when writing the > old key isn't used. Ah, you are right! I confirmed that the second part was not needed. Regards, Ken Takata -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: move tabs using mouse in gvim
Hi raju, 2015/1/25 Sun 11:38:42 UTC+9 kamaraju kusumanchi wrote: I see that you are the original author of the patch and proposed it more than a year ago and was also accepted by Bram Moolenaar. Do you know why it is not yet included in the official version of gvim? Because there are already too many items in the todo list, and priority of new features are lower than bug fixes. Fortunately, the priority of this patch becomes a little bit higher. https://code.google.com/p/vim/source/diff?spec=svn435956324539eea89a17f0409a15b588973c0cb9r=435956324539eea89a17f0409a15b588973c0cb9format=sidepath=/runtime/doc/todo.txt (Line 433 to Line 156) I hope this patch to be included in a few months. Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/5/12 Mon 22:17:05 UTC+9 Ken Takata wrote: Hi Bram, 2014/5/10 Sat 20:23:47 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/4/29 Tue 22:04:23 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/4/17 Thu 0:58:01 UTC+9 Adrian wrote: 'm helping another user open a large, 3Gb, file. The standard windows editors balk, so I recommended VIM. Unfortunately, even vim crashes after scrolling some amount. For instance, he can't go straight to the end of file. The work station is Windows 7, 64 bit, with 32Gb of RAM. Are there any settings to modify to make vim more stable with large files, or is there some Windows performance limitation and just out of luck? There is a related item in the todo.txt: | Win64: Seek error in swap file for a very big file (3 Gbyte). Check storing | pointer in long and seek offset in 64 bit var. I wrote some patches to fix this, but they seem to be still unstable. https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/support-largefiles-on-windows.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/use-stat_T.patch?at=default Did you make progress on this? I wrote still unstable, but it seems that it was my mistake. Now I think that the patches are OK. Sometimes Vim (without the patches) freezes when I open a very big file (about 2 GB) and scroll up and down using scroll bar. After applying the patches, Vim sometimes takes very long time for scrolling up and down, but it wasn't a freeze. (I misunderstood that.) BTW, I found that 32-bit Vim couldn't handle a very big file properly when :set noswapfile. In my understanding, this is an expected(?) behavior because Vim tries to load the whole file into the memory when 'swapfile' is off, and a 32-bit program can't allocate larger than 2-GiB memory. (Actually, a 32-bit program can get 3-GiB user space if /LARGEADDRESSAWARE option is specified for 'link'.) Can we also add some tests to verify the fix? I'm thinking what is the best way to test this. Something like this? Make sure that a line break is 1 byte. :set ff=unix :set undolevels=-1 Input 99 'A's. The line becomes 100 bytes including a line break. 99iAEsc yy Put 19,999,999 times. The file becomes 2,000,000,000 bytes. 1999p Moving around in the file randomly. G 10% 90% 50% gg ... Edit some lines. ... Extract some lines and write them to test.out. ... Although it would be good to test this way, I think it should not be part of make test, since it will probably fail on smaller systems. Perhaps we should make a make bigtest target, for more testing. I agree. Generally, I think we need to test that the patch doesn't break anything for normal editing. But perhaps the tests we already have are sufficient for that. If you look at your patch, are there any commands that would not be used by the existing tests? I think that the existing tests cover almost all part, but maybe they doesn't cover the following functions, commands and features: * getfsize(), getfperm(), getftime(), getftype() * :checktime * +cscope, +netbeans_intg BTW, I have updated the patch: https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/support-largefiles-on-windows.patch?at=default (same as before) https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/use-stat_T.patch?at=default * Define HAVE_STAT64 in vim.h and use it in os_mswin.c. * There was no need to use stat_T in os_unix.c. stat_T should be used with mch_stat(). After 7.4.399, support-largefiles-on-windows.patch couldn't be applied because of conflicts. So I have updated the patch. The latest patches are: https://bitbucket.org/k_takata/vim-ktakata-mq/src/be6f89cd8a129025d2a456eb60b946265d90dffe/support-largefiles-on-windows.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/be6f89cd8a129025d2a456eb60b946265d90dffe/use-stat_T.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/be6f89cd8a129025d2a456eb60b946265d90dffe/add-stat-test.patch?at=default Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/5/14 Wed 23:19:38 UTC+9 Ken Takata wrote: Hi Bram, 2014/5/13 Tue 20:12:59 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/5/13 Tue 3:40:37 UTC+9 Bram Moolenaar wrote: So is the patch now ready to be included, or did you still have a problem to fix? I think it's ready. I don't see any regressions with the patch (at least in my use cases). Updating the tests is another todo item. Well, it's better to have tests before including it. The tests might find a flaw. OK, I wrote very simple tests for getfsize(), getfperm(), getftime(), getftype() and :checktime. https://bitbucket.org/k_takata/vim-ktakata-mq/src/09e276a96d721ded06d8a140e730638ffdfb18ca/add-stat-test.patch I have updated the tests for 7.4.315. (Just renamed from test107 to test108.) https://bitbucket.org/k_takata/vim-ktakata-mq/src/tip/add-stat-test.patch Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/5/13 Tue 20:12:59 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/5/13 Tue 3:40:37 UTC+9 Bram Moolenaar wrote: So is the patch now ready to be included, or did you still have a problem to fix? I think it's ready. I don't see any regressions with the patch (at least in my use cases). Updating the tests is another todo item. Well, it's better to have tests before including it. The tests might find a flaw. OK, I wrote very simple tests for getfsize(), getfperm(), getftime(), getftype() and :checktime. https://bitbucket.org/k_takata/vim-ktakata-mq/src/09e276a96d721ded06d8a140e730638ffdfb18ca/add-stat-test.patch Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/5/10 Sat 20:23:47 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/4/29 Tue 22:04:23 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/4/17 Thu 0:58:01 UTC+9 Adrian wrote: 'm helping another user open a large, 3Gb, file. The standard windows editors balk, so I recommended VIM. Unfortunately, even vim crashes after scrolling some amount. For instance, he can't go straight to the end of file. The work station is Windows 7, 64 bit, with 32Gb of RAM. Are there any settings to modify to make vim more stable with large files, or is there some Windows performance limitation and just out of luck? There is a related item in the todo.txt: | Win64: Seek error in swap file for a very big file (3 Gbyte). Check storing | pointer in long and seek offset in 64 bit var. I wrote some patches to fix this, but they seem to be still unstable. https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/support-largefiles-on-windows.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/use-stat_T.patch?at=default Did you make progress on this? I wrote still unstable, but it seems that it was my mistake. Now I think that the patches are OK. Sometimes Vim (without the patches) freezes when I open a very big file (about 2 GB) and scroll up and down using scroll bar. After applying the patches, Vim sometimes takes very long time for scrolling up and down, but it wasn't a freeze. (I misunderstood that.) BTW, I found that 32-bit Vim couldn't handle a very big file properly when :set noswapfile. In my understanding, this is an expected(?) behavior because Vim tries to load the whole file into the memory when 'swapfile' is off, and a 32-bit program can't allocate larger than 2-GiB memory. (Actually, a 32-bit program can get 3-GiB user space if /LARGEADDRESSAWARE option is specified for 'link'.) Can we also add some tests to verify the fix? I'm thinking what is the best way to test this. Something like this? Make sure that a line break is 1 byte. :set ff=unix :set undolevels=-1 Input 99 'A's. The line becomes 100 bytes including a line break. 99iAEsc yy Put 19,999,999 times. The file becomes 2,000,000,000 bytes. 1999p Moving around in the file randomly. G 10% 90% 50% gg ... Edit some lines. ... Extract some lines and write them to test.out. ... Although it would be good to test this way, I think it should not be part of make test, since it will probably fail on smaller systems. Perhaps we should make a make bigtest target, for more testing. I agree. Generally, I think we need to test that the patch doesn't break anything for normal editing. But perhaps the tests we already have are sufficient for that. If you look at your patch, are there any commands that would not be used by the existing tests? I think that the existing tests cover almost all part, but maybe they doesn't cover the following functions, commands and features: * getfsize(), getfperm(), getftime(), getftype() * :checktime * +cscope, +netbeans_intg BTW, I have updated the patch: https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/support-largefiles-on-windows.patch?at=default (same as before) https://bitbucket.org/k_takata/vim-ktakata-mq/src/1ded06658094d26a5eef3ffe42e5edc94d93f59c/use-stat_T.patch?at=default * Define HAVE_STAT64 in vim.h and use it in os_mswin.c. * There was no need to use stat_T in os_unix.c. stat_T should be used with mch_stat(). Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/5/13 Tue 3:40:37 UTC+9 Bram Moolenaar wrote: So is the patch now ready to be included, or did you still have a problem to fix? I think it's ready. I don't see any regressions with the patch (at least in my use cases). Updating the tests is another todo item. Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi Bram, 2014/4/29 Tue 22:04:23 UTC+9 Bram Moolenaar wrote: Ken Takata wrote: 2014/4/17 Thu 0:58:01 UTC+9 Adrian wrote: 'm helping another user open a large, 3Gb, file. The standard windows editors balk, so I recommended VIM. Unfortunately, even vim crashes after scrolling some amount. For instance, he can't go straight to the end of file. The work station is Windows 7, 64 bit, with 32Gb of RAM. Are there any settings to modify to make vim more stable with large files, or is there some Windows performance limitation and just out of luck? There is a related item in the todo.txt: | Win64: Seek error in swap file for a very big file (3 Gbyte). Check storing | pointer in long and seek offset in 64 bit var. I wrote some patches to fix this, but they seem to be still unstable. https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/support-largefiles-on-windows.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/use-stat_T.patch?at=default Did you make progress on this? I wrote still unstable, but it seems that it was my mistake. Now I think that the patches are OK. Sometimes Vim (without the patches) freezes when I open a very big file (about 2 GB) and scroll up and down using scroll bar. After applying the patches, Vim sometimes takes very long time for scrolling up and down, but it wasn't a freeze. (I misunderstood that.) BTW, I found that 32-bit Vim couldn't handle a very big file properly when :set noswapfile. In my understanding, this is an expected(?) behavior because Vim tries to load the whole file into the memory when 'swapfile' is off, and a 32-bit program can't allocate larger than 2-GiB memory. (Actually, a 32-bit program can get 3-GiB user space if /LARGEADDRESSAWARE option is specified for 'link'.) Can we also add some tests to verify the fix? I'm thinking what is the best way to test this. Something like this? Make sure that a line break is 1 byte. :set ff=unix :set undolevels=-1 Input 99 'A's. The line becomes 100 bytes including a line break. 99iAEsc yy Put 19,999,999 times. The file becomes 2,000,000,000 bytes. 1999p Moving around in the file randomly. G 10% 90% 50% gg ... Edit some lines. ... Extract some lines and write them to test.out. ... Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opening large files?
Hi, 2014/4/17 Thu 0:58:01 UTC+9 Adrian wrote: 'm helping another user open a large, 3Gb, file. The standard windows editors balk, so I recommended VIM. Unfortunately, even vim crashes after scrolling some amount. For instance, he can't go straight to the end of file. The work station is Windows 7, 64 bit, with 32Gb of RAM. Are there any settings to modify to make vim more stable with large files, or is there some Windows performance limitation and just out of luck? There is a related item in the todo.txt: | Win64: Seek error in swap file for a very big file (3 Gbyte). Check storing | pointer in long and seek offset in 64 bit var. I wrote some patches to fix this, but they seem to be still unstable. https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/support-largefiles-on-windows.patch?at=default https://bitbucket.org/k_takata/vim-ktakata-mq/src/192069dac4356c186b89e0451a254599713d2309/use-stat_T.patch?at=default Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Question about integer size and limits
Hi, 2014/1/8 Wed 4:41:07 UTC+9 glts wrote: :h limits says that for maximum line length and max number of lines the number 2147483647 is the hard limit. For range of a number value (and maximum file size), however, it says 2147483647 or more. I see in the typedef for varnumber_T that on modern machines it will be defined as int. Now I wonder, can this ever be more than 2^31-1? Are there any circumstances (compile flags/architectures) where (for example) a Vim number could be greater than 2^31-1? You may find the same discussion at here: https://groups.google.com/d/topic/vim_dev/p8Fl_vJDGy8/discussion Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Vim redraw issue in Xubuntu 13.10 (running inside VMWare Workstation 10)
Hi, 2013/12/30 Mon 11:26:45 UTC+9 Some Developer wrote: It still happens when using gvim -u NONE. Steps to reproduce are easy. Load an HTML file with gvim, enter insert mode and press return a few times in the middle of the file to add new lines. After 2 or 3 new lines have been added the cursor starts overwriting text underneath rather than adding new lines. Exiting out of insert mode and pressing Ctrl-R to refresh the screen redraws everything and the file looks correct again. Do some more editing in insert mode and it screws up again until Ctrl-R is pressed again. I have a feeling this has something to do with GTK+ rather than Vim since the command line version works perfectly with the same file. I think this is related to the following item from the todo.txt: Problem caused by patch 7.3.638: window-open does not update window correctly. Issue 91. How about reverting the patch 7.3.638? Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: strikethrough text in gvim
Hi Christian,
2013/07/31 Wed 4:56:39 UTC+9 Christian Brabandt wrote:
Attached is a patch to try out. It seems to work for me with GTK and
Motif Gui. I am a Unix gui and can't say for sure the code for Windows
and Mac is actually correct and works, though.
I checked your patch on Windows. It works fine.
I checked it with the following process:
gvim -N foo.html
:syn enable
:syn region htmlStrike start=del\ end=/delme=e-6 contains=@htmlTop
:hi def htmlStrike term=strikethrough cterm=strikethrough gui=strikethrough
idelfoo/del
Secondly, I am unsure about the changes to term.c and term.h
I don't know, if these changes are actually needed, so I simply took the
undercurl code as an example and changed it so it would fit for
strikethrough.
I think it is better to add term cap entries. Currently, termcap doesn't
support strikethrough attributes, so we have to use our own attribute names.
(E.g. 't_Ts'/'t_Te' or 't_SS'/'t_SE')
I also think that a new flag (e.g. 't' or 'S') should be added in the
'highlight' option.
I and Hayaki Saito updated your patch to add them. After applying this patch
and setting escape sequences properly,
let t_Ts=\e[9m
let t_Te=\e[29m
some terminals (*) will show strikethrough lines.
(*)
RLogin: http://nanno.dip.jp/softlib/man/rlogin/ (Japanese)
pangoterm: https://launchpad.net/pangoterm/
Regards,
Ken Takata
--
--
You received this message from the vim_use 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_use group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -5881,6 +5881,7 @@
standout 1 if standout
underline 1 if underlined
undercurl 1 if undercurled
+ strike 1 if strikethrough
Example (echoes the color of the syntax item under the
cursor):
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -3927,6 +3927,7 @@
s standout (termcap entry so and se)
u underline (termcap entry us and ue)
c undercurl (termcap entry Cs and Ce)
+ t strikethrough (termcap entry Ts and Te)
n no highlighting
- no highlighting
: use a highlight group
diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt
--- a/runtime/doc/syntax.txt
+++ b/runtime/doc/syntax.txt
@@ -4457,12 +4457,14 @@
*bold* *underline* *undercurl*
*inverse* *italic* *standout*
+ *strikethrough*
term={attr-list} *attr-list* *highlight-term* *E418*
attr-list is a comma separated list (without spaces) of the
following items (in any order):
bold
underline
undercurl not always available
+ strikethrough not always available
reverse
inverse same as reverse
italic
@@ -4472,8 +4474,8 @@
Note that bold can be used here and by using a bold font. They
have the same effect.
undercurl is a curly underline. When undercurl is not possible
- then underline is used. In general undercurl is only available in
- the GUI. The color is set with |highlight-guisp|.
+ then underline is used. In general undercurl and strikethrough
+ is only available in the GUI. The color is set with |highlight-guisp|.
start={term-list}*highlight-start* *E422*
stop={term-list}*term-list* *highlight-stop*
@@ -4631,7 +4633,8 @@
guibg={color-name} *highlight-guibg*
guisp={color-name} *highlight-guisp*
These give the foreground (guifg), background (guibg) and special
- (guisp) color to use in the GUI. guisp is used for undercurl.
+ (guisp) color to use in the GUI. guisp is used for undercurl and
+ strikethrough.
There are a few special names:
NONE no color (transparent)
bg use normal background color
diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -272,8 +272,6 @@
t_ts set window title start (to status line) *t_ts* *'t_ts'*
t_ue underline end *t_ue* *'t_ue'*
t_us underline mode *t_us* *'t_us'*
- t_Ce undercurl end *t_Ce* *'t_Ce'*
- t_Cs undercurl mode *t_Cs* *'t_Cs'*
t_ut clearing uses the current background color *t_ut* *'t_ut'*
t_vb visual bell *t_vb* *'t_vb'*
t_ve cursor visible *t_ve* *'t_ve'*
@@ -285,6 +283,10 @@
t_ZR italics end *t_ZR* *'t_ZR'*
Added by Vim (there are no standard codes for these):
+ t_Ce undercurl end *t_Ce* *'t_Ce'*
+ t_Cs undercurl mode *t_Cs* *'t_Cs'*
+ t_Te strikethrough end*t_Te* *'t_Te'*
+ t_Ts strikethrough mode*t_Ts* *'t_Ts'*
t_IS set icon text start*t_IS* *'t_IS'*
t_IE set icon text end*t_IE* *'t_IE'*
t_WP set window position (Y, X) in pixels *t_WP* *'t_WP'*
diff
Re: Which version of Ruby should I use with Vim 7.4?
Hi Tony, 2013/09/11 Wed 9:21:20 UTC+9 Tony Mechelynck wrote: I'm surprised that your Ruby 1.9.3 has a ruby191.dll with it. If your gvim version needs a msvcrt-ruby192.dll, I would expect it to have been compiled for Ruby 1.9.2. It's not strange because the dll name is based on the API version, and Ruby 1.9.3's API version is 1.9.1. Maybe src\bigvim.bat is wrong. RUBY_VER_LONG should be 1.9.1, not 1.9.2. Additionaly, Ruby 1.9.2 is not maintained any more and it may have security issues. If Ruby 1.9.x is needed, 1.9.3 should be used. --- a/src/bigvim.bat +++ b/src/bigvim.bat @@ -1,5 +1,5 @@ :: command to build big Vim with OLE, Perl, Python, Ruby and Tcl SET VCDIR=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\ SET TOOLDIR=E:\ -%VCDIR%nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=E:\perl514 DYNAMIC_PERL=yes PERL_VER=514 PYTHON=%TOOLDIR%python27 DYNAMIC_PYTHON=yes PYTHON_VER=27 PYTHON3=%TOOLDIR%python32 DYNAMIC_PYTHON3=yes PYTHON3_VER=32 RUBY=%TOOLDIR%ruby192 DYNAMIC_RUBY=yes RUBY_VER=19 RUBY_VER_LONG=1.9.2 TCL=%TOOLDIR%tcl TCL_VER=85 TCL_VER_LONG=8.5 DYNAMIC_TCL=yes %1 IME=yes CSCOPE=yes +%VCDIR%nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=E:\perl514 DYNAMIC_PERL=yes PERL_VER=514 PYTHON=%TOOLDIR%python27 DYNAMIC_PYTHON=yes PYTHON_VER=27 PYTHON3=%TOOLDIR%python32 DYNAMIC_PYTHON3=yes PYTHON3_VER=32 RUBY=%TOOLDIR%ruby193 DYNAMIC_RUBY=yes RUBY_VER=19 RUBY_VER_LONG=1.9.1 TCL=%TOOLDIR%tcl TCL_VER=85 TCL_VER_LONG=8.5 DYNAMIC_TCL=yes %1 IME=yes CSCOPE=yes Regards, Ken Takata -- -- You received this message from the vim_use 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_use group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
