Benji Fisher wrote:
>      You can help!
>
>      This request is aimed at anyone on this list who has received
> valuable advice and wants to repay the vim community.  That includes
> lurkers!
>
>      Vim 7.0 has now started beta testing.  One thing that
> non-developers, even newbies, can help with before the final release is
> improving the documentation.
>
<snip>

After a total of 30 minutes playing with vim7, I decided to read through
the documentation on tabpage.  2 things I noticed:

1)  The introduction begins with: "A tab page holds one or more
windows."  At this point, it is not entirely clear what these words
mean.  It might be nice to have a link from here (possibly on the words
"tab page" and the word "window") to something like the definitions of
the words "screen", "shell", and "window" that appear in the
documentation for design-decisions.  This is perhaps not that
significant, but I think there is potential confusion.

2) he: tabdo  Tabdo is listed in the documentation as not taking a !
argument, while windo does.   I presume windo! {cmd}  will process cmd
on all windows, regardless of any errors, but that's not stated in the
text.  I notice that tabdo! is indeed not legal, and I'm curious to know
why.  It would be handy if you could continue to process other tabs when
an error occurs.  (Is that what the '!' on windo does?)

Also, I'm not sure if this is a result of an improper install (I
downloaded from the cvs, used 'vim -c make' to build, set VIMRUNTIME to
the resultant runtime dir, and executed via "vim -u NONE"), but I no
longer have any history in command mode, and I can't use <CTRL>f to
enter the command window.

There seems to be a way to "redir" something to all sorts of places but not
into a buffer.  Am I missing something?  Almost always all I want to do is suck
command/message window stuff into a buffer and edit it.  I know it's not that
hard to use it via the registers, but still....

The Vim7 sections I have had trouble with so far are for the "tabline" and the
new List and Dictionary support.  The examples have errors in them, ranging
from missing "let" commands before setting variables, to more subtle stuff.

It would have been better for the example for a "tabline" function to be a
working template.  I have just written a more detailed script.  I wasn't able
to find a .vim file delivered with the runtime stuff that is responsible for
the default tabline behaviour.  Is it internal, or did I miss something?  It
would be nice to have the default accessible, and perhaps a few alternatives
(like colorschemes, etc.).

The explanations of how failures manifest in the world of lists and dicts
should be extended.  It's pretty easy (for me anyway) to get yourself into a
mess where you are frazzled trying to track down "type mismatch" errors (I
posted about this maddness earlier).  I can't say whether the lists and dicts
will mature, and be completely robust about handling foolish invocations, but a
trouble shooting section would be helpful in any case.



--- Bill Pursell <bill.pursell@...> wrote:

> Benji Fisher wrote:
> >      You can help!
> >
> >      This request is aimed at anyone on this list who has received
> > valuable advice and wants to repay the vim community.  That includes
> > lurkers!
> >
> >      Vim 7.0 has now started beta testing.  One thing that
> > non-developers, even newbies, can help with before the final release is
> > improving the documentation.
> >
> <snip>

Dominic Evans wrote:

> > > --with-mac-arch=intel
> > >
> > > is broken for me (with latest cvs) it fails to identify a suitable
> > > terminal library and exits with
> > >  You need to install a terminal library; for example ncurses.
> > >       Or specify the name of the library with --with-tlib.])
> > >
> > > --with-mac-arch=both correctly builds a (universal) binary that
> > > runs on intel
> >
> > Strange that "intel" doesn't work then.  Did you try without any
> > argument?  The default now is to build for the current architecture,
> > thus on your system it should build an Intel binary, but does that
> > without any extra compiler arguments.
>
> Yes without argument it fails to detect Intel and just goes for PPC
> compilation.

If you are using a slightly older version, the configure script
accidentally used "-arch ppc" instead of leaving out the -arch argument.
I fixed that, but now CVS doesn't work thus I can't checkin a new
version.

--
"I love deadlines.  I especially like the whooshing sound they
make as they go flying by."
                          -- Douglas Adams

  /// Bram Moolenaar -- Bram@... -- 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://www.ICCF.nl         ///

--- Bill Pursell <bill.pursell@...> wrote:

