Re: Incorrect example for #!

2008-01-24 Thread Richard Hartmann

On Jan 24, 2008 12:23 AM, Dasn <[EMAIL PROTECTED]> wrote:

> #!/real-path-to-vim/vim -S
> echo "this is a Vim script"
> quit

That will confuse people who are not too familiar with Unix-type
OSes. Splitting this into sections for the various types of OS
and/or a quick introduction to which might be an option.


Richard

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread Richard Hartmann

On Jan 23, 2008 11:11 PM, Charles E Campbell Jr
<[EMAIL PROTECTED]> wrote:


>  How about an  errorstop  option:

The main problem is probably to define a list of cases that should be
defined as incorrect. That being said, I would make that the first line
of my vimrc the second this option were introduced.

I would prefer errorstop over erroract for the same reason that I always
use strict; for Perl scripts. If it is broken, I don't want to hope it
will work.
I want to fix it.


Richard

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread thomas

> bufnr("."), for example, when I should use bufnr("%")

For the moment, you could define some syntax in after/syntax/vim.vim
that highlights common mistakes. E.g.:

syn match VimWarningBufNr /^.\{-}bufnr('\.')/
hi def link VimWarningBufNr Error

Thomas.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread Charles E Campbell Jr

Tim Pope wrote:

>On Wed, Jan 23, 2008 at 05:11:53PM -0500, Charles E Campbell Jr wrote:
>  
>
>>Vim is often quite forgiving of user blunders.  However, for plugin 
>>development, I'd rather it be more strict.  I have a tendency of trying 
>>bufnr("."), for example, when I should use bufnr("%").  The strange 
>>thing is is that it seems to work on occasion (but erratically).  I've 
>>found other bugs in the past that vim glides over, but that makes it 
>>difficult to find them.
>>
>>How about an  errorstop  option:
>>
>>'errorstop'  'es'   boolean (default: off)
>>local to window
>>{not in Vi}
>>
>>This option makes Vim strict with respect to any errors, warnings, 
>>etc., when running a script.
>>Vim will immediately terminate the script with E???.
>>
>>
>
>Are you familiar with the abort qualifier to a function definition?
>Documented a bit below :help a:firstline .  It's applies to a function
>rather than a window, though I'm not quite sure how the latter makes
>sense.
>
>With regards to the specific example, bufnr() accepts several kinds of
>arguments, including partial buffer names.  So :e .vimrc|echo bufnr('.')
>would return that buffer's number, as the filename starts with a dot.
>  
>
I'd be changing a lot of function definitions, sometimes scattered 
across multiple files, and I don't want to impose that behavior by 
distributing them that way.

I think I'll use Thomas's suggestion and have bufnr(".") be highlighted 
with WarningMsg highlighting (not Error, as its possible to be correct 
in using it as  your example shows).

Regards,
Chip Campbell


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread Andy Wokula

Charles E Campbell Jr schrieb:
> Hello!
> 
> Vim is often quite forgiving of user blunders.  However, for plugin 
> development, I'd rather it be more strict.  I have a tendency of trying 
> bufnr("."), for example, when I should use bufnr("%").  The strange 
> thing is is that it seems to work on occasion (but erratically).  I've 
> found other bugs in the past that vim glides over, but that makes it 
> difficult to find them.
> 
> How about an  errorstop  option:
> 
> 'errorstop'  'es'   boolean (default: off)
> local to window
> {not in Vi}
> 
> This option makes Vim strict with respect to any errors, warnings, 
> etc., when running a script.
> Vim will immediately terminate the script with E???.
> 
> Regards,
> Chip Campbell

Also helpful:
:h 'debug

:set debug=msg
:echo bufnr(".")
E94: No matching buffer for .
-1

-- 
Andy

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



configure script bug

2008-01-24 Thread lorien

i found a little bug in the configure script
if your pager is not 'standart' i.e. less or more
the installer will hang at
file: gvim-7.1.123/work/vim71/src/auto/configure ( on my gentoo )
14458:echo $ECHO_N "checking how to run man with a section nr... 
$ECHO_C" >&6; }

line 14460:( eval man -s 2 read ) < /dev/null > /dev/null 2>&5

never comes out again

if i change from my normal pager ( reed ) to less there is no problem


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: configure script bug

2008-01-24 Thread Micah Cowan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

