Re: VimTips Wiki: New Direction
On Wed, Mar 07, 2007 at 08:39:23PM +1100, John Beckett wrote: Paul Irofti wrote: Back-ups are better made on the server side. For mediawiki a regular sqldump (maybe added in crontab) is all that is necessary. Good. But can we actually do that? I thought we were planning to use a system where we have no access to the server except via a wiki interface. John The admins must keep back-ups, I'm sure we can talk to them. After all, admins are humans too (-:
Re: VimTips Wiki: New Direction
On Wed, Mar 07, 2007 at 11:03:46AM +0100, A.J.Mechelynck wrote: John Beckett wrote: Brian McKee wrote: One of the first things I was thinking about mirrors the above comments. http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/ TipsSandbox/Tip_1:_the_super_star has a bunch of thanks for the great tip! type comments with more useage info interspersed. I think those 'great tip' comments go to a separate page, while the 'use # or % instead' kind of comments need to be edited into the actual tip itself. But why keep the 'great tip' comments? The friendly atmosphere of the current Vim Tips web site is rather nice, but why put all the work of moving it to a wiki unless you make the tips more helpful? Unhelpful tips and unhelpful comments should be omitted. I think this would imply a lot of manual labor and would render the porting scripts obsolete. And why is everyone so eager to delete the great-tip!!! kthnxbye!! comments?! They raise moral, encourage further contribution and counts as positive feedback (specially for first time tip-posters). Plus they're harmless. John Moving the tip body to a wiki page and the comments to its talk page can (IIUC) be automated. /Then/ the tip author (or maintainer, etc.) can archive the talk page, remove empty comments (of the great tip kind), refactor useful comments into the tip body, etc. I couldn't agree more. All comments should be placed in the talk page (it's just natural) and changes generated by the discussions should be added (and optionally thanked) on the front page. [--snip--]
Re: VimTips Wiki: New Direction
On Tue, Mar 06, 2007 at 06:45:51PM +1100, John Beckett wrote: Tom Purl wrote: I looked into the anti-spam features of Wikibooks, and they basically do the basics: blacklists for abusers and easy rollbacks. So the top 2% of spammers/vandalizers will be blocked, and it will be easy for the admins to roll back the problems created by the outher 98%. Wikibooks sounds good. I wonder if it would be worth looking for a volunteer to occasionally take a snapshot of the wiki as an emergency backup. Presumably wget or similar would be adequate, or maybe there is an easy way to get the mediawiki source. Such a backup might be useful in a few weeks, and then perhaps monthly. John Back-ups are better made on the server side. For mediawiki a regular sqldump (maybe added in crontab) is all that is necessary.
Re: VimTips - Google Wiki Usefulness
Hello vimmers, I don't understand why Google Wiki is being discussed here as the main solution. As I see it there are a few _major_ disadvantages of using it: - it has software limitations that a large community, such as ours, can't cope with - it's managed and offered by a third party organization - we don't have controls of what features we want in and/or out or the way the layout/code/roadmap goes - it's a commercial product and Vim will be asociated with it in the long run - Google is as corporate as you can get, corporations and OpenSource don't mix well together (there are tons of examples) - from what I've read in this thread it doesn't even have all the features needed for a working Vim-tips wiki On the other hand mediawiki seems the best solution for something like this: - it's *OpenSource* - it offers an easy management environment - it can support high loads of traffic (see wikipedia) - it has multi-language support - it's easy to customize and improve - it's not chown()-ed by any corporation I know I'm not a regular here, but I read most of the mail I get from vim@ and don't quite get why you people are seriously considering this. So I thought I'd drop my two cents and hope that someone can shed some light. Thanks, Paul.
Re: VimTips - Google Wiki Usefulness
Not sure this got through, resending. - Forwarded message from Paul Irofti [EMAIL PROTECTED] - From: Paul Irofti [EMAIL PROTECTED] To: A.J.Mechelynck [EMAIL PROTECTED] Cc: Tom Purl [EMAIL PROTECTED], Bram Moolenaar [EMAIL PROTECTED], vim@vim.org Date: Mon, 26 Feb 2007 12:42:34 +0200 Subject: Re: VimTips - Google Wiki Usefulness On Mon, Feb 26, 2007 at 11:24:10AM +0100, A.J.Mechelynck wrote: If we gan get hosting space somewhere for a mediawiki server, I'm all in favour. I'm not sure what the hosting deal is with vim.org or how much traffic it generates, but if we can't add a wiki there and no one volunteers to offer hosting, I guess a global call for contributions would solve the issue (I think a lot of people would chip-in and hosting isn't that expensive nowadays). Of course then the wiki will have to sustain itself from monthly donations (and that might be a bit hard if people aren't contributing, so the person in charge will have a bit of a hassle) but I think in the end all will be fine and it will be worth it. As an optional extra funding source, ads might come in handy. - End forwarded message -
Re: VimTips - Google Wiki Usefulness
On Mon, Feb 26, 2007 at 05:38:42AM -0500, Yakov Lerner wrote: ElWiki.com Free MediaWiki hosting with fast setup. A free .com/net/org domain is offered for wikis which reach 10 pages of content. Google AdSense text-ads may be added to the right sidebar to cover hosting expenses. From: http://en.wikibooks.org/wiki/Wiki_Science:How_to_start_a_Wiki Yakov That looks like just the kind of home Vim-tips has been looking for, although it seems too good to be true (-: I think further investigations (conditions, server access and management) should be conducted if this is to be chosen.
Re: VimTips - Google Wiki Usefulness
On Mon, Feb 26, 2007 at 12:55:58PM +0100, A.J.Mechelynck wrote: ! Obligations # The service is provided free-of-charge, as-is, and without any guarantees or obligations. # We reserve the right to cancel or alter the service at any time. ! [-snip-] ! Control and Approval # ElWiki reserves the right to reject creation of a Wiki, or delete a Wiki at it's sole discretion. # ElWiki may make ammendments to the site title, URL, or description. # You will be given non-exclusive administrative control over any site you choose to host with us. ! [--snip-snip--] It may be legalese -- some lawyers add that kind of talktalk just to stay on the safe side... for them -- yet these (marked out with !) are the kind of clauses I would hesitate long and hard (perhaps forever ;-) ) before signing. Short of a benevolent sponsor, I seriously wonder what we should do. This does sound risky and we should probably stay out of it. But it would've been nice. Someone mentioned a co-lo...maybe we'll find a home there.
Re: Keyboard mapping being changed during usage
On Thu, Jan 18, 2007 at 02:31:21PM -0200, Vinicius Pinto wrote: I'm using Vim 7.0 on Windows XP and my keyboard mapping is set so brazilian portuguese (ABNT2). The problem is that sometimes when I'm using Vim, it changes the mapping to US, so, for example, when I type the ? key, it prints a quote. If I close Vim and open again, it's back to the correct mapping. I'm not sure what's happening, but it seems that the problem occurs when I alternate between windows using ALT+Tab. Is there anyone with this problem? Thanks, Vinicius I'm a dvorak user. Everytime I end up on someone else's computer (or at a public console) I have to setup my layout from us to us.dvorak. Same goes for Windows XP. The thing I noticed with Windows versions (2000/XP/2003) is that, even if I set the dvorak layout to default, it keeps the layout settings for each window that was opened before my selection. So each time I switch to an already opened window I have to select the dvorak layout. Newly started applications start with dvorak now. Now all that's in theory. The thing is that Windows behavior is random regarding this issue. I can be in the middle of writing something in my favorite editor when suddenly the keyboard gets set back to default, i.e. qwerty layout. This happens rarely but it's frustrating. Thank God I only encounter Windows at the University (-: Anyway, you could be in the same situation here. I suggest you find a way to reproduce this (if you can) and submit a bug. Just make sure its vim doing all the mambo-jambo.
dvorak layout support
I've just switched to dvorak and was wondering if there's any support for dvorak keyboards as the old qwerty keyboard mappings tend to screw up all logic in command mode (specially movement).
Re: ruby indentation
On Thursday 19 October 2006 18:26, Akbar wrote: Hi, I use vim7 ( compiled from source ) This is my situation: open bla.rb def bla ( type def bla, enter ) print bla( type two spaces and print bla, enter ) print bli ( no need to type two spaces, sweet, type print bli, enter ) end ( type end, enter ) I want my vim do this: after I press enter ( after typing end ), the word end will indent to left automatically aligning with word def. How do I do that? Thank you. I had the same issue when I compiled from source via a-a-p on my Slackware machine at work. The thing is that at home I run OpenBSD and building from ports (this involves compiling too) returns other result (i.e. indention works like a charm). It might be something that broke along from patch 42 (that I have on OpenBSD) through patch 135, or whichever is the latest one, that I have at work. I really don't know, maybe a special configure flag (although I looked it up and found nothing). I hope someone can explain this...
Re: Can the mailing list owner set Reply-to field be [EMAIL PROTECTED]
On Thursday 19 October 2006 07:22, Kamaraju Kusumanchi wrote: On Wednesday 18 October 2006 22:22, Peng Yu wrote: Hi, Can the mailing list owner set Reply-to field in every mail forward from this mailing list be vim@vim.org? I replied some mails to the original poster. But sometime I forget to reply the mails to the mailing list. Use a decent email client like kmail, mutt etc., which are mailing list aware. That way if you hit 'L', the reply will be sent to the list. Of course, the letter 'L' can be configured to other letters if it is a decent email client. raju I agree, I use KMail and mutt... they're both a joy. Of course if you're stuck with Windows then I'd suggest Thunderbird or maybe a Windows port for the above (although I have no ideea if such a thing exists, you might be lucky with mutt, KMail is highly improbable without installing an X client on your Windows and having an X server forwarding traffic). Anyways good luck to the OP and please keep it the way it is.
Re: www.vim.org
Works just fine for me. Here's a traceroute for those in doubt: $ traceroute www.vim.org traceroute to vhost.sourceforge.net (66.35.250.210), 64 hops max, 40 byte packets 1 nautilus (192.168.1.1) 0.173 ms 0.183 ms 0.145 ms 2 86.106.2.2 (86.106.2.2) 0.456 ms 0.707 ms 0.430 ms 3 192.168.168.6 (192.168.168.6) 0.893 ms 1.577 ms 3.684 ms 4 84.234.111.177 (84.234.111.177) 4.277 ms 1.945 ms 5.977 ms 5 fibernet-gw-bfd.gtstelecom.ro (212.146.78.49) 1.978 ms 2.464 ms 6.106 ms 6 r11-Vl3101.buh7.ro.gtsce.net (85.9.9.10) 2.90 ms 3.536 ms 6.652 ms 7 r10-Ge2-1-3501.buh7.ro.gtsce.net (85.9.9.5) 9.170 ms 4.835 ms 3.104 ms 8 195.39.209.45 (195.39.209.45) 30.962 ms * 40.831 ms 9 sl-gw10-fra-4-0.sprintlink.net (217.147.111.113) 30.254 ms 38.539 ms 34.419 ms 10 sl-bb20-fra-8-0.sprintlink.net (217.147.96.37) 31.951 ms 30.927 ms 31.33 ms 11 acr1-so-3-2-0.Frankfurtfrx.savvis.net (208.174.57.9) 147.192 ms 149.122 ms 157.313 ms 12 dcr1-so-1-0-0.frankfurtfrx.savvis.net (204.70.194.162) 138.918 ms dcr2-so-1-0-0.frankfurtfrx.savvis.net (204.70.192.169) 159.958 ms 153.618 ms 13 dcr2-so-5-0-0.frankfurtfrx.savvis.net (204.70.194.126) 138.355 ms * bcs2-so-4-0-0.parisprx.savvis.net (204.70.194.130) 144.228 ms 14 bcs2-so-3-0-0.Washington.savvis.net (204.70.192.125) 138.130 ms bcs2-so-4-0-0.parisprx.savvis.net (204.70.194.130) 149.455 ms 143.350 ms 15 dcr2-so-7-3-0.Atlanta.savvis.net (204.70.192.65) 153.198 ms bcs2-so-3-0-0.Washington.savvis.net (204.70.192.125) 152.465 ms dcr2-so-7-3-0.Atlanta.savvis.net (204.70.192.65) 149.814 ms 16 dcr2-so-7-3-0.Atlanta.savvis.net (204.70.192.65) 154.255 ms dcr2-so-2-0-0.dallas.savvis.net (204.70.192.70) 187.901 ms dcr2-so-7-3-0.Atlanta.savvis.net (204.70.192.65) 147.65 ms 17 dcr2-so-2-0-0.dallas.savvis.net (204.70.192.70) 188.383 ms dcr1.lay-so-3-2-0.losangeles.savvis.net (204.70.194.53) 203.453 ms dcr2-so-2-0-0.dallas.savvis.net (204.70.192.70) 238.717 ms 18 dcr1.lay-so-3-2-0.losangeles.savvis.net (204.70.194.53) 205.409 ms * 203.311 ms 19 bhr1-pos-0-0.SantaClarasc8.savvis.net (208.172.156.198) 210 ms 217.57 ms 214.995 ms 20 bhr1-pos-0-0.SantaClarasc8.savvis.net (208.172.156.198) 215.606 ms csr1-ve240.santaclarasc8.savvis.net (66.35.194.34) 225.386 ms bhr1-pos-0-0.SantaClarasc8.savvis.net (208.172.156.198) 216.495 ms 21 66.35.212.174 (66.35.212.174) 223.687 ms 224.398 ms 223.288 ms 22 vhost.sourceforge.net (66.35.250.210) 222.879 ms !C 66.35.212.174 (66.35.212.174) 227.883 ms vhost.sourceforge.net (66.35.250.210) 226.879 ms !C 23 vhost.sourceforge.net (66.35.250.210) 242.337 ms !C 212.490 ms !C 219.345 ms !C
Re: gvim-7-0-118.exe virus found??
On Monday 16 October 2006 15:40, Benji Fisher wrote: On Mon, Oct 16, 2006 at 03:08:58PM +0800, Edward Wong wrote: Dear all, Just tried downloading gvim-7-0-118 from sourceforge and AVG detects there is a trojan virus. Can it be a false alarm? Ed Please be more specific. Can you give a link to the archive you downloaded? Or did you use CVS or SVN (and , if so, what command did you use)? HTH --Benji Fisher The name of the viril would be good to know also...
Re: Spell checking in comments only
On Sunday 15 October 2006 11:06, Przemyslaw Gawronski wrote: Hi, when writing code in Python, C, HTML (or any other) I would like to have spell checking only in comments. Is that possible? If so, how can I set it up? Thanks Przemek Have you tried it? I remember enabling spelling once when I was in a C file, and it only underlined the flawed words in comments, the code was pretty much ignored...
:cd and :E
Hi vim(m?)ers, If I :cd to another directory and then :E to browse through I get the directory where the current buffer resides. Is this correct/wanted behavior? And if so why? Thanks, Paul.
Fwd: Re: :cd and :E
It's to late apparently, it seems I only replied to Max, sorry about that too. :-( -- Forwarded Message -- Subject: Re: :cd and :E Date: Sunday 03 September 2006 01:10 From: Paul Irofti [EMAIL PROTECTED] To: Max Dyckhoff [EMAIL PROTECTED] On Sunday 03 September 2006 01:08, you wrote: From :help :E, it looks like it is the correct behaviour. :Explore[!] [dir]... Explore directory of current file Damn, I forgot to lookup the command in :he. Sorry about that... If you want to explore an arbitrary directory, then just add the directory that you :cd into to the :E command. I don't know of a command to browse the current working directory, sorry! If anyone else knows a command that will follow the behavior I expected please let me know, otherwise I'll just add another macro ;) Max -Original Message- From: Paul Irofti [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 2:59 PM To: vim@vim.org Subject: :cd and :E Hi vim(m?)ers, If I :cd to another directory and then :E to browse through I get the directory where the current buffer resides. Is this correct/wanted behavior? And if so why? Thanks, Paul. ---
Re: :cd and :E
On Sunday 03 September 2006 01:47, Max Dyckhoff wrote: I am so dense sometimes, I should have thought of that instantly :) Max -Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 3:45 PM To: Max Dyckhoff Cc: Paul Irofti; vim@vim.org Subject: Re: :cd and :E Max Dyckhoff wrote: From :help :E, it looks like it is the correct behaviour. :Explore[!] [dir]... Explore directory of current file If you want to explore an arbitrary directory, then just add the directory that you :cd into to the :E command. I don't know of a command to browse the current working directory, sorry! Max To browse the current directory (under Vim 7), use :edit ./ I suppose :Explore . (with a dot at the end) would also work, including in earlier Vim versions where Explorer was a different plugin than netrw. The single dot means the current directory. Best regards, Tony. Hehe, I never thought of using . either, it's just what I wanted:) Thanks a lot guys!
set vb t_vb=
Hi vimers, I have a problem since my latest update to vim7. My vimrc file contains, among other things, set vb t_vb=. Because I don't like any kind of beeps or other warnings. Now, after the update, it gives me a visual beep/warning although I have the same vimrc. If I issue at runtime: :set vb t_vb= it's all back to normal. No more visual effects! This seems to me like a possible bug. Here's some info regarding my system: $ dmesg OpenBSD 4.0-beta (GENERIC) #1064: Tue Aug 15 15:37:34 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz $ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 12 2006 11:22:09) Included patches: 1-4, 6-26, 29-31, 33-42 Compiled by [EMAIL PROTECTED] Normal version with GTK2 GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/local/share/vim Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -O2 -pipe -I/usr/X11R6/include Linking: cc -L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/local/lib -o vim -L/usr/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lXt -lcurses -lintl
Re: set vb t_vb=
On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote:
Paul Irofti wrote:
Hi vimers,
I have a problem since my latest update to vim7. My vimrc file
contains, among other things, set vb t_vb=. Because I don't like
any kind of beeps or other warnings.
Now, after the update, it gives me a visual beep/warning although I
have
the same vimrc. If I issue at runtime:
:set vb t_vb=
it's all back to normal. No more visual effects!
By doing
:verbose set vb? t_vb?
you'll be able to see which script (if any) last set these options.
(I wonder what it may be).
It was, as I suspected, vimrc.
Note that if you use gvim, t_vb is reset at its gvim default when
starting the GUI (after having sourced the vimrc). You may want to
set it to empty in both your vimrc (to avoid a visual bell in Console
Vim) and your gvimrc (for the GUI).
That was the problem. I thought vimrc was read first and afterwards, if
gvim was lunched, the gvimrc. I kept only gui specific stuff in gvimrc
such as:
set guioptions-=m
set guioptions-=T
set guioptions-=r
set guifont=Terminus\ 12
set lines=50
set columns=100
Is this normal behaviour? I remember reading that vimrc had precedence
and don't remember seeing any notes about gvim overwritting some of the
stuff there.
Or if you don't want to bother with a gvimrc just for that, use the
following in your vimrc:
set vb t_vb=
if has('+autocmd') exists('##GUIEnter')
au GUIEnter * set t_vb=
endif
Best regards,
Tony.
Thanks for clearing things up a bit.
Paul.
Re: set vb t_vb=
On Sunday 27 August 2006 19:01, Paul Irofti wrote:
On Sunday 27 August 2006 17:44, A.J.Mechelynck wrote:
Paul Irofti wrote:
Hi vimers,
I have a problem since my latest update to vim7. My vimrc file
contains, among other things, set vb t_vb=. Because I don't like
any kind of beeps or other warnings.
Now, after the update, it gives me a visual beep/warning although
I have
the same vimrc. If I issue at runtime:
:set vb t_vb=
it's all back to normal. No more visual effects!
By doing
:verbose set vb? t_vb?
you'll be able to see which script (if any) last set these options.
(I wonder what it may be).
It was, as I suspected, vimrc.
Note that if you use gvim, t_vb is reset at its gvim default when
starting the GUI (after having sourced the vimrc). You may want to
set it to empty in both your vimrc (to avoid a visual bell in
Console Vim) and your gvimrc (for the GUI).
That was the problem. I thought vimrc was read first and afterwards,
if gvim was lunched, the gvimrc. I kept only gui specific stuff in
gvimrc such as:
set guioptions-=m
set guioptions-=T
set guioptions-=r
set guifont=Terminus\ 12
set lines=50
set columns=100
Is this normal behaviour? I remember reading that vimrc had
precedence and don't remember seeing any notes about gvim
overwritting some of the stuff there.
Or if you don't want to bother with a gvimrc just for that, use the
following in your vimrc:
set vb t_vb=
if has('+autocmd') exists('##GUIEnter')
au GUIEnter * set t_vb=
endif
And on another note, which didn't concern ports@, this exemple has no
effect apparently.
It would be pretty cool if I could keep all my gui and non-gui stuff in
one single file with something similar to what you described here.
Can you please point me to some related :he pages?
Best regards,
Tony.
Thanks for clearing things up a bit.
Paul.
