Fwd: Vim MacPorts support

Maximilian Nickel mnick at macports.org
Thu Jul 23 12:19:31 PDT 2009


Fwding since i forgot to press reply all....


---------- Forwarded message ----------
From: Maximilian Nickel <mnick at macports.org>
Date: Thu, Jul 23, 2009 at 9:18 PM
Subject: Re: Vim MacPorts support
To: Rainer Müller <raimue at macports.org>


Rainer Müller wrote:
> We could either always print line numbers or add a --line-numbers switch
> to port lint.

Both options are fine for me. Some statements in lint already print
linenumbers btw, just the
errors and warning are missing it.

> But note that some messages lint reports are about missing statements or
> variables. What should the format be like if there is no line number to
> print?

It's ok if some messages don't report linenumbers. vim's errorformat
accepts multiple formats,
so we can just supply a parse-string for both and let vim do the rest.

>> Anyway, if you want to check it out, you can get the source with "svn
>> co https://svn.macports.org/repository/macports/users/mnick/macports.vim"
>> Just copy everything in that directory into your ~/.vim directory and
>> you should be set
>
> Are we allowed to also make changes? :-)

Sure, go ahead :)

> I suggest to move that to contrib/, as there is also already a language
> module for BBEdit/TextWrangler. Would probably make sense to move these
> into contrib/editors/ to keep some logical grouping. User directories
> are the private area in the repo and I don't like editing there.

Fine for me, i just thought the best starting point would be my user dir

>> I've not yet decided how to exactly color the syntax, so if you have
>> suggestions i'd be happy to hear them, along with any other
>> suggestions.
>
> Some phases and common options are missing yet (tests.* and livecheck.*).
Yes i didnt get around to add them yet. I didnt find a way to
automatically create some
of the regex's (like -append/delete), as vim's only accepts something
like syn match "some_string"
and not something like syn match fun("some_string"), so it's a lot of
manual work.

> But do we really want to list each and every port option or would it be
> enough to color anything that starts with the name of a phase followed
> by a dot (${phase}.*), depends_*, use_* and the usual port options like
> name, version, maintainer, etc.?

Yes, i started with that too. I switched to the more precise coloring
since i see syntax coloring also as an easy way to avoid
typo's. And typos can and, in some cases, are even more likely to
occur in the * part. We could just color for example
depends_ but this looks awkward imo. And coloring the whole depends_*
string even when it's not correct syntax seemed wrong to me too.

I will not be able to work on this much the next days, so just apply
the changes you feel are necessary if you like.

Cheers,
Max

P.S. For those using snipMate
(http://www.vim.org/scripts/script.php?script_id=2540). Some other
thing i'd like to add is snippets support. Something like new<Tab>
will create a Portfile skeleton in the buffer. variant<Tab> creates a
variant skeleton etc.


More information about the macports-dev mailing list