include new line chars in .*

18 views
Skip to first unread message

Robert Mark Bram

unread,
Dec 11, 2008, 2:54:14 AM12/11/08
to vim_use
Hi All,

I am using using TagList for ANT build files as per
http://vim.wikia.com/wiki/Using_TagList_for_ANT_build_files

To pick up targets, I am using:
--regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)".*>/\1/t,target/i

The problem is this will only pick up targets where the opening tag is
all on one line. For example, it will pick up
<target name="clean" depends="init" description="...">
but not
<target name="clean"
depends="init"
description="...">

Can anyone guide me as to how I can modify the ".*" in the above
expression to deal with new line chars too?

Thanks for any assistance!

Rob
:)

Jürgen Krämer

unread,
Dec 11, 2008, 3:24:24 AM12/11/08
to vim...@googlegroups.com
Hi,

Robert Mark Bram wrote:
>
> Can anyone guide me as to how I can modify the ".*" in the above
> expression to deal with new line chars too?

just prefix it with "\_", i.e., make it "\_.*".

And you probably want to put backslashes before "(", ")", and "+".

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

Tony Mechelynck

unread,
Dec 11, 2008, 3:39:20 AM12/11/08
to vim...@googlegroups.com
On 11/12/08 09:24, Jürgen Krämer wrote:
> Hi,
>
> Robert Mark Bram wrote:
>> Can anyone guide me as to how I can modify the ".*" in the above
>> expression to deal with new line chars too?
>
> just prefix it with "\_", i.e., make it "\_.*".
>
> And you probably want to put backslashes before "(", ")", and "+".
>
> Regards,
> Jürgen
>

Yes, and beware that the star multi is greedy, i.e., if you have several
matched begin- and end-patterns in the file, begin\_.*end will always
match with the _last_ "end" in the file, gobbling up any number of
begin-end blocks in between. \_.{-} will match as few of "anything
including a line break" as possible, which might be better suited to
your needs here. See ":help /multi".


Best regards,
Tony.
--
The debate rages on: Is PL/I Bachtrian or Dromedary?

Robert Mark Bram

unread,
Dec 11, 2008, 9:03:42 AM12/11/08
to vim_use
Thank you Tony and Jürgen,

> > Robert Mark Bram wrote:
> >> Can anyone guide me as to how I can modify the ".*" in the above
> >> expression to deal with new line chars too?
>
> > just prefix it with "\_", i.e., make it "\_.*".

This one resulted in no targets being identified.

--regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)"\_.*>/\1/t,target/i

> > And you probably want to put backslashes before "(", ")", and "+".

The plugin must be handling the RE differently, because the
backslashes broke the search i.e. no targets were identified with
this:--regex-ant=/^[ \t]*<[ \t]*target.*name="\([^<"&]\+\)".*>/\1/
t,target/i

> Yes, and beware that the star multi is greedy, i.e., if you have several
> matched begin- and end-patterns in the file, begin\_.*end will always
> match with the _last_ "end" in the file, gobbling up any number of
> begin-end blocks in between. \_.{-} will match as few of "anything
> including a line break" as possible, which might be better suited to
> your needs here. See ":help /multi".

This one resulted in the same i.e. no targets identified.

--regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)"\_.{-}>/\1/t,target/
i


Rob
:)

fritzophrenic

unread,
Dec 11, 2008, 10:51:44 AM12/11/08
to vim_use


On Dec 11, 2:24 am, Jürgen Krämer <jottka...@googlemail.com> wrote:
>
> just prefix it with "\_", i.e., make it "\_.*".
>
> And you probably want to put backslashes before "(", ")", and "+".
>

Except that the regex in question is being passed to ctags, not being
parsed by Vim.

I'm not sure where to find documentation about Ctags' regex
syntax...I'm sure there's some online documentation somewhere though.

David Fishburn

unread,
Dec 11, 2008, 11:09:04 AM12/11/08
to vim...@googlegroups.com
On 12/11/08, Robert Mark Bram <robertm...@gmail.com> wrote:
>
> Hi All,
>
> I am using using TagList for ANT build files as per
> http://vim.wikia.com/wiki/Using_TagList_for_ANT_build_files
>
> To pick up targets, I am using:
> --regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)".*>/\1/t,target/i
>
> The problem is this will only pick up targets where the opening tag is
> all on one line. For example, it will pick up
> <target name="clean" depends="init" description="...">
> but not
> <target name="clean"
> depends="init"
> description="...">