> Benji Fisher wrote:
> >      You can help!
> >
> >      This request is aimed at anyone on this list who has received
> > valuable advice and wants to repay the vim community.  That includes
> > lurkers!
> >
> >      Vim 7.0 has now started beta testing.  One thing that
> > non-developers, even newbies, can help with before the final release is
> > improving the documentation.
> >
> <snip>
>
> After a total of 30 minutes playing with vim7, I decided to read through
> the documentation on tabpage.  2 things I noticed:
>
> 1)  The introduction begins with: "A tab page holds one or more
> windows."  At this point, it is not entirely clear what these words
> mean.  It might be nice to have a link from here (possibly on the words
> "tab page" and the word "window") to something like the definitions of
> the words "screen", "shell", and "window" that appear in the
> documentation for design-decisions.  This is perhaps not that
> significant, but I think there is potential confusion.

:help windows

1. Introduction 				 *windows-intro*

A window is a viewport onto a buffer.  You can use multiple windows on one
buffer, or several windows on different buffers.

A buffer is a file loaded into memory for editing.  The original file remains
unchanged until you write the buffer to the file.



If you haven't figured out   :help window^D   to expand all possible
completions, then you need to staple it into your bag of tricks.  It's on the
first   :help    page, but until you use it some, it's [huge] value isn't
obvious.

I think the help doc.s lead you through the concepts pretty well.  If you don't
have the patience (i.e. me) to go through the doc.s as they are designed, then
it is up to you to handle the fragmented information stream into your brain.

There are also GUI windows, which refer to the whole running instance.  This
makes sense in the context of the X11 or MSwin envs.

A shell doesn't really belong in the same category as the others.  It refers to
the shell (i.e. sh/csh/etc) that Vim uses to start something outside itself.

>[...]
>
> Also, I'm not sure if this is a result of an improper install (I
> downloaded from the cvs, used 'vim -c make' to build, set VIMRUNTIME to
> the resultant runtime dir, and executed via "vim -u NONE"), but I no
> longer have any history in command mode, and I can't use <CTRL>f to
> enter the command window.
>

Umm, that's because you lost the "history" option by using -u NONE, among other
things.  Getting all those options set (probably for ^f also) is non-trivial,
that's why -u NONE is such a pain.

On 4/1/06, Eric Arnold <eric_p_arnold@...> wrote:
>
> There seems to be a way to "redir" something to all sorts of places but not
> into a buffer.  Am I missing something?  Almost always all I want to do is
suck
> command/message window stuff into a buffer and edit it.  I know it's not that
> hard to use it via the registers, but still....

http://www.vim.org/scripts/script.php?script_id=897
"ViewOutput : scroll back and search [long] output of vim command"

Yakov

Bill Pursell wrote:

> Benji Fisher wrote:
> >      You can help!
> >
> >      This request is aimed at anyone on this list who has received
> > valuable advice and wants to repay the vim community.  That includes
> > lurkers!
> >
> >      Vim 7.0 has now started beta testing.  One thing that
> > non-developers, even newbies, can help with before the final release is
> > improving the documentation.
> >
> <snip>
>
> After a total of 30 minutes playing with vim7, I decided to read through
> the documentation on tabpage.  2 things I noticed:
>
> 1)  The introduction begins with: "A tab page holds one or more
> windows."  At this point, it is not entirely clear what these words
> mean.  It might be nice to have a link from here (possibly on the words
> "tab page" and the word "window") to something like the definitions of
> the words "screen", "shell", and "window" that appear in the
> documentation for design-decisions.  This is perhaps not that
> significant, but I think there is potential confusion.

If you read the docs out-of-order you will miss some terms.  If you
don't know what a window is you really need to read part of the user
manual first.

> 2) he: tabdo  Tabdo is listed in the documentation as not taking a !
> argument, while windo does.   I presume windo! {cmd}  will process cmd
> on all windows, regardless of any errors, but that's not stated in the
> text.  I notice that tabdo! is indeed not legal, and I'm curious to know
> why.  It would be handy if you could continue to process other tabs when
> an error occurs.  (Is that what the '!' on windo does?)

Actually, :windo doesn't use the ! argument.  It's only for :bufdo,
which may need to close the current buffer, which fails if it was
modified.

There is no way for ":somedo" command to continue past an error, except
putting your commands in a try/catch block.

--
A disclaimer for the disclaimer:
"and before I get a huge amount of complaints , I have no control over the
disclaimer at the end of this mail :-)" (Timothy Aldrich)

  /// Bram Moolenaar -- Bram@... -- 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://www.ICCF.nl         ///

