Re: blank line at end of file
On Mon, 23 Apr 2007 09:47:21 -0500, Tim Chase [EMAIL PROTECTED] wrote: I use vim7 on Win32 and every time I save a file, vim adds a new blank (CR+LF) line at the end of the file although it is not visible when in vim. Is there an option to disable this behaviour? yes, there is a way to break expectations :) To expand on that, the CRLF (or LF on Unix or CR on Mac) is a line _terminator_, not a line _separator_, even though many people refer to it as a separator. Every line in a text file should end with the correct end of line sequence, including the last line. If some other editor misinterprets a final CRLF to mean that there's an empty blank line at the end of the file then that editor is broken. Some products will consider a file without a terminator on the final line to have been truncated, and will report it as a potential problem because from the product's point of view the input has terminated unexpectedly in the middle of a line. I used to have this problem at work when people edited scripts with Notepad and then passed them to Oracle's SQL*Plus, resulting in a complaint about truncated input on every script. -- Matthew Winn
adding buffer using find awk and stderr
Hello,
I am trying to open many buffers using some command line tools. For example.
find . -name pom.xml | awk '{print bad $1 /dev/stderr}' | vi -
then issuing ls to no avail
iff I issue
find . -name pom.xml | awk '{print bad $1 /dev/stderr}' 2
session ; vi -S session
Then I have all the buffers loaded. (note the stderr here IS superfluous)
The man page says
The file to edit is read from stdin. Commands are read from
stderr, which should be a tty.
I think I'm missing a point somewhere, can you think of anyway to skip
the intermediary session file?
Regards,
Warren
Re: adding buffer using find awk and stderr
find . -name pom.xml | awk '{print bad $1 /dev/stderr}' | vi -
then issuing ls to no avail
iff I issue
find . -name pom.xml | awk '{print bad $1 /dev/stderr}' 2
session ; vi -S session
[cut]
I think I'm missing a point somewhere, can you think of anyway to skip
the intermediary session file?
At least OpenBSD's xargs allows you to reopen stdin with
find . -name pom.xml | xargs -o vi
This is a fabulous feature, though checking several Linux
installs I have access to, none of their xargs offer a -o
parameter to reopen stdin. If you happen to be running on
OpenBSD (or perhaps the FreeBSD/NetBSD/Dragonfly offer similar
functionality), this is an elegant solution with no warts.
In a bash shell where you can create dynamic FIFOs as
pseudo-files, you might be able to get away with
vi -S (find . -name pom.xml | sed 's/^/bad /')
(using sed rather than Awk, as I'm not sure I understand the
complications about stdout vs. stderr in your example). This may
come with the wart of an empty buffer (the starting buffer) in
addition to all the badded buffers. This wart could be worked
around with some ugliness:
vi -S (find . -name pom.xml | sed -e '1s/^/e /' -e
'1!s/^/bad ')
which changes the first session command into e rather than bad.
None of these solutions leave intermediate session-files around.
Just a few ideas...
-tim
RE: blank line at end of file
Some products will consider a file without a terminator on the final line to have been truncated, and will report it as a potential problem because from the product's point of view the input has terminated Now ya know why I *always* put a blank line at the end of *everything*: .htm files, .css files, .c files, .l files, plain text files, email, *everything*. There was at least one uu-/xxdecoder program that'd require an *extra* blank line at the end of a source file, else it'd crap out with an incomplete decoding. So I'd just give it 3-4 extra. :D unexpectedly in the middle of a line. I used to have this problem at work when people edited scripts with Notepad and then passed them to Oracle's SQL*Plus, resulting in a complaint about truncated input on every script. Don't take this the wrong way, but that's just *too* funny... :D
RE: wish: collaboration of N vim instances editing same file
Odd, I got this here, but not from the vimlist... Couldn't the 'patch' command do this? E.g., Vim#1 has made some changes to example.c (but not saved them), and Vim#2 makes some different changes and ... Shouldn't this be possible through the autocommands? I think you could write this as a plugin, Yakov. Imagine it'd be possible with some script to throw together a 'vimdiff' of sorts and implement what you want, but me personally, I'd rather not ever use that. Would best be a plugin as you suggest, than as a built-in feature. I have to reiterate that to me, such a thing just sounds too dangerous to accidentally trash a file. Much better to detect the .swp file and keep things the way they are (eg, menu choice to ignore, reload, edit-anyway, etc.). Just my 2c.
Re: What plugin is the one that does the following ...
On 4/23/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: 1) Get up-to-date versions of vimball and netrw: vimball: http://vim.sourceforge.net/scripts/script.php?script_id=1502 -or- http://mysite.verizon.net/astronaut/vim/index.html#VimBall (the mysite.verizon.net one will be the more recent version) netrw: http://vim.sourceforge.net/scripts/script.php?script_id=1075 -or- http://mysite.verizon.net/astronaut/vim/index.html#NETRW 2) Remove the old vimball plugin and install the new one: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/vimball*.vim autoload/vimball*.vim doc/pi_vimball.txt mv (wherever it was downloaded)/vimball.tar.gz . gunzip vimball.tar.gz tar -xvf vimball.tar Windows: Under Windows, check your runtimepath to determine where your vim 7.0's runtime directories are: vim :echo rtp :q The first directory is likely your personal plugins directory, the second one is your vim system directory. cd (to your vim system directory) del plugin\vimballPlugin.vim del autoload\vimball.vim del doc\pi_vimball.txt ren (wherever)\vimball.tar.gz vimball.tar.gz gunzip vimball.tar.gz tar -xvf vimball.tar 3) Remove system version of netrw: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/netrw*.vim autoload/netrw*.vim doc/pi_netrw.txt syntax/netrw*.vim Windows: cd (to your vim system directory) del plugin\netrwPlugin.vim del autoload\netrw.vim del doc\pi_netrw.txt del syntax\netrw.vim 4) Install an up-to-date version of netrw: vim netrw.vba.gz :so % :q Regards, Chip Campbell Dr. Chip, Using your directions above, I continually get problems on step 4. when I so :so % I'm constantly returned UseVimball is not a vim command, or something similar. What might I be doing wrong? andy
Re: undo line numbers wrong
Rob Cussons wrote: just wondering if anyone else had experienced an error message like this. It seems that every so often, I've not managed to find any systematics to this, when I try to perform an undo, I get undo line numbers wrong or something similar, sorry I don't have the exact error in front of me, it happened about 5 minutes ago and I was in the middle of something, so I just dealt with it! It doesn't happen very often, but when it does if I later try to undo something, it all goes a bit haywire and seems to not undo the last change etc. Sorry this is so vague, if it happens again, I'll see if I can pin it down better. Just wondered if anyone else had experienced this and maybe knew the cause. What is your :version output? -- All good vision statements are created by groups of people with bloated bladders who would rather be doing anything else. (Scott Adams - The Dilbert principle) /// 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: What plugin is the one that does the following ...
Andrew Falanga wrote: On 4/23/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: 1) Get up-to-date versions of vimball and netrw: vimball: http://vim.sourceforge.net/scripts/script.php?script_id=1502 -or- http://mysite.verizon.net/astronaut/vim/index.html#VimBall (the mysite.verizon.net one will be the more recent version) netrw: http://vim.sourceforge.net/scripts/script.php?script_id=1075 -or- http://mysite.verizon.net/astronaut/vim/index.html#NETRW 2) Remove the old vimball plugin and install the new one: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/vimball*.vim autoload/vimball*.vim doc/pi_vimball.txt mv (wherever it was downloaded)/vimball.tar.gz . gunzip vimball.tar.gz tar -xvf vimball.tar Windows: Under Windows, check your runtimepath to determine where your vim 7.0's runtime directories are: vim :echo rtp :q The first directory is likely your personal plugins directory, the second one is your vim system directory. cd (to your vim system directory) del plugin\vimballPlugin.vim del autoload\vimball.vim del doc\pi_vimball.txt ren (wherever)\vimball.tar.gz vimball.tar.gz gunzip vimball.tar.gz tar -xvf vimball.tar 3) Remove system version of netrw: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/netrw*.vim autoload/netrw*.vim doc/pi_netrw.txt syntax/netrw*.vim Windows: cd (to your vim system directory) del plugin\netrwPlugin.vim del autoload\netrw.vim del doc\pi_netrw.txt del syntax\netrw.vim 4) Install an up-to-date version of netrw: vim netrw.vba.gz :so % :q Regards, Chip Campbell Dr. Chip, Using your directions above, I continually get problems on step 4. when I so :so % I'm constantly returned UseVimball is not a vim command, or something similar. What might I be doing wrong? andy It means step 2 wasn't done properly. You should find the unpacked vimball files in the plugin/ and autoload/ subfolders of some folder mentioned in 'runtimepath'. Best regards, Tony. -- ... So the documentary-makers stick with sharks. Generally, their procedure is to scatter bleeding fish pieces around their boat, so as to infest the waters. I would estimate that the primary food source of sharks today is bleeding fish pieces scattered by people making documentaries. Once the sharks arrive, they are generally fairly listless. The general shark attitude seems to be: Oh God, another documentary. So the divers have to somehow goad them into attacking, under the guise of Scientific Research. We know very little about the effect of electricity on sharks, the narrator will say, in a deeply scientific voice. That is why Todd is going to jab this Great White in the testicles with a cattle prod. The divers keep this kind of thing up until the shark finally gets irritated and snaps at them, and then they act as though this was a totally unexpected and very dangerous development, although clearly it is what they wanted all along. -- Dave Barry, The Wonders of Sharks on TV
Re: What plugin is the one that does the following ...
Andrew Falanga wrote: It means step 2 wasn't done properly. You should find the unpacked vimball files in the plugin/ and autoload/ subfolders of some folder mentioned in 'runtimepath'. Nope, I looked in each of the directories (after doing tar -tf vimball.tar, to get a list of the files), and all did extract properly. Andy Please use Reply to All, nor Reply to Sender next time, so that other Vim users (including the plugin author, Dr. Charles Chip Campbell), can see your post. :UseVimball is defined by the vimball plugin. If the vimball plugin files have been properly unpacked (and, maybe, you restarted Vim since then) then the :scriptnames command should show you that plugin/vimballPlugin.vim has been sourced. Best regards, Tony. -- Love means having to say you're sorry every five minutes.
Re: What plugin is the one that does the following ...
On 4/24/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Andrew Falanga wrote: It means step 2 wasn't done properly. You should find the unpacked vimball files in the plugin/ and autoload/ subfolders of some folder mentioned in 'runtimepath'. Nope, I looked in each of the directories (after doing tar -tf vimball.tar, to get a list of the files), and all did extract properly. Andy Please use Reply to All, nor Reply to Sender next time, so that other Vim users (including the plugin author, Dr. Charles Chip Campbell), can see your post. Sorry. I do have a hard time remembering. Will try to do better. :UseVimball is defined by the vimball plugin. If the vimball plugin files have been properly unpacked (and, maybe, you restarted Vim since then) then the :scriptnames command should show you that plugin/vimballPlugin.vim has been sourced. Ok, I did :scriptnames and I did see the plugin/vimballPlugin.vim as being sourced. However, I still get E492: Not an editor command: UseVimball when doing :so % as originally instructed by Dr. Chip. Andy
Re: What plugin is the one that does the following ...
Andrew Falanga wrote: On 4/24/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Andrew Falanga wrote: It means step 2 wasn't done properly. You should find the unpacked vimball files in the plugin/ and autoload/ subfolders of some folder mentioned in 'runtimepath'. Nope, I looked in each of the directories (after doing tar -tf vimball.tar, to get a list of the files), and all did extract properly. Andy Please use Reply to All, nor Reply to Sender next time, so that other Vim users (including the plugin author, Dr. Charles Chip Campbell), can see your post. Sorry. I do have a hard time remembering. Will try to do better. :UseVimball is defined by the vimball plugin. If the vimball plugin files have been properly unpacked (and, maybe, you restarted Vim since then) then the :scriptnames command should show you that plugin/vimballPlugin.vim has been sourced. Ok, I did :scriptnames and I did see the plugin/vimballPlugin.vim as being sourced. However, I still get E492: Not an editor command: UseVimball when doing :so % as originally instructed by Dr. Chip. Andy - Are you sure the vimballPlugin.vim that is sourced is the one you just installed? - Are you sure another version of the same is not _also_ sourced? - Are you sure you don't create a variable named loaded_vimballPlugin (or g:loaded_vimballPlugin) in your vimrc? Best regards, Tony. -- To be is to do. -- I. Kant To do is to be. -- A. Sartre Yabba-Dabba-Doo! -- F. Flinstone
Re: What plugin is the one that does the following ...
Quoting Andrew Falanga [EMAIL PROTECTED]:
On 4/24/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Andrew Falanga wrote:
Using your directions above, I continually get problems on step 4.
when I so :so % I'm constantly returned UseVimball is not a vim
command, or something similar. What might I be doing wrong?
Hmm, your original complaint was that netrw wasn't working at all, I
believe.
Do you have something like the following at the beginning of your
.vimrc file?
=
Initialize: {{{1
set nocp
if version = 600
filetype plugin indent on
endif
Actually, on this particular system, I have no ~/.vimrc file at all.
Without these commands, your vim is operating in vi-compatible mode, and
vi doesn't support plugins. Even with :set nocp, you need to enable plugins.
May I suggest trying the few lines above as your .vimrc, and then trying to
edit a directory.
Regards,
Chip Campbell
Re: Vim freezes system ?!
Tim Chase wrote:
Or even a quality :s command instead of a function:
:%s/.\{72}/r/g
Thanks - I occasionally need to split a line into equal-length blocks
and your command is excellent. Your posts are very valuable.
However, for anyone trying this, 'r' should be '\r'.
:%s/.\{72}/\r/g
John
Re: wish: allow a: in the function def
--- Nikolai Weibull [EMAIL PROTECTED] wrote: On 4/23/07, Yakov Lerner [EMAIL PROTECTED] wrote: wish: allow a: in the function definition line: function foo(a:line1, a:line2) This is currently not allowed. But it seems logical to allow it. Why should it be? Extra typing? So that the name is consistent everywhere. Makes it much easier to search. I would appreciate this addition, too. regards, Peter Send instant messages to your online friends http://au.messenger.yahoo.com
Re: replace VimScript (was: wish: allow a: in the function def)
Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: wish: allow a: in the function def
Thomas schrieb: Yakov Lerner schrieb: wish: allow a: in the function definition line: function foo(a:line1, a:line2) yeah, occasionally I do :setl isk+=: to get completion of variable names in vim scripts. I'd like to have this for function arguments, too. Counterwish: implement better semantics for VimScript so that the lookup order of variables alleviates the need for explicit environments. Yes, this will break backwards compatibility. I personally like both wishes. I don't think that this has to necessarily break backwards compatibility as variables can already have implicit prefixes: eg foo could be l:foo when used in a function or g:foo when used in global scope. So maybe one could make vimscript search a variable foo as l:foo, a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined variable name error if none exists. Or so. Don't like the idea. In Vim script there is no need or possibility to declare variables. Now, if I forget to init a fun-local variable (happens often to me) Vim gives me a helpful error (undefined variable). This wouldn't be the case anymore if Vim could find obscure variables with the same name I've never heard of (e.g. set by some weird plugin). Also would it be _recommended_ to ever use a window-local variable without the w: prefix? ... IMHO not. -- Regards, Andy EOM
Re: wish: allow a: in the function def
Also would it be _recommended_ to ever use a window-local variable
without
the w: prefix? ... IMHO not.
Well, it would make it easier for the user to configure scripts. I'm
myself not convinced that it's a good idea to allow this for all
variables, though. But I think it could be useful in some situations
when you want the user to set a variable per buffer/window or use the
global value. I sometimes end up with code like this
if a:0 = 1
let x = a:1
elseif exists('b:foo')
let x = b:foo
else
let x = g:foo
endif
The idea was to solve this with some magic.
Of course, with the exception of s:, a user-defined function could help
too, which probably is sufficient.
let x = a:0 = 1 ? a:1 : GetValue('foo', 'bg')
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language As a sarcastic joke, this sounds average. But seriously, vim having supprt for embedded perl,python,ruby, tcl and scheme interpreters, it is realistically to expect javascript interpreter added one day. Yakov
Re: Vim's ole functionality
Hello, Sorry for raising this issue again. The problem was not yet solved. I tried all the options I checked :version and there is this line with OLE support. I tried to run the application from python as said in documentation and its working fine there. But from java with swt library I'm getting the same error. On 4/23/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Nageshwar - Yes.. I did gvim -register But when i checked the :version details, i didn't get -DFEAT_OLE. I installed vim 7.0 windows installation package. Do you think that is the problem ? Not all gvim.exe have the OLE support. The second line of :version should say with OLE support. The self-installing executable does have OLE. src/bigvim.bat builds it. - Bram -- Imagine a world without hypothetical situations. /// 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: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. There's a lot to be said for following a path that leads to interoperability and code reuse. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. --Greg
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body So? In what way does this make it a good language? In what way does this make it a good language to extend Vim with? Anyone can write a standard. It doesn't mean that it's good or what is being standardized will be, either. 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) SpiderMonkey is a terribly inefficient implementation, which is why Tamarin will be used in future versions of Gecko. And I wouldn't say that efficiency is the primary concern of a language/runtime engine to use for Vim. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. nikolai
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language As a sarcastic joke, this sounds average. But seriously, vim having supprt for embedded perl,python,ruby, tcl and scheme interpreters, it is realistically to expect javascript interpreter added one day. Yes. All that is required is that someone actually invests some time into doing it. nikolai
Re: [PATCH] Determining whether a window used :lcd
On 4/23/07, Nikolai Weibull [EMAIL PROTECTED] wrote: The attached patch very simply implements the following from the todo: Wait! I have a comment! Isn't this todo just a subset of 6 Add :cdprev: go back to the previous directory. Need to remember a stack of previous directories. We also need :cdnext. Not at all. This patch merely exposes some information about the current cd/lcd functionality. It does not provide new directory changing stack capability. Thank you, bob
Re: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
Robert Lee wrote:
[snip]
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?
Aw, come on. Everyone knows ECMAScript. It's like with HTML:
everyone knows HTML. It's like on the web and stuff.
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', )
than
:set fo-=t
It's all about domain specific languages. It's said so on the internet.
Hey, congratulations! You designed a crappy API! Of course, you can
design a crappy API in any language. Take a look at this:
:let fo = substitute(fo, t, , )
That looks terrible! Oh, hang on, you say there's a better way?
I'm not impressed with your strawman argument.
nikolai
--Greg
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote:
On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
Robert Lee wrote:
[snip]
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?
Aw, come on. Everyone knows ECMAScript. It's like with HTML:
everyone knows HTML. It's like on the web and stuff.
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', )
than
:set fo-=t
It's all about domain specific languages. It's said so on the internet.
Hey, congratulations! You designed a crappy API! Of course, you can
design a crappy API in any language.
Yes, sorrry. My two minute API design is obviously flawed. Perhaps
we can get to see a better one?
Take a look at this:
:let fo = substitute(fo, t, , )
That looks terrible! Oh, hang on, you say there's a better way?
Yes?
I'm not impressed with your strawman argument.
And I'm not impressed with your argument for replacing VimScript with
ECMAScript.
Either way, this point is completely moot. VimScript strikes a
balance between being a set of editor commands and a programming
balance. It's not perfect by any means, but it does fit the model
quite well. It won't be replaced, for the simple reason that
VimScript is, in essence, Vim.
nikolai
Re: replace VimScript (was: wish: allow a: in the function def)
On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body So? In what way does this make it a good language? In what way does this make it a good language to extend Vim with? Anyone can write a standard. It doesn't mean that it's good or what is being standardized will be, either. Where did anyone say that standardization made it a better language than any other? Most of what makes it a good language has been there since the earliest JavaScript implementations. Many of the issues that have made it difficult to work with in the past have been hammered out during standardization or were API issues rather than language issues. But even that isn't what standardization buys you. The main advantage is interoperability. If someone writes some excellent library for use in some Flash app, but is of use in some other environment that provides ECMAScript extension, you can just copy it over and use it. I'm capable of porting an algorithm in one language I know to another language I know, but that's a bit more work than copy and paste. 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) SpiderMonkey is a terribly inefficient implementation, which is why Tamarin will be used in future versions of Gecko. And I wouldn't say that efficiency is the primary concern of a language/runtime engine to use for Vim. I strongly disagree with that statement. Efficiency is certainly important for an editor. I don't want to sit and twiddle my thumbs while vim starts up or executes hooks on file read, nor do I want it to suck up a big chunk of memory while it's going about its business. In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. Efficiency is definitely important. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? As for following the leader, you are on shaky ground. Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? nikolai --Greg
Re: wish: allow a: in the function def
Robert Lee wrote: [...] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language just to change the color scheme or keyboard mappings. Yes, this will break backwards compatibility. Tough. [...] Don't? WTF EMCAScript? If you want to replace vimscript by something I already know (yes, /I/ am people), use COBOL, BASIC or FORTRAN. Or even ALGOL. At least vimscript uses the same commands as those which I type at the vim command-line. OTOH, some other people prefer LISP. But replacing vimscript by Lisp has already been done: it's called Emacs. Or if you want to scrap ex-commands everywhere (even when typed-in by hand, one by one) and use EMC-WTF instead, go ahead, I'm not detaining you. But don't call your new editor Vim. Best regards, Tony. -- Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] Actually, I like the proposal for two entirely different reasons: 1) the language specification comes from an international standards body So? In what way does this make it a good language? In what way does this make it a good language to extend Vim with? Anyone can write a standard. It doesn't mean that it's good or what is being standardized will be, either. Where did anyone say that standardization made it a better language than any other? Most of what makes it a good language has been there since the earliest JavaScript implementations. Many of the issues that have made it difficult to work with in the past have been hammered out during standardization or were API issues rather than language issues. But even that isn't what standardization buys you. The main advantage is interoperability. If someone writes some excellent library for use in some Flash app, but is of use in some other environment that provides ECMAScript extension, you can just copy it over and use it. I'm capable of porting an algorithm in one language I know to another language I know, but that's a bit more work than copy and paste. 2) there are lots of people working on efficient implementations, at least two of which are open source (SpiderMonkey and Adobe's Tamarin, though there seem to be some plans to convert SpiderMonkey to use Tamarin) SpiderMonkey is a terribly inefficient implementation, which is why Tamarin will be used in future versions of Gecko. And I wouldn't say that efficiency is the primary concern of a language/runtime engine to use for Vim. I strongly disagree with that statement. Efficiency is certainly important for an editor. I don't want to sit and twiddle my thumbs while vim starts up or executes hooks on file read, nor do I want it to suck up a big chunk of memory while it's going about its business. In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. Efficiency is definitely important. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? Cool down. vimscript replacing with EcmaScript is not on the horizon, is not on the agenda, not going to happen. The only alternative to vimscript that Bram once contemplated was python, and it was decisively voted down by feature voting. (Python was considered at one point by Bram because Python is Bram's favourite language.) So do not worry, replacement of vimscript by the favourite language of some vim's random user is not going to happen. Yakov
Re: replace VimScript
Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
Robert Lee wrote:
[snip]
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?
Aw, come on. Everyone knows ECMAScript. It's like with HTML:
everyone knows HTML. It's like on the web and stuff.
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t',
)
than
:set fo-=t
It's all about domain specific languages. It's said so on the internet.
nikolai
More intuitive?
:set fo-=t
remove t from 'fo'. Nothing more intuitive than that, especially when there
is already :set fo+=t. If I were /required/ to learn that more verbose
gobbledygook, I'd be sure to make lots more errors writing wtf-script.
What about ;-)
[...]
DATA DIVISION.
WORKING-STORAGE SECTION.
77 I PICTURE S9(18) COMPUTATIONAL.
[...]
01 FORMATOPTIONS.
03 FORMAT-OPTION PICTURE X
OCCURS 20 TIMES.
[...]
CONSTANT SECTION.
[...]
77 FORMATOPTIONS-SIZE PICTURE 99 VALUE 20
USAGE COMPUTATIONAL.
[...]
PROCEDURE DIVISION.
[...]
MOVE 1 TO I.
X1234-1.
IF FORMAT-OPTION (I) IS EQUAL TO SPACE GO TO X1234-EXIT.
IF FORMAT-OPTION (I) IS EQUAL TO t GO TO X1234-2.
ADD 1 TO I.
IF I IS GREATER THAN FORMATOPTIONS-SIZE GO TO X1234-EXIT.
GO TO X1234-1.
X1234-2.
IF I IS EQUAL TO FORMATOPTIONS-SIZE THEN
MOVE SPACE TO FORMAT-OPTION (I)
GO TO X1234-EXIT.
MOVE FORMAT-OPTION (I + 1) TO FORMAT-OPTION (I).
ADD 1 TO I.
IF FORMAT-OPTION (I) IS EQUAL TO SPACE
GO TO X1234-EXIT.
GO TO X1234-2.
X1234-EXIT.
EXIT.
[...]
_That_ is really intuitive, don't you think? ;-)
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
195. Your cat has its own home page.
Re: search() and smartcase
Yakov Lerner wrote: The search() doesn't seem to follow 'smartcase' (and this does not seem to be documented). Is it possible to have a flag to search() to obey the 'smartcase' ? Can it be included into todo ? The search() function does use 'smartcase'. -- hundred-and-one symptoms of being an internet addict: 2. You kiss your girlfriend's home page. /// 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: [PATCH] Determining whether a window used :lcd
Bob Hiestand wrote: On 4/20/07, Bram Moolenaar [EMAIL PROTECTED] wrote: It was still in my pile of messages to read. I apologize for my impatience. I agree that a different function would be more useful. I prefer haslocaldir(). This would return zero when the current window uses the global directory, one when it has a local directory. Later we could add an argument for selecting the window. If you agree, and nobody has something to say on this, can you change your patch? Done. Please see attached. Great thanks. Good to see a patch with documentation updates! -- A)bort, R)etry, B)ang it with a large hammer /// 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: replace VimScript
Yakov Lerner wrote: [snip] So do not worry, replacement of vimscript by the favourite language of some vim's random user is not going to happen. That is obvious. The point was the question why the OP named language X and not Y for this. Yakov -- For robots (please don't mail me there): [EMAIL PROTECTED]
Re: coredump with match by lines-range (7.0.222); highlighting is not painted fully.
On 4/24/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Multi-line matches are not always displayed correctly. A match is searched for in the line where redrawing starts, which can be anywhere. Your pattern only matches when redrawing starts at or before line 4078. Maybe we need a pattern that matches at line =N and at line =N then ? (say \%123l \%123l, in addition to ==N, the \%123l). Or is there other way to highlight block of lines ? Thanks
Re: wish: allow a: in the function def
Nikolai Weibull schrieb: On 4/24/07, Andy Wokula [EMAIL PROTECTED] wrote: Thomas schrieb: So maybe one could make vimscript search a variable foo as l:foo, a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined variable name error if none exists. Or so. Don't like the idea. In Vim script there is no need or possibility to declare variables. Now, if I forget to init a fun-local variable (happens often to me) Vim gives me a helpful error (undefined variable). And I have the same problem with a: prefixes for my arguments. Fine, keep prefixes for g:, w:, and b:, but a: is just such an incredibly nonstandard way of doing things. In almost all languages parameters are treated the same as local variables. nikolai As long as function arguments are read-only, it is good to have the a: modifier. In fact, why are they read-only, although call is by value? -- Regards, Andy EOM
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. What plugins/functionality are we missing that require better efficiency? Efficiency is definitely important. VimScript is probably in the order of 10^6 times slower (if not more) than C, and yet we have loads and loads of usable plugins. And what about the size of, for example, Tamarin. It's quite a big piece of software. That would certainly incur a memory penalty. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? Microsoft has, though hardly to any real degree of success, always pushed for VBA. Sure it has JScript as well and many languages could be used for application automation of windows applications. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Wasn't that sort of my argument? Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? I don't see why you have to replace VimScript with ECMAScript to get ECMAScripts do what can be done with the, for example, Ruby bindings. As for following the leader, you are on shaky ground. No, but the following argument certainly is: Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. Yes, Vim took over where vi had stagnated. Linux was created as a free version of a Unix-like operating system. I don't see how that has anything to do with rip out all the internals of Vim and replace them with a spider-monkey-type-thingy. I mean, it's not like Bram had Vi, removed insert mode and replaced it with virtual replace mode and made a better editor. (Yes, straw-man that if you like.) And just because companies like Adobe and software foundations like Mozilla have chosen JavaScript (and most Adobe applications have a COM interface, so their not usually limited to just JavaScript) for their extension languages doesn't mean it makes sense for others. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? Would you like it if I talked condescending to you? The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. Argument 2) fails because using a standardized language instead of a application-specific language gives us no advantages. On can also argue that the application-specific language is standardized in the sense that it is the standard. Argument 3) fails because it simply isn't true. Last I heard Tamarin was going to be integrated with SpiderMonkey but that that mostly meant phasing out SpiderMonkey and replacing it with Tamarin. So that leaves Tamarin. And sure, there are probably a bunch of people working on Tamarin, because it's a complex piece of software, but plural number of (freely available) implementations I wouldn't say that there are. nikolai
Re: wish: allow a: in the function def
On 4/24/07, Yakov Lerner [EMAIL PROTECTED] wrote: Besides C and descentants, no other language treats function parameters as local variables. What am I missing? * You can assign to parameters in most languages. * You don't prefix parameters in some manner in most languages. * A parameter is shadowed by later declarations of variables with the same name in most languages. I actually like a:,l:,g:,b: etc prefixes. They are useful in practice because in languages like C++, people tend to invent project-specific suffixes and prefixes to distinguish between method vars, local vars, etc. Vim codifies this. I find this convenient. I have never seen anyone having a separate prefix for method variables and local variables. Instance variables, static variables, global variables, sure, for example, m_, s_, g_. Incredibly nonstandard ? Since when ALL programming languages obey one and the same standard ? From forth to lisp to vb.net to perl ? Where did you see common standard for all programing languages ? This thing does not exist. There are families of related languages with common features and spirit, yes, but where did you see standard features that programming language must obey ? This is ridiculous statement. There is no such thing. Eh, that incredibly nonstandard refers to the nonstandard treatment of parameters. nikolai
Re: wish: allow a: in the function def
Nikolai Weibull wrote: On 4/24/07, Andy Wokula [EMAIL PROTECTED] wrote: Nikolai Weibull schrieb: On 4/24/07, Andy Wokula [EMAIL PROTECTED] wrote: Thomas schrieb: So maybe one could make vimscript search a variable foo as l:foo, a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined variable name error if none exists. Or so. Don't like the idea. In Vim script there is no need or possibility to declare variables. Now, if I forget to init a fun-local variable (happens often to me) Vim gives me a helpful error (undefined variable). And I have the same problem with a: prefixes for my arguments. Fine, keep prefixes for g:, w:, and b:, but a: is just such an incredibly nonstandard way of doing things. In almost all languages parameters are treated the same as local variables. nikolai As long as function arguments are read-only, it is good to have the a: modifier. In fact, why are they read-only, although call is by value? Yes, that's the reason for the a: modifier. And yes, why are they read-only?VimScript isn't a functionaly programming language. Variables are mutable; arguments should be to. Why? Vim is a good programming language, arguments as such should never be mutable. When a value can be passed back (in languages which allow it), the argument is not the value but the _address_ of the value, and that is, again, not changeable. Although I'm sure there's an implementation reason for this, it must be possible to fix. Still, I don't have a patch, so I should probably just shut up now. I just hoped it could be better to spend some time to remove this restriction and drop the requirement of a: instead of adding additional handling for the declaration of parameters. nikolai Best regards, Tony. -- What this world needs is a good five-dollar plasma weapon.
Re: replace VimScript
Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. What plugins/functionality are we missing that require better efficiency? Efficiency is definitely important. VimScript is probably in the order of 10^6 times slower (if not more) than C, and yet we have loads and loads of usable plugins. And what about the size of, for example, Tamarin. It's quite a big piece of software. That would certainly incur a memory penalty. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? Microsoft has, though hardly to any real degree of success, always pushed for VBA. Sure it has JScript as well and many languages could be used for application automation of windows applications. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Wasn't that sort of my argument? Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? I don't see why you have to replace VimScript with ECMAScript to get ECMAScripts do what can be done with the, for example, Ruby bindings. As for following the leader, you are on shaky ground. No, but the following argument certainly is: Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. Yes, Vim took over where vi had stagnated. Linux was created as a free version of a Unix-like operating system. I don't see how that has anything to do with rip out all the internals of Vim and replace them with a spider-monkey-type-thingy. I mean, it's not like Bram had Vi, removed insert mode and replaced it with virtual replace mode and made a better editor. (Yes, straw-man that if you like.) And just because companies like Adobe and software foundations like Mozilla have chosen JavaScript (and most Adobe applications have a COM interface, so their not usually limited to just JavaScript) for their extension languages doesn't mean it makes sense for others. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? Would you like it if I talked condescending to you? The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. This is completely true. EMCAScript, however, is never going away and is known by a very large number of users (both technical and non-technical). Frankly, one of Vim's greatest barriers-of-entry is the learning curve. I think much of this is due to its use of proprietary scripting formats. I think there is probably a great deal of overlap between Vim users and current EMCAScript (a.k.a. JavaScript) users. For example, I'd imaging that many PHP developers use Vim as their primary editor (such as myself)...and that most of those users use JavaScript on the client. Argument 2) fails because using a standardized language instead of a application-specific language gives us no advantages. On can also
