Re: tips project
> Tom Purl * 3/1/2007 7:04 PM : >>> Okay, so now I am really an "outsider" to this whole issue as in that I >>> have just been following the whole thread with interest because i >>> regularly check vim tips/scripts at vim.org ... >> >> For more information of where people are right now, check the mailing >> list >> archive for a thread titled "VimTips - Google Wiki Usefulness". > Actually, I followed that other thread you mention - "VimTips - Google > Wiki Usefulness", and unless I missed something, people seem to agree > that requiring to register will not be a good idea, and will decrease > a number of useful tips. At least I haven't seen anyone argue the > opposite. I don't think that anyone has a problem with requiring wiki users to log in. The problem is that we don't want to set the bar too high, and the Google wiki requires potential editors to jump through far too many hoops just to register. > I thought there was talk about wikimedia and wikibooks, but then i saw > these messages about google's wiki again. How come? Because we don't want to rush the decision, and are considering all possibilities. Since the tips are probably going to be hosted on this wiki for quite a while, we all want to be happy with the decision that we make. > I'd argue that we should not even do the wiki and add more people to > administer the tips (to get rid of spam) if need be, as opposed to doing > the wiki which might discourage others from updating. Bram seems to be in favor of a wiki for the tips (or at least in favor of trying it out, I may be mistaken), and a lot of other Vim community members seems to think that it's a good idea. Of course, that doesn't mean that they're right, but that does mean that it's highly likely that the tips will be converted to a wiki sometime soon. Thanks! Tom Purl
Problem when formatting commented text
Hi all :) Probably you've noticed that I'm used to indent the first line of the paragraphs I write. I'm sooo used to do this that I'm not doing it conciously, so I do it on comments, too. The thing is that I've set 'fo+=2' to use the intentation from the second line of a para, not the first, and it works perfectly... as long as there are no comment leader on the line. If there are a comment leader, and even though I have 'fo+=c', the comment leader is properly placed but all lines have the same indentation: that of the FIRST line. Moreover, sometimes only the first line is reformatted (using the indent) while the rest are not (that happens in mail filetype, for example). I can post examples here if I haven't explained all this properly. Can I fix this tweaking 'fo', or 'comments', etc., or should I use 'formatexpr' or even an external formatter (like par)? Thanks a lot in advance : Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: Is this normal?
Hi Tony :) * A.J.Mechelynck <[EMAIL PROTECTED]> dixit: > DervishD wrote: > >Is this normal? Is it caused by 'virtualedit'? I've observed this > >behaviour in my own compiled version of Vim and in the packaged one > >in Debian, at least, and I'm just curious. > > It is normal and it has nothing to do with 'virtualedit'. If you place > the cursor intentionally "at the end" of a line, using in Insert > mode, or $ in Normal mode, etc., then moving the cursor up and > down keeps it at the end of the line. See at the end of the ":help > up-down-motions" section: I was looking at ":help ", in 'motion.txt' instead... My bad O:)) Thanks a lot for pointing to the explanation :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: Is this normal?
DervishD wrote: Hi all :) This is not a bug report, it's just I'm curious about a behaviour I've observed in vim, and I would like to know if this is the correct behaviour or if some of my mappings may be causing the effect. Let's say I have these two lines in a file: this is one line this is another line, longer If I'm in insert mode and I put the cursor in the first line and then I hit , the cursor is placed after the "e" in "line". Then, if I press , the cursor goes after the "r" in "longer" (I wanted to put it on the "l" in "line", in the second line). If instead of I use $, this doesn't happen, and in normal mode, it doesn't happen even using . Is this normal? Is it caused by 'virtualedit'? I've observed this behaviour in my own compiled version of Vim and in the packaged one in Debian, at least, and I'm just curious. Thanks! Raúl Núñez de Arenas Coronado It is normal and it has nothing to do with 'virtualedit'. If you place the cursor intentionally "at the end" of a line, using in Insert mode, or $ in Normal mode, etc., then moving the cursor up and down keeps it at the end of the line. See at the end of the ":help up-down-motions" section: These commands move to the specified line. They stop when reaching the first or the last line. The first two commands put the cursor in the same column (if possible) as it was after the last command that changed the column, except after the "$" command, then the cursor will be put on the last character of the line. ( is synonymous with $). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 82. AT&T names you Customer of the Month for the third consecutive time.
Re: Problem with C/C++ syntax folding
Jay Atkinson wrote: > I seem to be having a problem with the default syntax folding in Vim 7.0. > The syntax folding seems to get confused whenever there is a statement like > this: > > a = (b == 0) ? 1 : 2; > > After a statement like that, the folding just collapses everything after > that statement into one fold. It normally highlights all the following > curly braces in red as well. Has anyone stumbled across this problem and > come up with a fix? It appears to work fine for me. Try this: vim -u NONE yourfile.c source $VIMRUNTIME/syntax/c.vim set foldmethod=syntax Does it still happen then? If not then you have something added to the C syntax that causes the problem. -- hundred-and-one symptoms of being an internet addict: 241. You try to look for Net Search even when you're in File Manager. /// 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: Unicode U+2028 line separator
Matthew Winn wrote: On Fri, 02 Mar 2007 20:24:44 +0100, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: Bill Moseley wrote: I have a utf-8 file that uses the unicode line separator. Not something I've come across very often. In utf-8 the sequence is: 0xE2 0x80 0xA8 (e280a8) In a uxterm vim correctly reads (and sets) the file encoding as utf8 (there's no BOM on the file), but the U-2028 character is displayed as an un-displayable character and not displayed as a new line. That is, all the text is displayed as a single line. Can anyone educate me a bit on the use of the Line Separator character and if or how it can be supported in Vim? I may be wrong, but IIUC this codepoint plays the same role as the HTML tag: it does not define an "end of line" in the text file which contains it, but it means that, when rendered typographically, as in a browser or a WYSIWYG editor (neither of which Vim is, or tries to mimic), the rendered output must have a linebreak at this point. IOW: I think it's a feature, not a bug. You can add a linebreak after every occurrence of that codepoint by using :exe "%s/\/" . '\0\r/g' Note that I intentionally use double quotes in the first part and single quotes in the second part. According to http://www.unicode.org/reports/tr13/tr13-9.html the correct way to treat U+2028 and U+2029 (paragraph separator) is to translate them into the platform's standard sequence for representing the end of a line. (What it actually says is that if the purpose of the line break is unambiguously known -- that is, whether it is the end of a line or the end of a paragraph -- then the corresponding Unicode character should be used. But Vim is a text editor and knows nothing of paragraphs, so I would expect both these characters to be translated into the platform's end-of-line representation.) However, this would be lossy, so if this were to be implemented I suspect an option would be required for the benefit of people who want to edit Unicode text without losing the distinction between line and paragraph endings. That's why I suggested adding an ASCII linebreak after the LSEP, not replacing it. Best regards, Tony. -- There was a young lady from Maine Who claimed she had men on her brain. But you knew from the view, As her abdomen grew, It was not on her brain that he'd lain.
Is this normal?
Hi all :) This is not a bug report, it's just I'm curious about a behaviour I've observed in vim, and I would like to know if this is the correct behaviour or if some of my mappings may be causing the effect. Let's say I have these two lines in a file: this is one line this is another line, longer If I'm in insert mode and I put the cursor in the first line and then I hit , the cursor is placed after the "e" in "line". Then, if I press , the cursor goes after the "r" in "longer" (I wanted to put it on the "l" in "line", in the second line). If instead of I use $, this doesn't happen, and in normal mode, it doesn't happen even using . Is this normal? Is it caused by 'virtualedit'? I've observed this behaviour in my own compiled version of Vim and in the packaged one in Debian, at least, and I'm just curious. Thanks! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: hi Comment guifg=white guibg=black in ~/.vimrc ignored
Hi Tony, On Fri, 2007-03-02 at 10:52 +0100, A.J.Mechelynck wrote: > Mark Woodward wrote: > > Hi alex, > > > > On Thu, 2007-03-01 at 16:33 +0100, Alexander Farber wrote: > >> Hello Hugh, > >> > >> On 3/1/07, Hugh Sasse <[EMAIL PROTECTED]> wrote: > >>> :scriptnames > >> 1: C:\Documents and Settings\afarber\.vimrc > >> 2: C:\Program Files\Vim\vim70\syntax\syntax.vim > >> 3: C:\Program Files\Vim\vim70\syntax\synload.vim > >> 4: C:\Program Files\Vim\vim70\syntax\syncolor.vim > >> 5: C:\Program Files\Vim\vim70\filetype.vim > >> 6: C:\Program Files\Vim\vim70\menu.vim > >> 7: C:\Program Files\Vim\vim70\autoload\paste.vim > >> 8: C:\Program Files\Vim\vim70\plugin\getscript.vim > >> 9: C:\Program Files\Vim\vim70\plugin\gzip.vim > >> 10: C:\Program Files\Vim\vim70\plugin\matchparen.vim > >> 11: C:\Program Files\Vim\vim70\plugin\netrwPlugin.vim > >> 12: C:\Program Files\Vim\vim70\plugin\rrhelper.vim > >> 13: C:\Program Files\Vim\vim70\plugin\spellfile.vim > >> 14: C:\Program Files\Vim\vim70\plugin\tarPlugin.vim > >> 15: C:\Program Files\Vim\vim70\plugin\tohtml.vim > >> 16: C:\Program Files\Vim\vim70\plugin\vimballPlugin.vim > >> 17: C:\Program Files\Vim\vim70\plugin\zipPlugin.vim > >> 18: C:\Program Files\Vim\vim70\syntax\actionscript.vim > > > > Is this Vim or gVim? > > If the later, where's the .gvimrc file? > > If the former, putting guifg=... in the .vimrc is meaningless. > > > > If you're using gVim create a .gvimrc file in the same directory as > > the .vimrc. Place the guifg=... stuff in there. > > > > What is the output of scriptnames now? > > Is the syntax as you'd like it now? > > > > > > cheers, > > > > > > It's perfectly possible to run gvim with no gvimrc (it does source the > vimrc). > ":highlight" commands would sit better in a colorscheme, but regardless of > whether they're in a colorscheme or in the vimrc, it's possible to set both > cterm[bf]g= and gui[bf]g= (and term= if deemed necessary) in the same ":hi" > command. > > IIUC, ":syntax on" resets all colors, re-invoking the current colorscheme if > any: thus it's usually less problematic to define colors in a colorscheme. > (When default colors are OK, the corresponding highlight groups can be > omitted.) > > See (attached) an example colorscheme, which is the one I use for my > day-to-day editing. It may help you design your own. To use this one, drop it > in ~/.vim/colors and add > > colorscheme almost-default > > to your vimrc. > > > Best regards, > Tony. I agree gui hi can be set in the _vimrc file. However: However when I enter ":verbose hi Comment" I get: Commentxxx term=bold ctermfg=1 guifg=Blue Last set from C:\Program Files\Vim\vim70\syntax\syncolor.vim If the OP had a _gvimrc file it would be sources after the runtime syntax files: /home/mark/.vimrc /home/mark/.vim/filetype.vim /usr/local/share/vim/vim70/filetype.vim /home/mark/.vim/ftdetect/ruby.vim /usr/local/share/vim/vim70/menu.vim /usr/local/share/vim/vim70/autoload/paste.vim /home/mark/.vim/after/filetype.vim /usr/local/share/vim/vim70/ftplugin.vim /usr/local/share/vim/vim70/indent.vim /usr/local/share/vim/vim70/syntax/syntax.vim /usr/local/share/vim/vim70/syntax/synload.vim /usr/local/share/vim/vim70/syntax/syncolor.vim < /home/mark/.vim/plugin/curr_word.vim /home/mark/.vim/plugin/imaps.vim /home/mark/.vim/plugin/matchit.vim /home/mark/.vim/plugin/netrwPlugin.vim /home/mark/.vim/plugin/project.vim /home/mark/.vim/plugin/rails.vim /home/mark/.vim/plugin/rcodetools.vim /home/mark/.vim/plugin/taglist.vim /usr/local/share/vim/vim70/plugin/getscript.vim /usr/local/share/vim/vim70/plugin/getscriptPlugin.vim /usr/local/share/vim/vim70/plugin/gzip.vim /usr/local/share/vim/vim70/plugin/matchparen.vim /usr/local/share/vim/vim70/plugin/netrwPlugin.vim /usr/local/share/vim/vim70/plugin/rrhelper.vim /usr/local/share/vim/vim70/plugin/spellfile.vim /usr/local/share/vim/vim70/plugin/tarPlugin.vim /usr/local/share/vim/vim70/plugin/tohtml.vim /usr/local/share/vim/vim70/plugin/vimballPlugin.vim /usr/local/share/vim/vim70/plugin/zipPlugin.vim /home/mark/.gvimrc < /home/mark/.vim/after/color/tweak.vim ... I only source tweak.vim from .gvimrc and like you it's just a 'tweak' of the default colors. For some filetypes (ruby for eg) I have a ruby_cols.vim file in ~/after/ftplugin/ that contains specific hi commands: eg rubyBoolean, rubyComment, rubyDocumentation, rubyData, rubyStringDelimiter, rubyString, rubyNoInterpolation, rubyPseudoVariable, rubyInteger, rubyASCIICode, rubyFloat, rubyEscape, rubyInterpolation, rubyDataDirective, rubyOperator, which basically means I can go overboard tweaking ruby syntax ;-) cheers, -- Mark
Re: Unicode U+2028 line separator
On Fri, 02 Mar 2007 20:24:44 +0100, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: > Bill Moseley wrote: > > I have a utf-8 file that uses the unicode line separator. Not > > something I've come across very often. In utf-8 the sequence is: > > > > 0xE2 0x80 0xA8 (e280a8) > > > > In a uxterm vim correctly reads (and sets) the file encoding as utf8 > > (there's no BOM on the file), but the U-2028 character is displayed > > as an un-displayable character and not displayed as a new line. > > That is, all the text is displayed as a single line. > > > > Can anyone educate me a bit on the use of the Line Separator character > > and if or how it can be supported in Vim? > > I may be wrong, but IIUC this codepoint plays the same role as the HTML > tag: it does not define an "end of line" in the text file which contains it, > but it means that, when rendered typographically, as in a browser or a > WYSIWYG > editor (neither of which Vim is, or tries to mimic), the rendered output must > have a linebreak at this point. > > IOW: I think it's a feature, not a bug. > > You can add a linebreak after every occurrence of that codepoint by using > > :exe "%s/\/" . '\0\r/g' > > Note that I intentionally use double quotes in the first part and single > quotes in the second part. According to http://www.unicode.org/reports/tr13/tr13-9.html the correct way to treat U+2028 and U+2029 (paragraph separator) is to translate them into the platform's standard sequence for representing the end of a line. (What it actually says is that if the purpose of the line break is unambiguously known -- that is, whether it is the end of a line or the end of a paragraph -- then the corresponding Unicode character should be used. But Vim is a text editor and knows nothing of paragraphs, so I would expect both these characters to be translated into the platform's end-of-line representation.) However, this would be lossy, so if this were to be implemented I suspect an option would be required for the benefit of people who want to edit Unicode text without losing the distinction between line and paragraph endings. -- Matthew Winn