On 3/31/06, Bob Hensell <rhensell@...> wrote:
> Please disregard my previous email, and reply to this email, thank you:
>
>
>
> Does anyone have a tip for me?  I am running gvim 6.4 from cygwin on my XP
> machine.  Whenever I try to paste into gvim from another application using
> the middle mouse button, the text gets pasted, but a ^@ also gets appended
> to each line of my text.  Is there something I can put into my .vimrc file?
> I've tried the mswin.vim but that didn't help.  I'm rather new to vim and
> gvim.  I work with UNIX servers all day, so I'm used to vi, but I like the
> script coloring that is available in vim.  Any help would be greatly
> appreciated because as it works now with the appending text, it makes it
> virtually unusable because I do a lot of pasting into my scripts.

:inoremap <MiddleMouse> <MiddleMouse><esc>mz:silent! %s/<c-v>000//g<cr>'za
:noremap <MiddleMouse> <MiddleMouse>mz:silent! %s/<c-v>000//g<cr>'z

Yakov

Hi,

On 4/1/06, Yakov Lerner <iler.ml@...> wrote:
> On 4/1/06, Eric Arnold <eric_p_arnold@...> wrote:
> >
> > There seems to be a way to "redir" something to all sorts of places but not
> > into a buffer.  Am I missing something?  Almost always all I want to do is
suck
> > command/message window stuff into a buffer and edit it.  I know it's not
that
> > hard to use it via the registers, but still....
>
> http://www.vim.org/scripts/script.php?script_id=897
> "ViewOutput : scroll back and search [long] output of vim command"
>

In Vim7, you can scroll back and forth the output of a command at
the more prompt using the following commands:

u - scroll back a page
d - scroll down a page
b - back a screen
<Space> - down a screen
g - Go to the beginning of the output
G - Go to the end of the output

The normal mode command "g<" displays the last page of the
previous command output.

- Yegappan

Bram Moolenaar wrote:
> Bill Pursell wrote:
>
>
>>Benji Fisher wrote:
>>
>>>     You can help!
>>>
>>>     This request is aimed at anyone on this list who has received
>>>valuable advice and wants to repay the vim community.  That includes
>>>lurkers!
>>>
>>>     Vim 7.0 has now started beta testing.  One thing that
>>>non-developers, even newbies, can help with before the final release is
>>>improving the documentation.
>>>
>>
>><snip>
>>
>>After a total of 30 minutes playing with vim7, I decided to read through
>>the documentation on tabpage.  2 things I noticed:
>>
>>1)  The introduction begins with: "A tab page holds one or more
>>windows."  At this point, it is not entirely clear what these words
>>mean.  It might be nice to have a link from here (possibly on the words
>>"tab page" and the word "window") to something like the definitions of
>>the words "screen", "shell", and "window" that appear in the
>>documentation for design-decisions.  This is perhaps not that
>>significant, but I think there is potential confusion.
>
>
> If you read the docs out-of-order you will miss some terms.  If you
> don't know what a window is you really need to read part of the user
> manual first.
>

I know what the terms mean.  I'm simply trying to point out that it may
be useful to have a back reference at that point of the documentation.

>>2) he: tabdo  Tabdo is listed in the documentation as not taking a !
>>argument, while windo does.   I presume windo! {cmd}  will process cmd
>>on all windows, regardless of any errors, but that's not stated in the
>>text.  I notice that tabdo! is indeed not legal, and I'm curious to know
>>why.  It would be handy if you could continue to process other tabs when
>>an error occurs.  (Is that what the '!' on windo does?)
>
>
> Actually, :windo doesn't use the ! argument.  It's only for :bufdo,
> which may need to close the current buffer, which fails if it was
> modified.

Then I would suggest that the documentation for windo not specify an
optional !.  Either that, or tabdo do should allow it (and ignore it)
the same way windo does.  The documentation and behavior should be
consistent.

Is there, could there be a way to have regions defined in the tabline so on a
mouse click they would call user defined functions from arbitrary locations
(i.e. you can add "close" locations, but you can't intercept the click).

I'm thinking the %X thingy could look for a %{func(...) } but evaluate it upon
a click.  With this you could make the tabline much more interestingly useful
in other ways.



A misc. question:  is there a jumplist/nav. system for remembering your tracks
through windows (and tabs) like ^O ?  Similarly, is there a way to get the
A-Z0-9 mark jumps to move to the appropriate window, instead of opening that
buffer in the current window?

Eric Arnold wrote:

> Is there, could there be a way to have regions defined in the tabline
> so on a mouse click they would call user defined functions from
> arbitrary locations (i.e. you can add "close" locations, but you can't
> intercept the click).
>
> I'm thinking the %X thingy could look for a %{func(...) } but evaluate
> it upon a click.  With this you could make the tabline much more
> interestingly useful in other ways.

In general: no.  We now have three GUI tabline implementations (Motif
just added), it would be quite difficult to make this work for all of
them.

I do intend to make the popup menu for the tabline configurable some
day.  I don't have time for it right now.

--
People who want to share their religious views with you
almost never want you to share yours with them.

  /// Bram Moolenaar -- Bram@... -- 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://www.ICCF.nl         ///

Below is a sample of the html code processed by perl's Template.pm, I
will use vim and want to ident lots of unident codes more smartly,
just like external filter program perltidy or html indenting program
tidy, or set any expressing to indent the codes?
my problems are
1) I don't know if there is any this kind of program for template toolkit tidy?
2) if using expressing, I have no idea how to start, any docs?
I read the doc |indent-expression| but I still can't write my own
expression for the template toolkit.