lorien wrote:
> i found a little bug in the configure script
> if your pager is not 'standart' i.e. less or more
> the installer will hang at
> file: gvim-7.1.123/work/vim71/src/auto/configure ( on my gentoo )
> 14458:echo $ECHO_N "checking how to run man with a section nr... 
> $ECHO_C" >&6; }
> 
> line 14460:( eval man -s 2 read ) < /dev/null > /dev/null 2>&5
> 
> never comes out again
> 
> if i change from my normal pager ( reed ) to less there is no problem

Does it work if you change that line to (pardon the wrapping):

( eval MANPAGER=cat PAGER=cat man -s 2 read ) < /dev/null > /dev/null 2>&5

?

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmO297M8hyUobTrERAvZQAJ0fXGQ2evqx9X/nIrf+BRQ6IwMZnACfbWNI
5F8sp91bvQrE0qYJBsJ9xlc=
=eMFk
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread Charles E Campbell Jr

Andy Wokula wrote:

>Charles E Campbell Jr schrieb:
>  
>
>>Hello!
>>
>>Vim is often quite forgiving of user blunders.  However, for plugin 
>>development, I'd rather it be more strict.  I have a tendency of trying 
>>bufnr("."), for example, when I should use bufnr("%").  The strange 
>>thing is is that it seems to work on occasion (but erratically).  I've 
>>found other bugs in the past that vim glides over, but that makes it 
>>difficult to find them.
>>
>>How about an  errorstop  option:
>>
>>'errorstop'  'es'   boolean (default: off)
>>local to window
>>{not in Vi}
>>
>>This option makes Vim strict with respect to any errors, warnings, 
>>etc., when running a script.
>>Vim will immediately terminate the script with E???.
>>
>>Regards,
>>Chip Campbell
>>
>>
>
>Also helpful:
>:h 'debug
>
>:set debug=msg
>:echo bufnr(".")
>E94: No matching buffer for .
>-1
>  
>

That bufnr(".") was an example, folks.  Not the purpose of the 
suggestion.  The problem is that its difficult to find bugs in plugins 
because vim is forgiving of errors -- which is a good thing for users.  
In particular, consider the solution above as applied to the following code:

fun! ABC()
  let b= bufnr(".")
endfun

call ABC()


Source it in.  No error or error message results.  BTW, I note also that 
putting the "abort" keyword on the fun! line doesn't cause any 
stoppages., probably because files starting with "." are allowed.  I 
think the "solution" of having syntax/vim.vim flag this particular item 
with warning highlighting is the best idea -- don't prohibit it, just 
make the the programmer is aware of it.

Again: often, errors are silently ignored, and it'd be helpful if there 
was an option that would have Vim stop function execution when anything 
untoward occurred, for the primary purpose of helping one find the 
problems in the first place.  I'd give it priority over "silent"s, too.

Regards,
Chip Campbell


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Incorrect example for #!

2008-01-24 Thread Bram Moolenaar


Dasn wrote:

> On 23/01/08 21:20 +0100, Bram Moolenaar wrote:
> >
> >
> >It appears to work in more places when leaving out the "env" command:
> >
> > #!vim -S
> > echo "this is a Vim script"
> > quit
> 
> This will trigger 'not found' error in fbsd, obsd and linux (Arch with
> bash) in which I've tested.

I tested on FreeBSD and it worked then.  But now it doesn't...

> As this line should be ignored, what about in a descriptive manner? e.g:
> 
> #!/real-path-to-vim/vim -S
> echo "this is a Vim script"
> quit

Not really a nice way to give an example, it works for nobody as-is.

My "env" command supports the -S argument.  So this works:

#!/usr/bin/env -S vim -S
echo "this is a Vim script"
quit

How about other systems?  The man page for "env" suggests that it's a
FreeBSD specific extension and added recently.

-- 
CART DRIVER: Bring out your dead!
   There are legs stick out of windows and doors.  Two MEN are fighting in the
   mud - covered from head to foot in it.  Another MAN is on his hands in
   knees shovelling mud into his mouth.  We just catch sight of a MAN falling
   into a well.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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///

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: an idea for plugin development: strict mode

2008-01-24 Thread Tim Pope

On Thu, Jan 24, 2008 at 02:57:38PM -0500, Charles E Campbell Jr wrote:
> That bufnr(".") was an example, folks.  Not the purpose of the 
> suggestion.  The problem is that its difficult to find bugs in plugins 

The problem with the example is that it's not an error at all. bufnr()
serves several different purposes:

1. Given a number, check if that buffer exists
2. Given a full filename, check if that buffer exists
3. Given a full filename, return the buffer number
4. Given a partial filename, check if a matching buffer exists
5. Given a partial filename, return the buffer number
6. Given "" or "%", return the current buffer number
7. Given "#", return the alternate buffer number
8. Given "$", return the last buffer number

Now, you're after 6, but your mistake is causing 4 to be answered
instead.  If there is an error here, it's that the API is so
overloaded that it invites these kinds of issues.  But as it stands,
bufnr(".") is not an error, it's just a different use of the same
function.  An option that changed this to an error would eliminate
perfectly valid uses of the function.

> because vim is forgiving of errors -- which is a good thing for users.  

In the context of programming (and Vim scripting), silently ignoring
real errors is doing users a disservice, as I'm sure you'd agree.

Cheers,
Tim Pope

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: Incorrect example for #!

2008-01-24 Thread Matt Wozniski

On Jan 24, 2008 3:26 PM, Bram Moolenaar wrote:
> My "env" command supports the -S argument.  So this works:
>
> #!/usr/bin/env -S vim -S
> echo "this is a Vim script"
> quit
>
> How about other systems?  The man page for "env" suggests that it's a
> FreeBSD specific extension and added recently.

Definitely not available on linux as of coreutils 5.97.  Perhaps you
don't want to be so intrusive, but since the only really reliable way
to go is only passing one argument, you could always add another link
to vim (like evim, rvim, etc) that sources its arguments.  Then,
"#!/usr/bin/env vimsource" (or whatever..) would work.

~Matt

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: configure script bug

2008-01-24 Thread lorien

Micah Cowan wrote:
> lorien wrote:
>> i found a little bug in the configure script
>> if your pager is not 'standart' i.e. less or more
>> the installer will hang at
>> file: gvim-7.1.123/work/vim71/src/auto/configure ( on my gentoo )
>> 14458:echo $ECHO_N "checking how to run man with a section nr... 
>> $ECHO_C" >&6; }
> 
>> line 14460:( eval man -s 2 read ) < /dev/null > /dev/null 2>&5
> 
>> never comes out again
> 
>> if i change from my normal pager ( reed ) to less there is no problem
> 
> Does it work if you change that line to (pardon the wrapping):
> 
> ( eval MANPAGER=cat PAGER=cat man -s 2 read ) < /dev/null > /dev/null 2>&5
> 
> ?
> 

that did the trick :)
its in line 14215 in the normal /vim71/src/auto/configure ( i.e. not 
emerge )




--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: configure script bug

2008-01-24 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

lorien wrote:
> Micah Cowan wrote:
>> lorien wrote:
>>> i found a little bug in the configure script
>>> if your pager is not 'standart' i.e. less or more
>>> the installer will hang at
>>> file: gvim-7.1.123/work/vim71/src/auto/configure ( on my gentoo )
>>> 14458:echo $ECHO_N "checking how to run man with a section nr... 
>>> $ECHO_C" >&6; }
>>> line 14460:( eval man -s 2 read ) < /dev/null > /dev/null 2>&5
>>> never comes out again
>>> if i change from my normal pager ( reed ) to less there is no problem
>> Does it work if you change that line to (pardon the wrapping):
>>
>> ( eval MANPAGER=cat PAGER=cat man -s 2 read ) < /dev/null > /dev/null 2>&5
>>
>> ?
>>
> 
> that did the trick :)
> its in line 14215 in the normal /vim71/src/auto/configure ( i.e. not 
> emerge )

Well, the vim developers would want to make the change in
src/configure.in, anyway, and not auto/configure. Suggested patch included.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmQR17M8hyUobTrERAkTFAJ46qHJ2vtsL7XxyoKBqIncwj5pvOwCfW6pm
W+HRm7UiU2Nwxa2FBndhpGY=
=yFH2
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Index: configure.in
===
--- configure.in(revision 855)
+++ configure.in(working copy)
@@ -2726,7 +2726,7 @@
 dnl Check how we can run man with a section number
 AC_MSG_CHECKING(how to run man with a section nr)
 MANDEF="man"
-(eval man -s 2 read) < /dev/null > /dev/null 2>&AC_FD_CC && MANDEF="man -s"
+(eval MANPAGER=cat PAGER=cat man -s 2 read) < /dev/null > /dev/null 
2>&AC_FD_CC && MANDEF="man -s"
 AC_MSG_RESULT($MANDEF)
 if test "$MANDEF" = "man -s"; then
   AC_DEFINE(USEMAN_S)


configure-manpager.diff.sig
Description: Binary data