Bug in completion
Hi All, I see the following bug: 1. Open Vim, and vertically split into two windows. 2. File name complete something with very long file names (longer than the width of the window you're typing into). The screen is hodge podge. There are uncleared pieces of the completion menu left on the screen (on top of the other buffer). I'm using Vim 7.1a (sorry, haven't tested with 7.1b yet). GI -- 'Selfishness' -- Not being considerate of other people's selfishness.
Re: [Announcement] Subversion repository location changed
On Wed, May 09, 2007 at 02:20:52PM -0700, Micah Cowan wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? I got the same error. My response was rm -rf vim7 svn co https://svn.sourceforge.net/svnroot/vim/trunk vim7 I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? I hope so :) GI -- Top Ten New Intel Slogans For The Pentium: 6.831538 You Don't Need to Know What's Inside
Re: vim_is_xterm() and screen
On Tue, May 08, 2007 at 03:04:10PM -0700, Micah Cowan wrote: It's about time termcap/terminfo gets updated to support the features we need, instead of hacking solutions in all programs. I'm afraid I don't have time for this (the original development of termcap was closely related to the early development of vi). But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. I agree that fixing terminfo is the right solution, but that doesn't mean you shouldn't hack the working solution in now. You have already done so, or you wouldn't have any mouse support for the various xterm-like consoles in the first place. I'd be happy to write the patch (it should be pretty straightforward); I just want to get some agreement on the correct action to take. I for one would *love* to see this. I use mrxvt all the time. The terminal codes for mrxvt are somewhere between xterm and rxvt, thus mrxvt should have its own terminal type. However a *lot* of programs (including Vim and w3m) simply refuse to use the mouse if the terminal name is not rxvt or xterm. The ugly hack used my mrxvt right now is to install it's terminfo entry under the name rxvt! Numerous mrxvt users have complained about this. It would be nice if things could be made to work correctly with other terminals. GI PS: Mrxvt's mouse reporting is the same as the old xterm style mouse reporting. -- Reading while sunbathing makes you well-red.
Re: Highlighting keywords from C libraries
On Thu, Feb 22, 2007 at 03:19:24AM +0900, Kazunobu Kuriyama wrote: snip I attach a modified c.vim syntax file (minor changes to accommodate the modular structure above), and glibc.vim, xlib.vim (which should be put inside syntax/clibs/) to highlight functions and constants from glibc and xlib respectively. I'm afraid this is not a good idea; c.vim should not depend on any set of the symbols which come from the particular implementation of an arbitrarily chosen C library. To be more specific, I can't see any good reason why I have to give up highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, unless I use glibc.vim together with c.vim. I strongly believe that all symbols defined in the *standard* C library must remain in c.vim. Also, I hardly imagine a situation where all C library symbols are needed at a time to highlight a file in a buffer. For example, it is annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn are highlighted even if math.h is irrelevant that file. Well, I think that all symbols defined in the *standard* C library should be included in say libc.vim. I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. Lastly, I'm afraid that, since C library functions are so common, highlighting them would rather kill the purposes and effects of highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. GI -- 'Common' Proof Techniques: 14. Proof by eminent authority -- I saw Karp in the elevator and he said it was probably NP-complete.
Re: Highlighting keywords from C libraries
On Wed, Feb 21, 2007 at 10:07:22AM -0600, Bill McCarthy wrote: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. This is a nice addition that I would like to see included. I noticed that you patched c.vim against an older version. The current version is dated Feb 13, 2007. Sorry. I did this sometime last year, and completely forgot about it. After seeing Bram at Google, and the video of his talk yesterday I got reminded and sent it off to the list. If it looks like it's going to be included with Vim, I'll of course update to the latest version and write appropriate documentation. GI -- An Apple a day, keeps Windows away.
Re: Highlighting keywords from C libraries
On Thu, Feb 22, 2007 at 07:39:50AM +0900, Kazunobu Kuriyama wrote: snip I attach a modified c.vim syntax file (minor changes to accommodate the modular structure above), and glibc.vim, xlib.vim (which should be put inside syntax/clibs/) to highlight functions and constants from glibc and xlib respectively. I'm afraid this is not a good idea; c.vim should not depend on any set of the symbols which come from the particular implementation of an arbitrarily chosen C library. To be more specific, I can't see any good reason why I have to give up highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, unless I use glibc.vim together with c.vim. I strongly believe that all symbols defined in the *standard* C library must remain in c.vim. Also, I hardly imagine a situation where all C library symbols are needed at a time to highlight a file in a buffer. For example, it is annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn are highlighted even if math.h is irrelevant that file. Well, I think that all symbols defined in the *standard* C library should be included in say libc.vim. I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. I guess you could easily find someone around you who has a standard C library reference. Can't you borrow one from a public library or somewhere else, if not online... Theres no way I'm going to type in by hand all standard C keywords. If I can generate it easily from an online reference, I'll do that. I couldn't, so I did glibc from the info page instead. Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. It would be better to take into consideration those who source the current c.vim in their vim scripts. Are you sure that your proposed modularization scheme give little or no harm to such user scripts? It's not obvious to me. What's your prospect? Yes. Read the modification. All it does is define one new cluster, and include all files in the syntax/clibs directory PROVIDED some Vim variables are defined. If those variables are not defined, the syntax/clibs files are ignored, and c.vim should behave as it did earlier. (The commented out symbols you pointed out in your previous message will be added to a stdc.vim soon). Lastly, I'm afraid that, since C library functions are so common, highlighting them would rather kill the purposes and effects of highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. But once your syntax files are included in run time, poor users have to either follow your taste all along or reject it completely. Why not give them a middle ground? The proposed structure will surely give such flexibility as you claim, but I don't feel the syntax files you have proposed are written in such a way that they actually comply with your claim. Have you read the attached syntax files? They do exactly what I claimed. (Read glibc.vim with fdm=marker, and you will see). I still don't understand why familiar C library function calls ought to catch our eyes; it could be sometimes sort of distraction for some people. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. I don't think this is the right purpose of highlighting. It would be sometimes extremely harmful as much. If there are two or more similar names, you can't tell one from others only by highlighting. If it should pass compilation, you would surely get extremely frustrated to spot a bug, because you would wrongly keep believing you had chosen the right name. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. I rather want to highlight something I need to pay
Re: Quickfix window not working anymore
On Mon, Feb 19, 2007 at 02:21:49PM +0100, A.J.Mechelynck wrote: I just upgraded to Vim-7.0.195, and found that my quick fix bindings don't work any more. For instance :vimgrep /pattern/ *.c :copen Then pressing Enter on a particular error does not move to that error location quick fix window. The same happens if instead of vimgrep I use :grep or :make. Does any one else have this problem? Works for me. Hmm. It works for me in gvim, and console Vim in xterm. Looks like a problem with my terminal emulator, which I'll fix :). Thanks, GI -- I'm pink therefore I'm Spam.
Keyword completion
Hi All, Maybe this has been discussed already: When pressing Ctrl-P / Ctrl-N, can we get vim to complete from the list of syntax keywords? Better still say from a specified group? Or does one have to write out these keywords separately in a completion file? Thanks, GI -- A hangover is the wrath of grapes.
Re: [vim-dev] Re: Keyword completion
On Wed, Sep 20, 2006 at 10:41:58PM +0200, Martin Stubenschrott wrote: Maybe this has been discussed already: When pressing Ctrl-P / Ctrl-N, can we get vim to complete from the list of syntax keywords? You can do that by setting: :set omnifunc=syntaxcomplete#Complete and then use c-xc-o You can also specifiy certain syntax groups too use, but look into the docs/scripts, how to do that. Great! Thanks, Gautam -- 'Common' Proof Techniques: 10. Proof by cumbersome notation -- Best done with access to at least four alphabets and special symbols.
Re: vim mailing lists
On Fri, Sep 01, 2006 at 10:18:35PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? The plan was to move the maillists to the server that is now already the Vim mail server. And the one causing this blacklist trouble... There is no progress in moving the maillists. I suppose it's time to find a better place for the Vim mail server. Instead of a server that just happens to be available and run by someone who doesn't always respond, or some big and anonymous server park like Yahoo, I think we should look for a small site that does have 24 hour support. How about the sourceforge mailing lists? I know sourceforge has had numerous failures in the past. But I think their mailing lists might be OK. Features missing (at least): - When someone is not subscribed the message should bounce, not sent to the maillist owner. (I have to manually remove spam stuff from the a-a-p lists regularly). - Messages with just HTML, executable attachments etc. should be bounced. These rules must be configurable. - Loading all the old messages into the archive, so that searches find them. Bram, I just set up a new mailing list on SF. I think the above features are there on the version of mailman they just installed. Gautam -- 'Fortissimoe' -- The musical moment produced when someone serially slaps the faces of the first violin section.
Re: better recognising of tex vs plaintex filetype
On Wed, Aug 30, 2006 at 07:17:16PM +0200, Stefano Zacchiroli wrote: I agree with the comment that plain TeX users may also define such sectioning commands. Maybe it would be safe if you check for such definitions, using an include-file search ... but of course, that is more convenient after ftplugin/plaintex.vim has been :source'd. I'm not really fond of plain TeX, but I think it is not really widespread to \input slices of plain TeX. So the idea mentioned in this thread was to implement the policy: if a document starts with a lot of blanks followed by one of the possible LaTeX sectioning commands, then it is (probably) a LaTeX source file. What do you think of this policy? I actually like this policy a lot. Most people who break latex files up into tonnes and tonnes of little files, do so based on sections. Odds are, that the little files will begin with a bunch of comments, and a sectioning command. It would make life easier if this made it into filetype.vim. Especially because changing g:tex_flavor means that every time I edit a plain tex file, I need to unlet this variable. GI -- 'Common' Proof Techniques: 13. Proof by wishful citation -- The author cites the negation, converse, or generalization of a theorem from the literature to support his claims.
Re: vim mailing lists
On Wed, Aug 30, 2006 at 10:12:44PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? The plan was to move the maillists to the server that is now already the Vim mail server. And the one causing this blacklist trouble... There is no progress in moving the maillists. I suppose it's time to find a better place for the Vim mail server. Instead of a server that just happens to be available and run by someone who doesn't always respond, or some big and anonymous server park like Yahoo, I think we should look for a small site that does have 24 hour support. How about the sourceforge mailing lists? I know sourceforge has had numerous failures in the past. But I think their mailing lists might be OK. Plus the vim CVS / subversion repositories are hosted there anyway, GI -- ACTUAL LABEL INSTRUCTIONS ON CONSUMER GOODS: On Marks Spencer Bread Pudding: Product will be hot after heating.
folding error for C files
Hi Bram,
I noticed the following problem when typing C files: If you enter a {
on the last line of a file, and press enter, then the last two lines
become a closed fold *CONTAINING* the cursor. You can not see the
cursor, or the { in the previous line, until you type some text. At
that point the fold opens, and works as it should.
The problem does not occur if you type a { anywhere except on the last
line of the file.
I'm using Vim7 from subversion, and syntax folding.
GI
--
Twenty Ways To Maintain A Healthy Level of Insanity
17. When the money comes out the ATM, scream I won! I won!
Re: How to trigger a screen update from RealWaitForChar
On Thu, Aug 17, 2006 at 11:35:09PM -0700, Brad Beveridge wrote: Hi all, I'm working with a Vim that has been hacked so that you can get callbacks when data appears on a socket. Basically, our callback system works in pretty much the same way as the code in FEAT_SNIFF. We add the filedescriptors that we are interested in to the select/poll code in os_unix, if there is data pending on a socket then we callback a registered function, which should clear the data from the socket. In my particular case, the callback calls into Lisp code in our embedded Lisp interpreter, which writes data to buffers using ml_replace and ml_append. [snip] Q4) Would this callback mechanism be more generally useful for other scripting engines? Hi Brad, I'm not sure about other scripting engines -- But I can certainly think of one very good use: Poling for email :). If you add /var/spool/mail/uname to the select'ed file descriptors, then it would be nice to have a little message line pop up saying You have new mail. I know this can be done using biff / xbiff / kbiff, etc. But I much prefer a vimbiff :-). GI -- When an actress saw her first strands of gray hair, she thought she'd dye.
Re: foldmethod=expr very slow
On Mon, Jul 24, 2006 at 12:30:07PM -0500, Thore B. Karlsen wrote:
I use foldmethod=expr with the following foldexpr:
set foldexpr=GetFoldLevel(v:lnum)
function! GetFoldLevel(line)
let line_text = getline(a:line)
if (line_text =~ '\%({.*}\)\|\%(}.*{\)')
return '='
elseif (line_text =~ '{')
return a1
elseif (line_text =~ '}')
return s1
endif
return '='
endfunction
I haven't read the above too carefully: But if all you want to do is
fold your code based on {...} blocks, then use Vim 7 and set fdm=syntax
(for C / C++ files).
Incidentally, fdm=syntax is also slow (though much much faster than
fdm=expr). I could (grudgingly) live with a short delay when first
loading the file. The thing that bothers me is that when I switch
between buffers, Vim takes it's own sweet time to get the syntax based
folding right.
So I only enable syntax folding for files that have less than 3000
lines. Once my clever spies steal Benji Fisher's computer, I'm going to
up this limit to 18000.
GI
--
You're not drunk if you can lie on the floor without holding on.
Re: [BUG] Swap file searched for in the wrong place
On Fri, May 19, 2006 at 08:29:48PM +0200, A.J.Mechelynck wrote: Now when you type vim /tmp/bar it reports that a .swp file is found and asks you about recovery. However when you press R for recovering the file, vim complains saying it can not find the swap file (probably because vim looks for the swap file in /tmp, instead of in /tmp/foo). This appears to be fixed in vim7. I'm using Vim-7.017, and it's not fixed! Is there a more recent version? No, that's the current patchlevel. However: - The 'directory' option (q.v.) directs where the swap file shall reside - If you are reopening it with a different login name, there could be a permissions problem. Well, I certainly did not open the file with a different log in name. Also regardless of the 'directory' setting, I find it very strange (i.e. bug like) if Vim first asks me if I want to recover a file, and when I say yes, Vim tells me it can't find the swap file anymore ... Another possibility: Did you by any chance have a zero-length swap file? Vim creates the swap file when you open a non-readonly edit file, but the swapfile remains zero-length until you make a change in the file. Nope! When I changed to actual directory of the file (and not the symlink), vim recovered the file perfectly! GI -- 'Worry' -- The interest you pay on trouble before it comes.
[BUG] Swap file searched for in the wrong place
Hi All, I found the following bug: $ mkdir /tmp/foo $ touch /tmp/foo/bar $ cd /tmp/ $ ln -s foo/bar . $ vim bar Now type some text into bar, and then kill vim (say with kill -9) from a different terminal. Now when you type vim /tmp/bar it reports that a .swp file is found and asks you about recovery. However when you press R for recovering the file, vim complains saying it can not find the swap file (probably because vim looks for the swap file in /tmp, instead of in /tmp/foo). GI -- Modern Computer Viruses: Politically Correct Virus -- Never calls itself a virus, but instead refers to itself as an electronic microorganism.
Re: [BUG] Swap file searched for in the wrong place
On Wed, May 17, 2006 at 10:31:55AM -0400, James Vega wrote: On Tue, May 16, 2006 at 11:19:57PM -0500, Gautam Iyer wrote: Now when you type vim /tmp/bar it reports that a .swp file is found and asks you about recovery. However when you press R for recovering the file, vim complains saying it can not find the swap file (probably because vim looks for the swap file in /tmp, instead of in /tmp/foo). This appears to be fixed in vim7. I'm using Vim-7.017, and it's not fixed! Is there a more recent version? Gautam -- With her marriage, she got a new name and a dress.
Re: Vim 7 pre-announcement
On Sun, May 07, 2006 at 05:58:08PM +0200, Bram Moolenaar wrote: Before announcing it everywhere I'll wait until the Subversion repository has it. And I need to update the website. Ooh. Subversion repository! Thanks using the SourceForge subversion facilities. The CVS is *still* broken, and I've been using the ancient 'c' version or something :). I just gleefully upgraded. Thanks for the wonderful Vim7, Gautam -- 'Atheist' -- Someone with no invisible means of support.
mrxvtrc filetype and syntax files
Hi Bram,
Attached are the filetype, syntax and ftdetect files for mrxvt config
files. Sorry I couldn't make your April 20th deadline ... but maybe you
can stick these in Vim-7.1 if they don't make the Vim-7.0 release.
Gautam
--
BTW, FWIW, IMHO, AFAIK, yes. OTOH, AAMOF, maybe not. YMMV.
Created : Wed 26 Apr 2006 01:20:53 AM CDT
Modified : Thu 27 Apr 2006 03:21:09 AM CDT
Author: Gautam Iyer [EMAIL PROTECTED]
Description : Syntax file for mrxvtrc
Quit when a syntax file was already loaded
if exists(b:current_syntax)
finish
endif
Define options.
let s:boolOpts =
'(highlightTabOnBell|syncTabTitle|hideTabbar|autohideTabbar|bottomTabbar|hideButtons|syncTabIcon|veryBoldFont|maximized|fullscreen|reverseVideo|loginShell|jumpScroll|scrollBar|scrollbarRight|scrollbarFloating|scrollTtyOutputInhibit|scrollTtyKeypress|scrollWithBuffer|transparent|transparentForce|transparentScrollbar|transparentMenubar|transparentTabbar|tabUsePixmap|utmpInhibit|visualBell|mapAlert|meta8|mouseWheelScrollPage|multibyte_cursor|tripleclickwords|showMenu|xft|xftNomFont|xftSlowOutput|xftAntialias|xftHinting|xftAutoHint|xftGlobalAdvance|tabShell|cmdAllTabs|cmdInitTabs|protectSecondary|thai|borderLess|overrideRedirect|holdExit|broadcast|smartResize|smoothResize|pointerBlank|cursorBlink|noSysConfig|disableMacros|linuxHomeEndKey|sessionMgt)'
let s:colorOpts =
'(vt\d+.(foreground|background)|background|foreground|ufBackground|textShadow|i?tab(Foreground|Background)|color([0-9]|1[0-5]|BD|UL|RV)|(scroll|trough|highlight|cursor|pointer|border|tint)Color|cursorColor2)'
let s:numOpts =
'(vt\d+.saveLines|maxTabWidth|minVisibleTabs|saveLines|scrollbarThickness|xftmSize|xftSize|desktop|externalBorder|internalBorder|lineSpace|pointerBlankDelay|cursorBlinkInterval|initTermNumber|shading|backgroundFade|bgRefreshInterval|fading|opacity|opacityDegree|xftPSize)'
let s:strOpts =
'(vt\d+\.(tabTitle|command)|tabTitle|termName|title|clientName|iconName|bellCommand|holdExitText|backspaceKey|deleteKey|printPipe|cutChars|answerbackString|smClientID|geometry|confFileSave|path|boldFont|m?font[1-5]?|xftFont|xftmFont|xftPFont|inputMethod|greektoggle_key|menu|menubarPixmap|vt\d+\.Pixmap|Pixmap|scrollbarPixmap|tabbarPixmap|appIcon|multichar_encoding)'
syn case match
syn match mrxvtComment[EMAIL PROTECTED] '^\s*!.*$'
syn match mrxvtComment'\v^\s*!\s*\w+[.*]\w+.*:.*'
Generic options (string / color / number / boolean)
syn match mrxvtOptErr '\v^\s*\w+[.*]?.{-}(:|$)'
exec 'syn match mrxvtBoolOpts nextgroup=mrxvtBoolVal,mrxvtValErr'
\ '\v^\w+[.*]'.s:boolOpts.':\s*'
exec 'syn match mrxvtNumOptsnextgroup=mrxvtNumVal,mrxvtValErr'
\ '\v^\w+[.*]'.s:numOpts.':\s*'
exec 'syn match mrxvtColorOpts nextgroup=mrxvtColorVal'
\ '\v^\w+[.*]'.s:colorOpts.':\s*'
exec 'syn match mrxvtStrOptsnextgroup=mrxvtStrVal,mrxvtValErr'
\ '\v^\w+[.*]'.s:strOpts.':\s*'
syn match mrxvtValErr contained '\v.+$'
syn match mrxvtBoolValcontained
\ '\v\c(0|1|yes|no|on|off|true|false)\s*$'
syn match mrxvtStrVal contained '\v.+$'
syn match mrxvtColorVal contained '\v#[0-9a-fA-F]{6}\s*$'
syn match mrxvtNumVal contained '\v[+-]?(0[0-7]+|\d+|0x[0-9a-fA-F]+)$'
Options with special values
syn match mrxvtOptionsnextgroup=mrxvtSBstyle,mrxvtValErr
\ '\v^\w+[.*]scrollbarStyle:\s*'
syn match mrxvtSBstylecontained '\v(plain|xterm|rxvt|next|sgi)$'
syn match mrxvtOptionsnextgroup=mrxvtSBalign,mrxvtValErr
\ '\v^\w+[.*]scrollbarAlign:\s*'
syn match mrxvtSBaligncontained '\v(top|bottom)$'
syn match mrxvtOptionsnextgroup=mrxvtTSmode,mrxvtValErr
\ '\v^\w+[.*]textShadowMode:\s*'
syn match mrxvtTSmode contained
\ '\v(none|(top|bot)?(left|right)|(top|bottom))$'
syn match mrxvtOptionsnextgroup=mrxvtGrkKbd,mrxvtValErr
\ '\v^\w+[.*]greek_keyboard:\s*'
syn match mrxvtGrkKbd contained '\v(iso|ibm)$'
syn match mrxvtOptionsnextgroup=mrxvtXftWt,mrxvtValErr
\ '\v^\w+[.*]xftWeight:\s*'
syn match mrxvtXftWt contained '\v(light|medium|bold)$'
syn match mrxvtOptionsnextgroup=mrxvtXftSl,mrxvtValErr
\ '\v^\w+[.*]xftSlant:\s*'
syn match mrxvtXftSl contained '\v(roman|italic|oblique)$'
syn match mrxvtOptionsnextgroup=mrxvtXftWd,mrxvtValErr
\ '\v^\w+[.*]xftWidth:\s*'
syn match mrxvtXftWd contained
\ '\v((ultra)?(condensed|expanded)|normal)$'
syn match mrxvtOptionsnextgroup=mrxvtXftHt,mrxvtValErr
\ '\v^\w+[.*]xftRGBA:\s*'
syn match mrxvtXftHt contained '\v(v?(rgb|bgr)|none
Re: mrxvtrc filetype and syntax files
On Thu, Apr 27, 2006 at 11:35:52AM +0200, Nikolai Weibull wrote: On 4/27/06, Gautam Iyer [EMAIL PROTECTED] wrote: Attached are the filetype, syntax and ftdetect files for mrxvt config files. Sorry I couldn't make your April 20th deadline ... but maybe you can stick these in Vim-7.1 if they don't make the Vim-7.0 release. Just a comment on the syntax definition. You could be using :syn-keyword for quite a few of the things that you're currently using :syn-match for. :syn-keyword is clearer and a lot faster as well. Hi Nicolai, Thanks for pointing this out, I'll correct it. Since Benji Fisher's computer is 6 times faster than mine (which I'm still envious about), I'll jump through hoops to get my Vim to load up 0.1s faster ... :) :). Gautam -- A physics professor is one who talks in someone else's sleep.
Re: mrxvtrc filetype and syntax files
On Thu, Apr 27, 2006 at 09:40:56PM +0200, Nikolai Weibull wrote: On 4/27/06, Gautam Iyer [EMAIL PROTECTED] wrote: On Thu, Apr 27, 2006 at 11:35:52AM +0200, Nikolai Weibull wrote: Just a comment on the syntax definition. You could be using :syn-keyword for quite a few of the things that you're currently using :syn-match for. :syn-keyword is clearer and a lot faster as well. Hi Nicolai, Hi. I'm curious, why did you spell my name with a 'c'? During the last couple of days, people have called me Nicholas, Niklas, and twice Nicolai. I see a conspiracy forming... Well if Vim does not flag it as a spell error, I don't give it a second thought. Though I'm knot quiet clear weather this algorithm always leads two the write spelling. :) GI -- 'Television' -- The electronic device that alternates between extreme violence and finding great long-distance rates.
C syntax folding #if-0 omission
Hi Bram,
I just checked out C folding in Vim 7. Thanks a TON, it works great.
Just one request though -- The #if 0 constructs don't get folded as
comments do.
I would suggest enabling / disabling folding of #if 0 constructs
independently of the c_no_comment_fold variable, since some people use
#if0's to hide old code ... :).
The updated syntax file is attached. It uses the c_no_if0_fold variable
for if0 folding. If you like it, some mention of this 'c_no_if0_fold'
variable should be made in the docs. If you don't like it, it get's
added to my ~/.vim/after/syntax folder ... :)
Thanks,
Gautam
--
Sign in a bar: Those drinking to forget please pay in advance.
Vim syntax file
Language: C
Maintainer: Bram Moolenaar [EMAIL PROTECTED]
Last Change: 2005 Jun 20
Quit when a (custom) syntax file was already loaded
if exists(b:current_syntax)
finish
endif
A bunch of useful C keywords
syn keyword cStatement goto break return continue asm
syn keyword cLabel case default
syn keyword cConditionalif else switch
syn keyword cRepeat while for do
syn keyword cTodo contained TODO FIXME XXX
cCommentGroup allows adding matches for special things in comments
syn cluster cCommentGroup contains=cTodo
String and Character constants
Highlight special characters (those which have a backslash) differently
syn match cSpecialdisplay contained \\\(x\x\+\|\o\{1,3}\|.\|$\)
if !exists(c_no_utf)
syn match cSpecialdisplay contained \\\(u\x\{4}\|U\x\{8}\)
endif
if exists(c_no_cformat)
syn regioncString start=+L\=+ skip=+\|\\+ end=++
contains=cSpecial,@Spell
cCppString: same as cString, but ends at end of line
syn regioncCppString start=+L\=+ skip=+\|\\\|\\$+ excludenl
end=++ end='$' contains=cSpecial,@Spell
else
syn match cFormat display %\(\d\+\$\)\=[-+'
#0*]*\(\d*\|\*\|\*\d\+\$\)\(\.\(\d*\|\*\|\*\d\+\$\)\)\=\([hlL]\|ll\)\=\([bdiuoxXDOUfeEgGcCsSpn]\|\[\^\=.[^]]*\]\)
contained
syn match cFormat display %% contained
syn regioncString start=+L\=+ skip=+\|\\+ end=++
contains=cSpecial,cFormat,@Spell
cCppString: same as cString, but ends at end of line
syn regioncCppString start=+L\=+ skip=+\|\\\|\\$+ excludenl
end=++ end='$' contains=cSpecial,cFormat,@Spell
endif
syn match cCharacter L\='[^\\]'
syn match cCharacter L'[^']*' contains=cSpecial
if exists(c_gnu)
syn match cSpecialError L\='\\[^'\?\\abefnrtv]'
syn match cSpecialCharacter L\='\\['\?\\abefnrtv]'
else
syn match cSpecialError L\='\\[^'\?\\abfnrtv]'
syn match cSpecialCharacter L\='\\['\?\\abfnrtv]'
endif
syn match cSpecialCharacter display L\='\\\o\{1,3}'
syn match cSpecialCharacter display '\\x\x\{1,2}'
syn match cSpecialCharacter display L'\\x\x\+'
when wanted, highlight trailing white space
if exists(c_space_errors)
if !exists(c_no_trail_space_error)
syn match cSpaceError display excludenl \s\+$
endif
if !exists(c_no_tab_space_error)
syn match cSpaceError display \+\tme=e-1
endif
endif
catch errors caused by wrong parenthesis and brackets
also accept % for {, % for }, : for [ and : for ] (C99)
But avoid matching ::.
syn cluster cParenGroup
contains=cParenError,cIncluded,cSpecial,cCommentSkip,cCommentString,cComment2String,@cCommentGroup,cCommentStartError,cUserCont,cUserLabel,cBitField,cCommentSkip,cOctalZero,cCppOut,cCppOut2,cCppSkip,cFormat,cNumber,cFloat,cOctal,cOctalError,cNumbersCom
if exists(c_no_curly_error)
syn regioncParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
cCppParen: same as cParen but ends at end-of-line; used in cDefine
syn regioncCppParen transparent start='(' skip='\\$' excludenl
end=')' end='$' contained contains=ALLBUT,@cParenGroup,cParen,cString,@Spell
syn match cParenError display )
syn match cErrInParen display contained ^[{}]\|^%\|^%
elseif exists(c_no_bracket_error)
syn regioncParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
cCppParen: same as cParen but ends at end-of-line; used in cDefine
syn regioncCppParen transparent start='(' skip='\\$' excludenl
end=')' end='$' contained contains=ALLBUT,@cParenGroup,cParen,cString,@Spell
syn match cParenError display )
syn match cErrInParen display contained [{}]\|%\|%
else
syn regioncParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cErrInBracket,cCppBracket,cCppString,@Spell
cCppParen: same as cParen but ends at end-of-line; used in cDefine
syn regioncCppParen transparent start='(' skip='\\$' excludenl
end=')' end='$' contained
contains=ALLBUT,@cParenGroup,cErrInBracket,cParen,cBracket,cString,@Spell
syn match cParenError display
Re: Moderator for Vim Tips
On Wed, Apr 19, 2006 at 08:21:49PM -0400, Jeremy Conlin wrote: A few weeks (months?) ago a suggestion was made that the submissions to Vim tips be moderated. This is due to the address being used by spammers. Apparently nobody volunteered to do this because there are still inappropriate tips being submitted. I am willing to do this, but I don't have the expertise required to test all the tips. I can screen them to make sure they are appropriate. Would that agree with anyone? IMHO all a moderator should do is reject tips which are spam. The vim community can (and should) test the tips, vote on them, and post comments as desired :). Gautam -- 'eieio' -- A gross misspelling of the word 'farm'.
