Re: Bug in netrw.vim
That is exactly what I think. In most cast, http server and ftp server doesn't share the same PATH (I mean, http,ftp://somewhere/PATH). Consider about this case, if I tried to edit http://somewhere/~victor/ , and my vim opened ftp://somewhere/~victor/ instead, it's not gonna work at all. There is natrually difference between PROTOCOLs, simple mapping can be wrong. Regards, Victor On 10/7/06, mwoehlke <[EMAIL PROTECTED]> wrote: A.J.Mechelynck wrote: > Charles E Campbell Jr wrote: >> Victor Hsieh wrote: > [...] >>> I know. But I just want to read the html code or so with my favoriate >>> editor ;) I used to do it with vim6. Actually in most case, >>> connecting to ftp://somewhere (when open http://somewhere) is not >>> gonna work. >> >> Not if you don't have the username/password access to the site, 'tis >> true. > [...] > > Also not if there is no FTP server at that address. > > Many FTP servers can be accessed read-only by HTTP; but most HTTP > servers have no FTP counterpart AFAIK. "Many"? Like Victor, I would have said "most". In fact, other than software mirrors (gnu.org and the like) I think it's pretty rare to have a site where http and ftp are mirrors of each other (my web host, for instance, gives me a chroot'd environment when I log into ftp, so even though they have both, they are not symmetric). And most sites (e.g. google.com) don't have ftp at all. Trying ftp://somewhere when http://somewhere doesn't work *might* work 1% of the time. I would say http:// should be treated read-only, since it almost always is, and the few cases where it isn't span a wide variety of /ways/ in which it isn't. -- Matthew "What's Cygwin?" you ask. 'Tis mostly absurd software Concerning hippos.
Re: [macvim] modifiers should be applied to special keys too (patch)
Nicolas Weber wrote: > > Here is one key that doesn't work for me: Shift-Tab. Most notably > > when doing command line completion, where Tab gets the next match > > and Shift-Tab goes to the previous match. > > This is fixed in the attached patch. > > Another key that's still not working is Shift-Space (or Meta-Space). > I'll take care of that later (but that doesn't work in the current > mac vim either). Thanks. I'll try it out. -- hundred-and-one symptoms of being an internet addict: 17. You turn on your intercom when leaving the room so you can hear if new e-mail arrives. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG: syntax region overlaps keyword *sometimes*
Peter Hodge wrote: > Thanks for your help, I had another look and found out you need another syntax > command to reproduce it properly. Here is the revised bug report > > Start vim using > > vim -u NONE > > insert the following test code (note that the 4th line must be indented). > > array($foo) > is_array $foo > is_array($foo) > is_array($foo) > > Apply the following syntax commands: > > syn on > syn keyword Function is_array > syn region r1 matchgroup=Type start=/array(/ end=/)/ > syn keyword Error foo containedin=NOTHING > > You will find that the keyword is_array and region r1 are confused > over how to highlight is_array(...) when it doesn't start at the > beginning of the line, and it has something to do with the 'foo' > keyword having a 'containedin=' option. I can reproduce the problem. Indeed looks like a bug. Removing "containedin=NOTHING" solves it, while it should not change anything. -- hundred-and-one symptoms of being an internet addict: 10. And even your night dreams are in HTML. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG: getwinvar/gettabwinvar returns wrong dictionary w/ patch
Geoff Reedy wrote: > When calling getwinvar or gettabwinvar with an empty string as the > last argument it is supposed to return a dictionary of the values > defined in the specified window. This does not appear to be > documented in the help files but it is documented in a comment within > getwinvar in eval.c. The current code does not switch the window > before calling find_var_in_ht to get the dictionary so it always > returns the dictionary for the current window. The attached patch > switches the notion of curwin for all input instead of just when > retrieving a window local option. Good idea. One thing was wrong though: "curbuf" was obtained from the wrong window, since "curwin" is changed after getting "curbuf". I'll fix that. -- hundred-and-one symptoms of being an internet addict: 13. You refer to going to the bathroom as downloading. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Patch 7.0.120
Patch 7.0.120
Problem:Crash when using CTRL-R = at the command line and entering
"getreg('=')". (James Vega)
Solution: Avoid recursiveness of evaluating the = register.
Files: src/ops.c
*** ../vim-7.0.119/src/ops.cSun Jul 23 22:37:29 2006
--- src/ops.c Fri Oct 6 21:27:40 2006
***
*** 770,775
--- 770,776
{
char_u*expr_copy;
char_u*rv;
+ static intnested = 0;
if (expr_line == NULL)
return NULL;
***
*** 780,786
--- 781,794
if (expr_copy == NULL)
return NULL;
+ /* When we are invoked recursively limit the evaluation to 10 levels.
+ * Then return the string as-is. */
+ if (nested >= 10)
+ return expr_copy;
+
+ ++nested;
rv = eval_to_string(expr_copy, NULL, TRUE);
+ --nested;
vim_free(expr_copy);
return rv;
}
*** ../vim-7.0.119/src/version.cFri Oct 6 20:39:58 2006
--- src/version.c Fri Oct 6 21:31:56 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 120,
/**/
--
hundred-and-one symptoms of being an internet addict:
16. You step out of your room and realize that your parents have moved and
you don't have a clue when it happened.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Patch 7.0.119
Patch 7.0.119
Problem:When going back from Insert to Normal mode the CursorHold event
doesn't trigger. (Yakov Lerner)
Solution: Reset "did_cursorhold" when leaving Insert mode.
Files: src/edit.c
*** ../vim-7.0.118/src/edit.c Tue Oct 3 15:49:20 2006
--- src/edit.c Thu Oct 5 22:26:27 2006
***
*** 923,928
--- 923,929
if (cmdchar != 'r' && cmdchar != 'v')
apply_autocmds(EVENT_INSERTLEAVE, NULL, NULL,
FALSE, curbuf);
+ did_cursorhold = FALSE;
#endif
return (c == Ctrl_O);
}
*** ../vim-7.0.118/src/version.cTue Oct 3 17:21:04 2006
--- src/version.c Fri Oct 6 20:35:45 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 119,
/**/
--
The Feynman problem solving Algorithm:
1) Write down the problem
2) Think real hard
3) Write down the answer
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug in netrw.vim
A.J.Mechelynck wrote: mwoehlke failed to read the previous post carefully: A.J.Mechelynck wrote: Many FTP servers can be accessed read-only by HTTP; but most HTTP servers have no FTP counterpart AFAIK. "Many"? Like Victor, I would have said "most". [snip] Please re-read what I said. "Many FTP servers can be accessed read-only by HTTP" [snip] Gack, you're right! Sorry! :-) So I guess I'm just throwing my own $0.02 at the whole 'what's with the assumption that ftp can be used to read http sites?' thing. -- Matthew "What's Cygwin?" you ask. 'Tis mostly absurd software Concerning hippos.
Re: Bug in netrw.vim
mwoehlke wrote: A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Victor Hsieh wrote: [...] I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. [...] Also not if there is no FTP server at that address. Many FTP servers can be accessed read-only by HTTP; but most HTTP servers have no FTP counterpart AFAIK. "Many"? Like Victor, I would have said "most". In fact, other than software mirrors (gnu.org and the like) I think it's pretty rare to have a site where http and ftp are mirrors of each other (my web host, for instance, gives me a chroot'd environment when I log into ftp, so even though they have both, they are not symmetric). And most sites (e.g. google.com) don't have ftp at all. Trying ftp://somewhere when http://somewhere doesn't work *might* work 1% of the time. I would say http:// should be treated read-only, since it almost always is, and the few cases where it isn't span a wide variety of /ways/ in which it isn't. Please re-read what I said. "Many FTP servers can be accessed read-only by HTTP" (i.e., in many cases, but I didn't say "most", if FTP works, HTTP will work too, but read-only -- these "many" FTP/HTTP servers admittedly are usually anonymous servers like ftp.vim.org, ftp.mozilla.org, etc.) "; but most HTTP servers have no FTP counterpart" (i.e., but if HTTP works, in most cases FTP won't.) Best regards, Tony.
Re: Fwd: Do Not Reply To This Message:Re: Time to remove naming restrictions?
On Fri, 2006-10-06 at 21:48 +0200, A.J.Mechelynck wrote: > We'll see -- or rather (hopefully) we won't (see any more of these bothersome > bounces). I don't get them anymore :) mfg, Ali Akcaagac
Re: vim -u NONE
On Fri 6-Oct-06 12:38pm -0600, Yakov Lerner wrote: > On 10/6/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: >> On Thu 5-Oct-06 8:54pm -0600, Gary Johnson wrote: >> >> > gvim -u NONE -i NONE -N >> > Setting "-u NONE -i NONE -N" is all that's needed. See ":help -u". > I never noticed that 'vim -u NONE' ever read the .viminfo ? It doesn't, you're in 'cp' mode and 'viminfo' is empty. > For example, if I set 'set nocp' in 'vim -u NONE' then I don't > see any command history that I'd see had .viminfo been read in. That's the problem. As soon as you change to 'nocp' mode, 'viminfo' is populated. When you close, the viminfo file is overwritten. > Do you see any difference between 'vim -u NONE' and 'vi -u NONE -i' ? (Assuming the second is 'vim -u NONE -i NONE'.) Both come up in compatibility "mode." If that is changed to 'nocp' during the session, the chance of overwriting an existing viminfo file is greatly reduced by the second approach. -- Best regards, Bill
Re: Bug in netrw.vim
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Victor Hsieh wrote: [...] I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. [...] Also not if there is no FTP server at that address. Many FTP servers can be accessed read-only by HTTP; but most HTTP servers have no FTP counterpart AFAIK. "Many"? Like Victor, I would have said "most". In fact, other than software mirrors (gnu.org and the like) I think it's pretty rare to have a site where http and ftp are mirrors of each other (my web host, for instance, gives me a chroot'd environment when I log into ftp, so even though they have both, they are not symmetric). And most sites (e.g. google.com) don't have ftp at all. Trying ftp://somewhere when http://somewhere doesn't work *might* work 1% of the time. I would say http:// should be treated read-only, since it almost always is, and the few cases where it isn't span a wide variety of /ways/ in which it isn't. -- Matthew "What's Cygwin?" you ask. 'Tis mostly absurd software Concerning hippos.
Re: Fwd: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Ali Akcaagac wrote: Hello, I received feedback from them today and they said that they recently had a lot of issues with bouncing back and that they finally solved this issue. We therefore should not receive anything from them anymore. greetings, Ali Akcaagac We'll see -- or rather (hopefully) we won't (see any more of these bothersome bounces). Best regards, Tony.
Re: Bug in netrw.vim
Charles E Campbell Jr wrote: Victor Hsieh wrote: [...] I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. [...] Also not if there is no FTP server at that address. Many FTP servers can be accessed read-only by HTTP; but most HTTP servers have no FTP counterpart AFAIK. Best regards, Tony.
Re: Bug in netrw.vim
Victor Hsieh wrote: On 10/6/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Victor Hsieh wrote: > With vim 7.0 and netrw.vim version 98, I've encountered a problem > when trying to "vim http://somewhere/file.txt";. This patch will fix > the problem: This would silently let users overwrite their own work that they had not saved. I don't think this would be a good idea. In this case, explicitly open the url via "vim http://..."; can be detected, and there's no more risk. I suppose this is a possible solution :) Netrw uses the trailing slash to determine whether to browse the remote directory or to bring it up for editing. Consider ftp://hostname/some/directory/ -- that trailing slash tells netrw to display directory contents, not attempt to edit a file called "directory". Now, http://... normally uses wget, and there's no corresponding wput; hence, "editing" an http://... url is a read-only operation. So, if one tries to edit a "directory" with the http protocol (ie. wget), netrw does the best it can and brings it up using ftp. Of course, ftp is a read and write capable protocol, so one can really edit it. I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Regards, Chip Campbell Regards, Vicotr http://www.example.com/something/ gives you (usually) the default file in the specified directory. Depending on how the http server is configured, you could get anything. Far from always a directory listing: e.g., on user sites at my ISP (Belgacom Skynet), if there is a file named index.html, INDEX.HTML, index.htm or INDEX.HTM you get that, and if there isn't you are redirected to some Skynet portal. Try the following: http://users.skynet.be/antoine.mechelynck/ you get index.htm (my Welcome page) but the headers don't say so http://users.skynet.be/antoine.mechelynck/other/ you are redirected first to a page asking you to choose French or Dutch language, and then to the Skynet homepage http://users.skynet.be/antoine.mechelynck/other/imbecile.htm you get a "real" HTML page, with "Idiots annoy me" in a variety of languages (i.e. the directory exists). OTOH, ftp://www.example.com/something/ (when given to a browser) gives you an FTP directory listing of directory /something/ at the FTP site www.example.com (provided that there is an FTP server at that address). Depending on the server, anonymous FTP may or may not be possible. Best regards, Tony.
Re: Fwd: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Hello, I received feedback from them today and they said that they recently had a lot of issues with bouncing back and that they finally solved this issue. We therefore should not receive anything from them anymore. greetings, Ali Akcaagac On Tue, 2006-10-03 at 12:13 +0200, A.J.Mechelynck wrote: > It's not half a dozen unwanted emails. It's just one email address, i.e., > [EMAIL PROTECTED] -- these false bounces all come from the same > source. If you feel up to it, write [EMAIL PROTECTED] telling them their > mail routers are misconfigured (you can use my mail to Yakov in this thread > as > a kind of boilerplate). You can also point him to > http://www.spamcop.net/fom-serve/cache/329.html . But don't expect quick and > accurate action, that postmaster could quite possibly be an arrogant > blockhead > wo won't do anything you suggest to him "for his own good".
Re: vim -u NONE
Yakov Lerner wrote: On 10/6/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Peter Hodge wrote: [...] > I wouldn't think the -i option is necessary, because 'viminfo' is empty by > default anyway. [...] The 'viminfo' option is not empty by default, except in 'compatible' mode (see -u option forces 'compatible' on. Thus I an pretty sure -i is redundant if added to -u NONE. -n NONE forces 'compatible' and thus empty 'viminfo'. Yakov It forces 'compatible' on, unless -N is also used. Now go back to the example given (by Bill McCarthy on 5-Oct-2006 at 15:59:34 -0500) and you'll see that it was "gvim -u NONE -i NONE -N". In this case "-i NONE" is not redundant, because -N forces 'nocompatible': - If the "-N" command line argument is given, 'nocompatible' will be used, even when no vimrc file exists. (*starting.txt* For Vim version 7.0. Last change: 2006 Sep 01, lines 920-921). I just tried it to check: started Vim with -u NONE -N but without any -i argument. Immediately after startup: :set vi? viminfo='20,<50,s10,h which is the 'nocompatible' default for Unix, and implies a viminfo file at ~/.viminfo. And the viminfo is read too, as shown by the many registers listed by ":reg". Adding "-i NONE" doesn't change the 'viminfo' option but it does prevent the file from being read, as can be seen from the fact that ":reg" lists no other registers than * + : Best regards, Tony.
Re: Bug in netrw.vim
Victor Hsieh wrote: On 10/6/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Victor Hsieh wrote: > With vim 7.0 and netrw.vim version 98, I've encountered a problem > when trying to "vim http://somewhere/file.txt";. This patch will fix > the problem: This would silently let users overwrite their own work that they had not saved. I don't think this would be a good idea. In this case, explicitly open the url via "vim http://..."; can be detected, and there's no more risk. I suppose this is a possible solution :) Again, its not a good idea. Presumably the problem occurred because you edited the page. OK, so what I will do is make "files" obtained with the http://... format show up as readonly. At least you'll get an earlier notice that editing such files isn't a Good Idea. Netrw uses the trailing slash to determine whether to browse the remote directory or to bring it up for editing. Consider ftp://hostname/some/directory/ -- that trailing slash tells netrw to display directory contents, not attempt to edit a file called "directory". Now, http://... normally uses wget, and there's no corresponding wput; hence, "editing" an http://... url is a read-only operation. So, if one tries to edit a "directory" with the http protocol (ie. wget), netrw does the best it can and brings it up using ftp. Of course, ftp is a read and write capable protocol, so one can really edit it. I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. I've put a no-browsing exception in for http://... . Please try v107b now on my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs see "Network Oriented Reading, Writing, and Browsing" Regards, Chip Campbell
Re: vim -u NONE
On 10/6/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Peter Hodge wrote: [...] > I wouldn't think the -i option is necessary, because 'viminfo' is empty by > default anyway. [...] The 'viminfo' option is not empty by default, except in 'compatible' mode (see -u option forces 'compatible' on. Thus I an pretty sure -i is redundant if added to -u NONE. -n NONE forces 'compatible' and thus empty 'viminfo'. Yakov
Re: vim -u NONE
On 10/6/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: On Thu 5-Oct-06 8:54pm -0600, Gary Johnson wrote: >> > gvim -u NONE -i NONE -N > Setting "-u NONE -i NONE -N" is all that's needed. See ":help -u". I never noticed that 'vim -u NONE' ever read the .viminfo ? For example, if I set 'set nocp' in 'vim -u NONE' then I don't see any command history that I'd see had .viminfo been read in. Do you see any difference between 'vim -u NONE' and 'vi -u NONE -i' ? Yakov
Re: Bug in netrw.vim
On 10/6/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Victor Hsieh wrote: > With vim 7.0 and netrw.vim version 98, I've encountered a problem > when trying to "vim http://somewhere/file.txt";. This patch will fix > the problem: This would silently let users overwrite their own work that they had not saved. I don't think this would be a good idea. In this case, explicitly open the url via "vim http://..."; can be detected, and there's no more risk. I suppose this is a possible solution :) Netrw uses the trailing slash to determine whether to browse the remote directory or to bring it up for editing. Consider ftp://hostname/some/directory/ -- that trailing slash tells netrw to display directory contents, not attempt to edit a file called "directory". Now, http://... normally uses wget, and there's no corresponding wput; hence, "editing" an http://... url is a read-only operation. So, if one tries to edit a "directory" with the http protocol (ie. wget), netrw does the best it can and brings it up using ftp. Of course, ftp is a read and write capable protocol, so one can really edit it. I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Regards, Chip Campbell Regards, Vicotr
Re: Bug in netrw.vim
Victor Hsieh wrote: With vim 7.0 and netrw.vim version 98, I've encountered a problem when trying to "vim http://somewhere/file.txt";. This patch will fix the problem: By the way, netrw is up to version 107a on my website. If you have a problem with netrw, its always best to get the latest version from my website and see if the problem has already been addressed (although e is still being used rather than e! in v107a). My website is: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs (see "Network Oriented Reading, Writing, and Browsing" for netrw). Regards, Chip Campbell
Re: Bug in netrw.vim
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to "vim http://somewhere/file.txt";. This patch will fix
the problem:
--- netrw.vim 2006-10-06 13:53:03.567758750 +0800
+++ netrw.vim.orig 2006-10-06 13:47:02.757209500 +0800
@@ -753,7 +753,7 @@
call tar#Browse(tfile)
else
"call Decho("edit temporary file")
-e
+e!
endif
" rename buffer back to remote filename
This would silently let users overwrite their own work that they had not
saved.
I don't think this would be a good idea.
BTW, when I try to "vim http://somewhere/dir/"; (with slash at the
end), it'll try to connect to ftp://somewhere/dir/ instead of returned
html. If you look at netrw.vim, there's a snippet of code like this:
if method == "ftp" || method == "http"
let method = "ftp"
let listcmd = g:netrw_ftp_list_cmd
else
let listcmd =
substitute(g:netrw_list_cmd,'\',user.machine,'')
endif
If you remove the second line, everything is gonna be all right, even
the returned html code is parsed and vim will list the remote file
correctly. Does anybody know what's the second line for?
Netrw uses the trailing slash to determine whether to browse the remote
directory
or to bring it up for editing. Consider ftp://hostname/some/directory/
-- that trailing
slash tells netrw to display directory contents, not attempt to edit a
file called "directory".
Now, http://... normally uses wget, and there's no corresponding wput;
hence, "editing"
an http://... url is a read-only operation. So, if one tries to edit a
"directory" with the
http protocol (ie. wget), netrw does the best it can and brings it up
using ftp. Of course,
ftp is a read and write capable protocol, so one can really edit it.
Regards,
Chip Campbell
Re: [macvim] modifiers should be applied to special keys too (patch)
Nicolas Weber wrote: Hi, Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. This is fixed in the attached patch. Another key that's still not working is Shift-Space (or Meta-Space). I'll take care of that later (but that doesn't work in the current mac vim either). Bye, Nico IIUC, Shift-Space is supposed to be synonymous with Space. (When typing text, hitting the space bar produces a space regardless of whether you're typing lowercase or uppercase.) As for Meta-Space (aka Alt-Space), some OSes use it as a menu key, in which case it might be snatched away before Vim sees it. Best regards, Tony.
Re: vim -u NONE
Peter Hodge wrote: [...] I wouldn't think the -i option is necessary, because 'viminfo' is empty by default anyway. [...] The 'viminfo' option is not empty by default, except in 'compatible' mode (see ":help 'viminfo'"): 'compatible' default: viminfo= MS-DOS, Windows, OS/2 'nocompatible' default: viminfo='20,<50,s10,h,rA:,rB: Amiga 'nocompatible' default: viminfo='20,<50,s10,h,rdf0:,rdf1:rdf2: 'nocompatible' default on other platforms: viminfo='20,<50,s10,h All of these 'nocompatible' defaults implicitly reference a viminfo file named ~/_viminfo (on Dos/Windows), s:.viminfo (on the Amiga) or ~/.viminfo (on other systems including OS/2) -- unless of course the +viminfo feature was not compiled-in. "-i NONE" explicitly prevents reading or writing any viminfo file, regardless of any other settings (such as 'viminfo') or commands (such as ":rviminfo" or ":wviminfo"). Best regards, Tony.
Re: [macvim] modifiers should be applied to special keys too (patch)
Hi, Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. This is fixed in the attached patch. Another key that's still not working is Shift-Space (or Meta-Space). I'll take care of that later (but that doesn't work in the current mac vim either). Bye, Nico keyevent.diff Description: Binary data
Re: vim -u NONE
On Fri 6-Oct-06 12:15am -0600, Gary Johnson wrote:
> I also found this under ":help gui-init":
>
> To skip loading the system menu include 'M' in 'guioptions'.
>
> So to avoid loading _anything_, at the expense of not having any
> menus, one could start gvim as
>
> gvim -N -u NONE -i NONE --cmd 'set go+=M'
Since I use Gvim with no menu - much better syntax
highlighting than Vim - my vimrc has
set guioptions=M
which speeds up loading a bit. I also have a toggle in
gvimrc which, upon being toggled for the first time,
includes:
source $vimruntime\menu.vim
However, when I'm running Gvim to be as virgin as possible,
I keep the menu.
My actual aliases do the following (revised after wading
through all the existing startup docs and experimenting with
-V a few weekends ago):
gvim.exe -u NONE -i NONE -N --cmd "se rtp=$VIMRUNTIME" "+so $vim\_minrc"
and
vim.exe -u NONE -i NONE -N "+so $vim\_minrc"
where _minrc does some simple things like shut off bells and
screen flashing, gives me my normal 'rtp' and 'stl', and
sets 'gfn' (if has("GUI")) for normal and vimdiff.
--
Best regards,
Bill
Re: Vim 7.0 (1-109 patches) completion bug.
On Fri 6-Oct-06 12:25am -0600, Igor Prischepoff wrote: > Well, i still don't understand vim logic behind that process. > > Let's see more realistic example. > > gvim -U NONE -u NONE Only last time, although I don't think it matters in this example, you are working in 'cp' mode. Many of vim/gvim features will not work in that mode. (Also, the -U NONE is redundant. See ':h -u' second paragraph for why you don't need -U and the side effect of setting 'cp') > Let's suppose that I am a poor pascal programmer and typing code like this: > :set completeopt+=longest > :set complete-=t > i > var one : byte; > two : byte; > two_and_three : byte; > three : byte; > // may be this is a word? > one:=three; > // or next one is a a word? > one:=two_and_three; > o:=t > // completion in second still not working here... > // so there is no word? not 'one:=t*' or 't*' words in buffer? > // I still thinks it should be considered as a bug. What action did you take on the first ? Since 'o' is the longest common, no addition completion is done. If you just want the 'o' type , if you want 'one' type , or if you want 'or' type . Why ? See ':h complete_CTRL-Y' Now type ':=t'. What do you mean by "still not working"? I see (since I picked 'one' for the first completion): one:=t two two_and_three three this Nothing was added to the 't' because it's the longest common. If I now want 'this;' I would type ';'. My complete keystrokes from insert mode at the beginning of that line are: o:=t; and my line reads: one:=this; and my cursor would be on the ';'. -- Best regards, Bill
