Re: How to save a UTF-8 file on Windows using a non-ASCII name
Hi Fan, 2008/1/21 Fan Decheng [EMAIL PROTECTED]: [...] Here is a snippet from the Vim's reference: NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. To reload the menus see |:menutrans|. Thanks. It seems that setting `encoding' before opening the file works. Yes, it works fine for this case. But it doesn't necessary means that it's also OK for all the functions in Vim. So as a practical suggestion, never modify the encoding as long as you've already launched Vim. Only change this option *ONCE* in your .vimrc. L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: spend vs. spent
(totally off-topic couldn't be more off-topic... really, I warned you!) On Jan 20, 2008 3:01 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Corn oil comes from corn and olive oil comes from olives, so where does baby oil come from? You can make this even worse by saying: Corn oil comes from crushing corn and olive oil comes from crushing olives, so where does baby oil come from? Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [Alpha/Gcc] compiler warning for Vim 7.1.230
On Fri, Jan 18, 2008 at 13:29:51 +0100, Bram Moolenaar wrote: Adri Verhoef wrote: Compilation of Vim 7.1.230 on an Alpha processor with Gcc yielded: gui_motif.c: In function 'find_replace_dialog_create': gui_motif.c:3816: warning: cast to pointer from integer of different size That line would be: XtAddCallback(frdp-find, XmNactivateCallback, find_replace_callback, (XtPointer) (do_replace ? FRD_R_FINDNEXT : FRD_FINDNEXT)); I don't see how this is different from similar calls, e.g.: XtAddCallback(frdp-replace, XmNactivateCallback, find_replace_callback, (XtPointer)FRD_REPLACE); Perhaps you can try out what would silence the compiler? Here is the solution: XtAddCallback(frdp-find, XmNactivateCallback, find_replace_callback, (do_replace ? (XtPointer)FRD_R_FINDNEXT : (XtPointer)FRD_FINDNEXT)); Cheers, Adri --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [Alpha/Gcc] compiler warning for Vim 7.1.230
Adri Verhoef wrote: On Fri, Jan 18, 2008 at 13:29:51 +0100, Bram Moolenaar wrote: Adri Verhoef wrote: Compilation of Vim 7.1.230 on an Alpha processor with Gcc yielded: gui_motif.c: In function 'find_replace_dialog_create': gui_motif.c:3816: warning: cast to pointer from integer of different size That line would be: XtAddCallback(frdp-find, XmNactivateCallback, find_replace_callback, (XtPointer) (do_replace ? FRD_R_FINDNEXT : FRD_FINDNEXT)); I don't see how this is different from similar calls, e.g.: XtAddCallback(frdp-replace, XmNactivateCallback, find_replace_callback, (XtPointer)FRD_REPLACE); Perhaps you can try out what would silence the compiler? Here is the solution: XtAddCallback(frdp-find, XmNactivateCallback, find_replace_callback, (do_replace ? (XtPointer)FRD_R_FINDNEXT : (XtPointer)FRD_FINDNEXT)); Weird. I'll include it, should not hurt any other system. -- The most powerful force in the universe is gossip. /// 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/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
Ben Schmidt wrote: Here is a snippet from the Vim's reference: NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. To reload the menus see |:menutrans|. Personally I think this should be a bug of Vim. However, as it had already been well-documented, I think you should follow the principles. I personally think that's perfectly reasonable and not a bug. But something I really do think is worth changing because it's really confusing, is ++enc. Why do we call this ++enc not ++fenc which would make a huge amount more sense, and be more consistent with ++ff and ++bin which both set their namesake options? We see evidence of people getting 'enc' and 'fenc' confused on a regular basis, and this feature naming really doesn't help matters. What would you think of changing this, Bram? Perhaps making it officially ++fenc but accepting ++enc for compatibility with old scripts (and old users!)? These are not really option names, although I can see that they are so similar that people might think that. They are options for the command. Offering more alternatives isn't going to make it simpler. We also don't have 'fbin' for reading a file in binary mode. Also, I wonder whether it might be worth adding a 'best practices' section to mbyte.txt and referring to it in such places as 'enc' (probably mostly there) which explains the basics in a few short paragraphs: set 'enc' in your .vimrc (recommend utf-8), 'tenc' if your terminal/locale is different (unneeded in GUI), use ++fenc if a file is read with wrong encoding detected, 'fenc' to change what encoding to write a file with for future writes. This sort of material is repeated frequently on the mailing lists which suggests users aren't finding it easily in the help (though it is all there, it is somewhat spread around, etc.). Do others think this might or something similar might be a good idea? It will certainly help to update the documentation to explain common pitfalls. Writing this in a nice way, without becoming too verbose and putting it in the right place is not easy. If you or someone else can suggest a patch that would be great. -- Wi n0t trei a h0liday in Sweden thi yer? Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// 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/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
can not compile a GUI version vim on OpenSolaris
hi,I use OpenSolaris (solaris express community edition,snv_73).I download vim-7.1.tar.zip2,vim-7.1-extra.tar.zip2,vim-7.1-lang.tar.zip2,bunziped them into a directory .configureed options as bellow: ./configure --enable-gui --enable-pythoninterp --enable-cscope --enable-sniff --enable-multibyte --enable-xim --enable-fontset --enable-gui=gnome2 --with-features=huge --with-x --with-gnome make all but, I got a vim without ,why? how to comiled a GUI version on solaris ? - 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Set mouse=a causes Vim to hang in screen.
On Thu, Jan 17, 2008 at 05:19:39PM +0100, Dominique Pelle wrote: Then vim -u /tmp/vimrc -X hangs when run under screen. It does not display anything, or respond to terminal input (including Ctrl-C). When killed (SIGTERM), it draws the intro screen and prints a message saying Received TERM signal, exiting. Hmm. My sysadmin ran a system update, and now I can't reproduce the problem either. If I ever can, I'll be sure to send a GDB backtrace, or at least an strace output. Thanks for all your suggestions, GI -- Time is not wasted if you are wasted all the time. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Setting guifont from a modeline
I cannot imagine a situation where this would be desirable. Conversely, I think it makes for a great April Fool's Joke. I'd rather prefer not being the recipient, though. What does everyone think about making guifont unsettable from the modeline? It is a global option, after all. I just don't think it makes that much sense to be set from the modeline. For that matter, I propose that all options beginning with 'gui' not be settable from the mode-line. Regards, -- Erik Falor Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Setting guifont from a modeline
Erik Falor wrote: I cannot imagine a situation where this would be desirable. Conversely, I think it makes for a great April Fool's Joke. I'd rather prefer not being the recipient, though. What does everyone think about making guifont unsettable from the modeline? It is a global option, after all. I just don't think it makes that much sense to be set from the modeline. For that matter, I propose that all options beginning with 'gui' not be settable from the mode-line. Regards, -- Erik Falor Registered Linux User #445632 http://counter.li.org It is a global option, but if you know what you're doing it may sometimes be useful to set it from a modeline. However, I think I'm going to paraphrase what the Koran says about drinking wine, viz. there's good and bad in it, but more bad than good. Yes, some extreme Islamists assert that that saying is enough to make all alcohol-containing beverages strictly forbidden to all believers. But shall all of us have to abide by that interpretation? Making all guisomething options unsettable from the moudeline would IMHO be rather rash. Under :help modeline-local it is said: Although it's possible to set global options from a modeline, this is unusual. Best regards, Tony. -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use. -- Galileo Galilei --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
But something I really do think is worth changing because it's really confusing, is ++enc. Why do we call this ++enc not ++fenc which would make a huge amount more sense, and be more consistent with ++ff and ++bin which both set their namesake options? We see evidence of people getting 'enc' and 'fenc' confused on a regular basis, and this feature naming really doesn't help matters. What would you think of changing this, Bram? Perhaps making it officially ++fenc but accepting ++enc for compatibility with old scripts (and old users!)? These are not really option names, although I can see that they are so similar that people might think that. They are options for the command. Offering more alternatives isn't going to make it simpler. We also don't have 'fbin' for reading a file in binary mode. Yes, I realise they're not option names, but they undeniably do look like it, and time and time again we see people getting 'fenc' and 'enc' confused, and ++ff sets 'ff' when reading, ++bin sets 'bin', but ++enc sets 'fenc'. This is only confusing because there *is* an option called 'enc'. If there weren't, as there isn't a 'fbin' option, nor a 'format' option, it would be no problem. But, hey, it's not too important. I just thought I'd throw it out there, as I think it has potential to help a lot of users avoid confusion. Maybe I'm wrong. It would be interesting to hear what others think. Also, I wonder whether it might be worth adding a 'best practices' section to mbyte.txt and referring to it in such places as 'enc' (probably mostly there) which explains the basics in a few short paragraphs: set 'enc' in your .vimrc (recommend utf-8), 'tenc' if your terminal/locale is different (unneeded in GUI), use ++fenc if a file is read with wrong encoding detected, 'fenc' to change what encoding to write a file with for future writes. This sort of material is repeated frequently on the mailing lists which suggests users aren't finding it easily in the help (though it is all there, it is somewhat spread around, etc.). Do others think this might or something similar might be a good idea? It will certainly help to update the documentation to explain common pitfalls. Writing this in a nice way, without becoming too verbose and putting it in the right place is not easy. If you or someone else can suggest a patch that would be great. I agree. Terseness is definitely not my strength, though, so I might leave this to someone else to have a try if anyone is willing. Volunteers? Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
How to do dynamic syntax highlighting?
I am wondering how one might go about adding keywords while a file is being syntax-highlighted. The idea is that at the top of a file, one defines a new function. Afterwards, in that file, that function should be highlighted as known. I realize it can be done using tags; I am looking for something more dynamic. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: can not compile a GUI version vim on OpenSolaris
2008/1/21 noname wind [EMAIL PROTECTED]: but, I got a vim without ,why? I presume you mean you got a version without X. As you seem to have configured it correctly, I suggest you send the whole output of make to this list so people can look at it :) RIchard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Setting guifont from a modeline
Tony Mechelynck wrote: What does everyone think about making guifont unsettable from the modeline? It is a global option, after all. I just don't think it makes that much sense to be set from the modeline. It is a global option, but if you know what you're doing it may sometimes be useful to set it from a modeline. However, I think I'm going to paraphrase what the Koran says about drinking wine, viz. there's good and bad in it, but more bad than good. Yes, some extreme Islamists assert that that saying is enough to make all alcohol-containing beverages strictly forbidden to all believers. But shall all of us have to abide by that interpretation? Making all guisomething options unsettable from the modeline would IMHO be rather rash. Under :help modeline-local it is said: Although it's possible to set global options from a modeline, this is unusual. If I may be rash, I suggest that the OP was concerned about OTHER PEOPLE setting gui options in a modeline. It would not be unusual for a malware author to do something unexpected. My preference would be for Vim to be distributed in a locked down state, where modelines had only very limited functionality (local tab settings etc), and a user would have to put something in their vimrc to enable more modeline features. John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