[% FOREACH section = menu %]
    <a href="[% root %]/[% section %]/index.html">[% section %]</a>
[% END %]

<b>Client</a>: [% client.name %] (id: [% client.id %])

[% IF shopcart.nitems %]
    Your shopping cart contains the following items:
    <ul>
    [% FOREACH item = shopcart.contents %]
       <li>[% item.name %] : [% item.qty %] @ [% item.price %]
    [% END %]
    </ul>

    [% checkout(shopcart.total) %]

[% ELSE %]
    No items currently in shopping cart.
[% END %]

--
perl -e 'print unpack(u,"62V5N\"FME;G\!E<FQ`9VUA:6PN8V]M\"\@``
")'

On 2006-03-30, Benji Fisher <benji@...> wrote:

>      Do not neglect the users' manual:
>
> :help toc

One issue with the :help for Vim-7.0 is that that command doesn't
take you where it used to.  It now takes you to the Reference Manual
table of contents rather than the User Manual table of contents.
This is going to confuse people who, out of habit, type ":help toc"
to get to the User Manual.  It's also going to confuse people who
have been told by more experienced users on the vim list and on
comp.editors to use ":help toc" to get to the User Manual and
probably have that command written on a crib sheet.  For those
reasons, I would suggest adding just "toc" to the tags for the User
Manual table of contents.

Further, there is an inconsistency between the tags used for the two
tables of contents.  Since ":help toc" takes you to "ref-toc", upon
realizing your mistake, you might think that ":help user-toc" or
":help usr-toc" would take you where you want to go.  Wrong.  The
tag for the User Manual table of contents is "usr_toc.txt" or
"user-manual".

This illustrates the difference between "readability" and
"searchability" or "learnabilty".  Any of those tags looks
reasonable when you at it.  However, seeing one does not give you
reliable cues for finding the others.

Solving that problem properly would require developing a style for
Vim tags that might include rules for constructing abbreviations and
when to  use them (e.g., "usr" vs. "user") and for combining words
with '-' vs. '_' vs. just running the words together.

I'm not sure how far we or Bram want to take that, but one editing
task ought to be checking for the more obvious inconsistencies such
as the toc tags.

Gary

--
Gary Johnson                 | Agilent Technologies
garyjohn@...     | Wireless Division
                              | Spokane, Washington, USA

Hi Bram,

When a Windows text file does not end with CRLF, vim will consider it
a NOEOL UNIX file, displaying all the CRs. I think this could be
improved. (Though in the Vim way text file should always end with an
EOL, in the Windows world it is often not the case. And it is arguable
whether text files really should end with an EOL on non-POSIX worlds.
BTW, I found the problem because pages on http://www.cnet.com.au/ does
not end with an EOL; I do not think it a good idea to educate the Web
masters.)

Currently I am using Vim 6.4.10.

Best regards,

Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/

"Wu Yongwei" <wuyongwei@...> wrote on 2006.04.03 10:25:28:

> Hi Bram,
>
> When a Windows text file does not end with CRLF, vim will consider it
> a NOEOL UNIX file, displaying all the CRs. I think this could be
> improved. (Though in the Vim way text file should always end with an
> EOL, in the Windows world it is often not the case. And it is arguable
> whether text files really should end with an EOL on non-POSIX worlds.
> BTW, I found the problem because pages on http://www.cnet.com.au/ does
> not end with an EOL; I do not think it a good idea to educate the Web
> masters.)
>
> Currently I am using Vim 6.4.10.
>
> Best regards,
>
> Yongwei
> --
> Wu Yongwei
> URL: http://wyw.dcweb.cn/

I had tested with vim 6.4 but it is not as you'd described. The file not
end with the CR/LF at will be recognized as "NOEOL DOS" file not as you'd
described "NOEOL UNIX" file.