The problem with the suggestions from others is this is NOT a vim regex.
This is executed by ctags.exe, so you have to use Perl reg
expressions, not Vim ones.

Maybe the ones provided do work with Perl, but I don't think so.

I am not certain what the equivalent of Vim's \_.* is in Perl. Anyone?


As an alterative, do you really need to scan up to the closing >?

Just remove the closing > in the pattern.
--langdef=ant
--langmap=ant:.xml
--regex-ant=/^[ \t]*<[ \t]*project.*name="([^"]+)".*/\1/p,project/i
--regex-ant=/^[ \t]*<[ \t]*target.*name="([^"]+)".*/\1/t,target/i

And that should probably do it.
If so, let me know and I will update the Tip.

Dave

Erik Falor

unread,
Dec 11, 2008, 11:10:33 AM12/11/08
to vim...@googlegroups.com
On Thu, Dec 11, 2008 at 11:09:04AM -0500, David Fishburn wrote:

> I am not certain what the equivalent of Vim's \_.* is in Perl. Anyone?

The equivalent in Perl is to supply the s flag to the match.
i.e. "\n" =~ m/./s;

--
Erik Falor
Registered Linux User #445632 http://counter.li.org

Gary Johnson

unread,
Dec 11, 2008, 12:06:24 PM12/11/08
to vim...@googlegroups.com
On 2008-12-11, David Fishburn wrote:
> On 12/11/08, Robert Mark Bram <robertm...@gmail.com> wrote:
> >
> > Hi All,
> >
> > I am using using TagList for ANT build files as per
> > http://vim.wikia.com/wiki/Using_TagList_for_ANT_build_files
> >
> > To pick up targets, I am using:
> > --regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)".*>/\1/t,target/i
> >
> > The problem is this will only pick up targets where the opening tag is
> > all on one line. For example, it will pick up
> > <target name="clean" depends="init" description="...">
> > but not
> > <target name="clean"
> > depends="init"
> > description="...">
>
> The problem with the suggestions from others is this is NOT a vim regex.
> This is executed by ctags.exe, so you have to use Perl reg
> expressions, not Vim ones.
>
> Maybe the ones provided do work with Perl, but I don't think so.

On my system, "man ctags" for version 5.5.4 says nothing about
Perl--it says it uses Posix extended regular expressions, "roughly
that used by egrep(1)".

Regards,
Gary

David Fishburn

unread,
Dec 11, 2008, 12:24:15 PM12/11/08
to vim...@googlegroups.com
On 12/11/08, Gary Johnson <gary...@spk.agilent.com> wrote:
...
>> The problem with the suggestions from others is this is NOT a vim regex.
>> This is executed by ctags.exe, so you have to use Perl reg
>> expressions, not Vim ones.
>>
>> Maybe the ones provided do work with Perl, but I don't think so.
>
> On my system, "man ctags" for version 5.5.4 says nothing about
> Perl--it says it uses Posix extended regular expressions, "roughly
> that used by egrep(1)".

Poor choice of words, I said Perl meaning the "default standard".

So, really based on Erik's response, what we need to find is a
compatible egrep regex to span multiple lines.

The alternative is to ignore the closing brace, but we still could
potentially run into cases where the tag name is on a different line
from the initial brace. So, the proper solution is a complete egrep
regex.

Dave

Robert Mark Bram

unread,
Dec 11, 2008, 7:02:42 PM12/11/08
to vim_use
Hi David

> The alternative is to ignore the closing brace, but we still could
> potentially run into cases where the tag name is on a different line
> from the initial brace.  So, the proper solution is a complete egrep
> regex.

This is good enough for me.

--regex-ant=/^[ \t]*<[ \t]*target.*name="([^<"&]+)".*/\1/t,target/i

I am happy to live the condition that I write my targets with name on
the first line. :)

Compared to making a more powerful grep statement that will scan past
line terminators, do you think there is much in the way of a
performance issue?

Thank you again to everyone for your thoughts and help!

Rob
:)
Reply all
Reply to author
Forward
0 new messages