Re: [PATCH] Upstart syntax file
Hi Bram,
Updated patch attached.
Thanks in advance.
Kind regards,
James.
On 18 March 2011 13:18, Bram Moolenaar b...@moolenaar.net wrote:
James Hunt wrote:
Hi Thedward,
Thanks for the suggestion! Updated patch attached.
I actually don't like changing 'iskeyword' in a syntax file, it has side
effects. E.g., users may change 'iskeyword' to find text in comments,
thus it doesn't have to match what the language defines as a keyword.
So the option name is confusing.
In this case, if you really want to include - in keywords (so that you
can use them with :syn keyword), please use:
:setlocal iskeyword+=-
--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Any sufficiently advanced bug is indistinguishable from a feature.
Rich Kulawiec
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff -urN vim73/runtime/filetype.vim vim73-MODIFIED//runtime/filetype.vim
--- vim73/runtime/filetype.vim 2010-08-03 21:44:00.0 +0100
+++ vim73-MODIFIED//runtime/filetype.vim 2011-03-21 10:34:53.513458148 +
@@ -113,6 +113,10 @@
au BufNewFile,BufRead .htaccess,/etc/httpd/*.conf setf apache
au BufNewFile,BufRead httpd.conf*,srm.conf*,access.conf*,apache.conf*,apache2.conf*,/etc/apache2/*.conf*,/etc/httpd/conf.d/*.conf* call s:StarSetf('apache')
+ Upstart (init(8)) config files
+au BufNewFile,BufRead /etc/init/*.conf setf upstart
+au BufNewFile,BufRead /etc/init/*.override setf upstart
+
XA65 MOS6510 cross assembler
au BufNewFile,BufRead *.a65 setf a65
diff -urN vim73/runtime/syntax/upstart.vim vim73-MODIFIED//runtime/syntax/upstart.vim
--- vim73/runtime/syntax/upstart.vim 1970-01-01 01:00:00.0 +0100
+++ vim73-MODIFIED//runtime/syntax/upstart.vim 2011-03-21 11:04:36.964721354 +
@@ -0,0 +1,112 @@
+ Vim syntax file
+ Language: Upstart job files
+ Maintainer: Michael Biebl bi...@debian.org
+ James Hunt james.h...@ubuntu.com
+ Last Change: 2011 Mar 21
+ License: GPL v2
+ Version: 0.4
+ Remark: Syntax highlighting for Upstart (init(8)) job files.
+
+ It is inspired by the initng syntax file and includes sh.vim to do the
+ highlighting of script blocks.
+
+if version 600
+ syntax clear
+elseif exists(b:current_syntax)
+ finish
+endif
+
+let is_bash = 1
+syn include @Shell syntax/sh.vim
+
+syn case match
+
+ avoid need to use 'match' for most events
+setlocal iskeyword+=-
+
+syn match upstartComment /#.*$/ contains=upstartTodo
+syn keyword upstartTodo TODO FIXME contained
+
+syn region upstartString start=// end=// skip=/\\/
+
+syn region upstartScript matchgroup=upstartStatement start=script end=end script contains=@upstartShellCluster
+
+syn cluster upstartShellCluster contains=@Shell
+
+ one argument
+syn keyword upstartStatement description author version instance expect
+syn keyword upstartStatement pid kill normal console env exit export
+syn keyword upstartStatement umask nice oom chroot chdir exec
+
+ two arguments
+syn keyword upstartStatement limit
+
+ one or more arguments (events)
+syn keyword upstartStatement emits
+
+syn keyword upstartStatement on start stop
+
+ flag, no parameter
+syn keyword upstartStatement respawn service instance manual debug task
+
+ prefix for exec or script
+syn keyword upstartOption pre-start post-start pre-stop post-stop
+
+ option for kill
+syn keyword upstartOption timeout
+ option for oom
+syn keyword upstartOption never
+ options for console
+syn keyword upstartOption output owner
+ options for expect
+syn keyword upstartOption fork daemon
+ options for limit
+syn keyword upstartOption unlimited
+
+ 'options' for start/stop on
+syn keyword upstartOption and or
+
+ Upstart itself and associated utilities
+syn keyword upstartEvent runlevel
+syn keyword upstartEvent started
+syn keyword upstartEvent starting
+syn keyword upstartEvent startup
+syn keyword upstartEvent stopped
+syn keyword upstartEvent stopping
+syn keyword upstartEvent control-alt-delete
+syn keyword upstartEvent keyboard-request
+syn keyword upstartEvent power-status-changed
+
+ D-Bus
+syn keyword upstartEvent dbus-activation
+
+ Display Manager (ie gdm)
+syn keyword upstartEvent desktop-session-start
+syn keyword upstartEvent login-session-start
+
+ mountall
+syn keyword upstartEvent all-swaps
+syn keyword upstartEvent filesystem
+syn keyword upstartEvent mounted
+syn keyword upstartEvent mounting
+syn keyword upstartEvent local-filesystems
+syn keyword upstartEvent remote-filesystems
+syn keyword
Re: [PATCH] Upstart syntax file
Hi Bram,
Hopefully the final update based on Thilos comment and also added in
support for recognizing user jobs in filetype.vim.
Kind regards,
James
On 18 March 2011 13:18, Bram Moolenaar b...@moolenaar.net wrote:
James Hunt wrote:
Hi Thedward,
Thanks for the suggestion! Updated patch attached.
I actually don't like changing 'iskeyword' in a syntax file, it has side
effects. E.g., users may change 'iskeyword' to find text in comments,
thus it doesn't have to match what the language defines as a keyword.
So the option name is confusing.
In this case, if you really want to include - in keywords (so that you
can use them with :syn keyword), please use:
:setlocal iskeyword+=-
--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Any sufficiently advanced bug is indistinguishable from a feature.
Rich Kulawiec
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff -urN vim73/runtime/filetype.vim vim73-MODIFIED//runtime/filetype.vim
--- vim73/runtime/filetype.vim 2010-08-03 21:44:00.0 +0100
+++ vim73-MODIFIED//runtime/filetype.vim 2011-03-21 11:15:47.235581916 +
@@ -113,6 +113,10 @@
au BufNewFile,BufRead .htaccess,/etc/httpd/*.conf setf apache
au BufNewFile,BufRead httpd.conf*,srm.conf*,access.conf*,apache.conf*,apache2.conf*,/etc/apache2/*.conf*,/etc/httpd/conf.d/*.conf* call s:StarSetf('apache')
+ Upstart (init(8)) config files
+au BufNewFile,BufRead */etc/init/*.conf,~/.init/*.conf setf upstart
+au BufNewFile,BufRead */etc/init/*.override,~/.init/*.override setf upstart
+
XA65 MOS6510 cross assembler
au BufNewFile,BufRead *.a65 setf a65
diff -urN vim73/runtime/syntax/upstart.vim vim73-MODIFIED//runtime/syntax/upstart.vim
--- vim73/runtime/syntax/upstart.vim 1970-01-01 01:00:00.0 +0100
+++ vim73-MODIFIED//runtime/syntax/upstart.vim 2011-03-21 11:04:36.964721354 +
@@ -0,0 +1,112 @@
+ Vim syntax file
+ Language: Upstart job files
+ Maintainer: Michael Biebl bi...@debian.org
+ James Hunt james.h...@ubuntu.com
+ Last Change: 2011 Mar 21
+ License: GPL v2
+ Version: 0.4
+ Remark: Syntax highlighting for Upstart (init(8)) job files.
+
+ It is inspired by the initng syntax file and includes sh.vim to do the
+ highlighting of script blocks.
+
+if version 600
+ syntax clear
+elseif exists(b:current_syntax)
+ finish
+endif
+
+let is_bash = 1
+syn include @Shell syntax/sh.vim
+
+syn case match
+
+ avoid need to use 'match' for most events
+setlocal iskeyword+=-
+
+syn match upstartComment /#.*$/ contains=upstartTodo
+syn keyword upstartTodo TODO FIXME contained
+
+syn region upstartString start=// end=// skip=/\\/
+
+syn region upstartScript matchgroup=upstartStatement start=script end=end script contains=@upstartShellCluster
+
+syn cluster upstartShellCluster contains=@Shell
+
+ one argument
+syn keyword upstartStatement description author version instance expect
+syn keyword upstartStatement pid kill normal console env exit export
+syn keyword upstartStatement umask nice oom chroot chdir exec
+
+ two arguments
+syn keyword upstartStatement limit
+
+ one or more arguments (events)
+syn keyword upstartStatement emits
+
+syn keyword upstartStatement on start stop
+
+ flag, no parameter
+syn keyword upstartStatement respawn service instance manual debug task
+
+ prefix for exec or script
+syn keyword upstartOption pre-start post-start pre-stop post-stop
+
+ option for kill
+syn keyword upstartOption timeout
+ option for oom
+syn keyword upstartOption never
+ options for console
+syn keyword upstartOption output owner
+ options for expect
+syn keyword upstartOption fork daemon
+ options for limit
+syn keyword upstartOption unlimited
+
+ 'options' for start/stop on
+syn keyword upstartOption and or
+
+ Upstart itself and associated utilities
+syn keyword upstartEvent runlevel
+syn keyword upstartEvent started
+syn keyword upstartEvent starting
+syn keyword upstartEvent startup
+syn keyword upstartEvent stopped
+syn keyword upstartEvent stopping
+syn keyword upstartEvent control-alt-delete
+syn keyword upstartEvent keyboard-request
+syn keyword upstartEvent power-status-changed
+
+ D-Bus
+syn keyword upstartEvent dbus-activation
+
+ Display Manager (ie gdm)
+syn keyword upstartEvent desktop-session-start
+syn keyword upstartEvent login-session-start
+
+ mountall
+syn keyword upstartEvent all-swaps
+syn keyword upstartEvent filesystem
+syn keyword upstartEvent mounted
+syn keyword
Weird highlightings after /pattern + ^f
Hi all, Here is what to do (tried on windows only): 1. gvim.exe -u NONE -U NONE -N 2. i(oge)esc 3. :se iscr 4. /(oge)^f 5. Now just go up/down, left/right and there will be weird highlightings everywhere Version: 7.3, 1-138 PS: Sorry if this has already been reported Dimitar Dimitrov -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Filename expansion bug in 7.3.138 on Windows?
On 21/03/2011 00:57, Gary Johnson wrote: On 2011-03-21, Andy Wokula wrote: Am 18.03.2011 15:33, schrieb Mike Williams: The Win32 file search functions search both the long and short versions of file names. When the short version of a file name is created any extension is limited to 3 characters. You can see this when you do a dir /x in a directory. See also: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/20/440918.aspx There are ...Ex() versions of the file search functions which on Win2008R2 and Win7 can ignore the short file names but that doesn't help with VIM on older versions of Windows. Mike D:\tempdir /X *.vim ... Verzeichnis von D:\temp 17.03.2011 20:44 2.645 ABC~1.VIMabc.vimdef 17.03.2011 20:44 2.645 GARYJ~1.VIM garyj.vim,v 2 Datei(en) 5.290 Bytes ... D:\temp That explains it, thanks for the link! That suggests that Vim would try to source a file named abc.vimdef in a user's plugin directory, so I tried that at home. Not only did vim not try to source abc.vimdef, it didn't try to source garyj.vim,v either. So at home, where I'm still running Windows Vim 7.3.3, I don't see the problem. I discovered the problem at work, where I think I was running Windows Vim 7.3.46 at the time and upgraded to Windows Vim 7.3.138 before reporting the problem. A quick spelunk through the source shows that VIM filters the results from the Windows find file with the original pattern, I imagine to try and solve this issue. However, a quick play in VIM (7.3.138, Win7 x64) seems to show different behaviour with :args *.vim based on the directory location. Doing :args *.vim in a runtimepath plugin directory filters out any files whose extension is more than just .vim, while doing it in a directory not in the runtimepath picks up the all files whose extension starts with .vim. This also happens with vim -u NONE -U NONE. This will need some time in a debugger to find out why there is a difference, unless someone more experienced with the Windows file handling code in VIM already knows what is happening. Mike -- Mind Like A Steel Trap - Rusty And Illegal In 37 States. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.137
Ah, confirmed. I can now reproduce it too on Linux with Vim-7.3.138 in the terminal as well as with gvim (gtk2) with: $ vim -u NONE -c 'set lazyredraw' ... then typing :verCR does not show anything. I just came here to say the same thing. :messages and probably other commands are also affected. Tom -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
trivial fix to comment in options.c
backspace -- backslash -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php # HG changeset patch # Parent ea399ac2c1b963b068beed88bfaff7620d345333 diff --git a/src/option.c b/src/option.c --- a/src/option.c +++ b/src/option.c @@ -4700,8 +4700,8 @@ || s[i] == ',' || s[i] == NUL)) break; - /* Count backspaces. Only a comma with an -* even number of backspaces before it is + /* Count backslashes. Only a comma with an +* even number of backslashes before it is * recognized as a separator */ if (s origval s[-1] == '\\') ++bs;
multi repeat on intel x64
Hi, We are facing a severe problem on using :g on our machines at work. On two different dell machines this command causes problems after updating to x64 Windows 7 or Windows Server 2008. The scenario is as follows: * Logfile ~100Mb opened * execute :%g!/xxx/d to remove some lines * PC is completely blocking for more than 10 minutes. Task Manager is only updating sometimes and shows 99% CPU for gvim.exe. No other software can be used at this time. This is my PC: Intel i7 CPU 4x2.80 GHz, Hyper threading activated 16 Gb Ram 64bit Windows 7 We tried v 7.2, v7.3 for x86 and x64. I hope someone can help us...thank you Philipp -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: multi repeat on intel x64
Hi Philipp, if you are just trying of eliminate stuff, but then you don't need to really undo your changes, since you will not save back the files at the end, I suggest you: :set ul=-1 This should speed up things a lot. Please, let me know if it solves your problem All the best, Antonio On Mon, Mar 21, 2011 at 11:48 AM, pmehrwald phil_mehrw...@yahoo.com wrote: Hi, We are facing a severe problem on using :g on our machines at work. On two different dell machines this command causes problems after updating to x64 Windows 7 or Windows Server 2008. The scenario is as follows: * Logfile ~100Mb opened * execute :%g!/xxx/d to remove some lines * PC is completely blocking for more than 10 minutes. Task Manager is only updating sometimes and shows 99% CPU for gvim.exe. No other software can be used at this time. This is my PC: Intel i7 CPU 4x2.80 GHz, Hyper threading activated 16 Gb Ram 64bit Windows 7 We tried v 7.2, v7.3 for x86 and x64. I hope someone can help us...thank you Philipp -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: multi repeat on intel x64
On Mar 21, 5:48 am, pmehrwald phil_mehrw...@yahoo.com wrote: Hi, We are facing a severe problem on using :g on our machines at work. On two different dell machines this command causes problems after updating to x64 Windows 7 or Windows Server 2008. The scenario is as follows: * Logfile ~100Mb opened * execute :%g!/xxx/d to remove some lines * PC is completely blocking for more than 10 minutes. Task Manager is only updating sometimes and shows 99% CPU for gvim.exe. No other software can be used at this time. This is my PC: Intel i7 CPU 4x2.80 GHz, Hyper threading activated 16 Gb Ram 64bit Windows 7 I find it very strange that you have a 4-CPU system, and yet Vim (a single-threaded application) is able to max out all 4 of them. We tried v 7.2, v7.3 for x86 and x64. I hope someone can help us...thank you Philipp Is any syntax highlighting active? Is the log on a network share? Answering no to these should also make things faster. In addition to these and Antonio's 'ul' suggestion, you can try turning off swap files, undo files, and a few other things. Actually the LargeFile.vim plugin does a lot of this for you. 100MB is fairly large but Vim should still be able to handle it. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: multi repeat on intel x64
On Mon, Mar 21, 2011 at 13:48, pmehrwald phil_mehrw...@yahoo.com wrote: Hi, We are facing a severe problem on using :g on our machines at work. On two different dell machines this command causes problems after updating to x64 Windows 7 or Windows Server 2008. The scenario is as follows: * Logfile ~100Mb opened * execute :%g!/xxx/d to remove some lines Can you try this command instead and tell us if the problem is gone - :%g!/xxx/_d The _ part here tells d not to yank each line it deletes. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Cream without cream 7.3.138 gives errors with Diff
On Fri, 2011-03-18 at 18:35 -0400, James Vega wrote: The default vimrc is no vimrc. ...except on Windows... There's an example vimrc that the installer installs to $VIM (which one can change through the Advanced install options). Part of the confusion, IMO, is that, on Windows, Vim treats $VIM/_vimrc as an alternative location for the user's vimrc instead of as the system-wide vimrc. So, unlike on unix-like platforms, $VIM/_vimrc is *only* sourced if $HOME/_vimrc doesn't exist instead of always being sourced. I'm a little confused here, unless the user adds $HOME/_vimrc, then $VIM/_vimrc will be sourced by default, no? Which means there IS a default vimrc on Windows. The other bit is that the Windows installers (both yours and Bram's), have decided to use this to, by default, coddle new users by installing a vimrc to $VIM/_vimrc enabling a bunch of options to make Vim act more like a typical Windows application. That may be the right thing to do for new users, and leave the more experienced users to unselect that option (as I do) when installing Vim on a new Windows system. It depends on what learning curve you want to present to new users. Our installer is simply trying to duplicate the default Vim installer behavior. Whatever gets decided for the default will get adapted to ours. I also agree that the mswin option is confusing. I don't think that keeping it makes Vim any more understandable. (One of the reasons Cream was originally developed.) It forks the default Vim behavior by platform. (Ironically, Cream was developed to maintain the standard CUA behavior + features ACROSS platforms.) But then, should nocompatible be set by default on Windows, too? IMO, the correct behavior should be an empty vimrc named vimrc-example. Various features can be included (commented) with simple explanatory text, like a reference tutorial of the top 100 features most users tamper with. The first line explains how to rename the file to activate it. Something similar to http://vim.wikia.com/wiki/Example_vimrc, but with more settings commented out? Exactly. -- Steve Hall [ digitect dancingpaper com ] -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Cream without cream 7.3.138 gives errors with Diff
On Fri, 2011-03-18 at 10:46 -0700, Ben Fritz wrote: On Mar 18, 12:35 pm, Ben Fritz fritzophre...@gmail.com wrote: http://vim.wikia.com/wiki/Running_diff#Vim_distribution_from_Cream It looks like some changes have been made since the wiki article was written, I'm not sure if issues remain. It looks like at least the '!' placement has been fixed. ...but the backslash issues have not been fixed. Steve, the version installed on my machine (I always choose to overwrite the _vimrc) looks like this on line 20: if sh =~ '\cmd' let cmd = '\' . $VIMRUNTIME . '\diff\' let eq = '\\' If I get rid of the extra backslashes so it matches the version you posted, it works fine. If the backslashes are left in, it breaks as the OP describes. Ok, I have fixed this in our build code, effective our the next distributed build. Unless other conversation decides to eliminate the default vimrc for Windows entirely... :) -- Steve Hall [ digitect dancingpaper com ] -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Cream without cream 7.3.138 gives errors with Diff
On Mon, Mar 21, 2011 at 08:24:05PM -0400, Steve Hall wrote: On Fri, 2011-03-18 at 18:35 -0400, James Vega wrote: The default vimrc is no vimrc. ...except on Windows... That's an implementation detail of the installer which can be disabled by the user. There's no requirement for there to be $VIM/_vimrc. There's an example vimrc that the installer installs to $VIM (which one can change through the Advanced install options). Part of the confusion, IMO, is that, on Windows, Vim treats $VIM/_vimrc as an alternative location for the user's vimrc instead of as the system-wide vimrc. So, unlike on unix-like platforms, $VIM/_vimrc is *only* sourced if $HOME/_vimrc doesn't exist instead of always being sourced. I'm a little confused here, unless the user adds $HOME/_vimrc, then $VIM/_vimrc will be sourced by default, no? Which means there IS a default vimrc on Windows. See above reply. There are two default locations for a vimrc on Windows ($HOME/_vimrc and $VIM/_vimrc, in order), which seems unnecessary to me. If there are to be system-wide defaults, they should be in $VIM/vimrc. If a user wants a base vimrc to be installed for them when they install Vim, they should explicitly enable that in the installer and it should be installed to $HOME/_vimrc. Having different behavior on different platforms when one of Vim's selling points is that it is a very portable editor doesn't make sense. There are obviously going to be system-dependent features/functionality, but the overall functionality should be consistent across platforms. The other bit is that the Windows installers (both yours and Bram's), have decided to use this to, by default, coddle new users by installing a vimrc to $VIM/_vimrc enabling a bunch of options to make Vim act more like a typical Windows application. That may be the right thing to do for new users, and leave the more experienced users to unselect that option (as I do) when installing Vim on a new Windows system. It depends on what learning curve you want to present to new users. Our installer is simply trying to duplicate the default Vim installer behavior. Whatever gets decided for the default will get adapted to ours. Right, I wasn't trying to call you out specifically. I realize this is also the behavior in the standard installer. I also agree that the mswin option is confusing. I don't think that keeping it makes Vim any more understandable. (One of the reasons Cream was originally developed.) It forks the default Vim behavior by platform. (Ironically, Cream was developed to maintain the standard CUA behavior + features ACROSS platforms.) But then, should nocompatible be set by default on Windows, too? If I remember correctly, the installed vimrc sources vimrc_example.vim, so nocompatible is set. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