I suggest you check your 'fileformats' settings. My settings were:
set fileformats=unix,mac,dos

Perhaps some other related settings help... Try launch with vim -u NONE and
see if it happens again.

--
Sincerely
Pan, Shizhu. ext: 2221

I'm starting a new program and am planning on writing it as a literate
program.

For those who don't know, a literate program is one where the
documentation and code are interspersed so that the code can read like
a book.  As plain text doesn't allow for much formating a markup
language such as HTML or Tex/Latex is used for the documentation.

So I have a file where HTML and C++ are mixed together which I would
like to have the html and c++ syntax files apply to the html and c++
blocks respectively.  HTML blocks are marked by an '@' followed by a
space or newline and c++ blocks are marked by a line containing only
the text "<<code block>>=".

How can I go about making this work?

Thanks.

--Dave

On Fri, 31 Mar 2006 at 7:13am, Dave Roberts wrote:

> Charles E Campbell Jr wrote:
> > Dave Roberts wrote:
> >
> >> Is it possible to match a pattern only if it does not contain another
> >> specified pattern anywhere in it?
> >>
> >> For example, match a 'foo' followed by a 'bar' as long as there is no
> >> 'dave' between the foo and bar.
> >>
> >> So this foo line matches bar according to dave  (no embedded dave)
> >> but this foo line, according to dave, doesn't match bar. (embedded dave)
> >>
> >> It's easy enough to match if the pattern is in a specific place but
> >> how to match (or not) if the pattern can be anywhere?
> >>
> >> Apologies if this is described right in front of me in "pattern.txt"
> >> - it's getting late...
> >
> >
> > Try LogiPat,
> > http://vim.sourceforge.net/scripts/script.php?script_id=1290 .
> > It provides !, & and | (logical not, logical and, logical or)
> > operators and () for grouping.
> >
> > :LP !"foo.*dave.*bar"
> >
> > Regards,
> > Chip Campbell
> >
>
> I've looked at LogiPat before and it's useful but I'm looking at these
> regular expressions to figure out how to do syntax coloring on a
> complicated multi-line pattern that can have the same start and end
> patterns but differ by embedded patterns that mean something different
> if they themselves have a match or not inside the pattern. I'm getting
> closer using \@! but am still having trouble in one place.
>
> If I can't figure it out I'll post the whole thing eventually to let
> someone else have a crack at at.
>
> Thanks,
>
> - Dave

The way I usually manage with -ve part of the patterns is that I first
search without that and get the matching lines in a separate window, and
further narrow them by remove the lines matching the -ve pattern. This
requires multiple steps, and might not always suit your needs, but it
usually is simple enough. You can use grep to generate errorlist and
work on the error-list window, but I prefer to use my greputils plugin
to redirect the :g/re/p result to a window.

--
HTH,
Hari

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

On 4/3/06, panshizhu@... <panshizhu@...> wrote:
> "Wu Yongwei" <wuyongwei@...> wrote on 2006.04.03 10:25:28:
>
> > Hi Bram,
> >
> > When a Windows text file does not end with CRLF, vim will consider it
> > a NOEOL UNIX file, displaying all the CRs. I think this could be
> > improved. (Though in the Vim way text file should always end with an
> > EOL, in the Windows world it is often not the case. And it is arguable
> > whether text files really should end with an EOL on non-POSIX worlds.
> > BTW, I found the problem because pages on http://www.cnet.com.au/ does
> > not end with an EOL; I do not think it a good idea to educate the Web
> > masters.)
> >
> > Currently I am using Vim 6.4.10.
> >
> > Best regards,
> >
> > Yongwei
> > --
> > Wu Yongwei
> > URL: http://wyw.dcweb.cn/
>
> I had tested with vim 6.4 but it is not as you'd described. The file not
> end with the CR/LF at will be recognized as "NOEOL DOS" file not as you'd
> described "NOEOL UNIX" file.
>
> I suggest you check your 'fileformats' settings. My settings were:
> set fileformats=unix,mac,dos
>
> Perhaps some other related settings help... Try launch with vim -u NONE and
> see if it happens again.

OK, I see that you are right. Check this page: http://www.cnet.com.au/

Although I guess it intends to have Windows line endings, some of its
lines (8 out of 973) end with only LF. Sorry that I did not find it
earlier and not check carefully enough.

If Vim is designed for the mass, I would suggest to add some code to
handle this case. Since I do not think Bram will sacrifice consistency
for this trivia (though it happens a lot), it seems I have to give up
now.

However, I still wonder if there is any room for improvement....

Best regards,

Yongwei

"Wu Yongwei" <wuyongwei@...> wrote on 2006.04.03 12:49:31:
> OK, I see that you are right. Check this page: http://www.cnet.com.au/
>
> Although I guess it intends to have Windows line endings, some of its
> lines (8 out of 973) end with only LF. Sorry that I did not find it
> earlier and not check carefully enough.
>
> If Vim is designed for the mass, I would suggest to add some code to
> handle this case. Since I do not think Bram will sacrifice consistency
> for this trivia (though it happens a lot), it seems I have to give up
> now.
>
> However, I still wonder if there is any room for improvement....
>
> Best regards,
>
> Yongwei


IMO the improvement may be: write autocommand script to cope with this?

i.e. automatically remove all the ^M if a buffer opend with ff=unix ?

In the Unix world, the program should provide mechanism, not policy. So it
is unlikely that the feature be supplied inside vim executable, but the
run-control scripts could do the job if you wish.

--
Sincerely
Pan, Shizhu. ext: 2221

Dear all, would it be possible to configure :grep to search
case-insensitive filenames? Any help will be great!

On 4/1/06, Edward Wong <plwong@...> wrote:
> Today I just find out an interesting issue... when I uses grep it
> treats the filenames as case sensitive, even when I include the '-i'
> flag....but when I do grep in shell it works, because I configure
> cygwin to be case insensitive like dos.
>
> I'm now working with projects in dos with my co-workers....and
> sometimes they name the files in capital, and some don't. Also, I
> often need to grep generated files that the file names contain capital
> letters. Is there a way to configure grep in vim?
>
> PS: vimgrep works perfectly fine, but grep is faster.
>
> -- Ed
>

"Edward Wong" <plwong@...> wrote on 2006.04.03 13:36:38:
> On 4/1/06, Edward Wong <plwong@...> wrote:
> > Today I just find out an interesting issue... when I uses grep it
> > treats the filenames as case sensitive, even when I include the '-i'
> > flag....but when I do grep in shell it works, because I configure
> > cygwin to be case insensitive like dos.
> >
> > I'm now working with projects in dos with my co-workers....and
> > sometimes they name the files in capital, and some don't. Also, I
> > often need to grep generated files that the file names contain capital
> > letters. Is there a way to configure grep in vim?
> >
> > PS: vimgrep works perfectly fine, but grep is faster.
> >
> > -- Ed
> >

Are you sure you've tried to set ignorecase in VIM?

My grep works with mixed-case filename without problem.

--
Sincerely
Pan, Shizhu. ext: 2221

I want to call HTML completion on my own plugin.

I use the following code :


	     let l:st1 = htmlcomplete#CompleteTags(1,'')
              if ( l:st1>= 0 )
                  let l:str1 = getline('.')
                  let l:str2 = strpart(l:str1,l:st1,col('.')-l:st1)
                  return htmlcomplete#CompleteTags(0,l:str2)
              else
                  return ""
              endif

When I use a <c-x><c-u> to invoke this call .

I receive a E745 message.

Can anyone help me ?

Ok I did a bit more testing.

1) I have a generated file named PDA.SS and PDA.S10
2) in .vimrc, set grepprg=grep\ -Hn
3) using cygwin as shell

When I attempted to search a variable in PDA.SS and PDA.S10 I realized
the followings:

grep -i variable PDA.SS -> works
grep -i variable pda.ss   -> works
grep -i variable *.SS      -> works
grep -i variable PDA.*    -> works
grep -i variable *.ss       -> doesn't work
grep -i variable pda.*      -> doesn't work
grep -i variable *.*          -> works

grep -i variable PDA.S10 -> works
grep -i variable pda.s10   -> works
grep -i variable *.*10        -> works
grep -i variable *.s10       -> doesn't work

So it seems like :grep doesn't work as expected when I search file
patterns that contain combination of "*" and "letters with wrong
capital values". Basically it DOESN'T "ignorecase" when "*" presents.
However, I often needs to grep sth like *.s*, or pda.* for example.

Any idea?


On 4/3/06, panshizhu@... <panshizhu@...> wrote:
> "Edward Wong" <plwong@...> wrote on 2006.04.03 13:36:38:
> > On 4/1/06, Edward Wong <plwong@...> wrote:
> > > Today I just find out an interesting issue... when I uses grep it
> > > treats the filenames as case sensitive, even when I include the '-i'
> > > flag....but when I do grep in shell it works, because I configure
> > > cygwin to be case insensitive like dos.
> > >
> > > I'm now working with projects in dos with my co-workers....and
> > > sometimes they name the files in capital, and some don't. Also, I
> > > often need to grep generated files that the file names contain capital
> > > letters. Is there a way to configure grep in vim?
> > >
> > > PS: vimgrep works perfectly fine, but grep is faster.
> > >
> > > -- Ed
> > >
>
> Are you sure you've tried to set ignorecase in VIM?
>
> My grep works with mixed-case filename without problem.
>
> --
> Sincerely
> Pan, Shizhu. ext: 2221
>
>
>
>
>
>

On 4/3/06, Edward Wong <plwong@...> wrote:
> When I attempted to search a variable in PDA.SS and PDA.S10 I realized
> the followings:
[snip]
> So it seems like :grep doesn't work as expected when I search file
> patterns that contain combination of "*" and "letters with wrong
> capital values". Basically it DOESN'T "ignorecase" when "*" presents.
> However, I often needs to grep sth like *.s*, or pda.* for example.
>
> Any idea?

I might be wrong, but it seems to me that you're barking up the wrong
tree, here.  If you're using an external grep program then neither Vim
nor grep itself can influence which files it sees when you provide a
wildcard argument.  Expanding filename wildcards to proper name lists
is the responsibility of the shell, not Vim nor grep.  Your tests seem
to indicate that you have a case-insensitive file system (i.e.
providing a full name of the wrong case works), but not a
case-insensitive shell (i.e. wildcards are matched in case-sensitive
manner against the file names read from the file system).

You might be able to work around this by using the find command and
piping the resulting list of filenames to to grep.  Alternately, your
cygwin shell may include some configuration system which allows you to
change the globbing behaviour.  (Note that this paragraph is
speculation.)

HTH,
Chris Allen

"Edward Wong" <plwong@...> wrote on 2006.04.03 15:03:36:
> Ok I did a bit more testing.
>
> 1) I have a generated file named PDA.SS and PDA.S10
> 2) in .vimrc, set grepprg=grep\ -Hn
> 3) using cygwin as shell
>
> When I attempted to search a variable in PDA.SS and PDA.S10 I realized
> the followings:
>
> grep -i variable PDA.SS -> works
> grep -i variable pda.ss   -> works
> grep -i variable *.SS      -> works
> grep -i variable PDA.*    -> works
> grep -i variable *.ss       -> doesn't work
> grep -i variable pda.*      -> doesn't work
> grep -i variable *.*          -> works
>
> grep -i variable PDA.S10 -> works
> grep -i variable pda.s10   -> works
> grep -i variable *.*10        -> works
> grep -i variable *.s10       -> doesn't work
>
> So it seems like :grep doesn't work as expected when I search file
> patterns that contain combination of "*" and "letters with wrong
> capital values". Basically it DOESN'T "ignorecase" when "*" presents.
> However, I often needs to grep sth like *.s*, or pda.* for example.
>
> Any idea?

Have you tried that in your BASH prompt? My result are below:

pansz-pc:~$ grep fad test1.txt
adfadfaf
pansz-pc:~$ grep fad test1.TXT
adfadfaf
pansz-pc:~$ grep fad *.TXT
grep: *.TXT: No such file or directory
pansz-pc:~$ grep fad *.txt
test1.txt:adfadfaf
pansz-pc:~$

Remember that the GREP itself cannot expand "*.txt", *.txt are expanded by
BASH shell, NOT the GREP, so you may want to seek some help from your shell
(in cygwin it should be /bin/bash or /bin/sh).

--
Sincerely
Pan, Shizhu. ext: 2221

Which regular expression would match 3 words (w1,w2,w3)
in any order with anything between them withinh 1 paragragh ?
For example:

... w2 ..... w3 .... w1 .... -- paragraph matches.

... w3 ...w3  ..... w2..  w1.... w1 ... w2 .... -- paragraph matches.

... w1 ... w3 ... - paragraph does not match

Thanks
Yakov

On 4/3/06, panshizhu@... <panshizhu@...> wrote:
> "Edward Wong" <plwong@...> wrote on 2006.04.03 15:03:36:
> > Ok I did a bit more testing.
> >
> > 1) I have a generated file named PDA.SS and PDA.S10
> > 2) in .vimrc, set grepprg=grep\ -Hn
> > 3) using cygwin as shell
> >
> > When I attempted to search a variable in PDA.SS and PDA.S10 I realized
> > the followings:
> >
> > grep -i variable PDA.SS -> works
> > grep -i variable pda.ss   -> works
> > grep -i variable *.SS      -> works
> > grep -i variable PDA.*    -> works
> > grep -i variable *.ss       -> doesn't work
> > grep -i variable pda.*      -> doesn't work
> > grep -i variable *.*          -> works
> >
> > grep -i variable PDA.S10 -> works
> > grep -i variable pda.s10   -> works
> > grep -i variable *.*10        -> works
> > grep -i variable *.s10       -> doesn't work
> >
> > So it seems like :grep doesn't work as expected when I search file
> > patterns that contain combination of "*" and "letters with wrong
> > capital values". Basically it DOESN'T "ignorecase" when "*" presents.
> > However, I often needs to grep sth like *.s*, or pda.* for example.
> >
> > Any idea?
>
> Have you tried that in your BASH prompt? My result are below:
>
> pansz-pc:~$ grep fad test1.txt
> adfadfaf
> pansz-pc:~$ grep fad test1.TXT
> adfadfaf
> pansz-pc:~$ grep fad *.TXT
> grep: *.TXT: No such file or directory
> pansz-pc:~$ grep fad *.txt
> test1.txt:adfadfaf
> pansz-pc:~$

bash has 'nocaseglob' option. Excerpt from 'man bash':
   nocaseglob
                       If  set,  bash  matches  filenames in a case-insensitive
                       fashion when performing pathname expansion (see Pathname
                       Expansion above).
tcsh has similar option

Yakov

On Mon, 3 Apr 2006, Yakov Lerner wrote:

> Which regular expression would match 3 words (w1,w2,w3)
> in any order with anything between them withinh 1 paragragh ?
> For example:
>
> ... w2 ..... w3 .... w1 .... -- paragraph matches.
>
> ... w3 ...w3  ..... w2..  w1.... w1 ... w2 .... -- paragraph matches.
>
> ... w1 ... w3 ... - paragraph does not match

Would this do it?

    /.*w1\&.*w2\&.*w3

--
Gerald

In fact, it is not "in the Windows world", but rather "in the badly behaved
editors world". You see, Openoffice, MS Office, and I think even Notepad all
correctly use EOLs where they should be, and Eclipse, ZDE, and I think Scipe
(on all platforms - at least linux) incorrectly leave out the last EOL.

Traditionally, each line in a text file is terminated by the EOL sequence, no
matter the platform, and I think older (perhaps current?) versions of fgets in
C do not recognise a full line until it sees the EOL sequence (I could be wrong
about the specifics - it's years since I did any C programming - but I did read
that people encountered problems when processing 'incorrectly' terminated text
files). There are other problems with leaving out the last EOL in text files.
As well as concatenation, imagine you are processing a stream, line by line.
How do you know whether the last line is valid without an EOL? Maybe the stream
was interrupted or terminated by or for an error, etc. or maybe just that line
was interrupted.

If a text file does not end with EOL, how is vim to know whether this really is
a text file or just a binary file that happens to contain a suspicious amount
of ASCII and CR or CRLFs? It is best that vim tell you what is going on, rather
than assume one way or the other, the way the 'file' command does on a single
unterminated line ("ASCII text, with no line terminators").

See http://slashdot.org/comments.pl?sid=165492&cid=13808398 for more.

So you see, vim is doing exactly as it should when it encounters these corrupt
'text' files :)

You encountered this issue when viewing the source of a web page. I believe
this is a non-issue. You are opening up a file in your text editor that was
meant to be parsed by web browsers, which happen to ignore whitespace and other
formatting. Indeed you should not "educate the web masters". They have their
own editors and IDEs. Telling them that you have a problem when opening their
web server's output in your editor will, I believe, only serve to provide a
source of amusement.

On Mon, 3 Apr 2006, Wu Yongwei wrote:

> Hi Bram,
>
> When a Windows text file does not end with CRLF, vim will consider it
> a NOEOL UNIX file, displaying all the CRs. I think this could be
> improved. (Though in the Vim way text file should always end with an
> EOL, in the Windows world it is often not the case. And it is arguable
> whether text files really should end with an EOL on non-POSIX worlds.
> BTW, I found the problem because pages on http://www.cnet.com.au/ does
> not end with an EOL; I do not think it a good idea to educate the Web
> masters.)
>
> Currently I am using Vim 6.4.10.
>
> Best regards,
>
> Yongwei
> --
> Wu Yongwei
> URL: http://wyw.dcweb.cn/
>

--
.